One document matched: draft-schaad-plasma-service-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "bibxml/reference.RFC.2119.xml" >
<!ENTITY getPolicyRequest SYSTEM "ForDraft/getPolicyRequest">
<!ENTITY getPolicyResponse SYSTEM "ForDraft/getPolicyResponse">
<!ENTITY sendMessageRequest SYSTEM "ForDraft/sendMessageRequest">
<!ENTITY sendMessageResponse SYSTEM "ForDraft/sendMessageResponse">
<!ENTITY readMessageRequest SYSTEM "ForDraft/readMessageRequest">
<!ENTITY readMessageResponse SYSTEM "ForDraft/readMessageResponse">
<!ENTITY SOAP11 SYSTEM "bibxml4\reference.w3c.note-soap-20000508.xml">
<!ENTITY SOAP12 SYSTEM "bibxml4\reference.w3c.rec-soap12-part1-20070427.xml">
<!ENTITY XML-DIGSIG SYSTEM "bibxml4\reference.w3c.REC-xmldsig-core-20080610.xml">
<!ENTITY XML-C14N11 SYSTEM "bibxml4\reference.w3c.REC-xml-c14n11-20080502.xml">
<!ENTITY PlasmaSchema SYSTEM "ForDraft/Plasma.xsd.incl">
<!ENTITY RequestSchema SYSTEM "ForDraft/requestSchema">
<!ENTITY ResponseSchema SYSTEM "ForDraft/responseSchema">
<!ENTITY AuthenticationType SYSTEM "ForDraft/AuthenticationType">
<!ENTITY PlasmaTokensSchema SYSTEM "ForDraft/PlasmaTokensSchema">
<!ENTITY RequestMessageData SYSTEM "ForDraft/RequestMessageData">
<!ENTITY GetRoleRequestExample SYSTEM "ForDraft/GetRoleRequest.xml.incl">
<!ENTITY GetRoleResponseExample SYSTEM "ForDraft/Get-Role-Response.xml.incl">
<!ENTITY GetTokenRequestExample SYSTEM "ForDraft/Get-Token-Request.xml.incl">
<!ENTITY GetTokenResponseExample SYSTEM "ForDraft/Get-Token-Response.xml.incl">
<!ENTITY GetKeyRequestExample SYSTEM "ForDraft/Get-Key-Request.xml.incl">
<!ENTITY GetKeyResponseExample SYSTEM "ForDraft/Get-Key-Response.xml.incl">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xlst' ?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc comments="yes"?>
<rfc category="std" docName="draft-schaad-plasma-service-00" ipr="trust200902">
<front>
<title abbrev="EPS TRUST">Email Policy Service Trust Processing</title>
<author fullname="Jim Schaad" initials="J." surname="Schaad">
<organization>Soaring Hawk Consulting</organization>
<address>
<email>ietf@augustcellars.com</email>
</address>
</author>
<date/>
<abstract>
<t>Write Me</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="XML Nomenclature and Name Spaces">
<t>The following name spaces are used in this document:</t>
<texttable>
<ttcol>Prefix</ttcol><ttcol> Namespace</ttcol><ttcol> Specification(s)</ttcol>
<c>eps</c><c>http://ietf.org/2011/plasma/</c><c>This Specification</c>
<c>S11</c><c>http://schemas.xmlsoap.org/soap/envelope/</c><c><xref target="SOAP11"/></c>
<c>S12</c><c> http://www.w3.org/2003/05/soap-envelope</c><c><xref target="SOAP12"/></c>
<c>wst</c><c> http://docs.oasis-open.org/ws-sx/ws-trust/200512</c><c><xref target="WS-TRUST"/></c>
<c>wsu</c><c> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd</c><c> [WS-Security]</c>
<c>wsse</c><c> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd</c><c> [WS-Security]</c>
<c>wsse11</c><c> http://docs.oasis-open.org/wss/oasis-wss-wsecurity-secext-1.1.xsd</c><c> [WS-Security]</c>
<c>xacml</c><c>http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.html</c><c><xref target="XACML"/></c>
<c>ds</c><c> http://www.w3.org/2000/09/xmldsig#</c><c><xref target="XML-Signature"/></c>
<c>xenc</c><c> http://www.w3.org/2001/04/xmlenc#</c><c> [XML-Encrypt]</c>
<c>wsp</c><c> http://schemas.xmlsoap.org/ws/2004/09/policy</c><c> [WS-Policy]</c>
<c>wsa</c><c> http://www.w3.org/2005/08/addressing</c><c> [WS-Addressing]</c>
<c>xs</c><c> http://www.w3.org/2001/XMLSchema</c><c> [XML-Schema1][XML-Schema2]</c>
</texttable>
</section>
<section title="Requirements Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Components">
<section title="WS-Trust 1.3">
<t>We use WS-Trust as the basis for the protocol presented in this document. WS-Trust is a secure messaging protocol used for security token exchange to enable the issuance and dissemination of credentials within different trust domains. WS-Trust 1.3 is specified by OASIS in <xref target="WS-TRUST"/>. WS-Trust is built on SOAP (see <xref target="SOAP12"/>) to provide a messaging structure.</t>
</section>
<section title="XACML 3.0">
<t>The XACML specification (eXtensible Access Control Markup Language)<xref target="XACML"/> provides a framework for writing both access control policies and access control queries and responses. </t>
</section>
</section>
<section title="Model" anchor="model">
<t>To be supplied from the problem statement document. <cref source="Brian">Should one be able to create a policy on the fly for specific item where a set of attributes can be defined by the sender of the message.</cref></t>
<figure align="center" title="Message Access Control Actors" anchor="fig1"><artwork><![CDATA[
(1)(3) +----------+
+----------->|Sending |<------------+
| |Agent | |
(2) v +----------+ v
+----------+ ^ +---------+
|Email | | |Mail |
|Policy |<----------+ |Transfer |
|Service | |Agent |
+----------+ +---------+
() ^ +----------+ ^
| |Receiving | |
+----------->|Agent |<------------+
()() +----------+
]]></artwork></figure>
<t>List the boxes above and give some info about them.
<list style="hanging">
<t hangText="Email Policy Service"> is the gateway controller for accessing a message. Although it is represented as a single box in the diagram, there is no reason for it to be in practice. Each of the three protocols could be talking to different instances of a common system. This would allow for a server to operated by Company A, but be placed in Company B's network thus reducing the traffic sent between the two networks.</t>
<t hangText="Mail Transfer Agent"> is the entity or set of entities that is used to move the message from the sender to the receiver. Although this document describes the process in terms of mail, any method can be used to transfer the message.</t>
<t hangText="Receiving Agent"> is the entity that consumes the message.</t>
<t hangText="Sending Agent"> is the entity that originates the message.</t>
</list>
</t>
<section title="Sender Processing">
<t>We layout the general steps that need to be taken by the sender of an EPS message. The numbers in the steps below refer to the numbers in the upper half of <xref target="fig1"/>. A more detailed description of the processing is found in <xref target="getPolicy"/> for obtaining the security policies that can be applied to a messages and <xref target="sendMessage"/> for sending a message. </t>
<t>
<list style="numbers">
<t>The Sending Agent sends a message to one or more Email Policy Services in order to obtain the set of policies that it can apply to a message along with a security token to be used in proving the authorization. Details of the message send can be found in <xref target="getPolicy-Request"/>.</t>
<t>The Email Policy Service examines the set of policies that it understands and checks to see if the requester is authorized to send messages with the policy.</t>
<t>The Email Policy Service returns the set of policies and an security token to the Sending Agent. Details of the message sent can be found in <xref target="getPolicy-Response"/>.</t>
<t>The Sending Agent selects the Email Policy(s) to be applied to the message, along with the set of recipients for the message.</t>
<t>The Sending Agent relays the selected information to the Email Policy Service along with the security token. Details of this message can be found in <xref target="sendMessage-Request"/>.</t>
<t>The Email Policy Service creates the recipient info attribute as defined in <xref target="EPS-CMS"/>.</t>
<t>The Email Policy Service returns the created attribute to the Sending Agent. Details of this message can be found in <xref target="sendMessage-Response"/>.</t>
<t>The Sending Agent composes the CMS EnvelopedData content type placing the returned attribute into a KEKRecipientInfo structure and then send the message to the Mail Transport Agent.</t>
</list>
</t>
</section>
<section title="Recieving Agent Processing">
<t>We layout the general steps that need to be taken by the sender of an EPS message. The numbers in the steps below refer to the numbers in the lower half of <xref target="fig1"/>. A more detailed description of the processing is found in <xref target="readMessage"/>.</t>
<t>
<list style="numbers">
<t>The Receiving Agent obtains the message from the Mail Transport Agent.</t>
<t>The Receiving Agent starts to decode the message and in that process locates an EvelopedData content type which has a KEKRecipientInfo structure with a XXXX attribute.</t>
<t>The Receiving Agent processes the SignedData content of the XXXX attribute to determine that communicating with it falls within accepted policy.</t>
<t>The Receiving Agent transmits the content of the XXXX attribute to the referenced Email Policy Service. The details of this message can be found in <xref target="readMessage-Request"/>.</t>
<t>The Email Policy Service decrypts the content of the message and applies the policy to the credentials provided by the Receiving Agent.</t>
<t>If the policy passes, the Email Policy Service returns the appropriate key or RecipientInfo structure to the Receiving Agent. Details of this message can be found in <xref target="readMessage-Response"/>.</t>
<t>The Receiving Agent proceeds to decrypt the message and perform normal processing.</t>
</list>
</t>
</section>
</section>
<section title="Plasma Request">
<t>There is a single top level structure that is used by a client to send a request to the server.</t>
<t>The XML Schema used to describe the top level request is as follows:</t>
&RequestSchema;
<t>A Plasma Request will have two elements in it:
<list style="hanging">
<t hangText="Authentication">is an optional element that contains the various methods of authentication that are available for use.</t>
<t hangText="xacml:Request">is an optional element that contains the control information for a what is happening. This element is taken from the XACML specification.</t>
</list>
</t>
<section title="Authentication Element">
<t>The authentication type is used to carry information about the different ways that the Plasma server will allow for authentication to occur. More than one authentication field can be filled in when sending message to the server. If more than one authentication field is set, then the server can select which fields are to be used. More than one field can be used.</t>
&AuthenticationType;
<t>The fields of this element are:
<list style="hanging">
<t hangText="SAML_Collection">holds a sequence of one or more SAML assertions. These assertions can contain statements about attributes or keys for the requester.</t>
<t hangText="GSS_API"> holds a GSS-API message object. This message object will normally be using the GSS-API/EAP method defined by <xref target="ABFAB"/>.</t>
<t hangText="WS_Token"> holds a WS-Token obtained from some source. The most common source for a WS-Token to be obtained from will be from a previous conversation with a Plasma server. For example, one or more WS-Tokens will be returned from a Get Roles dialog.</t>
</list>
</t>
</section>
<section title="xacml:Request Element">
<t>We use the xacml:Request element for creating the access control request of the Plasma Server. When the request element is present, one will normally have an attribute from the urn:oasis:names:tc:xacml:3.0:attribute-category. This document defines a set of actions to be used with the server.</t>
<t>Additional attributes can be added to the request as well. These attributes can help control what is happening to the message and provide additional data to the request. When attributes are to be provided in an authenticated manner, then they must be provided in a different manner than being placed here. Unless self-assertion is considered sufficient.</t>
<t>For convenience the schema for the xacml:Request element is reproduced here:</t>
<figure><artwork><![CDATA[
<xs:element name="Request" type="xacml:RequestType"/>
<xs:complexType name="RequestType">
<xs:sequence>
<xs:element ref="xacml:RequestDefaults" minOccurs="0"/>
<xs:element ref="xacml:Attributes" maxOccurs="unbounded"/>
<xs:element ref="xacml:MultiRequests" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="ReturnPolicyIdList" type="xs:boolean" use="required"/>
<xs:attribute name="CombinedDecision" type="xs:boolean" use="required"/>
</xs:complexType>
]]></artwork></figure>
<t>The use of the RequestDefaults and MultiRequest elements is possible, but will generally not be supported.</t>
</section>
</section>
<section title="Plasma Response Element">
<t>There is a single top level structure that is used by the server to respond to a client request.</t>
<t>The XML Schema used to describe the top level response is as follows:</t>
&ResponseSchema;
<t>A Plasma Response has three elements used:
<list style="hanging">
<t hangText="xacml:Response"> is a mandatory element that returns the status of the access request.</t>
<t hangText="PlasmaTokens"> is an optional element that will return one or more PlasmaToken elements. </t>
<t hangText="CMSToken"> is an optional element that contains the CMS Token that is included in a CMS message as part of a recipient info element.</t>
<t hangText="CMSKey"> is an optional element that contains the key to be used in decrypting a CMS message.</t>
<t hangText="Authentication"> return a GSS-API element as part of a GSS-API authentication process. Also return a challenge. A full discussion of the Authentication element can be found in <xref target="AuthElement"/>.</t>
</list>
</t>
<section title="xacml:Response Element">
<t>The xacml:Response element has the ability to return both a decision, but additionally information about why a decision was not made.</t>
<t>The schema for the xacml:Response element is reproduced here for convenience:</t>
<figure><artwork><![CDATA[
<xs:element name="Response" type="xacml:ResponseType"/>
<xs:complexType name="ResponseType">
<xs:sequence>
<xs:element ref="xacml:Result" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="Result" type="xacml:ResultType"/>
<xs:complexType name="ResultType">
<xs:sequence>
<xs:element ref="xacml:Decision"/>
<xs:element ref="xacml:Status" minOccurs="0"/>
<xs:element ref="xacml:Obligations" minOccurs="0"/>
<xs:element ref="xacml:AssociatedAdvice" minOccurs="0"/>
<xs:element ref="xacml:Attributes" minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="xacml:PolicyIdentifierList" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
]]></artwork></figure>
<t>The xacml:Response element consists of one child the Result. While the schema allows for multiple results to be returned, it is constrained to be a single Result returned in this specification as only a single request will ever be made at one time.</t>
<t>The xacml:Response element consists of the following elements:
<list style="hanging">
<t hangText="xacml:Decision"> is a mandatory element that returns the possible decisions of the access control decision. The set of permitted values are Permit, Deny, Indeterminate and No Policy.</t>
<t hangText="xacml:Status"> is an optional element returned for the Indeterminate status which provides for the reason that a decision was not able to be reached. Additionally it can contain hints for remedying the situation. This document defines a new set of status values to be returned. Formal declaration may be found in <xref target="IANA"/>.
<list style="symbols">
<t>gss-api indicates that a gss-api message has been returned as part of the authentication process.</t>
</list>
</t>
<t hangText="xacml:Obligations"> is designed to force the PEP to perform specific actions prior to allowing access to the resource. This element is not used by Plasma and SHOULD be absent. If a response is returned with this element present, the processing MUST fail unless the PEP can perform the required action.<cref source="jls">My initial thought was that we would not defined any obligations or advice, but I am no longer sure that is true. Things like specifiying a mandatory encryption algorithm or time limit on keeping the decrypted KEK value would be reasonable to be placed here and give a standard way for the policy to communicate that to the client.</cref></t>
<t hangText="xacml:AssocatedAdvice"> is designed to give suggestions to the PEP about performing specific actions prior to allowing access to the resource. This element is not used by Plasma and SHOULD be absent. If the response is returned with this element present, processing will succeed even if the PEP does not know how to perform the required action.</t>
<t hangText="xacml:Attributes"> provides a location for the server to return attributes used in the access control evaluation process. Only those attributes requested in the Attributes section of the request are to be returned. Since Plasma does not generally supply attributes for the evaluation process, this field will normally be absent.</t>
<t hangText="xacml:PolicyIdentifierList"> provides a location to return the set of policies used to grant access to the resource. This element is expected to be absent for Plasma.</t>
</list>
</t>
</section>
</section>
<section title="Authentication Element" anchor="AuthElement">
<t>One of the core issues that the Plasma specification needs to address is how the client is authenticated to the server. This is important because many of the use cases envisioned are not the simple ones where Plasma server is going to know the authentication credentials for the client, but rather will need to get the authentication from a third part in some way. The authentication element therefore is somewhat complicated as it needs to allow for a variety of different authentication methods.</t>
<t>The schema for the Authentication element is:</t>
&AuthenticationType;
<t>More than one authentication element may be present in any single message. This is because a client may need to provide more than one piece of data to a server in order to authenticate, for example a holder of key SAML Assertion along with a signature created with that key. Additionally a client may want to provide the server an option of different ways of doing the authentication. In a federated scenario, an X.509 certificate with a signature can be presented and the server may not be able to build a trust path to it's set of trust anchors. In this case the server may opt to use the GSS-API/EAP protocol for doing the authentication. Finally, the client may want to provide the server with a SAML Assertion that binds a number of attributes to it's identities so that the server does not need to ask for those attributes at a later time.</t>
<section title="WS Trust Tokens">
<t>WS Trust tokens are used in two different ways by this specification. They can be used as the primary introduction method of a client to the server, or they can be used by the server to allow the client to be re-introduced to the server in such a way that the server can use cached information.</t>
<t>WS Trust tokens come in two basic flavors: Bearer tokens and Holder of Key tokens. With the first flavor, presentation of the token is considered to be sufficient to allow the server to validate the identity of the presenter and know the appropriate attributes to make a policy decision. In the second flavor some type of cryptographic operation is needed in addition to just presenting the token. The Signature element <xref target="Auth-Sig"/> provides necessary infrastructure to permit the cryptographic result to be passed to the server.</t>
<t>This document does not define the content or structure of any tokens to be used. This is strictly an implementation issue for the servers in question. This is because the client can treat the WS Token value presented to it as an opaque blob. Only the servers need to understand how to process the blob. However there are some additional fields which can be returned in addition to the token that need to be discussed:
<list style="hanging">
<t hangText="wst:TokenType"> SHOULD be returned if more than one type of token is used by the set of servers. If a token type is returned to the client, the client MUST include the element when the token is returned to the server.</t>
<t hangText="wst:BinarySecret"> SHOULD be returned for moderate duration tokens. If a binary secret is returned then the client MUST provide protection for the secret value. When a binary secret has been returned, then the client MUST create either a signature or MAC value and place it into the Signature element <xref target="Auth-Sig"/>. <cref source="JLS">I don't know of any way to say use the asymmetric key that you authenticated with originally - can this be done?</cref>.</t>
<t hangText="wst:Lifetime"> MUST be returned with the wsu:Expires element set. The wsu:Created element MAY be included. The element provides the client a way to know when a token is going to expire and obtain a new one as needed.</t>
</list>
</t>
</section>
<section title="XML Signature Element" anchor="Auth-Sig">
<t>The XML signature standard <xref target="XML-Signature"/> is used to provide for holder of key assertions and binary secrets to be used to create proofs that the respective secrets are held by the client. When creating either a signature or a MAC, the following statements hold:
<list style="symbols">
<t>The canonicalization algorithm Canonical XML 1.1 <xref target="XML-C14N11"/> without comments will be used in preparing the XML node set for hashing.</t>
<t>The Signature element SHOULD include an Enveloped Signature Transformation (Section 6.6.4 of <xref target="XML-Signature"/> but MAY be the root of the Plasm request. Both methods MUST be supported by Plasma servers.</t>
<t>The signature algorithm RSAwithSHA256 MUST be supported by both clients and servers. The MAC algorithm HMAC-SHA256 MUST be supported by both clients and servers.</t>
</list>
</t>
</section>
<section title="SAML Collection Element" anchor="Auth-SAML">
<t>The SAML collection element provides a holder to place one or more SAML Assertions. Three types of SAML assertions may be place in this location: Bearer assertions, Holder of Key assertions and Attribute assertions. The first two types are used for the purposes of authenticating the client to the server. The last type is used to carry a binding of attributes and identity. The first two types may also carry attributes other than just an identity statement.</t>
</section>
<section title="GSS-API Element">
<t>TBD - rules for using GSS-API in general and the EAP version from ABFAB particularly.
<list style="symbols">
<t>How to build the name.</t>
<t>Must use a secure tunnel for the outer EAP method and an appropriate inner EAP method(s) to accomplish the required level of authentication.</t>
<t>Server query of attributes and specification of LOA to the EAP IdP.</t>
<t>Any additional Trust model items.</t>
<t>How round trips are accomplished - the only case that a server will send back an Authentication element is on return processing of GSS-API messages. </t>
</list>
</t>
</section>
</section>
<section title="Role Token and Policy Acquisition" anchor="getPolicy">
<t>In order to send a message using a Plasma server, the first step is to obtain a role token that provides the description of the lables that can be applied and the authorization to send a message using one or more of the labels. The process of obtaining the role token is designed to be a query/response round trip to the Plasma server. In practice a number of round trips may be necessary in order to provide all of the identity and attributes to the Plasma server that are needed to evaluate the policies for the labels. An example of a request token can be found in <xref target="GetRoleExample"/>.</t>
<t>When a Plasma server receives a role token request from a client, it needs to perform a policy evaluation for all of the policies that it arbitrates along with all of the options for those policies. In general, the first time that a client requests a role token from the server, it will not know the level of authentication that is needed or the set of attributes that needs to be presented in order to get the set of tokens. A server MUST NOT issue a role token without first attempting to retrieve from an attribute source (either the client or a back end server) all of the attributes required to check all policies. Since the work load required on the server is expected to be potentially extensive for creating the role token, it is expected that the token returned will be valid for a period of time. This will allow for the frequency of the operation to be reduced. While the use of an extant role token can be used for identity proof, it is not generally suggested that a new token be issued without doing a full evaluation of the attributes of the client as either the policy or the set of client attributes may have changed in the mean time.</t>
<section title="Role Token Request" anchor="getPolicy-Request">
<t>The process starts by a client sending a server a role token request. Generally, but not always, the request will include some type of identity proof information and a set of generic attributes. It is suggested that, after the first successful conversation, the client cache hints about the identity and attributes needed for a server. This allows for fewer round trips in later conversations.</t>
<t>The role token request, as with all requests, is always built using the eps:PlasmaRequest XML structure. The xacml:Request element MUST be included on the first message, but is omitted on subsequent authentication round trips. The eps:Authentication MAY be included on the first message (depending on how authentication is going to be done) and MUST be included on subsequent authentication round trips.</t>
<t>When sending the role token there are a number of things that can be done. These include:
<list style="symbols">
<t>The client can optionally include an attribute to specify the name to be used for policy evaluation purposes. If this attribute is absent, then the name is extracted from the identity proof provided externally. This attribute allows for a client to get delegated permissions for a third party. One case where this would be used is for an executive assistant to be able to act as the executive for reading certain types of messages. When this behavior is desired, the following attribute is used:
<vspace blankLines='1'/>
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
<vspace blankLines='0'/>
AttributeId="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name"
<vspace blankLines='1'/>
Plasma servers MUST implement the rfc822Name attribute id, other name forms MAY be implemented as well.
</t>
<t>The client MUST include an action attribute. This document defines the action attribute to be used for requesting role tokens:
<vspace blankLines='1'/>
Category="urn:oasis:name:tc:xacml:3.0:attribute-category:action"
<vspace blankLines='0'/>
AttributeId="urn:ietf:plasma:action-id"
<vspace blankLines='0'/>
Attribute Value: GetRoleTokens
</t>
<t>
The client can optionally include a SAML assertion in the Authentication section of the message. See section <xref target="Auth-SAML"/> for more information on how to deal with SAML assertions carrying attribute statements.</t>
</list>
</t>
<t>An example of a message requesting the set of policy information is:
&getPolicyRequest;
In this example the identity information of the requester is implicit from the transport protocol used.</t>
</section>
<section title="Request Role Token Response" anchor="getPolicy-Response">
<t>In response to a role token request message, the Plasma server returns a role token request message. The response message uses the eps:PlasmaResponse XML structure. When a response message is create the following should be noted:
<list style="symbols">
<t>An xacml:Decision is always included in a response message. The values permitted are:
<list style="hanging">
<t hangText="Permit"> is used to signal success. In this case the response message MUST include an eps:PlasmaTokens element.</t>
<t hangText="Deny"> is used to signal failure. In this case the xacml:Status element MUST be present an contain a failure reason.</t>
<t hangText="Indeterminate"> is used to signal that a result cannot yet be reached. In this case there must be a request for additional attributes in the xacml:Result/Attributes element or additional authentication information to be carried in TBD.</t>
<t hangText="NotApplicable"> is returned if the Plasma server does not have the capability to issue role tokens.</t>
</list>
</t>
</list>
</t>
<t>An example of a message returning the set of policy information is:
&getPolicyResponse;
In this example, the Email Policy Service is returning three different policies that can be used along with a security token and a key to be used with the token when sending a message.
</t>
<section title="PlasmaTokens XML element">
<t>The eps:PlasmaTokens element is used to return one or more tokens to the client. Each token returned will contain one or more policies that can be asserted with the token and the token itself. Additionally the name of a Plasma server to be used with the token can be included as well as cryptographic information to be used with the token.</t>
<t>The schema used for the PlasmaTokens element is:</t>
&PlasmaTokensSchema;
<t>The eps:PlasmaTokens field will contain one or more eps:PlasmaToken elements.</t>
<t>The eps:PlasmaToken element contains the following items:
<list style="hanging">
<t hangText="PDP"> is an optional element. If the element is present, it provides one or more URLs to be used for containing a Plasma server for the purpose of sending a message. This element allows for the use of different Plasma servers for issuing role tokens and message tokens. No ranking of the servers is implied by the order of the URLs returned.</t>
<t hangText="PolicyList"> contains the description of one or more policies that can be asserted using the issued token. Any of the policies contained in the list may be combined together using the policy logic in constructing a label during the send message process.</t>
<t hangText="Label"> contains a single specific label. This element is returned as part of a read message token to allow for replies to be formulated by an entity that cannot generally originate a message using the policy.</t>
<t hangText="wst:RequestSecurityTokenResponse"> contains the actual token itself.</t>
</list>
</t>
<t>The eps:PolicyType type is used to represent the elements of a policy to the client. The elements in this type are:
<list style="hanging">
<t hangText="Name"> contains a display string that represents the policy. This element is localized in response to the TBD attribute in the TBD field.</t>
<t hangText="Identifier"> contains a "unique" identifier for the policy. This is the value that identifies the policy to the software. The type for the value is defined as a string and is expected to be either a URN, and Object Identifier or some equally unique identifier.</t>
<t hangText="Options"> allows for a set of options to be specified for the policy. The set of options is dependent on the policy and only those clients which have pre-knowledge of a policy are expected to be able to deal with them. The options can range from a simple yes/no selection to a list of strings. An example of using options is provided by the basic policies defined in [TBD] where a set of RFC 822 names is provided.<cref source="JLS">I keep wondering if we need to define a set of minimal structures that can be used for options so that the entirety is not pushed off onto the client and server to parse and understand the structures.</cref>
</t>
</list>
</t>
<t>When building the wst:RequestSecurityTokenResponse element, the following should be noted:
<list>
<t>A wst:RequestedSecruityToken element containing the security token MUST be included. The format of the security token is not specified and is implementation specific, it is not expected that . Examples of items that could be used as security tokens are SAML statements, encrypted record numbers in a server database. </t>
<t>A wst:Lifetime giving the life time of the token SHOULD be included. It is not expected that this should be determinable from the token itself and thus must be independently provided. There is no guarantee that the token will be good during the lifetime as it make get revoked due to changes in credentials, however the client is permitted to act as if it were. The token provided may be used for duration. If this element is absent, it should be assumed that the token is either a one time token or of limited duration.</t>
<t>Talk about cryptographic information</t>
</list>
</t>
</section>
</section>
</section>
<section title="Sending A Message" anchor="sendMessage">
<t>
After having obtained a role token from a Plasma server, the client can then prepare to send a message by requesting a message token from the Plasma server. As part of the preparatory process, the client will construct the label to be applied to the message from the set of policies that it can assert, determine the optional elements for those policies which have options, generate the random key encryption key and possible create the key recipient structures for the message. Although this section is written in terms of a CMS Encrypted message, there is nothing to prevent the specification of different formats and still use this same basic protocol. An example of a request token exchange can be found in <xref target="GetCMSTokenRequest"/>.</t>
<section title="Send Message Request" anchor="sendMessage-Request">
<t>The send message request is built using the eps:PlasmaRequest XML structure. When building the request, the following aplies:
<list style="symbols">
<t>The eps:Authentication element MAY be included in the initial message. The authorization is supplied by the role token which is included in the data structure, however authentication may be required as well. The authentication data is placed here.</t>
<t>The xacml:Request element MUST be included in the initial message.</t>
<t>The client MUST include an action attribute. This document defines the action attribute to be used for purpose:
<vspace blankLines='1'/>
Category = "urn:oasis:name:tc:xacml:3.0:attribute-category:action"
<vspace blankLines='0'/>
AttributeId="urn:ietf:plasma:action-id"
<vspace blankLines='0'/>
Attribute Value= GetSendCMSToken
</t>
<t>The client MUST include a data attribute. This attribute contains the information that is used to build the CMS Message token to be returned. There MAY be more than one data attribute, but this will not be a normal case. More details on this attribute are in <xref target="MessageTokenRequest"/>.</t>
</list>
</t>
<t>An example of a message returning the set of policy information is:
&sendMessageRequest;
</t>
<section title="CMS Message Token Data Structure" anchor="MessageTokenRequest">
<t>The message token data structure is used as an attribute to carry the necessary information to issue a CMS message token. The schema that describes the structure is:
</t>
&RequestMessageData;
<t>When used in an xacml:Attribute, the structure is identified by:
<vspace blankLines='1'/>
Category = "urn:oasis:name:tc:xacml:3.0:attribute-category:data"
<vspace blankLines='0'/>
AttributeId = "urn:ietf:plasma:data-id"
<vspace blankLines='0'/>
DataType = "http://www.w3.org/2001/XMLSchema#anyType"
</t>
<t>The elements of the structure are used as:
<list style="hanging">
<t hangText="RoleToken"> contains the previously issued role token which provides the authorization to use the policies in the label.</t>
<t hangText="Label"> contains the label to be applied to the message.</t>
<t hangText="Recipients"> is an optional element that contains one or more recipient info structures.</t>
<t hangText="KEK"> is an optional element that contains the KEK to decrypt the CMS lock box.</t>
</list>
One or both of KEK and Recipients MUST be present.
</t>
<t>The elements of the RecipientInfoType structure are:
<list style="hanging">
<t hangText="Subject"> contains a subject identifier. Since a CMS recipient info structure does not contain a great deal of information about the recipient, this element contains a string which can be used to identify the subject. This will normally be an RFC 822 name. Multiple subject names can be provided for a single lock box. This allows for the use a KEK value that is shared among the set of recipients but not the Plasma server.</t>
<t hangText="LockBox"> contains a hex encoded CMS Recipient Info structure. If the recipient info structure is placed here, it MUST NOT be placed in the CMS EnvelopedData structure as well.</t>
</list>
</t>
</section>
</section>
<section title="Send Message Response" anchor="sendMessage-Response">
<t>In response to a send message request, the Plasma server returns a send message response message. The response messages uses the eps:PlasmaResponse XML structure. When the response message is created, the following should be noted:
<list style="symbols">
<t>The xacml:Decisions is always included in the response. If the 'Permit' value is returned then the eps:CMSToken element MUST be present.</t>
<t>The eps:CMSToken element is included in a success message. It contains value of the keyatt-eps-kek attribute defined in <xref target="EPS-CMS"/>.</t>
</list>
</t>
<t>An example of a message returning the set of policy information is:
&sendMessageResponse;
</t>
</section>
</section>
<section title="Decoding A Message" anchor="readMessage">
<t>When the receiving agent is ready to decrypt the message, it identifies that there is a KEKRecipientInfo object which contains a key attribute identified by id-keyatt-eps-token. It validates that communicating with the Email Policy Service is within local policy and then sends a request to the service to obtain the encryption key for the message.</t>
<t>In some cases the recipient of a message is not authorized to use the same set of labels for sending a message. For this purpose a token can be returned in the message along with the key so that recipient of the can reply to the message using the same set of security labels.</t>
<section title="Requesting Message Key" anchor="readMessage-Request">
<t>The client sends a request to the Plasma server that is identified in the token. For the CMS base tokens, the address of the Plasma server to use is defined in <xref target="EPS-CMS"/> this is located in the aa-eps-url attribute.</t>
<t>The request uses the eps:PlasmaRequest XML structure. When building the request, the following should be noted:
<list style="symbols">
<t>The xacml:Request MUST be present in the first message of the exchange.</t>
<t>The action used to denote that a CMS token should be decrypted is:
<vspace blankLines="1"/>
Category="urn:oasis:names:tc:xaml:3.0:attribute-category:action"
<vspace blankLines="0"/>
AttributeId="urn:ietf:plasma:action-id"
<vspace blankLines="0"/>
Attribute Value: ParseCMSToken
</t>
<t>The CMS token to be cracked is identified by:<cref source="jls">I need to think this case out a bit more - I want to be able to supply multiple CMS tokens at one time, however I am not sure if that is do able because if you get a success for one token and a deny for another token there is no way to handle that in the xacml:Response.</cref>
<vspace blankLines="1"/>
Category="urn:oasis:names:tc:xacml:3.0:attribute-cateogry:data"
<vspace blankLines="0"/>
AttributeId="urn:ietf:plasma:data-id"
<vspace blankLines="0"/>
Attribute Value: CMSToken
</t>
<t>In the event that a reply to role token is wanted as well, then that is supplied as a separate action:
<vspace blankLines="1"/>
Category="urn:oasis:names:tc:xaml:3.0:attribute-category:action"
<vspace blankLines="0"/>
AttributeId="urn:ietf:plasma:action-id"
<vspace blankLines="0"/>
Attribute Value: GetReplyToken
</t>
</list>
</t>
<t>An example of a message returning the set of policy information is:
&readMessageRequest;
</t>
</section>
<section title="Requesting Message Key Response" anchor="readMessage-Response">
<t>In response to a message key request, the Plasma server returns a decrypted key. The response message uses the eps:Plasma XML structure. When a response message is create the following should be noted:
<list style="symbols">
<t>If the value of xacml:Decision is Permit, then response MUST include an eps:CMSKey element.</t>
<t>If a reply token was requested and granted, then the response MUST include an eps:PlasmaToken element. The eps:PlasmaToken element MUST use the Label option</t>
</list>
</t>
<t>An example of a message returning the set of policy information is:
&readMessageResponse;
</t>
</section>
</section>
<section title="Security Considerations">
<t>To be supplied after we have a better idea of what the document looks like.</t>
</section>
<section title="IANA Considerations" anchor="IANA">
<t>We should have at least one name space to be registered.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="ABFAB">
<front>
<title>A GSS-API Mechanism for the Extensible Authentication Protocol</title>
<author initials="S." surname="Hartman" />
<author initials="J." surname="Howlett" />
<date month="Oct" year="2011" />
</front>
<seriesInfo name="Work In Progress" value="draft-ietf-abfab-gss-eap-04" />
</reference>
&RFC2119;
<reference anchor="EPS-CMS">
<front>
<title>Email Policy Service ASN.1 Processing</title>
<author initials="J." surname='Schaad' fullname='Jim Schaad'/>
<date month='Jan' year='2011'/>
</front>
<seriesInfo name='Work In Pgoress' value='draft-eps-smime-00'/>
</reference>
&XML-DIGSIG;
&XML-C14N11;
&SOAP11;
&SOAP12;
<reference anchor="WS-TRUST" target="http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html">
<front>
<title>WS-Trust 1.3</title>
<author initials="K" surname="Lawrence"/>
<author initials="C" surname="Kaler"/>
<author initials="A" surname="Nadalin"/>
<author initials="M" surname="Goodner"/>
<author initials="M" surname="Gudgin"/>
<author initials="A" surname="Barbir"/>
<author initials="H" surname="Granqvist"/>
<date month="March" day='19' year='2007'/>
</front>
<seriesInfo name="OASIS Standard" value="ws-trust-200512"/>
<format type='HTML' target='http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html'/>
</reference>
<reference anchor="XACML" target="http://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-cs-01.en.doc">
<front>
<title>eXtensible Access Control Markup Language (XACML) Version 3.0</title>
<author initials="E" surname="Rissanen" role="Editor"/>
<date month="August" day='10' year='2010'/>
</front>
<seriesInfo name="OASIS Standard" value="xacml-201008"/>
<format type='HTML' target="http://docs.oasis-open.org/xacml/3.0/xacml03.0-core-spec-cs-01-en.html"/>
</reference>
</references>
<section title="XML Schema">
<t>This appendix represents the entirety of the XML Schema for Plasma documents.</t>
&PlasmaSchema;
</section>
<section title="Example: Get Roles Request" anchor="GetRoleExample">
<t>This section provides an example of a request message to obtain the set of roles for an individual named 'bart@simpsons.com'. The authentication provided in this is a SAML statement included in the SAML_Collection element.</t>
&GetRoleRequestExample;
</section>
<section title="Example: Get Roles Response" anchor="GetRoleResponse">
<t>This section provides an example response to a successful request for a role sets.</t>
&GetRoleResponseExample;
</section>
<section title="Example: Get CMS Token Request" anchor="GetCMSTokenRequest">
<t>This section contains an example of a request from a client to a server for a CMS message token to be issued. The authentication for the request is provided by using a WS-Trust token previously issued as part of a role request/response dialog. The request contains the following elements:
<list style="symbols">
<t>A complex rule set is requested where permission to is to be granted to anyone who meets either of the two policies given.</t>
<t>A specific recipient info structure is provided for a subject who's name is 'lisa@simpsons.com'. The details of the recipient info structure are skipped but it would be any encoding of a RecipientInfo structure from CMS.</t>
<t>A generic key encryption key is provided for any other subject who meets the policies specified.</t>
</list>
</t>
&GetTokenRequestExample;
</section>
<section title="Example: Get CMS Token Response" anchor="GetCMSTokenResponse">
<t>This section contains an example of a response from a server to a client for a CMS message token to be issued. The token is returned in the CMSToken element. This element would then be placed into the CMS message being created by the client.</t>
&GetTokenResponseExample;
</section>
<section title="Example: Get CMS Key Request" anchor="GetCMSKeyRequest">
&GetKeyRequestExample;
</section>
<section title="Example: Get CMS KeyResponse" anchor="GetCMSKeyResponse">
&GetKeyResponseExample;
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:21:38 |