Network Working Group J. Schaad Internet-Draft Soaring Hawk Consulting Intended status: Standards Track March 12, 2012 Expires: September 13, 2012 Email Policy Service Trust Processing draft-schaad-plasma-service-01 Abstract Write Me Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 13, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Schaad Expires September 13, 2012 [Page 1] Internet-Draft EPS TRUST March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. XML Nomenclature and Name Spaces . . . . . . . . . . . . . 4 1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 5 2. Components . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. WS-Trust 1.3 . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. XACML 3.0 . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Sender Processing . . . . . . . . . . . . . . . . . . . . 7 3.2. Recieving Agent Processing . . . . . . . . . . . . . . . . 8 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10 5. Plasma Request . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Authentication Element . . . . . . . . . . . . . . . . . . 12 5.2. xacml:Request Element . . . . . . . . . . . . . . . . . . 13 6. Plasma Response Element . . . . . . . . . . . . . . . . . . . 14 6.1. xacml:Response Element . . . . . . . . . . . . . . . . . . 15 7. Authentication Element . . . . . . . . . . . . . . . . . . . . 17 7.1. SAML Collection Element . . . . . . . . . . . . . . . . . 18 7.2. WS Trust Tokens . . . . . . . . . . . . . . . . . . . . . 19 7.3. XML Signature Element . . . . . . . . . . . . . . . . . . 20 7.4. GSS-API Element . . . . . . . . . . . . . . . . . . . . . 22 8. Role Token and Policy Acquisition . . . . . . . . . . . . . . 23 8.1. Role Token Request . . . . . . . . . . . . . . . . . . . . 23 8.2. Request Role Token Response . . . . . . . . . . . . . . . 25 8.2.1. PlasmaTokens XML element . . . . . . . . . . . . . . . 26 9. Sending A Message . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Send Message Request . . . . . . . . . . . . . . . . . . . 29 9.1.1. CMS Message Token Data Structure . . . . . . . . . . . 30 9.2. Send Message Response . . . . . . . . . . . . . . . . . . 32 10. Decoding A Message . . . . . . . . . . . . . . . . . . . . . . 33 10.1. Requesting Message Key . . . . . . . . . . . . . . . . . . 33 10.2. Requesting Message Key Response . . . . . . . . . . . . . 34 11. Plasma Attributes . . . . . . . . . . . . . . . . . . . . . . 36 11.1. Data Attributes . . . . . . . . . . . . . . . . . . . . . 36 11.1.1. Channel Binding Data Attribute . . . . . . . . . . . . 36 11.1.2. CMS Signer Info Data Attribute . . . . . . . . . . . . 37 11.1.3. S/MIME Capabilities Data Attribute . . . . . . . . . . 37 11.2. Obligations and Advice . . . . . . . . . . . . . . . . . . 38 11.2.1. Signature Required . . . . . . . . . . . . . . . . . . 38 11.2.2. Encryption Required . . . . . . . . . . . . . . . . . 38 12. Security Considerations . . . . . . . . . . . . . . . . . . . 40 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 43 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 15.1. Normative References . . . . . . . . . . . . . . . . . . . 44 15.2. Informative References . . . . . . . . . . . . . . . . . . 45 Schaad Expires September 13, 2012 [Page 2] Internet-Draft EPS TRUST March 2012 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 47 Appendix B. Example: Get Roles Request . . . . . . . . . . . . . 52 Appendix C. Example: Get Roles Response . . . . . . . . . . . . . 53 Appendix D. Example: Get CMS Token Request . . . . . . . . . . . 54 Appendix E. Example: Get CMS Token Response . . . . . . . . . . . 56 Appendix F. Example: Get CMS Key Request . . . . . . . . . . . . 57 Appendix G. Example: Get CMS KeyResponse . . . . . . . . . . . . 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 59 Schaad Expires September 13, 2012 [Page 3] Internet-Draft EPS TRUST March 2012 1. Introduction 1.1. XML Nomenclature and Name Spaces The following name spaces are used in this document: +-----+--------------------------------------------+----------------+ | Pre | Namespace | Specification( | | fix | | s) | +-----+--------------------------------------------+----------------+ | eps | http://ietf.org/2011/plasma/ | This | | | | Specification | | | | | | wst | http://docs.oasis-open.org/ws-sx/ws-trust/ | [WS-TRUST] | | | 200512 | | | | | | | wsu | http://docs.oasis-open.org/wss/2004/01/oas | [WS-Security] | | | is-200401-wss-wssecurity-utility-1.0.xsd | | | | | | | wss | http://docs.oasis-open.org/wss/2004/01/oas | [WS-Security] | | e | is-200401-wss-wssecurity-secext-1.0.xsd | | | | | | | wss | http://docs.oasis-open.org/wss/oasis-wss-w | [WS-Security] | | e11 | security-secext-1.1.xsd | | | | | | | xac | http://docs.oasis-open.org/xacml/3.0/xacml | [XACML] | | ml | -3.0-core-spec-cs-01-en.html | | | | | | | ds | http://www.w3.org/2000/09/xmldsig# | [XML-Signature | | | | ] | | | | | | xen | http://www.w3.org/2001/04/xmlenc# | [XML-Encrypt] | | c | | | | | | | | wsp | http://schemas.xmlsoap.org/ws/2004/09/poli | [WS-Policy] | | | cy | | | | | | | wsa | http://www.w3.org/2005/08/addressing | [WS-Addressing | | | | ] | | | | | | xs | http://www.w3.org/2001/XMLSchema | [XML-Schema1][ | | | | XML-Schema2] | +-----+--------------------------------------------+----------------+ Schaad Expires September 13, 2012 [Page 4] Internet-Draft EPS TRUST March 2012 1.2. Requirements Terminology 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 [RFC2119]. Schaad Expires September 13, 2012 [Page 5] Internet-Draft EPS TRUST March 2012 2. Components 2.1. WS-Trust 1.3 We use WS-Trust as the basis for the protocol presented in this document. WS-Trust is a secure messaging protocol used for security token exchange to enable the issuance and dissemination of credentials within different trust domains. WS-Trust 1.3 is specified by OASIS in [WS-TRUST]. WS-Trust is built on SOAP (see [SOAP12]) to provide a messaging structure. 2.2. XACML 3.0 The XACML specification (eXtensible Access Control Markup Language) [XACML] provides a framework for writing access control policies and for creating standardized access control queries and responses. For creating the query/response messages, the specification is written assuming that there is a high degree of trust in both the PEP and the PDP. If one looks at Figure 2 in [Plasma], this corresponds to the (a) case in the diagram. For this specification we are assuming that the PEP is not a trusted entity leading to some additional message wrapping and requirements. 2.3. SAML We use the SAML specification. Schaad Expires September 13, 2012 [Page 6] Internet-Draft EPS TRUST March 2012 3. Model To be supplied from the problem statement document. [anchor8] (1)(3) +----------+ +----------->|Sending |<------------+ | |Agent | | (2) v +----------+ v +----------+ ^ +---------+ |Email | | |Mail | |Policy |<----------+ |Transfer | |Service | |Agent | +----------+ +---------+ () ^ +----------+ ^ | |Receiving | | +----------->|Agent |<------------+ ()() +----------+ Figure 1: Message Access Control Actors List the boxes above and give some info about them. 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. 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. Receiving Agent is the entity that consumes the message. Sending Agent is the entity that originates the message. 3.1. Sender Processing 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 Figure 1. A more detailed description of the processing is found in Section 8 for obtaining the security policies that can be applied to a messages and Section 9 for sending a Schaad Expires September 13, 2012 [Page 7] Internet-Draft EPS TRUST March 2012 message. 1. 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 Section 8.1. 2. 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. 3. 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 Section 8.2. 4. The Sending Agent selects the Email Policy(s) to be applied to the message, along with the set of recipients for the message. 5. 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 Section 9.1. 6. The Email Policy Service creates the recipient info attribute as defined in [EPS-CMS]. 7. The Email Policy Service returns the created attribute to the Sending Agent. Details of this message can be found in Section 9.2. 8. 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. 3.2. Recieving Agent Processing 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 Figure 1. A more detailed description of the processing is found in Section 10. 1. The Receiving Agent obtains the message from the Mail Transport Agent. 2. 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. Schaad Expires September 13, 2012 [Page 8] Internet-Draft EPS TRUST March 2012 3. The Receiving Agent processes the SignedData content of the XXXX attribute to determine that communicating with it falls within accepted policy. 4. 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 Section 10.1. 5. The Email Policy Service decrypts the content of the message and applies the policy to the credentials provided by the Receiving Agent. 6. 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 Section 10.2. 7. The Receiving Agent proceeds to decrypt the message and perform normal processing. Schaad Expires September 13, 2012 [Page 9] Internet-Draft EPS TRUST March 2012 4. Protocol Overview 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 query/repsonse dialog from the client to the server. A completed dialog can consist of one or more query/response message pairs as the protocol allows for multiple round trips within a single dialog so that a client can provide additional authentication, authorization and attribute information to the server. The protocol MUST be run over a secure transport, while the protocol allows for signature operations to occur on sections of the message structure, the secure transport is responsible for providing the confidentiality and integrity protection services over the entire message. Multiple dialogs may be run over a single secure transport. 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. This is an indicator that the dialog has not yet completed. Plasma compliant implementations MUST support TLS 1.1 [RFC4346] and above as secure transports. Implementations SHOULD NOT allow for the use of TLS 1.0 or SSL. Other secure transports MAY be implemented. Schaad Expires September 13, 2012 [Page 10] Internet-Draft EPS TRUST March 2012 5. Plasma Request The specification is written using XACML as the basic structure used to frame a request for an operation to occur. The request for operations to occur are written in terms of XACML action items. This specification defines a number of actions specific to the use of this document in a CMS environment. Other specifications may define additional action items for other environments (for example the XML encryption environment) or other purposes. (It has been suggested that this basic structure could be used to standardize the dialogs between PDPs and PAPs.) 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. Additionally the authentication can be performed by the secure transport, for example TLS with client authentication by X.509 certificates or a login dialog box. The request message uses a single XML structure. This structure is the eps:PlasmaRequest object. The XML Schema used to describe this structure is: A Plasma Request will have two elements in it: Authentication is an optional element that contains the various methods of authentication that are available for use. The authentication element is also used to contain SAML assertions containing attributes about the individual being authenticated. xacml:Request is an optional 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, this is they are deemed not to come from a reliable source even in the event that an authentication is successfully completed. Attributes for the policy enforcement SHOULD NOT be self-asserted values. This element is taken from Schaad Expires September 13, 2012 [Page 11] Internet-Draft EPS TRUST March 2012 the XACML specification. Clients sending a Plasma Request to a server MUST populate one or both elements. 5.1. Authentication Element NOTE: I think this section goes away as it is covered later. The authentication type is used to carry information about the different ways that the Plasma server will allow for authentication to occur. More than one authentication field can be filled in when sending message to the server. If more than one authentication field is set, then the server can select which fields are to be used. More than one field can be used. Additionally, the authentication element can be used to transport attributes about the entity being authenticated by including a SAML assertion with the attribute values. The assertion of attributes is treated as being separate from authentication, however a single SAML assertion can contain both authentication and attribute information. The XML Schema used for the Authentication element is: The fields of this element are: SAML_Collection holds a sequence of one or more SAML assertions. These assertions can contain statements about attributes or keys for the requester. Schaad Expires September 13, 2012 [Page 12] Internet-Draft EPS TRUST March 2012 GSS_API holds a GSS-API message object. This message object will normally be using the GSS-API/EAP method defined by [ABFAB]. WS_Token holds a WS-Token obtained from some source. The most common source for a WS-Token to be obtained from will be from a previous conversation with a Plasma server. For example, one or more WS-Tokens will be returned from a Get Roles dialog. ds:Signature 5.2. xacml:Request Element We use the xacml:Request element for creating the access control request of the Plasma Server. When the request element is present, one will normally have an attribute from the urn:oasis:names:tc:xacml:3.0:attribute-category. This document defines a set of actions to be used with the server. Additional attributes can be added to the request as well. These attributes can help control what is happening to the message and provide additional data to the request. When attributes are to be provided in an authenticated manner, then they must be provided in a different manner than being placed here. Unless self-assertion is considered sufficient. For convenience the schema for the xacml:Request element is reproduced here: The use of the RequestDefaults element is possible, but will generally not be supported. The use of MultiRequest element is strongly discouraged. Schaad Expires September 13, 2012 [Page 13] Internet-Draft EPS TRUST March 2012 6. Plasma Response Element There is a single top level structure that is used by the server to respond to a client request. The XML Schema used to describe the top level response is as follows: A Plasma Response has three elements used: xacml:Response is a mandatory element that returns the status of the access request. PlasmaTokens is an optional element that will return one or more PlasmaToken elements. CMSToken is an optional element that contains the CMS Token that is included in a CMS message as part of a recipient info element. CMSKey is an optional element that contains the key to be used in decrypting a CMS message. Schaad Expires September 13, 2012 [Page 14] Internet-Draft EPS TRUST March 2012 Authentication return a GSS-API element as part of a GSS-API authentication process. Also return a challenge. A full discussion of the Authentication element can be found in Section 7. 6.1. xacml:Response Element The xacml:Response element has the ability to return both a decision, but additionally information about why a decision was not made. The schema for the xacml:Response element is reproduced here for convenience: The xacml:Response element consists of one child the Result. While the schema allows for multiple results to be returned, it is constrained to be a single Result returned in this specification as only a single request will ever be made at one time. The xacml:Response element consists of the following elements: 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. xacml:Status is an optional element returned for the Indeterminate status which provides for the reason that a decision was not able to be reached. Additionally it can contain hints for remedying the situation. This document defines a new set of status values to be returned. Formal declaration may be found in Section 13. Schaad Expires September 13, 2012 [Page 15] Internet-Draft EPS TRUST March 2012 * gss-api indicates that a gss-api message has been returned as part of the authentication process. xacml:Obligations is designed to force the PEP to perform specific actions prior to allowing access to the resource. This element is not used by Plasma and SHOULD be absent. If a response is returned with this element present, the processing MUST fail unless the PEP can perform the required action. A set of Plasma specific obligations are found in Section 11.2. 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 advoice elements are found in Section 11.2. 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. 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. Schaad Expires September 13, 2012 [Page 16] Internet-Draft EPS TRUST March 2012 7. Authentication Element One of the major goals in the Plasma work is to attempt and 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. 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: o SAML Assertions - many different types of SAML assertions are supported. The specification allows for both bearer and holder of key assertions. o X.509 Certificates can be used for the purpose of authentication by creating a signature with the XML Digital Signature standard. o 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. o WS-Trust tokens allow for much of the same type of information to be passed as SAML assertions. The Plasma specification has been designed mailing for the use of WS-Trust tokens to be used for caching prior authentication sessions. More than one authentication element may be present in any single message. This is because a client may need to provide more than one piece of data to a server in order to authenticate, for example a holder of key SAML Assertion along with a signature created with that key. Additionally a client may want to provide the server an option of different ways of doing the authentication. In a federated scenario, an X.509 certificate with a signature can be presented and the server may not be able to build a trust path to it's set of trust anchors. In this case the server may opt to use the GSS-API/EAP Schaad Expires September 13, 2012 [Page 17] Internet-Draft EPS TRUST March 2012 protocol for doing the authentication. Finally, the client may want to provide the server with a SAML Assertion that binds a number of attributes to it's identities so that the server does not need to ask for those attributes at a later time. 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 PDP 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 [XACML]. 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. The schema for the Authentication element directly maps to the ability to hold the above elements. The schema for the Authentication element is: 7.1. SAML Collection Element The SAML collection element provides a holder to place one or more SAML Assertions[anchor16]. SAML has defined three different types of assertions in it's core specification [OASIS-CORE]: o Authentication: The assertion subject was authenticated by a particular means at a particular time. Schaad Expires September 13, 2012 [Page 18] Internet-Draft EPS TRUST March 2012 o Attribute: The assertion subject is associated with the supplied attributes. o Authorization Decision: A request to allow the assertion subject to access the specified resource has been granted or denied. 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: o A bearer statement: These statements are belong to anybody who presents them. The owner is required to take the necessary precautions to protect them. o A holder of key statement: These statements belong to anybody who can use the key associated with the statement. o Subject name match: These statements can be associated to an identity by matching the name of the entity. When a holder of key identification is used, the XML Signature element is used to provide the key usage element. 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 [SAML-XACML]. 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. 7.2. WS Trust Tokens 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 Schaad Expires September 13, 2012 [Page 19] Internet-Draft EPS TRUST March 2012 be re-introduced to the server in such a way that the server can use cached information. WS Trust tokens come in two basic flavors: Bearer tokens and Holder of Key tokens. With the first flavor, presentation of the token is considered to be sufficient to allow the server to validate the identity of the presenter and know the appropriate attributes to make a policy decision. In the second flavor some type of cryptographic operation is needed in addition to just presenting the token. The Signature element Section 7.3 provides necessary infrastructure to permit the cryptographic result to be passed to the server. This document does not define the content or structure of any tokens to be used. This is strictly an implementation issue for the servers in question. This is because the client can treat the WS Token value presented to it as an opaque blob. Only the servers need to understand how to process the blob. However there are some additional fields which can be returned in addition to the token that need to be discussed: 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. 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 Section 7.3. [anchor18]. 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. 7.3. XML Signature Element 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 possesion step so that the Plasma server can validate that the entity does hold the key. The credentials can hold either asymmetic keys (X.509 certificates and SAML Assertions) or symmetic 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 [XML-Signature] provides an infrastructure to for holding Schaad Expires September 13, 2012 [Page 20] Internet-Draft EPS TRUST March 2012 the proof of possession information. When the XML Signature element is used in the first message of the dialog, an XACML Request element be present in the document. In this case the signature is to be computed over the XACML Request. After the first message, the XACML Request element may be present, but usually is not. When the XACML Request element is present in the subsequent messages it may be signed, however the SignBody XML element has been defined for use in subsequenct messages. The XML schema for this element is: In the SignBodyType show above, the ChannelBinding element contains a value derived from the TLS tunnel used to transport the protocol. The details for the value derivation can be find in section Section 11.1.1. 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 conversation and are not replayed from previous conversations. When creating either a signature or a MAC, the following statements hold: o The canonicalization algorithm Canonical XML 1.1 [XML-C14N11] without comments MUST be supported and SHOULD be used in preparing the XML node set for hashing. Other canonicalization algorithms MAY be used. o The Signature element SHOULD include an Enveloped Signature Transformation (Section 6.6.4 of [XML-Signature] but MAY be the root of the Plasm request. Both methods MUST be supported by Plasma servers. o The signature algorithms RSAwithSHA256 and ECDSAwithSHA256 MUST be supported by both clients and servers. The MAC algorithm HMAC- SHA256 MUST be supported by both clients and servers. Other signature and MAC algorithms MAY be supported. o Set the additional attributes that must be included in a signature - what should they be? Schaad Expires September 13, 2012 [Page 21] Internet-Draft EPS TRUST March 2012 o If an xacml:Request element is referenced by an XML Signature element, the xacml:Request element MUST include the ChannelBinding token (Section 11.1.1) as one of the attributes. o 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). 7.4. GSS-API Element TBD - rules for using GSS-API in general and the EAP version from ABFAB particularly. o How to build the name. o Must use a secure tunnel for the outer EAP method and an appropriate inner EAP method(s) to accomplish the required level of authentication. o Server query of attributes and specification of LOA to the EAP IdP. o Any additional Trust model items. o 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. Schaad Expires September 13, 2012 [Page 22] Internet-Draft EPS TRUST March 2012 8. Role Token and Policy Acquisition In order to send a message using a Plasma server, the first step is to obtain a role token that provides the description of the lables that can be applied and the authorization to send a message using one or more of the labels. The process of obtaining the role token is designed to be a query/response round trip to the Plasma server. In practice a number of round trips may be necessary in order to provide all of the identity and attributes to the Plasma server that are needed to evaluate the policies for the labels. An example of a request token can be found in Appendix B. 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. 8.1. Role Token Request The process starts by a client sending a server a role token request. Generally, but not always, the request will include some type of identity proof information and a set of generic attributes. It is suggested that, after the first successful conversation, the client cache hints about the identity and attributes needed for a server. This allows for fewer round trips in later conversations. The role token request, as with all requests, is always built using the eps:PlasmaRequest XML structure. The xacml:Request element MUST be included on the first message, but is omitted on subsequent authentication round trips. The eps:Authentication MAY be included on the first message (depending on how authentication is going to be done) and MUST be included on subsequent authentication round trips. When sending the role token there are a number of things that can be Schaad Expires September 13, 2012 [Page 23] Internet-Draft EPS TRUST March 2012 done. These include: o The client can optionally include an attribute to specify the name to be used for policy evaluation purposes. If this attribute is absent, then the name is extracted from the identity proof provided externally. This attribute allows for a client to get delegated permissions for a third party. One case where this would be used is for an executive assistant to be able to act as the executive for reading certain types of messages. When this behavior is desired, the following attribute is used: Category="urn:oasis:names:tc:xacml:1.0:subject-category:access- subject" AttributeId="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name" Plasma servers MUST implement the rfc822Name attribute id, other name forms MAY be implemented as well. o The client MUST include an action attribute. This document defines the action attribute to be used for requesting role tokens: Category="urn:oasis:name:tc:xacml:3.0:attribute-category:action" AttributeId="urn:ietf:plasma:action-id" Attribute Value: GetRoleTokens o If the client is using the XML Digital Signature element in this message, then the client MUST include the cryptographic channel binding token (Section 11.1.1) in the set of XACML attributes. o The client can optionally include a SAML assertion in the Authentication section of the message. See section Section 7.1 for more information on how to deal with SAML assertions carrying attribute statements. An example of a message requesting the set of policy information is: ... GetRoleToken Schaad Expires September 13, 2012 [Page 24] Internet-Draft EPS TRUST March 2012 In this example the identity information of the requester is implicit from the data in the Authentication element. 8.2. Request Role Token Response In response to a role token request message, the Plasma server returns a role token request message. The response message uses the eps:PlasmaResponse XML structure. When a response message is create the following should be noted: o An xacml:Decision is always included in a response message. The values permitted are: Permit is used to signal success. In this case the response message MUST include an eps:PlasmaTokens element. Deny is used to signal failure. In this case the xacml:Status element MUST be present an contain a failure reason. Indeterminate is used to signal that a result cannot yet be reached. In this case there must be a request for additional attributes in the xacml:Result/Attributes element or additional authentication information to be carried in TBD. NotApplicable is returned if the Plasma server does not have the capability to issue role tokens. An example of a message returning the set of policy information is: Schaad Expires September 13, 2012 [Page 25] Internet-Draft EPS TRUST March 2012 Permit Details of a policy ... More policies ... urn:...:plasma:roleToken ... In this example, the Email Policy Service is returning three different policies that can be used along with a security token and a key to be used with the token when sending a message. 8.2.1. PlasmaTokens XML element The eps:PlasmaTokens element is used to return one or more tokens to the client. Each token returned will contain one or more policies that can be asserted with the token and the token itself. Additionally the name of a Plasma server to be used with the token can be included as well as cryptographic information to be used with the token. The schema used for the PlasmaTokens element is: Schaad Expires September 13, 2012 [Page 26] Internet-Draft EPS TRUST March 2012 The eps:PlasmaTokens field will contain one or more eps:PlasmaToken elements. The eps:PlasmaToken element contains the following items: PDP is an optional element. If the element is present, it provides one or more URLs to be used for containing a Plasma server for the purpose of sending a message. This element allows for the use of different Plasma servers for issuing role tokens and message tokens. No ranking of the servers is implied by the order of the URLs returned. PolicyList contains the description of one or more policies that can be asserted using the issued token. Any of the policies contained in the list may be combined together using the policy logic in constructing a label during the send message process. Label contains a single specific label. This element is returned as part of a read message token to allow for replies to be formulated by an entity that cannot generally originate a message using the policy. Schaad Expires September 13, 2012 [Page 27] Internet-Draft EPS TRUST March 2012 wst:RequestSecurityTokenResponse contains the actual token itself. The eps:PolicyType type is used to represent the elements of a policy to the client. The elements in this type are: Name contains a display string that represents the policy. This element is localized in response to the TBD attribute in the TBD field. Identifier contains a "unique" identifier for the policy. This is the value that identifies the policy to the software. The type for the value is defined as a string and is expected to be either a URN, and Object Identifier or some equally unique identifier. Options allows for a set of options to be specified for the policy. The set of options is dependent on the policy and only those clients which have pre-knowledge of a policy are expected to be able to deal with them. The options can range from a simple yes/no selection to a list of strings. An example of using options is provided by the basic policies defined in [TBD] where a set of RFC 822 names is provided.[anchor21] When building the wst:RequestSecurityTokenResponse element, the following should be noted: A wst:RequestedSecruityToken element containing the security token MUST be included. The format of the security token is not specified and is implementation specific, it is not expected that . Examples of items that could be used as security tokens are SAML statements, encrypted record numbers in a server database. A wst:Lifetime giving the life time of the token SHOULD be included. It is not expected that this should be determinable from the token itself and thus must be independently provided. There is no guarantee that the token will be good during the lifetime as it make get revoked due to changes in credentials, however the client is permitted to act as if it were. The token provided may be used for duration. If this element is absent, it should be assumed that the token is either a one time token or of limited duration. Talk about cryptographic information Schaad Expires September 13, 2012 [Page 28] Internet-Draft EPS TRUST March 2012 9. Sending A Message After having obtained a role token from a Plasma server, the client can then prepare to send a message by requesting a message token from the Plasma server. As part of the preparatory process, the client will construct the label to be applied to the message from the set of policies that it can assert, determine the optional elements for those policies which have options, generate the random key encryption key and possible create the key recipient structures for the message. Although this section is written in terms of a CMS Encrypted message, there is nothing to prevent the specification of different formats and still use this same basic protocol. An example of a request token exchange can be found in Appendix D. 9.1. Send Message Request The send message request is built using the eps:PlasmaRequest XML structure. When building the request, the following aplies: o The eps:Authentication element MAY be included in the initial message. The authorization is supplied by the role token which is included in the data structure, however authentication may be required as well. The authentication data is placed here. o The xacml:Request element MUST be included in the initial message. o The client MUST include an action attribute. This document defines the action attribute to be used for purpose: Category = "urn:oasis:name:tc:xacml:3.0:attribute-category:action" AttributeId="urn:ietf:plasma:action-id" Attribute Value= GetSendCMSToken o 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 Section 9.1.1. o 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"/>) in the set of XACML attributes. An example of a message returning the set of policy information is: Schaad Expires September 13, 2012 [Page 29] Internet-Draft EPS TRUST March 2012 Role Token goes here GetSendCMSToken Label and keys 9.1.1. CMS Message Token Data Structure 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: Schaad Expires September 13, 2012 [Page 30] Internet-Draft EPS TRUST March 2012 When used in an xacml:Attribute, the structure is identified by: Category = "urn:oasis:name:tc:xacml:3.0:attribute-category:data" AttributeId = "urn:ietf:plasma:data-id" DataType = "http://www.w3.org/2001/XMLSchema#anyType" The elements of the structure are used as: RoleToken contains the previously issued role token which provides the authorization to use the policies in the label. Label contains the label to be applied to the message. Recipients is an optional element that contains one or more recipient info structures. KEK is an optional element that contains the KEK to decrypt the CMS lock box. One or both of KEK and Recipients MUST be present. The elements of the RecipientInfoType structure are: Schaad Expires September 13, 2012 [Page 31] Internet-Draft EPS TRUST March 2012 Subject contains a subject identifier. Since a CMS recipient info structure does not contain a great deal of information about the recipient, this element contains a string which can be used to identify the subject. This will normally be an RFC 822 name. Multiple subject names can be provided for a single lock box. This allows for the use a KEK value that is shared among the set of recipients but not the Plasma server. LockBox contains a hex encoded CMS Recipient Info structure. If the recipient info structure is placed here, it MUST NOT be placed in the CMS EnvelopedData structure as well. 9.2. Send Message Response 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: o The xacml:Decisions is always included in the response. If the 'Permit' value is returned then the eps:CMSToken element MUST be present. o The eps:CMSToken element is included in a success message. It contains value of the keyatt-eps-kek attribute defined in [EPS-CMS]. An example of a message returning the set of policy information is: Permit 234e34d3 Schaad Expires September 13, 2012 [Page 32] Internet-Draft EPS TRUST March 2012 10. Decoding A Message When the receiving agent is ready to decrypt the message, it identifies that there is a KEKRecipientInfo object which contains a key attribute identified by id-keyatt-eps-token. It validates that communicating with the Email Policy Service is within local policy and then sends a request to the service to obtain the encryption key for the message. 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. 10.1. Requesting Message Key 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 [EPS-CMS] this is located in the aa-eps-url attribute. The request uses the eps:PlasmaRequest XML structure. When building the request, the following should be noted: o The xacml:Request MUST be present in the first message of the exchange. o The action used to denote that a CMS token should be decrypted is: Category="urn:oasis:names:tc:xaml:3.0:attribute-category:action" AttributeId="urn:ietf:plasma:action-id" Attribute Value: ParseCMSToken o The CMS token to be cracked is identified by:[anchor22] Category="urn:oasis:names:tc:xacml:3.0:attribute-cateogry:data" AttributeId="urn:ietf:plasma:data-id" Attribute Value: CMSToken o In the event that a reply to role token is wanted as well, then that is supplied as a separate action: Category="urn:oasis:names:tc:xaml:3.0:attribute-category:action" AttributeId="urn:ietf:plasma:action-id" Attribute Value: GetReplyToken Schaad Expires September 13, 2012 [Page 33] Internet-Draft EPS TRUST March 2012 o 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"/>) in the set of XACML attributes. An example of a message returning the set of policy information is: ... ParseCMSToken Hex encoded CMS Token Value 10.2. Requesting Message Key Response In response to a message key request, the Plasma server returns a decrypted key. The response message uses the eps:Plasma XML structure. When a response message is create the following should be noted: o If the value of xacml:Decision is Permit, then response MUST include an eps:CMSKey element. o 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 An example of a message returning the set of policy information is: Schaad Expires September 13, 2012 [Page 34] Internet-Draft EPS TRUST March 2012 Permit Label TExt hex based KEK Schaad Expires September 13, 2012 [Page 35] Internet-Draft EPS TRUST March 2012 11. Plasma Attributes In this document a number of different XAMCL attributes have been defined, this section provides a more detailed description of these elements. 11.1. Data Attributes 11.1.1. Channel Binding Data Attribute 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. The channel binding value to be used is created by the TLS key exporter specification defined in RFC 5705 [RFC5705]. 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 will be 512 bits in length, and no context is provided to the exporter. When used as an XACML attribute in a request: The category of the attribute is "urn:oasis:names:tc:xacml:3.0:attribute-category:data". The AttributeId attribute is "urn:ietf:params:xml:plasma:data-id:ChannelBinding". The Issuer attribute is absent. The DataType is either base64Binary or hexBinary The same value is used for both the XACML channel binding data attribute and the XML channel binding structure defined in Section 7.3. Schaad Expires September 13, 2012 [Page 36] Internet-Draft EPS TRUST March 2012 11.1.2. CMS Signer Info Data Attribute In many cases a policy stays 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. 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 setup for archival operations. One way to do archiving is to use the data records defined in [RFC4998]. The following applies when this data value is present: The Category attribute is "urn:oasis:names:tc:xacml:3.0:attribute-category:data". The AttributeId attribute is "urn:ietf:params:xml:plasma:data-id:CMSSignerInfo". The Issuer attribute is absent. The DataType attribute is either base64Binary or hexBinary. 11.1.3. S/MIME Capabilities Data Attribute 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 [SMIME-MSG]. The following attributes are to be set for the data value: The Category attribute is "urn:oasis:names:tc:xacml:3.0:attribute-category:data". The AttributeId attribute is "urn:ietf:params:xml:plasma:data-id:SMIME-Capabilties". Schaad Expires September 13, 2012 [Page 37] Internet-Draft EPS TRUST March 2012 The Issuer attribute is absent. The DataType attribute is either base64binary or hexBinary. 11.2. Obligations and Advice 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. 11.2.1. Signature Required 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 (Section 8.2). When used as an Obligation: The ObligationId attribute is "urn:ietf:params:xml:plasma:obligation:signature-required". 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. 11.2.2. Encryption Required 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. When used as an Obligation: The ObligationId attribute is "urn:ietf:params:xml:plasma:obligation:encryption-required". Schaad Expires September 13, 2012 [Page 38] Internet-Draft EPS TRUST March 2012 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. Schaad Expires September 13, 2012 [Page 39] Internet-Draft EPS TRUST March 2012 12. Security Considerations To be supplied after we have a better idea of what the document looks like. Schaad Expires September 13, 2012 [Page 40] Internet-Draft EPS TRUST March 2012 13. IANA Considerations We define the following name spaces New name space for the plasma documents urn:ietf:params:xml:ns:plasma Define a new action name space urn:ietf:params:xml:ns:plasma:action-id GetRoleTokens GetSendCMSToken ParseCMSToken GetReplyToken Define a new data name space urn:ietf:params:xml:ns:plasma:data-id CMSToken ChannelBinding SMIME-Capabilities Define a new name space for status codes at urn:ietf:params:xml:ns:plasma:status. The initial set of values is authentication-error This identifier indicates that the authentication methods failed to successfully complete. 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. 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 [SMIME-MSG] 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. encryption-algorithms see above Schaad Expires September 13, 2012 [Page 41] Internet-Draft EPS TRUST March 2012 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. We define a schema in appendix A at urn:ietf:params:xml:schema:plasma-RFCTBD Schaad Expires September 13, 2012 [Page 42] Internet-Draft EPS TRUST March 2012 14. Open Issues List of Open Issues: o JLS: URL definitions - do we need a new schema or do we just overload https? For our URLs - do we require that they be passed through the internationalization step first? Probably should since the locale information is on the server and the client might not agree. o JLS: Should we require that any SignatureProperty be present for XML Signature elements? o 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. o JLS: Should X.509 certificates and attribute certificates be fully specified as an authentication method? o 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 Schaad Expires September 13, 2012 [Page 43] Internet-Draft EPS TRUST March 2012 15. References 15.1. Normative References [ABFAB] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the Extensible Authentication Protocol", Work In Progress draft-ietf-abfab-gss-eap-04, Oct 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [EPS-CMS] Schaad, J., "Email Policy Service ASN.1 Processing", Work In Progress draft-schaad-plamsa-cms, Jan 2011. [XML-Signature] Roessler, T., Reagle, J., Hirsch, F., Eastlake, D., and D. Solo, "XML Signature Syntax and Processing (Second Edition)", World Wide Web Consortium Recommendation REC- xmldsig-core-20080610, June 2008, . [XML-C14N11] Boyer, J. and G. Marcy, "Canonical XML Version 1.1", World Wide Web Consortium Recommendation REC-xml-c14n11- 20080502, May 2008, . [WS-TRUST] Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin, M., Barbir, A., and H. Granqvist, "WS-Trust 1.3", OASIS Standard ws-trust-200512, March 2007, . [XACML] Rissanen, E., "eXtensible Access Control Markup Language (XACML) Version 3.0", OASIS Standard xacml-201008, August 2010, . [Plasma] Freeman, T., Schaad, J., and P. Patterson, "Requirements for Message Access Control", Work in progress draft-freeman-message-access-control, October 2011. [OASIS-CORE] Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0", OASIS Standard saml-core- Schaad Expires September 13, 2012 [Page 44] Internet-Draft EPS TRUST March 2012 2.0-os, March 2005. [RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010. [SMIME-MSG] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. 15.2. Informative References [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence Record Syntax (ERS)", RFC 4998, August 2007. [SAML-XACML] Anderson, A. and H. Lockhart, "SAML 2.0 profile of XACML v2.0", OASIS Standard access_control-xacml-2.0-saml- profile-spec-os.pdf, February 2005. [SOAP11] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", W3C NOTE NOTE- SOAP-20000508, May 2000. [SOAP12] Lafon, Y., Gudgin, M., Hadley, M., Moreau, J., Mendelsohn, N., Karmarkar, A., and H. Nielsen, "SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)", World Wide Web Consortium Recommendation REC-soap12-part1-20070427, April 2007, . Schaad Expires September 13, 2012 [Page 45] Internet-Draft EPS TRUST March 2012 Editorial Comments [anchor8] 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. [anchor16] jls: Should this be the collection element as it currently is, or should it be an unbounded occurs element instead? [anchor18] JLS: I don't know of any way to say use the asymmetric key that you authenticated with originally - can this be done? [anchor21] JLS: I keep wondering if we need to define a set of minimal structures that can be used for options so that the entirety is not pushed off onto the client and server to parse and understand the structures. [anchor22] jls: I need to think this case out a bit more - I want to be able to supply multiple CMS tokens at one time, however I am not sure if that is do able because if you get a success for one token and a deny for another token there is no way to handle that in the xacml:Response. Schaad Expires September 13, 2012 [Page 46] Internet-Draft EPS TRUST March 2012 Appendix A. XML Schema This appendix represents the entirety of the XML Schema for Plasma documents. 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 Schaad Expires September 13, 2012 [Page 47] Internet-Draft EPS TRUST March 2012 Schaad Expires September 13, 2012 [Page 48] Internet-Draft EPS TRUST March 2012 Schaad Expires September 13, 2012 [Page 49] Internet-Draft EPS TRUST March 2012 Schaad Expires September 13, 2012 [Page 50] Internet-Draft EPS TRUST March 2012 Schaad Expires September 13, 2012 [Page 51] Internet-Draft EPS TRUST March 2012 Appendix B. Example: Get Roles Request 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. ... bart@simpsons.com GetRoleTokens Schaad Expires September 13, 2012 [Page 52] Internet-Draft EPS TRUST March 2012 Appendix C. Example: Get Roles Response This section provides an example response to a successful request for a role sets. Permit https://pdp.example.com/companyPolicies Company Confidential urn:example:policies:confidential Plasma Project urn:example:policies:plasma urn:plasma:roleToken .... 12345678 2012-02-01T00:00:00 Schaad Expires September 13, 2012 [Page 53] Internet-Draft EPS TRUST March 2012 Appendix D. Example: Get CMS Token Request 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: o A complex rule set is requested where permission to is to be granted to anyone who meets either of the two policies given. o 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. o A generic key encryption key is provided for any other subject who meets the policies specified. Schaad Expires September 13, 2012 [Page 54] Internet-Draft EPS TRUST March 2012 123456 GetCMSToken lisa@simpsons.com FF33eeddccaa002234 AB123456 Schaad Expires September 13, 2012 [Page 55] Internet-Draft EPS TRUST March 2012 Appendix E. Example: Get CMS Token Response 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. Permit 3425342352343243 Schaad Expires September 13, 2012 [Page 56] Internet-Draft EPS TRUST March 2012 Appendix F. Example: Get CMS Key Request .... ParseCMSToken GetReplyToken AABBDDEEFF1122344 Schaad Expires September 13, 2012 [Page 57] Internet-Draft EPS TRUST March 2012 Appendix G. Example: Get CMS KeyResponse Permit Company Confidential 3425342352343243 https://pdp.example.com/companyPolicies urn:plasma:roleToken .... 2012-02-01T00:00:00 Schaad Expires September 13, 2012 [Page 58] Internet-Draft EPS TRUST March 2012 Author's Address Jim Schaad Soaring Hawk Consulting Email: ietf@augustcellars.com Schaad Expires September 13, 2012 [Page 59]