Network Working Group J. Schaad
Internet-Draft Soaring Hawk Consulting
Intended status: Standards Track January 10, 2012
Expires: July 13, 2012
Email Policy Service Trust Processing
draft-schaad-plasma-service-00
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 July 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 July 13, 2012 [Page 1]
Internet-Draft EPS TRUST January 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. XML Nomenclature and Name Spaces . . . . . . . . . . . . . 3
1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 4
2. Components . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. WS-Trust 1.3 . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. XACML 3.0 . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Sender Processing . . . . . . . . . . . . . . . . . . . . 6
3.2. Recieving Agent Processing . . . . . . . . . . . . . . . . 7
4. Plasma Request . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Authentication Element . . . . . . . . . . . . . . . . . . 9
4.2. xacml:Request Element . . . . . . . . . . . . . . . . . . 10
5. Plasma Response Element . . . . . . . . . . . . . . . . . . . 11
5.1. xacml:Response Element . . . . . . . . . . . . . . . . . . 12
6. Authentication Element . . . . . . . . . . . . . . . . . . . . 14
6.1. WS Trust Tokens . . . . . . . . . . . . . . . . . . . . . 14
6.2. XML Signature Element . . . . . . . . . . . . . . . . . . 15
6.3. SAML Collection Element . . . . . . . . . . . . . . . . . 16
6.4. GSS-API Element . . . . . . . . . . . . . . . . . . . . . 16
7. Role Token and Policy Acquisition . . . . . . . . . . . . . . 17
7.1. Role Token Request . . . . . . . . . . . . . . . . . . . . 17
7.2. Request Role Token Response . . . . . . . . . . . . . . . 19
7.2.1. PlasmaTokens XML element . . . . . . . . . . . . . . . 20
8. Sending A Message . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Send Message Request . . . . . . . . . . . . . . . . . . . 23
8.1.1. CMS Message Token Data Structure . . . . . . . . . . . 24
8.2. Send Message Response . . . . . . . . . . . . . . . . . . 26
9. Decoding A Message . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Requesting Message Key . . . . . . . . . . . . . . . . . . 27
9.2. Requesting Message Key Response . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. Normative References . . . . . . . . . . . . . . . . . . . . . 31
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 33
Appendix B. Example: Get Roles Request . . . . . . . . . . . . . 38
Appendix C. Example: Get Roles Response . . . . . . . . . . . . . 39
Appendix D. Example: Get CMS Token Request . . . . . . . . . . . 40
Appendix E. Example: Get CMS Token Response . . . . . . . . . . . 42
Appendix F. Example: Get CMS Key Request . . . . . . . . . . . . 43
Appendix G. Example: Get CMS KeyResponse . . . . . . . . . . . . 44
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 45
Schaad Expires July 13, 2012 [Page 2]
Internet-Draft EPS TRUST January 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 |
| | | |
| S11 | http://schemas.xmlsoap.org/soap/envelope/ | [SOAP11] |
| | | |
| S12 | http://www.w3.org/2003/05/soap-envelope | [SOAP12] |
| | | |
| 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 July 13, 2012 [Page 3]
Internet-Draft EPS TRUST January 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 July 13, 2012 [Page 4]
Internet-Draft EPS TRUST January 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 both access control
policies and access control queries and responses.
Schaad Expires July 13, 2012 [Page 5]
Internet-Draft EPS TRUST January 2012
3. Model
To be supplied from the problem statement document. [anchor7]
(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 7 for obtaining the security policies
that can be applied to a messages and Section 8 for sending a
Schaad Expires July 13, 2012 [Page 6]
Internet-Draft EPS TRUST January 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 7.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 7.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 8.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 8.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 9.
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 July 13, 2012 [Page 7]
Internet-Draft EPS TRUST January 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 9.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 9.2.
7. The Receiving Agent proceeds to decrypt the message and perform
normal processing.
Schaad Expires July 13, 2012 [Page 8]
Internet-Draft EPS TRUST January 2012
4. Plasma Request
There is a single top level structure that is used by a client to
send a request to the server.
The XML Schema used to describe the top level request is as follows:
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.
xacml:Request is an optional element that contains the control
information for a what is happening. This element is taken from
the XACML specification.
4.1. Authentication Element
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.
Schaad Expires July 13, 2012 [Page 9]
Internet-Draft EPS TRUST January 2012
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.
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.
4.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 and MultiRequest elements is possible,
but will generally not be supported.
Schaad Expires July 13, 2012 [Page 10]
Internet-Draft EPS TRUST January 2012
5. 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 July 13, 2012 [Page 11]
Internet-Draft EPS TRUST January 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 6.
5.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 11.
Schaad Expires July 13, 2012 [Page 12]
Internet-Draft EPS TRUST January 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.[anchor15]
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.
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 July 13, 2012 [Page 13]
Internet-Draft EPS TRUST January 2012
6. Authentication Element
One of the core issues that the Plasma specification needs to address
is how the client is authenticated to the server. This is important
because many of the use cases envisioned are not the simple ones
where Plasma server is going to know the authentication credentials
for the client, but rather will need to get the authentication from a
third part in some way. The authentication element therefore is
somewhat complicated as it needs to allow for a variety of different
authentication methods.
The schema for the Authentication element is:
More than one authentication element may be present in any single
message. This is because a client may need to provide more than one
piece of data to a server in order to authenticate, for example a
holder of key SAML Assertion along with a signature created with that
key. Additionally a client may want to provide the server an option
of different ways of doing the authentication. In a federated
scenario, an X.509 certificate with a signature can be presented and
the server may not be able to build a trust path to it's set of trust
anchors. In this case the server may opt to use the GSS-API/EAP
protocol for doing the authentication. Finally, the client may want
to provide the server with a SAML Assertion that binds a number of
attributes to it's identities so that the server does not need to ask
for those attributes at a later time.
6.1. 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 July 13, 2012 [Page 14]
Internet-Draft EPS TRUST January 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 6.2 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 6.2.
[anchor17].
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.
6.2. XML Signature Element
The XML signature standard [XML-Signature] is used to provide for
holder of key assertions and binary secrets to be used to create
proofs that the respective secrets are held by the client. When
creating either a signature or a MAC, the following statements hold:
o The canonicalization algorithm Canonical XML 1.1 [XML-C14N11]
without comments will be used in preparing the XML node set for
hashing.
Schaad Expires July 13, 2012 [Page 15]
Internet-Draft EPS TRUST January 2012
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 algorithm RSAwithSHA256 MUST be supported by both
clients and servers. The MAC algorithm HMAC-SHA256 MUST be
supported by both clients and servers.
6.3. SAML Collection Element
The SAML collection element provides a holder to place one or more
SAML Assertions. Three types of SAML assertions may be place in this
location: Bearer assertions, Holder of Key assertions and Attribute
assertions. The first two types are used for the purposes of
authenticating the client to the server. The last type is used to
carry a binding of attributes and identity. The first two types may
also carry attributes other than just an identity statement.
6.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 July 13, 2012 [Page 16]
Internet-Draft EPS TRUST January 2012
7. 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.
7.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 July 13, 2012 [Page 17]
Internet-Draft EPS TRUST January 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 The client can optionally include a SAML assertion in the
Authentication section of the message. See section Section 6.3
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
In this example the identity information of the requester is implicit
from the transport protocol used.
Schaad Expires July 13, 2012 [Page 18]
Internet-Draft EPS TRUST January 2012
7.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:
Permit
Details of a policy
... More policies ...
urn:...:plasma:roleToken...
Schaad Expires July 13, 2012 [Page 19]
Internet-Draft EPS TRUST January 2012
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.
7.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:
The eps:PlasmaTokens field will contain one or more eps:PlasmaToken
elements.
The eps:PlasmaToken element contains the following items:
Schaad Expires July 13, 2012 [Page 20]
Internet-Draft EPS TRUST January 2012
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.
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.[anchor20]
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.
Schaad Expires July 13, 2012 [Page 21]
Internet-Draft EPS TRUST January 2012
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 July 13, 2012 [Page 22]
Internet-Draft EPS TRUST January 2012
8. 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.
8.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 8.1.1.
An example of a message returning the set of policy information is:
Schaad Expires July 13, 2012 [Page 23]
Internet-Draft EPS TRUST January 2012
Role Token goes here
GetSendCMSToken
Label and keys
8.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 July 13, 2012 [Page 24]
Internet-Draft EPS TRUST January 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 July 13, 2012 [Page 25]
Internet-Draft EPS TRUST January 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.
8.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:
Permit234e34d3
Schaad Expires July 13, 2012 [Page 26]
Internet-Draft EPS TRUST January 2012
9. 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.
9.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:[anchor21]
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
An example of a message returning the set of policy information is:
Schaad Expires July 13, 2012 [Page 27]
Internet-Draft EPS TRUST January 2012
...ParseCMSToken
Hex encoded CMS Token Value
9.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:
PermitLabel TExthex based KEK
Schaad Expires July 13, 2012 [Page 28]
Internet-Draft EPS TRUST January 2012
10. Security Considerations
To be supplied after we have a better idea of what the document looks
like.
Schaad Expires July 13, 2012 [Page 29]
Internet-Draft EPS TRUST January 2012
11. IANA Considerations
We should have at least one name space to be registered.
Schaad Expires July 13, 2012 [Page 30]
Internet-Draft EPS TRUST January 2012
12. 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 Pgoress draft-eps-smime-00, 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,
.
[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,
.
[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, .
Schaad Expires July 13, 2012 [Page 31]
Internet-Draft EPS TRUST January 2012
Editorial Comments
[anchor7] 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.
[anchor15] jls: My initial thought was that we would not defined any
obligations or advice, but I am no longer sure that is
true. Things like specifiying a mandatory encryption
algorithm or time limit on keeping the decrypted KEK
value would be reasonable to be placed here and give a
standard way for the policy to communicate that to the
client.
[anchor17] JLS: I don't know of any way to say use the asymmetric
key that you authenticated with originally - can this be
done?
[anchor20] 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.
[anchor21] 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 July 13, 2012 [Page 32]
Internet-Draft EPS TRUST January 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 July 13, 2012 [Page 33]
Internet-Draft EPS TRUST January 2012
Schaad Expires July 13, 2012 [Page 34]
Internet-Draft EPS TRUST January 2012
Schaad Expires July 13, 2012 [Page 35]
Internet-Draft EPS TRUST January 2012
Schaad Expires July 13, 2012 [Page 36]
Internet-Draft EPS TRUST January 2012
Schaad Expires July 13, 2012 [Page 37]
Internet-Draft EPS TRUST January 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.comGetRoleTokens
Schaad Expires July 13, 2012 [Page 38]
Internet-Draft EPS TRUST January 2012
Appendix C. Example: Get Roles Response
This section provides an example response to a successful request for
a role sets.
Permithttps://pdp.example.com/companyPoliciesCompany Confidentialurn:example:policies:confidentialPlasma Projecturn:example:policies:plasmaurn:plasma:roleToken....123456782012-02-01T00:00:00
Schaad Expires July 13, 2012 [Page 39]
Internet-Draft EPS TRUST January 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 July 13, 2012 [Page 40]
Internet-Draft EPS TRUST January 2012
123456GetCMSToken
lisa@simpsons.com
FF33eeddccaa002234AB123456
Schaad Expires July 13, 2012 [Page 41]
Internet-Draft EPS TRUST January 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.
Permit3425342352343243
Schaad Expires July 13, 2012 [Page 42]
Internet-Draft EPS TRUST January 2012
Appendix F. Example: Get CMS Key Request
....ParseCMSTokenGetReplyTokenAABBDDEEFF1122344
Schaad Expires July 13, 2012 [Page 43]
Internet-Draft EPS TRUST January 2012
Appendix G. Example: Get CMS KeyResponse
PermitCompany Confidential3425342352343243https://pdp.example.com/companyPoliciesurn:plasma:roleToken....2012-02-01T00:00:00
Schaad Expires July 13, 2012 [Page 44]
Internet-Draft EPS TRUST January 2012
Author's Address
Jim Schaad
Soaring Hawk Consulting
Email: ietf@augustcellars.com
Schaad Expires July 13, 2012 [Page 45]