One document matched: draft-schaad-plasma-service-05.xml
<?xml version='1.0' encoding='ascii'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xlst' ?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="std" docName="draft-schaad-plasma-service-05" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<front>
<title abbrev="EPS TRUST">Plasma 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><!--RFC TBD is draft-freeman-plasma-requirements --> RFC TBD describes a new model and set of requirements to implement a labeling system on Cryptographic Message Syntax (CMS) objects where the entity in charge of doing the label enforcement is under the control of a central authority rather than the recipient of the object. </t>
<t>This document describes a protocol to be used by senders and recipients of CMS objects to communicate with a centralized label enforcement server. The document outlines how a client will get the set of labels or policies that it can use for sending messages, composes a secure CMS object with a label on it and gets the necessary keys to decrypt a CMS object from the server. <!--RFC TBD2 is draft-schaad-plasma-cms --> This document is designed to be used with RFC TBD2 which describes the extensions used in CMS objects to hold the label information. </t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>RFC TBD <xref target="I-D.freeman-plasma-requirements" pageno="false" format="default"/> describes a new model and set of requirements to implement a labeling system on Cryptographic Message Syntax (CMS) objects where the entity in charge of doing the label enforcement is under the control of a central authority rather than the recipient of the object. </t>
<t>This document describes a protocol to be used by senders and recipients of CMS objects to communicate with a centralized label enforcement server. The document outlines how a client will get the set of labels or policies that it can use for sending messages, composes a secure CMS object with a label on it and gets the necessary keys to decrypt a CMS object from the server. This document is designed to be used with RFC TBD <xref target="I-D.schaad-plasma-cms" pageno="false" format="default"/> which describes the extensions used in CMS objects to hold the label information. </t>
<section title="XML Nomenclature and Name Spaces" toc="default">
<t>The following name spaces are used in this document:</t>
<texttable title="" suppress-title="false" align="center" style="full">
<ttcol align="left">Prefix</ttcol>
<ttcol align="left">Namespace</ttcol>
<ttcol align="left">Specification(s)</ttcol>
<c>eps</c>
<c>http://ietf.org/2011/plasma/</c>
<c>This Specification</c>
<c>wst</c>
<c>http://docs.oasis-open.org/ws-sx/ws-trust/200512</c>
<c>
<xref target="WS-TRUST" pageno="false" format="default"/>
</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" pageno="false" format="default"/>
</c>
<c>ds2</c>
<c>http://www.w3.org/2000/09/xmldsig#</c>
<c>
<xref target="XML-Signature" pageno="false" format="default"/>
</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" toc="default">
<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" pageno="false" format="default"/>.</t>
<t>When the words appear in lower case, their natural language meaning is used.</t>
</section>
</section>
<section title="Components" toc="default">
<t>In designing this specification we used a number of pre-existing specifications as building blocks. In some cases we use the entirety of the specification and in other case we use only select pieces.</t>
<section title="XACML 3.0" toc="default">
<t>The XACML specification (eXtensible Access Control Markup Language) <xref target="XACML" pageno="false" format="default"/> provides a framework for writing access control policies and for creating standardized access control queries and responses. The request and response portion of the specification is used to build the request (<xref target="xacml_Request" pageno="false" format="default"/>) and response (<xref target="xacml_Response" pageno="false" format="default"/>) messages in this specification. The structure for writing the access control policies is out of scope for this document, but XACML is one of the possibilities that can be used for that purpose. </t>
</section>
<section title="SAML" toc="default">
<t>A number of different methods for carrying both identification and attributes of the party requesting access is permitted in this specification. SAML is one of the methods that is permitted for that purpose.</t>
<t>SAML has defined three different types of assertions in it's core specification <xref target="OASIS-CORE" pageno="false" format="default"/>: <list style="symbols"><t>Authentication: The assertion subject was authenticated by a particular means at a particular time.</t><t>Attribute: The assertion subject is associated with the supplied attributes.</t><t>Authorization Decision:<cref source="Trevor">I don't see Plasma using this type</cref> A request to allow the assertion subject to access the specified resource has been granted or denied.</t></list> While a PDP can use an Authorization Decision as input, this is unexpected and MAY be supported. In addition there are three different ways that the subject of a SAML statement can be identified: <list style="symbols"><t>A bearer statement: These statements are belong to anybody who presents them. The owner is required to take the necessary precautions to protect them.</t><t>A holder of key statement: These statements belong to anybody who can use the key associated with the statement. </t><t>Subject match:<cref source="Trevor">What about attribute match?</cref> These statements can be associated to an identity by matching the name of the entity.</t><!--Also add attribute match for this --></list> </t>
<t>We cannot pass a SAML assertion with attributes as a single attribute in the XACML request as XACML wants each of the different attributes to be individually listed in the request. This greatly simplifies the XACML code, but means that one needs to do a mapping process from the SAML attributes to the XACML attributes. This process has been discussed in Section 2 of <xref target="SAML-XACML" pageno="false" format="default"/>. This mapping process MUST be done by a trusted agent, as there are a number of steps that need to be done including the validation of the signature on the SAML assertion. This process cannot be done by the PEP that is residing on the Plasma client's system as this is considered to be an untrusted entity by the Plasma system as a whole. One method for this to be addressed is to treat the Plasma server as both a PDP (for the Plasma client) and a PDP for the true XACML policy evaluator. In this model, the Plasma server becomes the trusted PEP party and has the ability to do the necessary signature validation and mapping processes. A new XACML request is then created and either re-submitted to itself for complete evaluation or to a third party which does the actual XACML processing.<cref source="Trevor">This sounds like we ignore the mapping on the wire. There is no reason to mandate the mapping occurs inside the PDP.</cref></t>
</section>
<section title="WS-Trust 1.4" toc="default">
<t>The WS-Trust 1.4 <xref target="WS-TRUST" pageno="false" format="default"/> standard provides for methods for issuing, renewing, and validating security tokens. This specification uses only a small portion of that standard, specifically the structure that returns a trust token from the issuer to the requester. </t>
<t>This specification makes no statements on the content and format of the token returned from the Plasma server to the Plasma client in the wst:RequestSecurityTokenResponse field. These tokens may be parseable by the client, but there is no requirement that the client be able to understand the token. The token can always be treated as an opaque blob by the client which is simply reflected back to the server at a later time. The attributes that client needs to understand in order to use the token, such as the life time, are returned as fields of the token response.</t>
<t>TODO: need to discuss the content model and say what elements need to be supported and what elements can be ignored -- safely.</t>
</section>
</section>
<section title="Model" anchor="model" toc="default">
<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" suppress-title="false" alt="" width="" height="">
<artwork xml:space="preserve" name="" type="" alt="" width="" height="">
(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" toc="default">
<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" pageno="false" format="default"/>. A more detailed description of the processing is found in <xref target="getPolicy" pageno="false" format="default"/> for obtaining the security policies that can be applied to a messages and <xref target="sendMessage" pageno="false" format="default"/> 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" pageno="false" format="default"/>.</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" pageno="false" format="default"/>.</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" pageno="false" format="default"/>.</t><t>The Email Policy Service creates the recipient info attribute as defined in <xref target="I-D.schaad-plasma-cms" pageno="false" format="default"/>.</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" pageno="false" format="default"/>.</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" toc="default">
<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" pageno="false" format="default"/>. A more detailed description of the processing is found in <xref target="readMessage" pageno="false" format="default"/>.</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" pageno="false" format="default"/>.</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" pageno="false" format="default"/>.</t><t>The Receiving Agent proceeds to decrypt the message and perform normal processing.</t></list> </t>
</section>
</section>
<section title="Protocol Overview" anchor="Overview" toc="default">
<t>The protocol defined in this document is designed to take place between a Plasma server and a Plasma client. The protocol takes place in terms of a request/response dialog from the client to the server. A single dialog can consist of more than one request/response message pair. Multiple round trips within allow a client to provide additional authentication, authorization and attribute information to the server.</t>
<t>Each dialog contains one or more action attributes specifying what actions the client wishes the server to take. Depending on the action requested, additional attributes may be present providing data for the action to use as input. Finally, each dialog will contain authentication and attributes supplied by one or more authorities that the server can use either as input to the action or as input to policy decisions about whether to perform the action.</t>
<t>The protocol MUST be run over a secure transport, the secure transport is responsible for providing the confidentiality and integrity protection services over the entire message. The protocol allows for signature operations to occur on sub-sections of the message structure, howewever this is used for creation of identity proofs and not for integrity protection. </t>
<t>Multiple dialogs may be run over a single secure transport session. Before a new dialog may be started, the previous dialog MUST have completed to a state of success, failure or not applicable. A new dialog MUST NOT be started after receiving a response with an indeterminate status. If a new dialog is desired in these circumstances, then the transport session MUST to be closed and re-opened. <cref source="JLS">--- I want to say that TLS reconnect using caching is OK here. Is that a reasonable statement? I don't think we want to say that the server will keep Plasma session data across TLS sessions.</cref> </t>
</section>
<section title="Plasma Request" toc="default"><t>The specification is written using XACML as the basic structure to frame a request for an operation. The request for operations to occur are written using XACML action items. This specification defines actions specific to Plasma in a CMS environment. Other specifications can define additional action items for other environments (for example the XML encryption environment) or other purposes. (Future work could use this basic structure to standardize the dialogs between PDPs and PAPs or to facilitate legal signatures on emails.) </t><t>In addition to the XACML action request there is a set of structures to allow for a variety of authentication mechanisms to be used. By allowing for the use of SAML and GSS-API as base authentication mechanisms, the mechanism used is contained in a sub-system and thus does not directly impact the protocol. </t><!--WIF base library Windows Identity Foundation --><!--Have to differeniate between subject and environment (user vs machine) for both SAML and x.509 certificates. --><t>The request message uses a single XML structure. This structure is the eps:PlasmaRequest object. The XML Schema used to describe this structure is:</t><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<xs:element name="PlasmaRequest" type="eps:RequestType"/>
<xs:complexType name="RequestType">
<xs:sequence>
<xs:element ref="eps:Authentication" minOccurs="0"/>
<xs:element ref="xacml:Request"/>
</xs:sequence>
<xs:attribute name="Version" type="xs:string" default="1.0"/>
</xs:complexType>
</artwork></figure> <t>The RequestType has two elements in it: <list style="hanging"><t hangText="Authentication">is an optional element that holds the structures used for doing authentication and authorization. Unless no authentication is required by the Plasma server, the element is going to exist for one or more requests in the dialog.</t><t hangText="xacml:Request">is a required element that contains the control information for the action requested. The control information takes the form of an action request plus additional data to be used as part of the action request. The data and actions are to be treated as self-asserted, that is they are deemed not to come from a reliable source even in the event that an authentication is successfully completed. As self-asserted values, Plasma servers need to exercise extreme care about which are included in the policy enforcement decisions. As an example, it makes sense to allow for the action identifier to be included in the policy enforcement, but assertions about the identity of the subject should be omitted. This element is taken from the XACML specification. </t></list> </t><t>For some operations, display string values are returned as part of the response from the server. The xml:lang attribute SHOULD be included in the RequestType element to inform the server as to what language client wishes to have the strings in. The server SHOULD attempt to return strings in the language requested or a related language if at all possible.</t><section title="Authentication Element" anchor="AuthElement" toc="default"><t>One of the major goals in the Plasma work is to detach the process of authentication specifics from the Plasma protocol. In order to accomplish this we are specifying the use of two general mechanisms (SAML and GSS-API) which can be configured and expanded without changing the core Plasma protocol itself. The authentication element has two main purposes: 1) to process the authentication being used by the client and 2) to carry authenticated attributes for use in the policy evaluation. </t><t>When transporting the authentication information, one needs to recognize that there may be a single or multiple messages in the dialog in order to complete the authentication process. In performing the process of authenticating, any or all of the elements in this structure can be used. If there are multiple elements filled out, the server can choose to process the elements in any order. This means that the Plasma protocol itself does not favor any specific mechanism. The current set of mechanisms that are built into the Plasma specification are: <list style="symbols"><t>SAML Assertions - many different types of SAML assertions are supported. The specification uses both bearer and holder of key assertions.</t><t>X.509 Certificates can be used for the purpose of authentication by creating a signature with the XML Digital Signature standard.</t><t>GSS-API - the specification allows for the use of GSS-API in performing the authentication process. The ABFAB mechanism in GSS-API is specifically designed for use in a federated community and allows for both authentication and attribute information to be queried from the identity server.</t><t>WS-Trust tokens allow for much of the same type of information to be passed as SAML assertions. The Plasma specification has been designed mainly for the use of WS-Trust tokens to be used for caching prior authentication sessions. <!--Trevor - What is the difference between WS-trust SAML assertions and the SAML assertions above? --> <!--JLS - In principle, there is no difference between what is presented. The fact that a SAML assertion can be returned as a WS-Trust token is implementation dependent. By default, consumers of WS-Tokens may not understand the format of the token. Additionally, there is no reason to assume that a WS-Trust token returned to the user is a SAML assertion. --> </t></list> </t><t>More than one authentication element can 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 client may need to use the GSS-API/EAP protocol for doing the authentication. The client may want to provide the server with one or more 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. Finally, multiple entities may need to be validated (for example the user and the user's machine). </t><t>When transporting the attribute information, one needs to recognize that there may be single or multiple messages in the dialog in order to complete the authorization process. The server will return a status code of urn:oasis:names:xacml:1.0:status:missing-attribute in the event that one or more attributes are needed in order to complete the authorization process. The details on how XACML returns missing attribute information is found in Section 7.17.3 of <xref target="XACML" pageno="false" format="default"/>. When the list of attributes is returned, the client has two choices: 1) It can close the dialog, look for a source of the missing attributes and then start a new dialog, 2) it can just get an assertion for the missing attributes and send the new assertion as in a new request message within the same dialog. The decision of which process to use will depend in part on how long it is expected to take to get the new attribute assertion to be returned. </t><t>The same authentication data does not need to be re-transmitted to the server in a subsequent message within a single dialog. The server MUST retain all authenticated assertion information during a single dialog. </t><t>The schema for the Authentication element directly maps to the ability to hold the above elements. The schema for the Authentication element is:</t><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<xs:element name="Authentication" type="eps:AuthenticationType"/>
<xs:complexType name="AuthenticationType">
<xs:choice maxOccurs="unbounded">
<xs:element ref="saml:Assertion"/>
<xs:element name="GSSAPI" type="xs:hexBinary"/>
<xs:element name="RoleToken">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##any" processContents="lax"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ds2:Signature"/>
<xs:element name="Other">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
</artwork></figure> <t>The schema allows for multiple authentication elements to occur in any order. It is suggested, but not required, that the ds2:Signature element occur after the authentication element that has an assoicated key. This makes it easier for servers to make a one pass validate of all authentication elements.</t><t>The Other element is provided to allow for additional authentication elements, include SAML version 1.1, to be used.</t><section title="SAML Assertion" anchor="Auth-SAML" toc="default"><t>SAML Assertions can provide authentication or attribute information to the server. A SAML statement only needs to be provided once during a single dialog, the server MUST remember all attributes during the dialog.</t><t>When a SAML Assertion contains a SubjectConformation element using the KeyInfoConfirmationDataType as a subject conformation element, the confirmation shall be performed by the creation of an XML Signature authentication element. The signature element shall be created using an appropriate algorithm for the key referenced in the SAML statement.</t><t>Identify a SAML statement in the delegation/subject/environment space - need text for this <cref source="JLS">I don't remember what this is supposed to be anymore.</cref> </t></section><section title="WS Trust Tokens" toc="default"><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. <!--Trevor - Would we use bearer tokens to reintroduce the client? The main protection of bearer tokens is if they are fresh so you have had little time to stream one --> <!--JLS - Yes it would be used for re-introduction either from the Plasma server or from another server. The use of bearer tokens is probably wider spread than it should be, why should we find the current trend --> 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 (usually a signature or MAC computation) is needed in addition to just presenting the token. The Signature element (<xref target="Auth-Sig" pageno="false" format="default"/>) 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.<cref source="trevor">Is this totally true? Don't we need some kind of identifier so the server can indicate when the token can be replayed in a subsequence request? E.g. give me these attributes or a foo token.</cref> 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" pageno="false" format="default"/>. <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" toc="default"><t>When a holder of key credential is used to determine the attributes associated with an entity, there is a requirement that the key be used in a proof of possession step so that the Plasma server can validate that the entity does hold the key. The credentials can hold either asymmetric keys (X.509 certificates and SAML Assertions) or symmetric keys (WS Trust Tokens and SAML Assertions) which use Digital Signatures or Message Authentication Codes (MACs) respectively to create and validate a key usage statement. The XML signature standard <xref target="XML-Signature" pageno="false" format="default"/> provides an infrastructure to for conveying the proof of possession information. </t><t>The signature is computed over the XACML request element as a detached signature. When a signature element exists in the message, the ChannelBinding attribute (<xref target="ChannelBind" pageno="false" format="default"/>) MUST be included in the request. By the use of a value which is derived from the cryptographic keys used in for protecting the tunnel, it is possible for the server to verify that the authentication values computed were done specifically for this specific dialog and are not replayed.</t><t>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" pageno="false" format="default"/> without comments MUST be supported and SHOULD be used in preparing the XML node set for hashing. Other canonicalization algorithms MAY be used.</t><t>The signature algorithms RSAwithSHA256 and ECDSAwithSHA256 MUST be supported by servers. At least one of the algorithms MUST be supported by clients. The MAC algorithm HMAC-SHA256 MUST be supported by both clients and servers. Other signature and MAC algorithms MAY be supported.</t><t>Set the additional attributes that must be included in a signature - what should they be?</t><t>If an xacml:Request element is referenced by an XML Signature element, the xacml:Request element MUST include the ChannelBinding token (<xref target="ChannelBind" pageno="false" format="default"/>) as one of the attributes.</t><t>The keys used in computing the authentication value need to be identified for the recipient. For X509 certificates, the full raw certificate will normally be included as part of the signature, but MAY be referenced instead. For SAML assertions, the specific assertion carrying the asymmetric key can be identified by TBD HERE. In the event that symmetric keys are used by holder of key assertions, the specific assertion will be identified by TBD HERE. In these cases the server is expected to be able to associated the key with the assertion by some means (either locally or perhaps encrypted into the assertion). </t></list> </t></section><section title="GSS-API Element" toc="default"><t>GSS-API <xref target="RFC2743" pageno="false" format="default"/> provides a security services to callers in a generic fasion, supportable with a range of underlying mechanisms and technologies. GSS-API has been extended by providing a mechanism for EAP <xref target="RFC7055" pageno="false" format="default"/> which is designed to work in a federated environment. This effort was done by the Application Bridging for Federated Access Beyond web (ABFAB) working group. In this document the mechanism is referred to as ABFAB. This is the same type of environment that the Plasma protocol is expected to operate as well. </t><t>GSS-API offers a number of security services that are not currently used by the Plasma system. At this point in time we are only looking at the initial authentiction methods and not using the message encryption or encryption services. </t><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 title="Generic Requirements" toc="default"><t>Not all GSS-API mechanisms have the required features to support the necessary security that is needed by Plasma. GSS-API mechanisms need to support the following features: <list style="symbols"><t>The mechanism MUST support the binding of the TLS tunnel to the authentication via channel binding.</t><t>Either the mechanism MUST support mutual authentication or the TLS tunnel MUST be usable to authenticate the server being talked to. Anonymous TLS sessions can be use when mutual authentication is provided by the GSS-API mechanism.</t></list> </t></section><section title="GSS-EAP Requirements" toc="default"><t>When forming a mechnism name for GSS-API the following guidelines SHOULD be followed: <list style="symbols"><t>The user-or-service string is "plasma" (all in lower case).</t><t>The host name is to be provided. When obtained from the URL, the host name is to be the entire host name in the URL.</t><t>There are currently no service-specific options defined.</t><t>The realm name is OPTIONAL. When obtained from the URL, the realm name is omitted.</t><t>Realm and host names should be prepared according to <xref target="RFC5891" pageno="false" format="default"/> prior to passing them into GSS-API.</t></list> </t><t>Clients MUST use a tunneling EAP method that supports channel binding between the tunnel and the inner EAP methods. At this point in time only the TEAP method <xref target="I-D.ietf-emu-eap-tunnel-method" pageno="false" format="default"/> provides the necessary support. While any inner EAP method can be used, it is strongly recommended that only those methods that support generation of EMSK (extended master session keys) be used, however methods tht only support generation of a MSK (master session key) can be used. (A discussion of why EMSKs should be generated can be found in <xref target="RFC7029" pageno="false" format="default"/>.) </t><t>IdPs MUST support the EAP channel binding that is part of TEAP. At a minimum the service name, host name and real names MUST be checked for matches between the information provided by the TEAP channel binding and the RADIUS attributes. </t></section><section title="GSS-API Channel Bindings" toc="default"><t>The calls to GSS_Init_sec_content and GSS_Accept_sec_context take a chan_bindings parameter. The value is a GSS_CHANNEL_BINDINGS structure <xref target="RFC5554" pageno="false" format="default"/>. </t><t>The initiator-address-type and acceptor-address-type fields of the GSS-CHANNEL-BINDINGS structure MUST be set to 0. The initiator-address and acceptor-address fields MUST be the empty string. </t><t>The application-data field MUST be set to the channel binding value defined in <xref target="ChannelBind" pageno="false" format="default"/>. </t></section></section></section><section title="xacml:Request Element" anchor="xacml_Request" toc="default"><t>The request for an action to be performed by the Plasma server along with the data that needs to be supplied by the client in order for the server to complete the action are placed into the xacml:Request element of the request. This document defines a set of actions that are to be understood by the Plasma server. One (or more) action is to be placed in the request message.</t><t>In addition to the request for a specific action to occur, the client can place additional attributes in the request as well. These attributes are provided in order to assist the server either in identifying who the various agents on the client side are or to provide suggestions of attributes for using in making control decisions. Any data provided by the client in this manner is to be considered as a self-asserted value and to be treated as if it comes from the client as oppose to a trusted attribute agent.</t><t>For convenience the schema for the xacml:Request element is reproduced here:</t><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<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 RequestDefaults element of the XACML Request MUST be omitted by the clients. If present servers MUST ignore the RequestDefaults element. The use of the MultiRequest element is current not defined for a Plasma server and SHOULD be omitted by clients.</t><t>Clients MAY set ReturnPolicyIdList to true in order to find out which policies where used by the server in making the decision. Server MAY ignore this field and not return the policy list even if requested.</t><t>A number of different entities may need to be identified to Plasma server as part of a request. These entities include: <list style="numbers"><t>The subject making the request to the server. </t><t>The machine on the subject is using.</t><t>The entity the subject is acting for. Converse about Delegation.</t></list> </t></section></section>
<section title="Plasma Response Element" toc="default"><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><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<xs:element name="PlasmaResponse" type="eps:ResponseType"/>
<xs:complexType name="ResponseType">
<xs:sequence>
<xs:element ref="xacml:Response"/>
<xs:element ref="eps:PlasmaReturnToken" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Version" type="xs:string" default="1.0"/>
</xs:complexType>
<xs:element name="PlasmaReturnToken" type="eps:PlasmaReturnTokenType"/>
<xs:complexType name="PlasmaReturnTokenType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"/>
</xs:sequence>
<xs:attribute name="DecisionId" type="xs:string"/>
</xs:complexType>
</artwork></figure> <t>A Plasma Response has two elements: <list style="hanging"><t hangText="xacml:Response">is a mandatory element that returns the status of the access request.</t><t hangText="PlasmaReturnToken">is an optional element to return a token. These tokens represent the answer, for a success, of the request. If multiple tokens are being returned, then the element will occur mutiple times. </t></list> </t><t>A Plasma Return Token is a wrapper for the actual token being returned. The returned token may be any content. This document defines the following elements that are to be returned in this location <list style="symbols"><t>RoleToken - used to return roles.</t><t>CMSMessageToken - used to return one or more CMS RecipientInfo strucutures.</t><t>CMSKeyToken - used to return either a CMS RecipientInfo structure or a bare content encryption key.</t></list> </t><t>The PlasmaReturneTokenType has an optional attribute DecisionId. This attribute is used when in the case multiple requests are made at the same time in order to assoicate the rquest and the response tokens. </t><section title="xacml:Response Element" anchor="xacml_Response" toc="default"><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 title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<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.</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 an additional set of status values to be returned. Formal declaration may be found in <xref target="IANA" pageno="false" format="default"/>. <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. If a response is returned with this element present, the processing MUST fail unless the PEP can perform the required action. A set of Plasma specific obligations are found in <xref target="OurObligations" pageno="false" format="default"/>. <cref source="Trevor">What about audit obligatiouns</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. A set of Plasma specific advice elements are found in <xref target="OurObligations" pageno="false" format="default"/>.</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. <cref source="Trevor">Should we ignore it if present?</cref><cref source="JLS">I don't think we need to say anything about looking at it or ignoring it. While it would be something for debugging, as a general rule the client does not care which policies where evaluated and passed to grant access.</cref></t></list> </t></section></section>
<section title="Role Token and Policy Acquisition" anchor="getPolicy" toc="default">
<t>In order to send an email using a Plasma server, the first step is to obtain a role token that provides the description of the labels that can be applied and the authorization to send an email using one or more of the labels. The process of obtaining the role token is designed to be a request/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. </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" toc="default"><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 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. An example of a request token can be found in <xref target="GetRoleExample" pageno="false" format="default"/>. </t><t>The role token request, as with all requests, uses the eps:PlasmaRequest XML structure. The eps:Authentication MAY be included on the first message and MUST be included on subsequent authentication round trips. </t><t>A role token request by a client MUST include the GetRoleTokens Plasma action request as an attribute of the xacml:Request element. Details on the action can be found in section <xref target="Action-Ids" pageno="false" format="default"/>. When role tokens are requested, no additional data needs to be supplied by the requester. </t><t>An example of a message requesting the set of policy information is: </t><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<esp:PlasmaRequest>
<eps:Authentication>...</eps:Authentication>
<xacml:Request>
<xacml:Attributes Category="...:action">
<xacml:Attribute AttributeId="urn:plasma:action-id">
<xacml:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">
GetRoleToken</xacml:AttributeValue>
</xacml:Attribute>
</xacml:Attributes>
</xacml:Request>
</esp:PlasmaRequest>
</artwork></figure> </section>
<section title="Request Role Token Response" anchor="getPolicy-Response" toc="default">
<t>In response to a role token request, the Plasma server returns a role token response. The response uses the eps:PlasmaResponse XML structure. When a response is create the following should be noted: </t>
<t>An xacml:Decision is always included in a response. The values permitted are: <list style="hanging"><t hangText="Permit">is used to signal success. In this case the response MUST include one or more eps:RoleToken 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 final result has not yet been reached. When this decision is reached, the server SHOULD return a list of additional attributes to be returned and SHOULD return the list of role tokens that have been granted based on the attributes received to that point.</t><t hangText="NotApplicable">is returned if the Plasma server does not have the capability to issue role tokens.</t></list> </t>
<t>An example of a response returning the set of policy information is: <figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<eps:PlasmaResponse>
<xacml:Response>
<xacml:Result>
<xacml:Decision>Permit</xacml:Decision>
</xacml:Result>
</xacml:Response>
<eps:PlasmaTokens>
<eps:PlasmaToken>
<eps:PolicyList>
<eps:Policy>
Details of a policy
</eps:Policy>
... More policies ...
<wst:RequestSecurityTokenResponse>
<wst:TokenType>urn:...:plasma:roleToken</wst:TokenType>
<wst:RequestedSecurityToken>...</wst:RequestedSecurityToken>
</wst:RequestSecurityTokenResponse>
</eps:PolicyList>
</eps:PlasmaToken>
</eps:PlasmaTokens>
</eps:PlasmaResponse>
</artwork></figure> </t>
<t>The process of getting role tokens has a problem that is not part of the normal XACML design. It is possible to compute a partial result based on the current set of attributes that have been supplied by the client, while having other role tokens that cannot be provided to the client since required attributes have not been provided. Since this is not part of the standard XACML model, one only has a single access/deny decision and if the attributes have not been provided then the response would be deny, we need to look at it in a bit more detail here. </t>
<t>In the process of discussions three different solutions to the problem were considered: <list><t>A signal could be added that allows for the client to signal that it cannot provide any more attributes to the server. This would allow for a final decision to be provided, but would potentially involve an additional round trip as the set of attributes can be determined based on the set of attributes provided. Supplying new attributes from the client can result in the server asking for new attributes from the client. This is not currently supported by the XACML model and there is no clear point where it would go into our model. </t><t>The server can return a partial result on each round trip. This maps directly onto the XACML model, but leads to some other problems. It means that all of the policies must be designed such that adding a new attribute to the policy evaluation process will not cause a policy that previously had been permitted is now denied. </t><t>A method could be added that allows for the client to state that it either does not have or does not know what an attribute is. This method would allow for the server to make a definitive answer, but it requires that one extra round trip be made to get the final answer. </t></list> </t>
<t>The normal mode that Plasma servers are expected to operate in is returning incremental results, however they can also keep internal state looking at what additional attributes are being provided by the client. If the client provides no new attributes, then the server can return a set of role tokens close down the conversation. If the server expects to get all attributes from the back end, and just get authentication from client, then it can return a set of role tokens immediately without providing a list of attributes to the client for it to try and satisfy. </t>
<section title="RoleToken XML element" toc="default"><t>The eps:PlasmaReturnToken element is used to return a role token to the client. Multiple role tokens can be returned by using multiple eps:PlasmaReturnToken elements. Each role token returned contains one or more policies that can be asserted, the role token, and optionally one or more set of obligations or advice that need to be observed when creating messages. 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><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<xs:element name="RoleToken" type="eps:RoleTokenType"/>
<xs:complexType name="RoleTokenType">
<xs:sequence>
<xs:element name="FriendlyName" type="xs:string"/>
<xs:element name="PDP" type="xs:anyURI" maxOccurs="unbounded"/>
<xs:choice>
<xs:element name="PolicyList">
<xs:complexType>
<xs:sequence>
<xs:element name="Policy" type="eps:PolicyDescType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="eps:Policy"/>
<xs:element ref="eps:PolicySet"/>
</xs:choice>
<xs:element ref="wst:RequestSecurityTokenResponse"/>
<xs:element ref="xacml:Obligations" minOccurs="0"/>
<xs:element ref="xacml:AssociatedAdvice" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PolicyDescType">
<xs:sequence>
<xs:element name="FriendlyName" type="xs:string"/>
<xs:element name="Options" minOccurs="0">
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:anyType">
<xs:attribute name="optionsType" type="xs:anyURI" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>
</xs:complexType>
</artwork></figure> <t>The eps:RoleToken element contains the following items: <list style="hanging"><t hangText="FriendlyName">This element returns a descriptive name of the role as a whole. The string returned SHOULD be selected based on the language attribute on the request message. The string is suitable for display to the user and should be indicative of the scope of the role. Examples of role descriptive strings would be "Company President", "Senior Executive", "Project X Electrical Engineer".</t><t hangText="PDP">The element provides one or more URLs to be used for contacting 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.<cref source="JLS">Should perhaps rename to be more understandable - perhaps Server</cref></t><t hangText="PolicyList">contains the description of one or more policies that can be asserted using the issued role 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="Policy">contains a single simple policy. This element is returned as part of a read message token. The purposes is to allow for a recipient to reply to a message that they would not normally be able to assert. </t><t hangText="PolicySet">contains a complex policy. This element is returned as part of a read message token The purpose is to allow for a recipient to reply to a message that they would not normally be able to assert. </t><t hangText="wst:RequestSecurityTokenResponse">contains the actual token itself.</t><t hangText="xacml:Obligations">This optional element contains a set of obligations that the client is required to enforce in order to use any of the policies listed when combined with the returned security token. These obligations can include items such as required algorithms or required operational steps such as requiring a signature to be placed on the content. A policy can be listed in multiple role tokens and the set of obligations may be different depending on which role token is used. If the client is unable to fulfill the obligations then it MUST NOT allow the role token to be used. </t><t hangText="xacml:AssociatedAdvice">This optional element contains a set of advice statements that the client is requested to enforce when using any of the policies listed when combined with the returned security token. This advice can include items such as encryption or signature algorithms or operational steps such as requiring a signature to be placed on the content. The client is SHOULD fulfill the advice, however if it cannot fulfill the advice the role token may still be used. </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="FriendlyName">contains a display string that represents the policy. This element is localized in response to the xs:lang attribute in the eps:PlasmaRequest node.</t><t hangText="PolicyId">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 URI. </t><t hangText="Options">This element is used to inform the client what the set of options that need to be filled in as part of asserting the policy. If the client software does not understand how to set the options for the supplied type, then the client software MUST NOT allow the user to assert the policy. The option structure is identified by the URI in the optionsType attribute. This document defines one option structure for holding a list of email addresses (section <xref target="RFC822Options" pageno="false" format="default"/>). This option structure is used in the basic policies defined in <xref target="PlasmaBasicPolicy" pageno="false" format="default"/>.</t></list> </t><t>When building the wst:RequestSecurityTokenResponse element, the following should be noted: <list><t>A wst:RequestedSecurityToken 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 clients should be able to get useful information from the token itself. Information such as lifetimes need to be provided as addition elements in the response. Examples of items that could be used as security tokens are SAML statements or 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 may get revoked due to changes in the environment (for example, if the policies are updated then all existing tokens may need to be re-issued), 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 - There are three different types of crypto information that can be returned and we need to figure out how to talk about them. These are 1) a symmetric key, 2) a new asymmetric key and 3) a pre-existing asymmetric key - for example from the certificate used for authentication purposes. There is probably good ways to do 1 and 2, but I don't know how to talk about 3 at this point in time. </t></list> </t></section>
<section title="Email Address List Options" anchor="RFC822Options" toc="default">
<t>Some policies are designed to be restricted to a set of explicitly named people by the sender of the message. This policy is used for the set of basic policies defined in <xref target="PlasmaBasicPolicy" pageno="false" format="default"/>. In these cases the creator of the message specifies a set of recipients by using email address names without any decoration. </t>
<t>The Email Address List Option is identified by the uri "urn:ietf:params:xml:ns:plasma:options:emailAddrs". The type associated with the structure is a string. The string contains a space separated set of internalized email addresses. Domains SHOULD be encoded as U-labels rather than using puny code. </t>
<t>All Plasma clients and servers MUST be able to create, parse and use the Email Address List Option for any policy. </t>
<t>As of the release of this document, Plasma clients and servers are not expected to understand any other options. </t>
</section>
</section>
</section>
<section title="Sending An Email" anchor="sendMessage" toc="default">
<t>After having obtained a role token from a Plasma server, the client can then prepare to send an Email 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 Email 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 email. 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 send mail request token can be found in <xref target="GetCMSTokenRequest" pageno="false" format="default"/>. </t>
<section title="Send Message Request" anchor="sendMessage-Request" toc="default">
<t>The send message request is built using the eps:PlasmaRequest XML structure. When building the request, the following applies: <list style="symbols"><t>The eps:Authentication element MUST be included in the initial message. The role token that authorizes the use of the label MUST be included in the initial message. If the role token is dependent on a cryptographic key for authentication, then that authentication MUST be included in the initial message. </t><t>The client MUST include an action attribute. This document defines the GetSendCMSToken action attribute for this purpose. </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" pageno="false" format="default"/>. </t><t>If the client is using the XML Digital Signature element in this message, then the client MUST include the cryptographic channel binding token (<xref target="ChannelBind" pageno="false" format="default"/>) in the set of XACML attributes. </t></list> </t>
<t>A message requesting that a CMS message token be created looks like this: <figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<eps:PlasmaRequest>
<eps:Authentication>
<eps:WS_Token>
Role Token goes here
</eps:WS_Token>
<xacml:Request>
<xacml:Attributes Category="...:action">
<xacml:Attribute AttributeId="urn:plasma:action-id">
<xacml:AttributeValue>
GetSendCMSToken
</xacml:AttributeValue>
</xacml:Attribute>
</xacml:Attributes>
<xacml:Attributes Category="...:data">
<xcaml:Attribute AttributeId="urn:plasma:data-id">
<xacml:AttributeValue>
Label and keys
</xacml:AttributeValue>
</xcaml:Attribute>
</xacml:Attributes>
</xacml:Request>
</eps:Authentication>
</eps:PlasmaRequest>
</artwork></figure> </t>
<section title="CMS Message Token Data Structure" anchor="MessageTokenRequest" toc="default"><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><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<xs:element name="GetCMSToken" type="eps:CMSTokenRequestType"/>
<xs:complexType name="CMSTokenRequestType">
<xs:sequence>
<xs:choice>
<xs:element ref="eps:Policy"/>
<xs:element ref="eps:PolicySet"/>
</xs:choice>
<xs:element name="Hash">
<xs:complexType>
<xs:sequence>
<xs:element ref="ds2:DigestMethod"/>
<xs:element ref="ds2:DigestValue" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="LockBox" type="eps:LockBoxType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="CEK" type="xs:hexBinary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="LockBox" type="eps:LockBoxType"/>
<xs:complexType name="LockBoxType">
<xs:sequence>
<xs:element name="Subject" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:anySimpleType">
<xs:attribute name="type" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:choice>
<xs:element name="CMSLockBox" type="xs:base64Binary"/>
<xs:element name="XMLLockBox" type="xenc:EncryptedKeyType"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
</artwork></figure> <t>When used in an xacml:Attribute, the structure is identified by: <vspace blankLines="1"/> Category = "urn:ietf:params:xml:ns:plasma:data" <vspace blankLines="0"/> AttributeId = "urn:ietf:params:xml:ns:plasma:data:CMSTokenRequest" <vspace blankLines="0"/> DataType = "urn:ietf:params:xml:schema:plasma:1.0#CMSTokenRequestType" </t><t>The elements of the structure are used as: <list style="hanging"><t hangText="Policy"><vspace blankLines="0"/> This element contains a the policy to be applied to the message when a single policy is used. </t><t hangText="PolicySet"><vspace blankLines="0"/> This element contains the policy to be applied to the message when a combination of policies is to be applied. </t><t hangText="Hash"><vspace blankLines="0"/> This element contains the hash of the encrypted content of the message that the policy is being applied to. The algorithm used to compute the hash is contained in the DigestMethod element and the value is contained in the DigestValue element. </t><t hangText="LockBox"><vspace blankLines="0"/> This optional element contains a pre-computed CMS recipient info structure for a message recipient. This element may be repeated when more than one lock box is pre-computed for recipients by the message sender. This element is used in those cases where the sender does not want to share the content encryption key with the Plasma server and the sender has the ability to retrieve the necessary keys for all of the recipients. If the #### obligation was returned for the role token, then a recipient info lock box MUST be created for the Plasma server and the CEK element MUST absent. <cref source="JLS">Do we define this obligation or remove the previous sentence?</cref> </t><t hangText="CEK"><vspace blankLines="0"/> This optional element contains the content encryption key (CEK) to decrypt the message. </t></list> One or both of CEK and Recipients elements MUST be present. </t><t>The elements of the LockBoxType structure are: <list style="hanging"><t hangText="Subject"><vspace blankLines="0"/> This element contains a subject identifier. The element can occur more than one time in situations where a subject has multiple names or a key is used by multiple subjects. 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. The format of the subject name is provided by the required type attribute of the element. All implementations MUST recognize "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" as a name type. <cref source="JLS">Call for other mandatory to implement name types</cref> Other name types MAY be recognized. </t><t hangText="CMSLockBox"><vspace blankLines="0"/> This element contains a base64 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><t hangText="XMLLockBox"><vspace blankLines="0"/> This element contains an EncryptedKeyType structure as defined by the XML Encryption standard <xref target="W3C.WD-xmlenc-core1-20101130" pageno="false" format="default"/>. If this recipien structure is placed here, it MUST NOT placed in the XML EncryptedType struture as well. </t></list> In addition, the structure allows for other formats of encrypted data structures to be included as well. Servers which do not recognize the name space and data structure MUST return an unrecognized data structure error and not process the request. </t></section>
<section title="XML Label Structure" anchor="label-info" toc="default">
<t>A client is allowed to build a complex label to be sent to the Plasma server for evaluation. While there are some cases that a simple single policy is applied to a message, it is expected that many, if not most, messages will have more than one policy applied to it with logical statements connected those policies. </t>
<t>The schema for specifying a label is: <figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<xs:element name="PolicySet" type="eps:PolicySetType"/>
<xs:complexType name="PolicySetType">
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element ref="eps:Policy"/>
<xs:element ref="eps:PolicySet"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="PolicyCombiningAlgId" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:element name="Policy" type="eps:PolicyType"/>
<xs:complexType name="PolicyType">
<xs:sequence>
<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>
</xs:complexType>
</artwork></figure> </t>
<t>The Policy and the PolicySet elements are used when specifying a policy for a message depending on whether a single policy or multiple policies are to be evaluated. </t>
<t>The Policy element is used to specify a single policy to the server along with any options that are defined for that policy. The Policy element contains: <list style="hanging"><t hangText="PolicyId"><vspace blankLines="0"/> Is an attribute that contains the URI which identifies a specific policy to be evaluated. </t><t hangText="inner content"><vspace blankLines="0"/> The content of the Policy element can be any XML element. The content is to be the set of selected options for the policy (if any exist). The schema applied to the content is based on the policy selected. </t></list> </t>
<t>The PolicySet element is used to specify a logical set of policies to be applied to the message. This element allows one to specify multiple policies along with a logic operation to combine them together. <list style="hanging"><t hangText="Policy"><vspace blankLines="0"/> This element allows for a single policy and any policy specific options for the policy to be specified. This element can occur zero or more times. </t><t hangText="PolicySet"><vspace blankLines="0"/> This element allows for a logical set of policies to be recursively evaluated. This element can occur zero or more times. </t><t hangText="PolicyCombiningAlgId"><vspace blankLines="0"/> This attribute specifies the operation to be used in combining the elements of the tree together. This specification uses the XACML policy combining algorithms from <xref target="XACML" pageno="false" format="default"/>. Servers and clients MUST support the unordered Deny-Overrides and Permit-Overrides policy combining rules. Servers SHOULD support all of the policy combining rules defined in <xref target="XACML" pageno="false" format="default"/>. Clients are expected to use a friendly name when displaying the policy combining rule to users. When displaying strings to users, the following strings are suggested: <list style="hanging"><t hangText="AND">Is used to represent either the ordered or unordered Deny-Overrides combining algorithm.</t><t hangText="OR">Is used to represent either the ordered or unordered Permit-Overrides combining algorithm.</t></list> </t></list> </t>
</section>
</section>
<section title="Send Message Response" anchor="sendMessage-Response" toc="default"><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:Decision is always included in the response. If the 'Permit' value is returned then a CMS Token Response element MUST be present.</t><t>The PlasmaReturnToken element with a eps:CMSToken content is included with a permit response. The CMSToken contains one or more CMS RecipientInfo objects to be included in the message sent. </t></list> </t><t>An example of a message returning the set of policy information is: <figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<eps:PlasmaResponse>
<xacml:Response>
<xacml:Result>
<xacml:Decision>Permit</xacml:Decision>
</xacml:Result>
</xacml:Response>
<eps:CMSToken>234e34d3</eps:CMSToken>
</eps:PlasmaResponse>
</artwork></figure> </t><t>The schema use for returning a CMS token is:</t><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<xs:element name="CMSToken" type="eps:CMSTokenResponseType"/>
<xs:complexType name="CMSTokenResponseType">
<xs:sequence>
<xs:element name="CMSLockBox" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="CMSType" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</artwork></figure> <t>This schema fragment extends the Plasma response token type and allows for the return of one or more base64 encoded RecipientInfo structures. The Plasma server can return recipient info information for any recipient that it pre-authorizes to receive the message (see Section ### of <xref target="I-D.freeman-plasma-requirements" pageno="false" format="default"/> for examples of when this would occur). Additionally the Plasma server can return a KEKRecipientInfo structure with the Plasma Other Key attribute. (For details see <xref target="I-D.schaad-plasma-cms" pageno="false" format="default"/>.) In some extremely rare cases where the Plasma server can pre-authorize the entire set of recipients , the KEKRecipientInfo structure with the Plasma Other Key Attribute may not be included in the returned set of recipients. The recipient info structure for the plasma server SHOULD be placed last in the list of recipients infos. </t><t>The CMSTokenResponse type has the following: <list style="hanging"><t hangText="CMSLockBox"><vspace blankLines="0"/> This element contains the ASN.1 encoding for a CMS RecipientInfo structure to be placed in the final message. This element will occur multiple times if there are multiple CMS RecipientInfo structures being returned from the server. </t><t hangText="CMSType"><vspace blankLines="0"/>This attribute of the RecipientInfo structure is an optional text value that identifies the type of recipient info structure returned. NOTE: This attribute is currently optional and is likely to disappear if I do not find it useful.</t></list> </t></section>
<section title="XML Message Send Request" toc="default">
<t>It is possible to do a send message request for an XML rather than a CMS message structure. The send message request is built using the eps:PlasmaRequest XML structure. When building the request, the following applies: <list style="symbols"><t>The eps:Authentication element MUST be included in the initial message. The role token that authorizes the use of the label MUST be included in the initial message. If the role token is dependent on a cryptographic key for authentication, then that authentication MUST be included in the initial message. </t><t>The client MUST include an action attribute. This document defines the GetSendXMLToken action attribute for this purpose. </t><t>The client MUST include a data attribute. This attribute contains the information that is used to build the XML Message token to be returned. There MAY be more than one data attribute but that is not a normal case. More details on this attribute are in <xref target="MessageTokenRequest" pageno="false" format="default"/>. </t><t>If the client using the XML Digital Signature element in this message, then the client MUST include the cryptographic channel binding token (<xref target="ChannelBind" pageno="false" format="default"/>) in the set of the XACML attributes. </t></list> </t>
</section>
<section title="XML Message Send Response" toc="default"><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:Decision is always included in the response. If the 'Permit' value is returned then a XML Token Response element MUST be present. </t><t>The PlasmaReturnToken element with a eps:XMLToken content is included with a permit response. The XMLToken contains one or more XML EncyptedKey objects to be included in the message sent. </t></list> </t><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<xs:element name="XMLToken" type="eps:XMLTokenResponseType"/>
<xs:complexType name="XMLTokenResponseType">
<xs:sequence>
<xs:element name="XMLLockBox" maxOccurs="unbounded" type="xenc:EncryptedKeyType"/>
</xs:sequence>
</xs:complexType>
</artwork></figure> </section>
</section>
<section title="Decoding A Message" anchor="readMessage" toc="default">
<t>When the receiving agent is ready to decrypt the email, it identifies that there is a KEKRecipientInfo object which contains a key attribute identified by id-keyatt-eps-token. It validates the signature, determines that communicating with the Plasma Service is within local policy, and then sends a request to the service to obtain the decryption 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" toc="default">
<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="I-D.schaad-plasma-cms" pageno="false" format="default"/> 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 "ParseCMSToken".</t><t>The CMS token to be cracked is identified by "CMSToken"</t><t>In the event that a reply to role token is wanted as well, then that is supplied as a separate action. <cref source="jls">We may want to require that a reply token always be returned instead of just returning it on demand.</cref> In this case the action is "GetReplyToken". </t><t>If the client is using the XML Digital Signature element in this message, then the client MUST include the cryptographic channel binding token (<xref target="ChannelBind" pageno="false" format="default"/>) in the set of XACML attributes. </t></list> </t>
<t>An example of a message returning the set of policy information is: <figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<eps:PlasmaRequest>
<eps:Authentication>...</eps:Authentication>
<xacml:Request>
<xacml:Attributes Category="...:action">
<xacml:Attribute AttributeId="..:action-id">
<xacml:AttributeValue>ParseCMSToken</xacml:AttributeValue>
</xacml:Attribute>
</xacml:Attributes>
<xacml:Attribute Category="...:data">
<xacml:Attribute AttreibuteId="..:data-id">
<xacml:AttributeValue>
Hex encoded CMS Token Value
</xacml:AttributeValue>
</xacml:Attribute>
</xacml:Attribute>
</xacml:Request>
</eps:PlasmaRequest>
</artwork></figure> </t>
<t>When used in an xacml:Attribute, the structure is identified by: <vspace blankLines="1"/> Category = "urn:ietf:params:xml:ns:plasma:data" <vspace blankLines="0"/> AttributeId = "urn:ietf:params:xml:ns:plasma:data:CMSToken" <vspace blankLines="0"/> DataType = "urn:ietf:params:xml:schema:plasma:1.0#CMSTokenResponseType </t>
</section>
<section title="Requesting Message Key Response" anchor="readMessage-Response" toc="default"><t>In response to a message key request, the Plasma server returns a decrypted key in the message key response. 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>For all other decision types the eps:CMSKey MUST be absent.</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><t>Only the CEK and CMSLockBox elements in the choice are permitted for the CMSKey tag name.</t></list> </t><t>An example of a message returning the set of policy information is: <figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<eps:PlasmaResponse>
<xacml:Response>
<xacml:Result>
<xacml:Decision>Permit</xacml:Decision>
</xacml:Result>
</xacml:Response>
<eps:CMSKey>
<eps:DisplayString>Label TExt</eps:DisplayString>
<eps:KEK>hex based KEK</eps:KEK>
</eps:CMSKey>
</eps:PlasmaResponse>
</artwork></figure> </t><t>The schema for returning the decrypted key is:</t><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<xs:element name="CMSKey" type="eps:CMSKeyResponseType"/>
<xs:complexType name="CMSKeyResponseType">
<xs:sequence>
<xs:element name="DisplayString" type="xs:string"/>
<xs:choice>
<xs:element name="CEK" type="xs:base64Binary"/>
<xs:element name="CMSLockBox" type="xs:base64Binary"/>
<xs:element name="XMLLockBox" type="enc:EncryptedKeyType"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
<xs:element ref="eps:RoleToken" minOccurs="0"/>
<xs:element ref="xacml:Attributes" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</artwork></figure> <t>This schema extends the Plasma response token type and restricts the content to the listed elements. The values returned are: <list style="hanging"><t hangText="DisplayString">returns a localized display string for the policy(s) which were applied to the message. The lang attribute on the request is used to determine which language to use for this string.</t><t hangText="CEK">returns the base64 encoded content encryption key.</t><t hangText="CMSLockBox">returns the content encryption key in the form of a CMS RecipientInfo structure.</t><t hangText="XMLLockBox">returns the content encryption key in the form of an XML Encrypted Key type.</t><t hangText="RoleToken">optionally returns a role token for replying to this message. </t><t hangText="Attributes">optionally returns a set of attributes associated with the message. </t></list> The structure allows for additional key types to be defined in other schemas and returned in this structure as well. The set of allows lock boxes to be returned is restricted by the XML tag nd not the schema. </t></section>
</section>
<section title="Plasma Attributes" toc="default">
<t>In this document a number of different XACML attributes have been defined, this section provides a more detailed description of these elements. </t>
<section title="Data Attributes" toc="default">
<section title="Channel Binding Data Attribute" anchor="ChannelBind" toc="default">
<t>The channel binding data attribute is used to provide for a binding of the TLS session that is being used to transport the Plasma messages with the content of the Plasma requests themselves. There is a need for the server to be able to validate that the cryptographic operations related to holder of key statements be made specifically for the current conversation and not be left over from a previous one as a replay attack. By deriving a cryptographic value from the shared TLS session key and signing that value we are able to do so. </t>
<t>The channel binding value to be used is created by the TLS key exporter specification defined in RFC 5705 <xref target="RFC5705" pageno="false" format="default"/>. This allows for a new cryptographic value to be derived from the existing shared secret key with additional input to defined the context in which the key is being derived. When using the exporter, the label to be input into the key exporter is "EXPORTER_PLASMA". The value to be derived is 512 bits in length, and no context is provided to the exporter. </t>
<t>When used as an XACML attribute in a request: <list><t>The category of the attribute is "urn:ietf:params:xml:ns:plasma:data".</t><t>The AttributeId attribute is "urn:ietf:params:xml:ns:plasma:data:ChannelBinding".</t><t>The Issuer attribute is absent.</t><t>The DataType is either base64Binary or hexBinary</t></list> </t>
<t>The same value is used for both the XACML channel binding data attribute and the XM1L channel binding structure defined in <xref target="Auth-Sig" pageno="false" format="default"/>. </t>
</section>
<section title="CMS Signer Info Data Attribute" anchor="SignerInfo" toc="default">
<t>In many cases a policy states that the client is required to sign the message before encrypting it. The server cannot verify that a signature is applied to the message and included, but we can require that a signature be supplied to the server. This signature can then be validated by the server (except for the message digest attribute value), and the server can take a hash of the value and return it as part of the key returned to a decrypting agent. This agent can then validate that the signature is a part of the message and complain if it absent. This means we do not have an enforcement mechanism, but we do have a way of performing an audit at a later time to see that the signature operation was carried out correctly. </t>
<t>By requiring that a signature be supplied to the server as part of the authentication process, the Plasma server can also be setup so that the supplied signature is automatically feed into archival operations. One way to do archiving is to use the data records defined in <xref target="RFC4998" pageno="false" format="default"/>. </t>
<t>The following applies when this data value is present: <list><t>The Category attribute is "urn:ietf:params:xml:ns:plasma:data".</t><t>The AttributeId attribute is "urn:ietf:params:xml:ns:plasma:data:CMSSignerInfo".</t><t>The Issuer attribute is absent.</t><t>The DataType attribute is either base64Binary or hexBinary.</t><t>The data value is a CMSSignerInfo ASN.1 encoded object.</t></list> </t>
</section>
<section title="S/MIME Capabilities Data Attribute" anchor="SMimeCaps" toc="default">
<t>Policies sometimes require that specific algorithms be used in order to meet the security needs of the policy. This attribute allows for an S/MIME Capabilities to be carried in a DER encoded SMIMECapabilities ASN.1 structure to be transmitted to the client. Details on how the S/MIME Capabilities function can be found in <xref target="RFC5751" pageno="false" format="default"/>. </t>
<t>The following attributes are to be set for the data value: <list><t>The Category attribute is "urn:ietf:params:xml:ns:plasma:data".</t><t>The AttributeId attribute is "urn:ietf:params:xml:ns:plasma:data:SMIME-Capabilties".</t><t>The Issuer attribute is absent.</t><t>The DataType attribute is either base64binary or hexBinary.</t></list> </t>
</section>
<section title="EMAIL Recipient Addreses" anchor="EmailRecipients" toc="default">
<t>In order for Plasma Servers to do pre-authentication in the Email environment, it is necessary for the set of recipient addresses to be delivered to the Plasma Server. The Plasma Server cannot reliably determine the set of recipients from the policies set on the message as the set of recipients and the set of people authorized to view the message may not have a one-to-one correspondance. People may be authorized to see the content who are not recipients of the message or visa versa. </t>
<t>The content of the attribute is a space separated list of email addresses. Each address represents an Email recipient address that the client will be placing in one or more of the recipient fields in the message submission. </t>
<t>The following attributes are to be set for the data value: <list><t>The Category for the attribute is "urn:ietf:params:xml:ns:plasma:data".</t><t>The AttributeId for the attribute is "urn:ietf:params:xml:ns:plasma:data:SMTPRecipients".</t><t>The Issuer for the attribute is absent.</t><t>The DataType for the attribute is "http://www.w3.org/2001/XMLSchema#string".</t></list> </t>
</section>
<section title="Return Lockbox Key Information" toc="default"><t>Some policies require that the content encryption key be transported wrapped by another key rather than being sent in plain text. This data value allows for this state to be indicated by the Plasma Server to the Plasma Client, and for the client to provide the necessary key information to the server. </t><t>This data attribute is returned as a missing attribute under the circumstances where it is required by the policy and has not been provided the client. This is an indication that the content encryption key needs to be returned in a lock box rather than as plain text. The Plasma Server MAY ignore this data value if it is provided in a situation where the policy does not require that the content encryption key be returned in an encrypted form. </t><t>The following attributes are to be set for this data value: <list><t>The Category for the attribute is "urn:ietf:params:xml:ns:plasma:data".</t><t>The AttributeId for the attribute is "urn:ietf:params:xml:ns:plasma:data:LockboxKey".</t><t>The issue for the attribute is absent.</t><t>The DataType for the attribute is "urn:ietf:params:xml:schema:plasma:1.0LockboxKey".</t></list> </t><t>The schema for the type LockboxKey is: </t><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<xs:complexType name="LockboxKey">
<xs:sequence>
<xs:choice>
<xs:element name="X509Certificate" type="xs:base64Binary"/>
<xs:element name="PGPKey" type="xs:base64Binary"/>
<xs:element ref="ds2:KeyInfo"/>
</xs:choice>
<xs:element name="Capabilities" type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</artwork></figure> <t>The fields of this structure are as follows: <list style="hanging"><t hangText="X509Certificate">holds a certificate with the public key to be used in building the CMS Lockbox returned containing the content encryption key.</t><t hangText="PGPKey">holds a PGP public key to be used in building the PGP lock box returned containing the content encryption key.</t><t hangText="ds2:KeyInfo">holds a public key to be used in building a CMS lock box returned containing the content encryption key.</t><t hangText="Capabilities">contains a base64 encoded SMimeCapablities ASN.1 structure allowing the client to advertise to the server which algorithms are supported for building the lockbox structure. This element is optional. If the element is omitted then the server will make the selection of algorithms to be used based solely on the pubic key. </t></list> </t></section>
</section>
<section title="Obligations and Advice" anchor="OurObligations" toc="default">
<t>Obligations and advice consist of actions that the Plasma server either requires or requests that the client PEP perform in order to gain access or before granting access to the data. These normally represent actions or restrictions that the PDP itself cannot enforce and thus are not input attributes to the policy evaluation. The same set of values can be used either as obligations or advice, the difference being that if the PEP cannot do an obligation it is required to change the policy decision. </t>
<section title="Signature Required" toc="default">
<t>Many policies require that a message be signed before it is encrypted and sent. Since the unencrypted version of message is not sent to the Plasma server, the policy cannot verify that a signature has been placed onto the signed message. The attribute is not for use as a returned obligation from an XACML decisions, rather it is for a pre-request obligations used in role responses (<xref target="getPolicy-Response" pageno="false" format="default"/>). </t>
<t>When used as an Obligation: <list><t>The ObligationId attribute is "urn:ietf:params:xml:ns:plasma:obligation:signature-required".</t><t>A S/MIME Capabilities data value can optionally be included. If it is included, then it contains the set of S/MIME capabilities that describes the set of signature algorithms from which the signature algorithm for the message MUST be selected.</t></list> </t>
</section>
<section title="Content Encryption Algorithm Required" toc="default">
<t>Occasionally a policy requires a specific set of encryption algorithms be used for a message, when this is the case then the encryption required obligation is included in the returned set of obligations. If the default set of encryption algorithms is sufficient then the obligation is omitted. </t>
<t>When used as an Obligation: <list><t>The ObligationId attribute is "urn:ietf:params:xml:schema:plasma:1.0:obligation:content-encryption".</t><t>An S/MIME Capabilities data value MUST be included containing the set of permitted encryption algorithms. The algorithms included MUST include a sufficient set of algorithms for the message to be encrypted. An absolute minimum would be a content encryption algorithm and key encryption algorithm. </t></list> </t>
</section>
<section title="Lock Box Required" toc="default">
<t>This obligation will be used in one of two situations: <list style="numbers"><t>The policy requires that the plain content encryption key not be given to the Plasma server, but instead the Plasma client is required to locate the appropriate certificates and create lock boxes for each of the message recipients. In this situation, the Plasma server would never have any access to the content encryption key and thus would be unable to provide the key to any entity. The Plasma server in this case is responsible only for the enforcement of the policy enforcement on the message access. </t><t>The policy requires that the content encryption key not be given to the Plasma server as a base64 encoded blob, but instead the Plasma client is required to use the provided certificate to create a lock box for the Plasma server. In this situation, the Plasma server does have access to the content encryption key and thus has the ability to do late binding. The Plasma server is also still responsible for the enforcement of the policy on message access. </t></list> </t>
<t>When used as an Obligation: <list><t>The ObligationId attribute is "urn:ietf:params:xml:schema:plasma:1.0:obligation:lockbox-required".</t><t>There is no data value when the client is required to create lock boxes for every recipient, i.e. early binding. </t><t>The data value is an X509 certificate when the Plasma client is required to create a lock box for the Plasma server. The certificate provided MUST have the Plasma CEK Transport EKU specified. </t></list> </t>
</section>
</section>
</section>
<section title="Certificate Profiles" toc="default">
<t>We need to put in text to express the following items: <list><t>DNS or IPAddr subject alt name to be present</t><t>Have one of four EKUs <list><t>Plasma Token EKU - Signals that it can sign and/or encrypt a plasma object</t><t>Plasma Secure Session - Use for the TLS session</t><t>Plasma CEK Transport - Used for transporting the CEK to the server in high security situations</t></list> MUST NOT have the anyPolicy EKU set </t></list> </t>
</section>
<section title="Message Transmission" toc="default">
<t>Plasma messages are sent over a TCP connection using port TBD1 on the server. The client first setups up TLS on the connection, then sends the UTF8 encoded XML message over the TLS connection as an atomic message. The XML MUST be encoded as UTF8, however the Byte Order Mark (BOM) is sent. The response comes back on the same connection. The client is responsible for closing the TLS session and the TCP connection when either no more messages are to be sent to the server or a final indeterminate state has been reached.</t>
<t>If a Plasma server receives an XML request which is not well formed XML, the server if free to close the connection without first sending an error reply.</t>
<t>The Plasma server SHOULD support TLS resumption <xref target="RFC5077" pageno="false" format="default"/>. </t>
<t>Plasma clients and server MUST support TLS 1.1 <xref target="RFC4346" pageno="false" format="default"/> and above. Implementations SHOULD NOT allow for the use of TLS 1.0 or SSL.</t>
</section>
<section title="Plasma URI Scheme" toc="default">
<section title="Plasma URI Schema Syntax" toc="default">
<t>The scheme name for is "plasma". </t>
<t>The syntax for the plasma URI Schema is: <vspace blankLines="1"/> URI = "plasma" ":" "//" authority path-empty <vspace blankLines="1"/> Using the ABNF defined in <xref target="RFC3986" pageno="false" format="default"/>. When the port component is absent, then the value of TBD1 will be used. The userinfo portion of the authority MUST be absent. </t>
</section>
<section title="Definition of Operations" toc="default">
<t>This schema is defined to provide the location of a Plasma server. The sole operation is to establish a connection to the Plasma server over which the protocol defined in this document is to run. </t>
</section>
</section>
<section title="Security Considerations" toc="default">
<t>To be supplied after we have a better idea of what the document looks like.</t>
<section title="Plasma URI Schema Considerations" toc="default">
<t>TBD </t>
</section>
</section>
<section title="IANA Considerations" anchor="IANA" toc="default">
<t>We define the following name spaces</t>
<t>New name space for the plasma documents urn:ietf:params:xml:ns:plasma</t>
<section title="Plasma Action Values" anchor="Action-Ids" toc="default">
<t>A new registry is established for Plasma server action identifiers using the tag "actions". The full urn for the registry is "urn:ietf:params:xml:ns:plasma:actions". This registry operates under a specification required policy. All entries in this registry require the following elements: <list style="symbols"><t>A string in camel case which identifies the action to be performed.</t><t>An optional XML data structure used to carry the control data for the action.</t><t>An optional XML data structure used to return the result of the action from the server.</t><t>A document reference describing the steps to be taken by the server.</t></list> </t>
<t>The registry will be initially populated with the following:</t>
<texttable title="" suppress-title="false" align="center" style="full">
<ttcol align="left">Action Id</ttcol>
<ttcol align="left">Input Structure</ttcol>
<ttcol align="left">Output Structure</ttcol>
<c>GetRoleTokens</c>
<c>none</c>
<c>eps:RoleToken</c>
<c>GetSendCMSToken</c>
<c>eps:GetCMSToken</c>
<c>eps:CMSLockBox</c>
<c>ParseCMSToken</c>
<c>eps:CMSLockBox</c>
<c>eps:CMSKey</c>
<c>GetReplyToken</c>
<c>none</c>
<c>eps:RoleToken</c>
</texttable>
<t>When these actions are placed in an xacml:Request, <list style="symbols"><t>the Category is "urn:oasis:names:tc:xacml:3.0:attribute-category:action",</t><t>the AttributeId is "urn:ietf:params:xml:ns:plasma:actions",</t><t>the DataType is "http://www.w3.org/2001/XMLSchema#string"</t></list> </t>
</section>
<section title="non" toc="default">
<t>Define a new data name space urn:ietf:params:xml:ns:plasma:data <list><t>CMSToken</t><t>ChannelBinding</t><t>SMIME-Capabilities</t></list> </t>
<t>Define a new name space for status codes at urn:ietf:params:xml:ns:plasma:status. The initial set of values is <list style="hanging"><t hangText="authentication-error">This identifier indicates that the authentication methods failed to successfully complete.</t></list> </t>
<t>Define a new name space for obligations. The same namespace will be used both for obligations and for advice and the values may appear in either section. <list style="hanging"><t hangText="signature-required">This identifier indicates that that the encrypted body must contain a signature element. The data value of this type shall be "http://www.w3.org/2001/XMLSchema#hexBinary" and the data structure shall consist of a DER encoded CMSCapabilities structure <xref target="RFC5751" pageno="false" format="default"/> with the list of permitted signature algorithms. If there are no restrictions on the algorithms or the restriction is implicit, then the data value MAY be omitted.</t><t hangText="encryption-algorithms">see above </t><t hangText="ambigous-identity">The identity of the client is either not stated in a form the Plasma server understands, or there are multiple identities in the authentication data. To remedy this situation, the client includes an explicit identity in the xacml:Reqeust element.</t></list> </t>
<t>We define a schema in appendix A at urn:ietf:params:xml:schema:plasma:1.0:RFCTBD</t>
<t>Define a new Status Code for use in the Status URI field. <list><t>urn:ietf:params:xml:ns:plasma:status:gss-api-response - This status is returned only with Indefinite responses. Indicates a GSS-API response object was returned in the GSSAPIResponse token type. Will return until authentication has been completed.</t></list> </t>
</section>
<section title="Port Assignment" toc="default">
<t>We request that IANA assign a new port for the use of this protocol.</t>
<t>Service name: plasma</t>
<t>Port Number: TBD1</t>
<t>Transport Protocol: TCP</t>
<t>Description: Plasma Service Protocol</t>
<t>Reference: This document</t>
<t>Assignee: iesg@ietf.org</t>
<t>Contact: chair@ietf.org</t>
<t>Notes: The protocol requires that TLS be used to communicate over this port. There is no provision for unsecure messages to be sent to this protocol.</t>
</section>
</section>
<section title="Open Issues" toc="default">
<t>List of Open Issues: <list style="symbols"><t>JLS: Should we require that any SignatureProperty be present for XML Signature elements?</t><t>JLS: Need to figure out an appropriate way to reference the assertion from a dig sig element. Could use a special version of RetrievalMethod with a transform, but that does not seem correct. May need to define a new KeyInfo structure to do it.</t><t>JLS: Should X.509 certificates and attribute certificates be fully specified as an authentication method?</t><t>JLS: Should a SignerInfo attribute be placed under the access-subject Category for a senders version and under Environment for a machine version? Currently both are under Data</t><t>JLS: Need an obligation to say that CEK must be encrypted. Do we also need to have recipient info structures encrypted?</t></list> </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><reference anchor="RFC2119"><front><title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title><author initials="S." surname="Bradner" fullname="Scott Bradner"><organization>Harvard University</organization><address><postal><street>1350 Mass. Ave.</street><street>Cambridge</street><street>MA 02138</street></postal><phone>- +1 617 495 3864</phone><email>sob@harvard.edu</email></address></author><date year="1997" month="March"/><area>General</area><keyword>keyword</keyword><abstract><t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: <list><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 RFC 2119. </t></list></t><t>Note that the force of these words is modified by the requirement level of the document in which they are used. </t></abstract></front><seriesInfo name="BCP" value="14"/><seriesInfo name="RFC" value="2119"/><format type="TXT" octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt"/><format type="HTML" octets="17970" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/><format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/></reference> <reference anchor="I-D.schaad-plasma-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 Progress" value="draft-schaad-plamsa-cms"/></reference><reference anchor="XML-Signature" target="http://www.w3.org/TR/2008/REC-xmldsig-core-20080610"><front><title>XML Signature Syntax and Processing (Second Edition)</title><author initials="T." surname="Roessler" fullname="Thomas Roessler"><organization/></author><author initials="J." surname="Reagle" fullname="Joseph Reagle"><organization/></author><author initials="F." surname="Hirsch" fullname="Frederick Hirsch"><organization/></author><author initials="D." surname="Eastlake" fullname="Donald Eastlake"><organization/></author><author initials="D." surname="Solo" fullname="David Solo"><organization/></author><date month="June" day="10" year="2008"/></front><seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xmldsig-core-20080610"/><format type="HTML" target="http://www.w3.org/TR/2008/REC-xmldsig-core-20080610"/></reference> <reference anchor="XML-C14N11" target="http://www.w3.org/TR/2008/REC-xml-c14n11-20080502"><front><title>Canonical XML Version 1.1</title><author initials="J." surname="Boyer" fullname="John Boyer"><organization/></author><author initials="G." surname="Marcy" fullname="Glenn Marcy"><organization/></author><date month="May" day="2" year="2008"/></front><seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-c14n11-20080502"/><format type="HTML" target="http://www.w3.org/TR/2008/REC-xml-c14n11-20080502"/></reference> <reference anchor="WS-TRUST" target="http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.html"><front><title>WS-Trust 1.4</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-200902"/><format type="HTML" target="http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/ws-trust.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><reference anchor="I-D.freeman-plasma-requirements"><front><title>Requirements for Message Access Control</title><author initials="T." surname="Freeman"/><author initials="J." surname="Schaad"/><author initials="P." surname="Patterson"/><date month="October" year="2011"/></front><seriesInfo name="Work in progress" value="draft-freeman-message-access-control"/></reference><reference anchor="OASIS-CORE"><front><title>Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0</title><author initials="S." surname="Cantor" role="editor"/><author initials="J." surname="Kemp" role="editor"/><author initials="R." surname="Philpott" role="editor"/><author initials="E." surname="Maler" role="editor"/><date month="March" day="15" year="2005"/></front><seriesInfo name="OASIS Standard" value="saml-core-2.0-os"/></reference><reference anchor="RFC5705"><front><title>Keying Material Exporters for Transport Layer Security (TLS)</title><author initials="E." surname="Rescorla" fullname="E. Rescorla"><organization/></author><date year="2010" month="March"/><abstract><t>A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5705"/><format type="TXT" octets="16346" target="http://www.rfc-editor.org/rfc/rfc5705.txt"/></reference> <reference anchor="RFC5751"><front><title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification</title><author initials="B." surname="Ramsdell" fullname="B. Ramsdell"><organization/></author><author initials="S." surname="Turner" fullname="S. Turner"><organization/></author><date year="2010" month="January"/><abstract><t>This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2. S/MIME provides a consistent way to send and receive secure MIME data. Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin. Encryption provides data confidentiality. Compression can be used to reduce data size. This document obsoletes RFC 3851. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5751"/><format type="TXT" octets="98638" target="http://www.rfc-editor.org/rfc/rfc5751.txt"/></reference> <reference anchor="RFC7055"><front><title>A GSS-API Mechanism for the Extensible Authentication Protocol</title><author initials="S." surname="Hartman" fullname="S. Hartman"><organization/></author><author initials="J." surname="Howlett" fullname="J. Howlett"><organization/></author><date year="2013" month="December"/><abstract><t>This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Extensible Authentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL) applications use the Extensible Authentication Protocol.</t></abstract></front><seriesInfo name="RFC" value="7055"/><format type="TXT" octets="87564" target="http://www.rfc-editor.org/rfc/rfc7055.txt"/></reference> </references>
<references title="Informative References"><reference anchor="RFC5554"><front><title>Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings</title><author initials="N." surname="Williams" fullname="N. Williams"><organization/></author><date year="2009" month="May"/><abstract><t>This document clarifies and generalizes the Generic Security Service Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5554"/><format type="TXT" octets="8173" target="http://www.rfc-editor.org/rfc/rfc5554.txt"/></reference> <reference anchor="RFC2743"><front><title abbrev="GSS-API">Generic Security Service Application Program Interface Version 2, Update 1</title><author initials="J." surname="Linn" fullname="John Linn"><organization>RSA Laboratories</organization><address><postal><street>20 Crosby Drive</street><city>Bedford</city><region>MA</region><code>01730</code><country>US</country></postal><phone>+1 781 687 7817</phone><email>jlinn@rsasecurity.com</email></address></author><date year="2000" month="January"/><abstract><t>The Generic Security Service Application Program Interface (GSS-API), Version 2, as defined in, provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications:</t><t>documents defining specific parameter bindings for particular language environments</t><t>documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms</t><t>This memo obsoletesmaking specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track.</t></abstract></front><seriesInfo name="RFC" value="2743"/><format type="TXT" octets="229418" target="http://www.rfc-editor.org/rfc/rfc2743.txt"/></reference> <reference anchor="RFC4346"><front><title>The Transport Layer Security (TLS) Protocol Version 1.1</title><author initials="T." surname="Dierks" fullname="T. Dierks"><organization/></author><author initials="E." surname="Rescorla" fullname="E. Rescorla"><organization/></author><date year="2006" month="April"/><abstract><t>This document specifies Version 1.1 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="4346"/><format type="TXT" octets="187041" target="http://www.rfc-editor.org/rfc/rfc4346.txt"/></reference> <reference anchor="RFC4998"><front><title>Evidence Record Syntax (ERS)</title><author initials="T." surname="Gondrom" fullname="T. Gondrom"><organization/></author><author initials="R." surname="Brandner" fullname="R. Brandner"><organization/></author><author initials="U." surname="Pordesch" fullname="U. Pordesch"><organization/></author><date year="2007" month="August"/><abstract><t>In many scenarios, users must be able prove the existence and integrity of data, including digitally signed data, in a common and reproducible way over a long and possibly undetermined period of time. This document specifies the syntax and processing of an Evidence Record, a structure designed to support long-term non-repudiation of existence of data. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="4998"/><format type="TXT" octets="66888" target="http://www.rfc-editor.org/rfc/rfc4998.txt"/></reference> <reference anchor="RFC5077"><front><title>Transport Layer Security (TLS) Session Resumption without Server-Side State</title><author initials="J." surname="Salowey" fullname="J. Salowey"><organization/></author><author initials="H." surname="Zhou" fullname="H. Zhou"><organization/></author><author initials="P." surname="Eronen" fullname="P. Eronen"><organization/></author><author initials="H." surname="Tschofenig" fullname="H. Tschofenig"><organization/></author><date year="2008" month="January"/><abstract><t>This document describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state. The TLS server encapsulates the session state into a ticket and forwards it to the client. The client can subsequently resume a session using the obtained ticket. This document obsoletes RFC 4507. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5077"/><format type="TXT" octets="41989" target="http://www.rfc-editor.org/rfc/rfc5077.txt"/></reference> <reference anchor="RFC3986"><front><title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title><author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"><organization abbrev="W3C/MIT">World Wide Web Consortium</organization><address><postal><street>Massachusetts Institute of Technology</street><street>77 Massachusetts Avenue</street><city>Cambridge</city><region>MA</region><code>02139</code><country>USA</country></postal><phone>+1-617-253-5702</phone><facsimile>+1-617-258-5999</facsimile><email>timbl@w3.org</email><uri>http://www.w3.org/People/Berners-Lee/</uri></address></author><author initials="R." surname="Fielding" fullname="Roy T. Fielding"><organization abbrev="Day Software">Day Software</organization><address><postal><street>5251 California Ave., Suite 110</street><city>Irvine</city><region>CA</region><code>92617</code><country>USA</country></postal><phone>+1-949-679-2960</phone><facsimile>+1-949-679-2972</facsimile><email>fielding@gbiv.com</email><uri>http://roy.gbiv.com/</uri></address></author><author initials="L." surname="Masinter" fullname="Larry Masinter"><organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization><address><postal><street>345 Park Ave</street><city>San Jose</city><region>CA</region><code>95110</code><country>USA</country></postal><phone>+1-408-536-3024</phone><email>LMM@acm.org</email><uri>http://larry.masinter.net/</uri></address></author><date year="2005" month="January"/><area>Applications</area><keyword>uniform resource identifier</keyword><keyword>URI</keyword><keyword>URL</keyword><keyword>URN</keyword><keyword>WWW</keyword><keyword>resource</keyword><abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. </t></abstract></front><seriesInfo name="STD" value="66"/><seriesInfo name="RFC" value="3986"/><format type="TXT" octets="141811" target="http://www.rfc-editor.org/rfc/rfc3986.txt"/><format type="HTML" octets="214067" target="http://xml.resource.org/public/rfc/html/rfc3986.html"/><format type="XML" octets="163534" target="http://xml.resource.org/public/rfc/xml/rfc3986.xml"/></reference> <reference anchor="SAML-XACML"><front><title>SAML 2.0 profile of XACML v2.0</title><author initials="A." surname="Anderson" role="editor"/><author initials="H." surname="Lockhart" role="editor"/><date month="February" day="1" year="2005"/></front><seriesInfo name="OASIS Standard" value="access_control-xacml-2.0-saml-profile-spec-os.pdf"/></reference><reference anchor="PlasmaBasicPolicy"><front><title>IETF Defined Plasma Policies</title><author initials="A." surname="Anon"/><date month="February" day="1" year="2005"/></front></reference><reference anchor="SOAP11"><front><title>Simple Object Access Protocol (SOAP) 1.1</title><author initials="D" surname="Box" fullname="Don Box"><organization/></author><author initials="D" surname="Ehnebuske" fullname="David Ehnebuske"><organization/></author><author initials="G" surname="Kakivaya" fullname="Gopal Kakivaya"><organization/></author><author initials="A" surname="Layman" fullname="Andrew Layman"><organization/></author><author initials="N" surname="Mendelsohn" fullname="Noah Mendelsohn"><organization/></author><author initials="H" surname="Nielsen" fullname="Henrik Frystyk Nielsen"><organization/></author><author initials="S" surname="Thatte" fullname="Satish Thatte"><organization/></author><author initials="D" surname="Winer" fullname="Dave Winer"><organization/></author><date month="May" day="8" year="2000"/></front><seriesInfo name="W3C NOTE" value="NOTE-SOAP-20000508"/><format type="HTML" target="http://www.w3.org/TR/2000/NOTE-SOAP-20000508"/></reference> <reference anchor="SOAP12" target="http://www.w3.org/TR/2007/REC-soap12-part1-20070427"><front><title>SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)</title><author initials="Y." surname="Lafon" fullname="Yves Lafon"><organization/></author><author initials="M." surname="Gudgin" fullname="Martin Gudgin"><organization/></author><author initials="M." surname="Hadley" fullname="Marc Hadley"><organization/></author><author initials="J." surname="Moreau" fullname="Jean-Jacques Moreau"><organization/></author><author initials="N." surname="Mendelsohn" fullname="Noah Mendelsohn"><organization/></author><author initials="A." surname="Karmarkar" fullname="Anish Karmarkar"><organization/></author><author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen"><organization/></author><date month="April" day="27" year="2007"/></front><seriesInfo name="World Wide Web Consortium Recommendation" value="REC-soap12-part1-20070427"/><format type="HTML" target="http://www.w3.org/TR/2007/REC-soap12-part1-20070427"/></reference> <reference anchor="I-D.ietf-emu-eap-tunnel-method"><front><title>Tunnel EAP Method (TEAP) Version 1</title><author initials="H" surname="Zhou" fullname="Hao Zhou"><organization/></author><author initials="N" surname="Cam-Winget" fullname="Nancy Cam-Winget"><organization/></author><author initials="J" surname="Salowey" fullname="Joseph Salowey"><organization/></author><author initials="S" surname="Hanna" fullname="Stephen Hanna"><organization/></author><date month="September" day="30" year="2013"/><abstract><t>This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server.</t></abstract></front><seriesInfo name="Internet-Draft" value="draft-ietf-emu-eap-tunnel-method-09"/><format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-tunnel-method-09.txt"/></reference> <reference anchor="RFC7029"><front><title>Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding</title><author initials="S." surname="Hartman" fullname="S. Hartman"><organization/></author><author initials="M." surname="Wasserman" fullname="M. Wasserman"><organization/></author><author initials="D." surname="Zhang" fullname="D. Zhang"><organization/></author><date year="2013" month="October"/><abstract><t>As the Extensible Authentication Protocol (EAP) evolves, EAP peers rely increasingly on information received from the EAP server. EAP extensions such as channel binding or network posture information are often carried in tunnel methods; peers are likely to rely on this information. Cryptographic binding is a facility described in RFC 3748 that protects tunnel methods against man-in-the-middle attacks. However, cryptographic binding focuses on protecting the server rather than the peer. This memo explores attacks possible when the peer is not protected from man-in-the-middle attacks and recommends cryptographic binding based on an Extended Master Session Key, a new form of cryptographic binding that protects both peer and server along with other mitigations.</t></abstract></front><seriesInfo name="RFC" value="7029"/><format type="TXT" octets="45360" target="http://www.rfc-editor.org/rfc/rfc7029.txt"/></reference> <reference anchor="RFC5891"><front><title>Internationalized Domain Names in Applications (IDNA): Protocol</title><author initials="J." surname="Klensin" fullname="J. Klensin"><organization/></author><date year="2010" month="August"/><abstract><t>This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS-TRACK]</t></abstract></front><seriesInfo name="RFC" value="5891"/><format type="TXT" octets="38105" target="http://www.rfc-editor.org/rfc/rfc5891.txt"/></reference> <reference anchor="W3C.WD-xmlenc-core1-20101130" target="http://www.w3.org/TR/2010/WD-xmlenc-core1-20101130"><front><title>XML Encryption Syntax and Processing Version 1.1</title><author initials="T." surname="Roessler" fullname="Thomas Roessler"><organization/></author><author initials="J." surname="Reagle" fullname="Joseph Reagle"><organization/></author><author initials="F." surname="Hirsch" fullname="Frederick Hirsch"><organization/></author><author initials="D." surname="Eastlake" fullname="Donald Eastlake"><organization/></author><date month="November" day="30" year="2010"/></front><seriesInfo name="World Wide Web Consortium LastCall" value="WD-xmlenc-core1-20101130"/><format type="HTML" target="http://www.w3.org/TR/2010/WD-xmlenc-core1-20101130"/></reference> </references>
<section title="XML Schema" toc="default"><t>This appendix represents the entirety of the XML Schema for Plasma documents.</t><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSpy v2007 rel. 3 sp1 (http://www.altova.com) by James Schaad (exmsft) -->
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust" xmlns:eps="urn:ietf:params:ns:plasma:1.0" xmlns:ds2="http://www.w3.org/2000/09/xmldsig#" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" targetNamespace="urn:ietf:params:ns:plasma:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation>
The PlasmaRequest element is one of two top level elements defined by this XSD schema.
The PlasmaRequest element is sent from the client to the server in order to
</xs:documentation>
</xs:annotation>
<xs:element name="PlasmaRequest" type="eps:RequestType"/>
<xs:complexType name="RequestType">
<xs:sequence>
<xs:element ref="eps:Authentication" minOccurs="0"/>
<xs:element ref="xacml:Request"/>
</xs:sequence>
<xs:attribute name="Version" type="xs:string" default="1.0"/>
</xs:complexType>
<xs:element name="PlasmaResponse" type="eps:ResponseType"/>
<xs:complexType name="ResponseType">
<xs:sequence>
<xs:element ref="xacml:Response"/>
<xs:element ref="eps:PlasmaReturnToken" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="Version" type="xs:string" default="1.0"/>
</xs:complexType>
<xs:element name="PlasmaReturnToken" type="eps:PlasmaReturnTokenType"/>
<xs:complexType name="PlasmaReturnTokenType">
<xs:sequence>
<xs:any namespace="##any" processContents="lax"/>
</xs:sequence>
<xs:attribute name="DecisionId" type="xs:string"/>
</xs:complexType>
<xs:element name="Authentication" type="eps:AuthenticationType"/>
<xs:complexType name="AuthenticationType">
<xs:choice maxOccurs="unbounded">
<xs:element ref="saml:Assertion"/>
<xs:element name="GSSAPI" type="xs:hexBinary"/>
<xs:element name="RoleToken">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##any" processContents="lax"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="ds2:Signature"/>
<xs:element name="Other">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:complexType>
<xs:element name="RoleToken" type="eps:RoleTokenType"/>
<xs:complexType name="RoleTokenType">
<xs:sequence>
<xs:element name="FriendlyName" type="xs:string"/>
<xs:element name="PDP" type="xs:anyURI" maxOccurs="unbounded"/>
<xs:choice>
<xs:element name="PolicyList">
<xs:complexType>
<xs:sequence>
<xs:element name="Policy" type="eps:PolicyDescType" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="eps:Policy"/>
<xs:element ref="eps:PolicySet"/>
</xs:choice>
<xs:element ref="wst:RequestSecurityTokenResponse"/>
<xs:element ref="xacml:Obligations" minOccurs="0"/>
<xs:element ref="xacml:AssociatedAdvice" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="PolicyDescType">
<xs:sequence>
<xs:element name="FriendlyName" type="xs:string"/>
<xs:element name="Options" minOccurs="0">
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:anyType">
<xs:attribute name="optionsType" type="xs:anyURI" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:element name="PolicySet" type="eps:PolicySetType"/>
<xs:complexType name="PolicySetType">
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element ref="eps:Policy"/>
<xs:element ref="eps:PolicySet"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="PolicyCombiningAlgId" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:element name="Policy" type="eps:PolicyType"/>
<xs:complexType name="PolicyType">
<xs:sequence>
<xs:any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:element name="GetCMSToken" type="eps:CMSTokenRequestType"/>
<xs:complexType name="CMSTokenRequestType">
<xs:sequence>
<xs:choice>
<xs:element ref="eps:Policy"/>
<xs:element ref="eps:PolicySet"/>
</xs:choice>
<xs:element name="Hash">
<xs:complexType>
<xs:sequence>
<xs:element ref="ds2:DigestMethod"/>
<xs:element ref="ds2:DigestValue" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="LockBox" type="eps:LockBoxType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="CEK" type="xs:hexBinary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="LockBox" type="eps:LockBoxType"/>
<xs:complexType name="LockBoxType">
<xs:sequence>
<xs:element name="Subject" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:anySimpleType">
<xs:attribute name="type" type="xs:string" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:choice>
<xs:element name="CMSLockBox" type="xs:base64Binary"/>
<xs:element name="XMLLockBox" type="xenc:EncryptedKeyType"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:element name="CMSKey" type="eps:CMSKeyResponseType"/>
<xs:complexType name="CMSKeyResponseType">
<xs:sequence>
<xs:element name="DisplayString" type="xs:string"/>
<xs:choice>
<xs:element name="CEK" type="xs:base64Binary"/>
<xs:element name="CMSLockBox" type="xs:base64Binary"/>
<xs:element name="XMLLockBox" type="enc:EncryptedKeyType"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
<xs:element ref="eps:RoleToken" minOccurs="0"/>
<xs:element ref="xacml:Attributes" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:element name="CMSToken" type="eps:CMSTokenResponseType"/>
<xs:complexType name="CMSTokenResponseType">
<xs:sequence>
<xs:element name="CMSLockBox" maxOccurs="unbounded">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="CMSType" type="xs:string"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="LockboxKey">
<xs:sequence>
<xs:choice>
<xs:element name="X509Certificate" type="xs:base64Binary"/>
<xs:element name="PGPKey" type="xs:base64Binary"/>
<xs:element ref="ds2:KeyInfo"/>
</xs:choice>
<xs:element name="Capabilities" type="xs:base64Binary" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:element name="XMLToken" type="eps:XMLTokenResponseType"/>
<xs:complexType name="XMLTokenResponseType">
<xs:sequence>
<xs:element name="XMLLockBox" maxOccurs="unbounded" type="xenc:EncryptedKeyType"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
</artwork></figure> </section>
<section title="Example: Get Roles Request" anchor="GetRoleExample" toc="default"><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><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<?xml version="1.0" encoding="UTF-8"?>
<PlasmaRequest xmlns="urn:ietf:schema:plasma:1.0"
xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:schema:plasma:1.0 C:\ietf\drafts\Schema\Plasma.xsd" >
<Authentication>
<WS-Token>123456</WS-Token>
<!-- <saml:Assertion>....</saml:Assertion> -->
</Authentication>
<xacml:Request CombinedDecision="false" ReturnPolicyIdList="false">
<xacml:Attributes Category="urn:oasis:names:tc:xaml:3.0:attribute-catagory:action">
<xacml:Attribute IncludeInResult="false" AttributeId="urn:plasma:action-id">
<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GetRoleTokens</xacml:AttributeValue>
</xacml:Attribute>
</xacml:Attributes>
<xacml:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment">
<xacml:Attribute AttributeId="urn:ietf:plasma:data:channel" IncludeInResult="false">
<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#base64Binary">ABCDEFGH</xacml:AttributeValue>
</xacml:Attribute>
</xacml:Attributes>
</xacml:Request>
</PlasmaRequest>
</artwork></figure> </section>
<section title="Example: Get Roles Response" anchor="GetRoleResponse" toc="default"><t>This section provides an example response to a successful request for a role sets.</t><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<eps:PlasmaResponse xmlns:eps="urn:ietf:params:ns:plasma:1.0">
<xacml:Response xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
<xacml:Result>
<xacml:Decision>Permit</xacml:Decision>
</xacml:Result>
</xacml:Response>
<eps:PlasmaReturnToken>
<eps:RoleToken>
<eps:FriendlyName>Role #1</eps:FriendlyName>
<eps:PDP>plasma://localhost:8080</eps:PDP>
<eps:PolicyList>
<eps:Policy PolicyId="urn:example:PlasmaPolicies:Policy1">
<eps:FriendlyName>Schaad Policy 1</eps:FriendlyName>
</eps:Policy>
</eps:PolicyList>
<wst:RequestSecurityTokenResponse xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<wst:RequestedSecurityToken>
<ex:MyToken xmlns:ex="http://example.com/SecurityToken">MCgMCzxDb250ZXh0IC8+AgEBMBYYFDEvMTAvMjAxMyA0OjIyOjAwIEFN</ex:MyToken>
</wst:RequestedSecurityToken>
<wst:Lifetime>
<wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2013-01-10T04:22:00</wsu:Expires>
</wst:Lifetime>
</wst:RequestSecurityTokenResponse>
<Obligations xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
<Obligation ObligationId="Obligation-Fred" />
</Obligations>
</eps:RoleToken>
</eps:PlasmaReturnToken>
<eps:PlasmaReturnToken>
<eps:RoleToken>
<eps:FriendlyName>Plasma Basic Policy</eps:FriendlyName>
<eps:PDP>plasma://localhost:8080</eps:PDP>
<eps:PolicyList>
<eps:Policy PolicyId="urn:ietf:ns:plasma:policy:basic">
<eps:FriendlyName>Plasma Basic Policy</eps:FriendlyName>
</eps:Policy>
<eps:Policy PolicyId="urn:example:PlasmaPolicies:Policy1">
<eps:FriendlyName>Schaad Policy 1</eps:FriendlyName>
</eps:Policy>
</eps:PolicyList>
<wst:RequestSecurityTokenResponse xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<wst:RequestedSecurityToken>
<ex:MyToken xmlns:ex="http://example.com/SecurityToken">MCgMCzxDb250ZXh0IC8+AgEBMBYYFDEvMTAvMjAxMyA0OjIyOjAwIEFN</ex:MyToken>
</wst:RequestedSecurityToken>
<wst:Lifetime>
<wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2013-01-10T04:22:00</wsu:Expires>
</wst:Lifetime>
</wst:RequestSecurityTokenResponse>
</eps:RoleToken>
</eps:PlasmaReturnToken>
</eps:PlasmaResponse></artwork></figure> <t>In this example a role is returned that has two different policies that can be used by that role. Along with the role token, a binary secret is returned that is to be used in proving that the same entity is returning to use the roles.</t></section>
<section title="Example: Get CMS Token Request" anchor="GetCMSTokenRequest" toc="default"><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><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<eps:PlasmaRequest xmlns:eps="urn:ietf:params:ns:plasma:1.0">
<eps:Authentication>
<eps:RoleToken>
<ex:MyToken xmlns:ex="http://example.com/SecurityToken">MCgMCzxDb250ZXh0IC8+AgEBMBYYFDEvMTAvMjAxMyAxOjI3OjEyIEFN</ex:MyToken>
</eps:RoleToken>
</eps:Authentication>
<xacml:Request CombinedDecision="false" ReturnPolicyIdList="false" id="XACMLRequest" xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
<xacml:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<xacml:Attribute AttributeId="urn:ietf:params:xml:ns:params:actions" IncludeInResult="false">
<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GetCMSToken</xacml:AttributeValue>
</xacml:Attribute>
</xacml:Attributes>
<xacml:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment">
<xacml:Attribute AttributeId="urn:ietf:params:xml:ns:plasma:data:channel" IncludeInResult="false">
<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#base64Binary">tls-unique</xacml:AttributeValue>
</xacml:Attribute>
</xacml:Attributes>
<xacml:Attributes Category="urn:ietf:params:xml:ns:params:data">
<xacml:Attribute AttributeId="urn:ietf:params:xml:ns:params:data:CMSTokenRequest" IncludeInResult="false">
<xacml:AttributeValue DataType="urn:ietf:params:ns:plasma:1.0#CMSTokenRequestType">
<eps:GetCMSToken>
<eps:PolicySet PolicyCombiningAlgId="urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-overrides">
<eps:Policy PolicyId="urn:example:PlasmaPolicies:Policy1" />
</eps:PolicySet>
<eps:Hash>
<ds2:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" xmlns:ds2="http://www.w3.org/2000/09/xmldsig#" />
<ds2:DigestValue xmlns:ds2="http://www.w3.org/2000/09/xmldsig#">AQIDBAUGBwgJCg==</ds2:DigestValue>
</eps:Hash>
<eps:CEK>0102030405060708090A</eps:CEK>
</eps:GetCMSToken>
</xacml:AttributeValue>
</xacml:Attribute>
</xacml:Attributes>
</xacml:Request>
</eps:PlasmaRequest>
</artwork></figure> </section>
<section title="Example: Get CMS Token Response" anchor="GetCMSTokenResponse" toc="default"><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><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<eps:PlasmaResponse xmlns:eps="urn:ietf:params:ns:plasma:1.0">
<xacml:Response xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
<xacml:Result>
<xacml:Decision>Permit</xacml:Decision>
</xacml:Result>
</xacml:Response>
<eps:PlasmaReturnToken>
<eps:CMSLockbox>MIIQJAYJKoZIhvcNAQcCoIIQFTCCEBECAQExCzAJBgUrDgMCGgUAMIIDOQYJKoZIhvcNAQcDoIIDKjCCAyYGCSqGSIb3DQEHA6CCAxcwggMTAgEAMYIB4TCCAd0CAQAwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDVeeyr0T13xrMgLQj+cJ0iMA0GCSqGSIb3DQEBAQUABIIBAEB7LT/qFbvzz7xxan6Q01By/J8X12Mpq00jLVst0+mGl7cmsBknS6TXC13638r8ow904GMB/1YzmWVYs4Pc+p9l7UJ0MFjhVULuahMbwrpEEFg90GBvZzZXKy8syxTcyh3TwCMTpYHOJxz9DfowvSJi2TPUiXG0mXzzMkbS3yiyJasacbgmG2d9G/cYJpVDlQqMCOVui7UMlQAz3LQLa9GINTzs1I5j8uqPDwPKxKmWNJ5AYj3jb6uLsf0tD1h+mCKotjdVsC0Jx05xZ53UCYPg3K5IoK8v/hu8psH7Njq3aZ6McxgeBFKxswSD3ffipEWkwLyN0heyhvIn3/prEsAwggEnBgsqhkiG9w0BB4aNFzAUBggqhkiG9w0DBwQIirvrkunYtn+AggEAlPZGLqxBvE2sdmmzUfAljJpKredC3fUxXgvPcpf07hcDz+NRf/miOwNTCUNrXg82s1NYfhWAQEuTxDtuGq7Lwd70fohcX0mXgxGbqlaPjEVzhUQwZvJfn1r7oosJ5qzO59sKStEntQdYR5cyYXnHDO2xGE1TdB7X6ibfTubPq52UC/Lt7xRyB1HMz+eeLTl6amF1lO8VOITkAEOeI9noaePDheHMS7k0xMQMEMHYU1TN/09/2RSbMY740MEDNpidtomFv4gvhWWzGrzYNPFNtHQh/4UDhqXl9eJ+MOXRdGupV9vdt6RhGKC6krszfMV9O0vHzh750XwqxtQ38FolZ6CCChEwggSKMIIDcqADAgECAhAn9OoR9HqGxG6du26pFwcHMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOB4TCB3jAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9jYS5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDANBgkqhkiG9w0BAQUFAAOCAQEAGdiJEW8orKYAoueHwZuQA9t+oRL9HvPi8AGplFRCa5oJxKBt15CSBANmeUNx/Phvr9t2ReI3Gj3d5FkEeKwc9ING83rPW4RyLeVGwboYESnzy0l5hzy6bQWdpG1oT61yFDaoubH9v89/8KRqlDVQj8+BbVWx3VkwSt9toJxkH0l87za79ONp9Pg5j1qtS4U6tw7t088NRKL7BL/kL3COJftaVAaz0MS8bY37czIs6ZuEJC3Wf5F6aAJQHw4/TenM9btn6NwcLjv8Ts3+Ao7jqBMKpSZEZekQ8k1Sp67cPsprMlxBbP71XaDq/9H6m4ZYbT2WR+X+LpUEwgDMjqHyuzCCBX8wggRnoAMCAQICEQDVeeyr0T13xrMgLQj+cJ0iMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDUyNzAwMDAwMFoXDTEyMDUyNjIzNTk1OVowKTEnMCUGCSqGSIb3DQEJARYYamltc2NoYWFkQHpzLnBlbmFuZ28ubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBLgJtGWe6ib5nTzwL2QAVPwQCUeTl0ItoLig2/WhKcrZJIcM9c/opX6Mi7V44v38hFxwurjJplF74xLp5IqhaPGXHf0t8Yas/F06UnZyMlXQ197jCIkqChfqnOxDJ+7zASoveRt6aNyFJRy3eJyYasqbURvmdBYom1UOYxfWrIM9VaulvW5TCiJIpbKiEwdIcs+JCLuNs/OgtFXB7C+IjIw1C7ZTxBD9Q8g9RRr/TvmhGQ1Ru1BL7g52+Hs1vrAtjENxwmJwrZSsJHgMw5FfDbVLrwOI97iCWnrQ8acFiS5iRFGqWzQCJyWhJFHYvuw7RzQg761+tin8hpue2OsEwIDAQABo4ICGjCCAhYwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFNltOqTDux3i8fOkK7gnr5Zo/FEfMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAjBgNVHREEHDAagRhqaW1zY2hhYWRAenMucGVuYW5nby5uZXQwDQYJKoZIhvcNAQEFBQADggEBAK9Ndz6RqjMdXDXZ5xrkc1FYcq69Gm/yacR4Lkj35uHZ6kzndhsdcsug06879gOsW1OTFMSRYvHhYkwknLL4PKISxozVmiDvVYzYXqE+Gj4jZaNzbF8suowQCq7dS82Ggoj68C4Hh5+PyUlySmQZKnsyDuE6PxIlFlhLCmFYl9hsgRmgqe4sbB2cxZu03SYWvWI92IwwrouOtrI3JbFXJnn9obKLYj3LMRr9VrAHBd3A99VW6OMNT75b0ScuwcoS96YZutVC/y1Y65mMlGQW+FOr8sIxxFz6lsvTxEul0VXUxbfAZ0MkrRxJH0Mw3W2QUAQ3dRR81Ba/g8GNhawC+jUxggKrMIICpwIBATCBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRANV57KvRPXfGsyAtCP5wnSIwCQYFKw4DAhoFAKCBvDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcDMBwGCSqGSIb3DQEJBTEPFw0xMzAxMDgwNjQ1MTBaMCMGCSqGSIb3DQEJBDEWBBSHHd6eVaOraNTvfMOaBDOIsfS5eDArBgsqhkiG9w0BCYaNGjEcMBowDAYKKhCGSAFlAwQCAQQKAQIDBAUGBwgJCjAwBgsqhkiG9w0BCYaNGTEhDB9wbGFzbWE6cGxhc21hLmF1Z3VzdGNlbGxhcnMuY29tMA0GCSqGSIb3DQEBAQUABIIBAKUc/zlevtNMuRrfnRJA30ecoXgXr33rEsbj9xEgH+xaJwBotwLC/i7wKutjc+Z8sfUt9X+H/jNFyMFZwXYF2fgw6xKtSlkYXgTu9GioK6rpftHSifOd+aRJHMKJTeWAkwamF9XBmaWhQusDVHZmmd9uUEPNkUSo4T6r2atZ8avgMc8DhwKLw8NGf9ZhkNtJciIW76X3AO+XbUr4vIsLT1mTFr4wJ7Tk9rOnk6oyGS/q1jvgVl53xKCTP+xa1usZarYUo2u974JjADN8uGlI4gv1wH1scojgXVYp8HWe6Uh0fYFdFRmefHj5rEkiB4POVVQoq8Bsk4sJUR3+rfaM3QI=</eps:CMSLockbox>
</eps:PlasmaReturnToken>
</eps:PlasmaResponse></artwork></figure> </section>
<section title="Example: Get CMS Key Request" anchor="GetCMSKeyRequest" toc="default"><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<eps:PlasmaRequest xmlns:eps="urn:ietf:params:ns:plasma:1.0">
<eps:Authentication>
<eps:RoleToken>
<ex:MyToken xmlns:ex="http://example.com/SecurityToken">MCgMCzxDb250ZXh0IC8+AgEBMBYYFDEvMTAvMjAxMyAxOjI3OjEyIEFN</ex:MyToken>
</eps:RoleToken>
</eps:Authentication>
<xacml:Request CombinedDecision="false" ReturnPolicyIdList="false" xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
<xacml:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
<xacml:Attribute AttributeId="urn:ietf:params:xml:ns:params:actions" IncludeInResult="false">
<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GetCMSKey</xacml:AttributeValue>
</xacml:Attribute>
</xacml:Attributes>
<xacml:Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment">
<xacml:Attribute AttributeId="urn:ietf:params:xml:ns:plasma:data:channel" IncludeInResult="false">
<xacml:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#base64Binary">tls-unique</xacml:AttributeValue>
</xacml:Attribute>
</xacml:Attributes>
<xacml:Attributes Category="urn:ietf:params:xml:ns:params:data">
<xacml:Attribute AttributeId="urn:ietf:params:xml:ns:params:data:CMSKeyRequest" IncludeInResult="false">
<xacml:AttributeValue DataType="urn:ietf:params:ns:plasma:1.0#CMSLockbox">
<eps:CMSLockbox>MIIQJAYJKoZIhvcNAQcCoIIQFTCCEBECAQExCzAJBgUrDgMCGgUAMIIDOQYJKoZIhvcNAQcDoIIDKjCCAyYGCSqGSIb3DQEHA6CCAxcwggMTAgEAMYIB4TCCAd0CAQAwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDVeeyr0T13xrMgLQj+cJ0iMA0GCSqGSIb3DQEBAQUABIIBAEB7LT/qFbvzz7xxan6Q01By/J8X12Mpq00jLVst0+mGl7cmsBknS6TXC13638r8ow904GMB/1YzmWVYs4Pc+p9l7UJ0MFjhVULuahMbwrpEEFg90GBvZzZXKy8syxTcyh3TwCMTpYHOJxz9DfowvSJi2TPUiXG0mXzzMkbS3yiyJasacbgmG2d9G/cYJpVDlQqMCOVui7UMlQAz3LQLa9GINTzs1I5j8uqPDwPKxKmWNJ5AYj3jb6uLsf0tD1h+mCKotjdVsC0Jx05xZ53UCYPg3K5IoK8v/hu8psH7Njq3aZ6McxgeBFKxswSD3ffipEWkwLyN0heyhvIn3/prEsAwggEnBgsqhkiG9w0BB4aNFzAUBggqhkiG9w0DBwQIirvrkunYtn+AggEAlPZGLqxBvE2sdmmzUfAljJpKredC3fUxXgvPcpf07hcDz+NRf/miOwNTCUNrXg82s1NYfhWAQEuTxDtuGq7Lwd70fohcX0mXgxGbqlaPjEVzhUQwZvJfn1r7oosJ5qzO59sKStEntQdYR5cyYXnHDO2xGE1TdB7X6ibfTubPq52UC/Lt7xRyB1HMz+eeLTl6amF1lO8VOITkAEOeI9noaePDheHMS7k0xMQMEMHYU1TN/09/2RSbMY740MEDNpidtomFv4gvhWWzGrzYNPFNtHQh/4UDhqXl9eJ+MOXRdGupV9vdt6RhGKC6krszfMV9O0vHzh750XwqxtQ38FolZ6CCChEwggSKMIIDcqADAgECAhAn9OoR9HqGxG6du26pFwcHMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOB4TCB3jAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9jYS5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDANBgkqhkiG9w0BAQUFAAOCAQEAGdiJEW8orKYAoueHwZuQA9t+oRL9HvPi8AGplFRCa5oJxKBt15CSBANmeUNx/Phvr9t2ReI3Gj3d5FkEeKwc9ING83rPW4RyLeVGwboYESnzy0l5hzy6bQWdpG1oT61yFDaoubH9v89/8KRqlDVQj8+BbVWx3VkwSt9toJxkH0l87za79ONp9Pg5j1qtS4U6tw7t088NRKL7BL/kL3COJftaVAaz0MS8bY37czIs6ZuEJC3Wf5F6aAJQHw4/TenM9btn6NwcLjv8Ts3+Ao7jqBMKpSZEZekQ8k1Sp67cPsprMlxBbP71XaDq/9H6m4ZYbT2WR+X+LpUEwgDMjqHyuzCCBX8wggRnoAMCAQICEQDVeeyr0T13xrMgLQj+cJ0iMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDUyNzAwMDAwMFoXDTEyMDUyNjIzNTk1OVowKTEnMCUGCSqGSIb3DQEJARYYamltc2NoYWFkQHpzLnBlbmFuZ28ubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBLgJtGWe6ib5nTzwL2QAVPwQCUeTl0ItoLig2/WhKcrZJIcM9c/opX6Mi7V44v38hFxwurjJplF74xLp5IqhaPGXHf0t8Yas/F06UnZyMlXQ197jCIkqChfqnOxDJ+7zASoveRt6aNyFJRy3eJyYasqbURvmdBYom1UOYxfWrIM9VaulvW5TCiJIpbKiEwdIcs+JCLuNs/OgtFXB7C+IjIw1C7ZTxBD9Q8g9RRr/TvmhGQ1Ru1BL7g52+Hs1vrAtjENxwmJwrZSsJHgMw5FfDbVLrwOI97iCWnrQ8acFiS5iRFGqWzQCJyWhJFHYvuw7RzQg761+tin8hpue2OsEwIDAQABo4ICGjCCAhYwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFNltOqTDux3i8fOkK7gnr5Zo/FEfMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAjBgNVHREEHDAagRhqaW1zY2hhYWRAenMucGVuYW5nby5uZXQwDQYJKoZIhvcNAQEFBQADggEBAK9Ndz6RqjMdXDXZ5xrkc1FYcq69Gm/yacR4Lkj35uHZ6kzndhsdcsug06879gOsW1OTFMSRYvHhYkwknLL4PKISxozVmiDvVYzYXqE+Gj4jZaNzbF8suowQCq7dS82Ggoj68C4Hh5+PyUlySmQZKnsyDuE6PxIlFlhLCmFYl9hsgRmgqe4sbB2cxZu03SYWvWI92IwwrouOtrI3JbFXJnn9obKLYj3LMRr9VrAHBd3A99VW6OMNT75b0ScuwcoS96YZutVC/y1Y65mMlGQW+FOr8sIxxFz6lsvTxEul0VXUxbfAZ0MkrRxJH0Mw3W2QUAQ3dRR81Ba/g8GNhawC+jUxggKrMIICpwIBATCBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRANV57KvRPXfGsyAtCP5wnSIwCQYFKw4DAhoFAKCBvDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcDMBwGCSqGSIb3DQEJBTEPFw0xMzAxMDgwNjQ1MTBaMCMGCSqGSIb3DQEJBDEWBBSHHd6eVaOraNTvfMOaBDOIsfS5eDArBgsqhkiG9w0BCYaNGjEcMBowDAYKKhCGSAFlAwQCAQQKAQIDBAUGBwgJCjAwBgsqhkiG9w0BCYaNGTEhDB9wbGFzbWE6cGxhc21hLmF1Z3VzdGNlbGxhcnMuY29tMA0GCSqGSIb3DQEBAQUABIIBAKUc/zlevtNMuRrfnRJA30ecoXgXr33rEsbj9xEgH+xaJwBotwLC/i7wKutjc+Z8sfUt9X+H/jNFyMFZwXYF2fgw6xKtSlkYXgTu9GioK6rpftHSifOd+aRJHMKJTeWAkwamF9XBmaWhQusDVHZmmd9uUEPNkUSo4T6r2atZ8avgMc8DhwKLw8NGf9ZhkNtJciIW76X3AO+XbUr4vIsLT1mTFr4wJ7Tk9rOnk6oyGS/q1jvgVl53xKCTP+xa1usZarYUo2u974JjADN8uGlI4gv1wH1scojgXVYp8HWe6Uh0fYFdFRmefHj5rEkiB4POVVQoq8Bsk4sJUR3+rfaM3QI=</eps:CMSLockbox>
</xacml:AttributeValue>
</xacml:Attribute>
</xacml:Attributes>
</xacml:Request>
</eps:PlasmaRequest></artwork></figure> </section>
<section title="Example: Get CMS KeyResponse" anchor="GetCMSKeyResponse" toc="default"><figure title="" suppress-title="false" alt="" width="" height=""><artwork xml:space="preserve" name="" type="" alt="" width="" height="">
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<eps:PlasmaResponse xmlns:eps="urn:ietf:params:ns:plasma:1.0">
<xacml:Response xmlns:xacml="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
<xacml:Result>
<xacml:Decision>Permit</xacml:Decision>
</xacml:Result>
</xacml:Response>
<eps:PlasmaReturnToken>
<CMSKey:eps xmlns:CMSKey="urn:ietf:params:ns:plasma:1.0">
<eps:DisplayString>Schaad Policy 1</eps:DisplayString>
<eps:CEK>AQIDBAUGBwgJCg==</eps:CEK>
</CMSKey:eps>
</eps:PlasmaReturnToken>
</eps:PlasmaResponse></artwork></figure> </section>
<section title="Enabling the MultiRequests option" toc="default">
<t>NOTE: RFC Editor please remove this section prior to publication. This section exists as a note to the author to make sure that it can be done. It will be published as a separate document if desired.</t>
<t>One of the issues in doing multiple requests in a single message is the issue of correlation between the request and the results. We have make this issue even worse by the fact that we are return results that are not input attributes for the decision and that we are not returning as attributes of the decision.</t>
<t>The best way to deal with this is by putting tags into the request and reflect them in the return values for the response. The only place that this does not work is for the GSS-API response token as this element would normally be part of the response of multiple requests. You want to finish that authentication step before issuing final decisions if the input is needed as part of that decision.</t>
<t>With this in mind what we do is the following: <list style="symbols"><t>Define a new data attribute for plasma as plasma-request-id. The category for it is urn:ietf:params:xml:ns:plasma:data. The type will be a string.</t><t>When the new attribute is used, then the return attribute flag MUST be set on the attribute.</t><t>There MUST be one entity of the new attribute, with a unique value, for each of the requests in the MultiRequest element.</t><t>Exactly one of the new attributes MUST be referenced in each request in the MultiRequest element.</t><t>The server copies the value of the attribute into the *** attribute of the returned token.</t></list> </t>
<t>We could probably relax the restrictions if we know that the token can only be returned by one request, however using the token to correlate the request and the decision is still probably desired so that those values can be correlated.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:14:00 |