idnits 2.17.1
draft-schaad-plasma-service-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 54 instances of too long lines in the document, the longest
one being 5487 characters in excess of 72.
== There are 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 296 has weird spacing: '...Service is th...'
== Line 304 has weird spacing: '...r Agent is th...'
== Line 309 has weird spacing: '...g Agent is th...'
== Line 311 has weird spacing: '...g Agent is th...'
== Line 450 has weird spacing: '...ication is an...'
== (24 more instances...)
-- The document date (January 11, 2013) is 4123 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Missing Reference: 'WS-Security' is mentioned on line 151, but not
defined
== Missing Reference: 'XML-Encrypt' is mentioned on line 160, but not
defined
== Missing Reference: 'WS-Policy' is mentioned on line 163, but not defined
== Missing Reference: 'XML-Schema1' is mentioned on line 169, but not
defined
== Unused Reference: 'ABFAB' is defined on line 2069, but no explicit
reference was found in the text
== Unused Reference: 'SOAP11' is defined on line 2146, but no explicit
reference was found in the text
== Unused Reference: 'SOAP12' is defined on line 2151, but no explicit
reference was found in the text
== Outdated reference: A later version (-09) exists of
draft-ietf-abfab-gss-eap-04
-- No information found for draft-schaad-plamsa-cms - is the name correct?
-- Possible downref: Normative reference to a draft: ref. 'EPS-CMS'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML-Signature'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML-C14N11'
-- Possible downref: Non-RFC (?) normative reference: ref. 'WS-TRUST'
-- Possible downref: Non-RFC (?) normative reference: ref. 'XACML'
-- No information found for draft-freeman-message-access-control - is the
name correct?
-- Possible downref: Normative reference to a draft: ref. 'Plasma'
-- Possible downref: Non-RFC (?) normative reference: ref. 'OASIS-CORE'
** Obsolete normative reference: RFC 5751 (ref. 'SMIME-MSG') (Obsoleted by
RFC 8551)
-- Obsolete informational reference (is this intentional?): RFC 4346
(Obsoleted by RFC 5246)
-- Obsolete informational reference (is this intentional?): RFC 5077
(Obsoleted by RFC 8446)
Summary: 2 errors (**), 0 flaws (~~), 16 warnings (==), 12 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Schaad
3 Internet-Draft Soaring Hawk Consulting
4 Intended status: Standards Track January 11, 2013
5 Expires: July 15, 2013
7 Plasma Service Trust Processing
8 draft-schaad-plasma-service-04
10 Abstract
12 RFC TBD describes a new model and set of requirements to implement a
13 labeling system on Cryptographic Message Syntax (CMS) objects where
14 the entity in charge of doing the label enforcement is under the
15 control of a central authority rather than the recipient of the
16 object.
18 This document describes a protocol to be used by senders and
19 recipients of CMS objects to communicate with a centralized label
20 enforcement server. The document outlines how a client will get the
21 set of labels or policies that it can use for sending messages,
22 composes a secure CMS object with a label on it and gets the
23 necessary keys to decrypt a CMS object from the server. This
24 document is designed to be used with RFC TBD2 which describes the
25 extensions used in CMS objects to hold the label information.
27 Status of this Memo
29 This Internet-Draft is submitted in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at http://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on July 15, 2013.
44 Copyright Notice
46 Copyright (c) 2013 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (http://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Simplified BSD License text as described in Section 4.e of
56 the Trust Legal Provisions and are provided without warranty as
57 described in the Simplified BSD License.
59 Table of Contents
61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
62 1.1. XML Nomenclature and Name Spaces . . . . . . . . . . . . . 4
63 1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 5
64 2. Components . . . . . . . . . . . . . . . . . . . . . . . . . . 6
65 2.1. XACML 3.0 . . . . . . . . . . . . . . . . . . . . . . . . 6
66 2.2. SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
67 2.3. WS-Trust 1.4 . . . . . . . . . . . . . . . . . . . . . . . 7
68 3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
69 3.1. Sender Processing . . . . . . . . . . . . . . . . . . . . 8
70 3.2. Recieving Agent Processing . . . . . . . . . . . . . . . . 9
71 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 11
72 5. Plasma Request . . . . . . . . . . . . . . . . . . . . . . . . 12
73 5.1. Authentication Element . . . . . . . . . . . . . . . . . . 13
74 5.1.1. SAML Assertion . . . . . . . . . . . . . . . . . . . . 15
75 5.1.2. WS Trust Tokens . . . . . . . . . . . . . . . . . . . 16
76 5.1.3. XML Signature Element . . . . . . . . . . . . . . . . 16
77 5.1.4. GSS-API Element . . . . . . . . . . . . . . . . . . . 18
78 5.2. xacml:Request Element . . . . . . . . . . . . . . . . . . 18
79 6. Plasma Response Element . . . . . . . . . . . . . . . . . . . 20
80 6.1. xacml:Response Element . . . . . . . . . . . . . . . . . . 21
81 7. Role Token and Policy Acquisition . . . . . . . . . . . . . . 23
82 7.1. Role Token Request . . . . . . . . . . . . . . . . . . . . 23
83 7.2. Request Role Token Response . . . . . . . . . . . . . . . 24
84 7.2.1. RoleToken XML element . . . . . . . . . . . . . . . . 26
85 7.2.2. Email Address List Options . . . . . . . . . . . . . . 30
86 8. Sending An Email . . . . . . . . . . . . . . . . . . . . . . . 31
87 8.1. Send Message Request . . . . . . . . . . . . . . . . . . . 31
88 8.1.1. CMS Message Token Data Structure . . . . . . . . . . . 32
89 8.1.2. XML Label Structure . . . . . . . . . . . . . . . . . 35
90 8.2. Send Message Response . . . . . . . . . . . . . . . . . . 36
91 9. Decoding A Message . . . . . . . . . . . . . . . . . . . . . . 39
92 9.1. Requesting Message Key . . . . . . . . . . . . . . . . . . 39
93 9.2. Requesting Message Key Response . . . . . . . . . . . . . 40
94 10. Plasma Attributes . . . . . . . . . . . . . . . . . . . . . . 42
95 10.1. Data Attributes . . . . . . . . . . . . . . . . . . . . . 42
96 10.1.1. Channel Binding Data Attribute . . . . . . . . . . . . 42
97 10.1.2. CMS Signer Info Data Attribute . . . . . . . . . . . . 43
98 10.1.3. S/MIME Capabilities Data Attribute . . . . . . . . . . 43
99 10.1.4. EMAIL Recipient Addreses . . . . . . . . . . . . . . . 44
100 10.2. Obligations and Advice . . . . . . . . . . . . . . . . . . 44
101 10.2.1. Signature Required . . . . . . . . . . . . . . . . . . 44
102 10.2.2. Encryption Required . . . . . . . . . . . . . . . . . 45
103 11. Certificate Profiles . . . . . . . . . . . . . . . . . . . . . 46
104 12. Message Transmission . . . . . . . . . . . . . . . . . . . . . 47
105 13. Plasma URI Scheme . . . . . . . . . . . . . . . . . . . . . . 48
106 13.1. Plasma URI Schema Syntax . . . . . . . . . . . . . . . . . 48
107 13.2. Definition of Operations . . . . . . . . . . . . . . . . . 48
108 14. Security Considerations . . . . . . . . . . . . . . . . . . . 49
109 14.1. Plasma URI Schema Considerations . . . . . . . . . . . . . 49
110 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
111 15.1. Plasma Action Values . . . . . . . . . . . . . . . . . . . 50
112 15.2. non . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
113 15.3. Port Assignment . . . . . . . . . . . . . . . . . . . . . 52
114 16. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 53
115 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
116 17.1. Normative References . . . . . . . . . . . . . . . . . . . 54
117 17.2. Informative References . . . . . . . . . . . . . . . . . . 55
118 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . .
119 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 58
120 Appendix B. Example: Get Roles Request . . . . . . . . . . . . . 59
121 Appendix C. Example: Get Roles Response . . . . . . . . . . . . . 60
122 Appendix D. Example: Get CMS Token Request . . . . . . . . . . . 62
123 Appendix E. Example: Get CMS Token Response . . . . . . . . . . . 64
124 Appendix F. Example: Get CMS Key Request . . . . . . . . . . . . 65
125 Appendix G. Example: Get CMS KeyResponse . . . . . . . . . . . . 66
126 Appendix H. Enabling the MultiRequests option . . . . . . . . . . 67
127 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 68
129 1. Introduction
131 1.1. XML Nomenclature and Name Spaces
133 The following name spaces are used in this document:
135 +-----+--------------------------------------------+----------------+
136 | Pre | Namespace | Specification( |
137 | fix | | s) |
138 +-----+--------------------------------------------+----------------+
139 | eps | http://ietf.org/2011/plasma/ | This |
140 | | | Specification |
141 | | | |
142 | wst | http://docs.oasis-open.org/ws-sx/ws-trust/ | [WS-TRUST] |
143 | | 200512 | |
144 | | | |
145 | wsu | http://docs.oasis-open.org/wss/2004/01/oas | [WS-Security] |
146 | | is-200401-wss-wssecurity-utility-1.0.xsd | |
147 | | | |
148 | wss | http://docs.oasis-open.org/wss/2004/01/oas | [WS-Security] |
149 | e | is-200401-wss-wssecurity-secext-1.0.xsd | |
150 | | | |
151 | wss | http://docs.oasis-open.org/wss/oasis-wss-w | [WS-Security] |
152 | e11 | security-secext-1.1.xsd | |
153 | | | |
154 | xac | http://docs.oasis-open.org/xacml/3.0/xacml | [XACML] |
155 | ml | -3.0-core-spec-cs-01-en.html | |
156 | | | |
157 | ds | http://www.w3.org/2000/09/xmldsig# | [XML-Signature |
158 | | | ] |
159 | | | |
160 | xen | http://www.w3.org/2001/04/xmlenc# | [XML-Encrypt] |
161 | c | | |
162 | | | |
163 | wsp | http://schemas.xmlsoap.org/ws/2004/09/poli | [WS-Policy] |
164 | | cy | |
165 | | | |
166 | wsa | http://www.w3.org/2005/08/addressing | [WS-Addressing |
167 | | | ] |
168 | | | |
169 | xs | http://www.w3.org/2001/XMLSchema | [XML-Schema1][ |
170 | | | XML-Schema2] |
171 +-----+--------------------------------------------+----------------+
173 1.2. Requirements Terminology
175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
177 document are to be interpreted as described in [RFC2119].
179 When the words appear in lower case, their natural language meaning
180 is used.
182 2. Components
184 In designing this specification we used a number of pre-existing
185 specifications as building blocks. In some cases we use the entirety
186 of the specification and in other case we use only select pieces.
188 2.1. XACML 3.0
190 The XACML specification (eXtensible Access Control Markup Language)
191 [XACML] provides a framework for writing access control policies and
192 for creating standardized access control queries and responses. The
193 request and response portion of the specification is used to build
194 the request (Section 5.2) and response (Section 6.1) messages in this
195 specification. The structure for writing the access control policies
196 is out of scope for this document, but XACML is one of the
197 possibilities that can be used for that purpose.
199 2.2. SAML
201 A number of different methods for carrying both identification and
202 attributes of the party requesting access is permitted in this
203 specification. SAML is one of the methods that is permitted for that
204 purpose.
206 SAML has defined three different types of assertions in it's core
207 specification [OASIS-CORE]:
209 o Authentication: The assertion subject was authenticated by a
210 particular means at a particular time.
212 o Attribute: The assertion subject is associated with the supplied
213 attributes.
215 o Authorization Decision:[anchor7] A request to allow the assertion
216 subject to access the specified resource has been granted or
217 denied.
219 While a PDP can use an Authorization Decision as input, this is
220 unexpected and MAY be supported. In addition there are three
221 different ways that the subject of a SAML statement can be
222 identified:
224 o A bearer statement: These statements are belong to anybody who
225 presents them. The owner is required to take the necessary
226 precautions to protect them.
228 o A holder of key statement: These statements belong to anybody who
229 can use the key associated with the statement.
231 o Subject match:[anchor8] These statements can be associated to an
232 identity by matching the name of the entity.
234 We cannot pass a SAML assertion with attributes as a single attribute
235 in the XACML request as XACML wants each of the different attributes
236 to be individually listed in the request. This greatly simplifies
237 the XACML code, but means that one needs to do a mapping process from
238 the SAML attributes to the XACML attributes. This process has been
239 discussed in Section 2 of [SAML-XACML]. This mapping process MUST be
240 done by a trusted agent, as there are a number of steps that need to
241 be done including the validation of the signature on the SAML
242 assertion. This process cannot be done by the PEP that is residing
243 on the Plasma client's system as this is considered to be an
244 untrusted entity by the Plasma system as a whole. One method for
245 this to be addressed is to treat the Plasma server as both a PDP (for
246 the Plasma client) and a PDP for the true XACML policy evaluator. In
247 this model, the Plasma server becomes the trusted PEP party and has
248 the ability to do the necessary signature validation and mapping
249 processes. A new XACML request is then created and either re-
250 submitted to itself for complete evaluation or to a third party which
251 does the actual XACML processing.[anchor9]
253 2.3. WS-Trust 1.4
255 The WS-Trust 1.4 [WS-TRUST] standard provides for methods for
256 issuing, renewing, and validating security tokens. This
257 specification uses only a small portion of that standard,
258 specifically the structure that returns a trust token from the issuer
259 to the requester.
261 This specification makes no statements on the content and format of
262 the token returned from the Plasma server to the Plasma client in the
263 wst:RequestSecurityTokenResponse field. These tokens may be
264 parseable by the client, but there is no requirement that the client
265 be able to understand the token. The token can always be treated as
266 an opaque blob by the client which is simply reflected back to the
267 server at a later time. The attributes that client needs to
268 understand in order to use the token, such as the life time, are
269 returned as fields of the token response.
271 TODO: need to discuss the content model and say what elements need to
272 be supported and what elements can be ignored -- safely.
274 3. Model
276 To be supplied from the problem statement document. [anchor11]
278 (1)(3) +----------+
279 +----------->|Sending |<------------+
280 | |Agent | |
281 (2) v +----------+ v
282 +----------+ ^ +---------+
283 |Email | | |Mail |
284 |Policy |<----------+ |Transfer |
285 |Service | |Agent |
286 +----------+ +---------+
287 () ^ +----------+ ^
288 | |Receiving | |
289 +----------->|Agent |<------------+
290 ()() +----------+
292 Figure 1: Message Access Control Actors
294 List the boxes above and give some info about them.
296 Email Policy Service is the gateway controller for accessing a
297 message. Although it is represented as a single box in the
298 diagram, there is no reason for it to be in practice. Each of the
299 three protocols could be talking to different instances of a
300 common system. This would allow for a server to operated by
301 Company A, but be placed in Company B's network thus reducing the
302 traffic sent between the two networks.
304 Mail Transfer Agent is the entity or set of entities that is used to
305 move the message from the sender to the receiver. Although this
306 document describes the process in terms of mail, any method can be
307 used to transfer the message.
309 Receiving Agent is the entity that consumes the message.
311 Sending Agent is the entity that originates the message.
313 3.1. Sender Processing
315 We layout the general steps that need to be taken by the sender of an
316 EPS message. The numbers in the steps below refer to the numbers in
317 the upper half of Figure 1. A more detailed description of the
318 processing is found in Section 7 for obtaining the security policies
319 that can be applied to a messages and Section 8 for sending a
320 message.
322 1. The Sending Agent sends a message to one or more Email Policy
323 Services in order to obtain the set of policies that it can apply
324 to a message along with a security token to be used in proving
325 the authorization. Details of the message send can be found in
326 Section 7.1.
328 2. The Email Policy Service examines the set of policies that it
329 understands and checks to see if the requester is authorized to
330 send messages with the policy.
332 3. The Email Policy Service returns the set of policies and an
333 security token to the Sending Agent. Details of the message sent
334 can be found in Section 7.2.
336 4. The Sending Agent selects the Email Policy(s) to be applied to
337 the message, along with the set of recipients for the message.
339 5. The Sending Agent relays the selected information to the Email
340 Policy Service along with the security token. Details of this
341 message can be found in Section 8.1.
343 6. The Email Policy Service creates the recipient info attribute as
344 defined in [EPS-CMS].
346 7. The Email Policy Service returns the created attribute to the
347 Sending Agent. Details of this message can be found in
348 Section 8.2.
350 8. The Sending Agent composes the CMS EnvelopedData content type
351 placing the returned attribute into a KEKRecipientInfo structure
352 and then send the message to the Mail Transport Agent.
354 3.2. Recieving Agent Processing
356 We layout the general steps that need to be taken by the sender of an
357 EPS message. The numbers in the steps below refer to the numbers in
358 the lower half of Figure 1. A more detailed description of the
359 processing is found in Section 9.
361 1. The Receiving Agent obtains the message from the Mail Transport
362 Agent.
364 2. The Receiving Agent starts to decode the message and in that
365 process locates an EvelopedData content type which has a
366 KEKRecipientInfo structure with a XXXX attribute.
368 3. The Receiving Agent processes the SignedData content of the XXXX
369 attribute to determine that communicating with it falls within
370 accepted policy.
372 4. The Receiving Agent transmits the content of the XXXX attribute
373 to the referenced Email Policy Service. The details of this
374 message can be found in Section 9.1.
376 5. The Email Policy Service decrypts the content of the message and
377 applies the policy to the credentials provided by the Receiving
378 Agent.
380 6. If the policy passes, the Email Policy Service returns the
381 appropriate key or RecipientInfo structure to the Receiving
382 Agent. Details of this message can be found in Section 9.2.
384 7. The Receiving Agent proceeds to decrypt the message and perform
385 normal processing.
387 4. Protocol Overview
389 The protocol defined in this document is designed to take place
390 between a Plasma server and a Plasma client. The protocol takes
391 place in terms of a request/response dialog from the client to the
392 server. A single dialog can consist of more than one request/
393 response message pair. Multiple round trips within allow a client to
394 provide additional authentication, authorization and attribute
395 information to the server.
397 Each dialog contains one or more action attributes specifying what
398 actions the client wishes the server to take. Depending on the
399 action requested, additional attributes may be present providing data
400 for the action to use as input. Finally, each dialog will contain
401 authentication and attributes supplied by one or more authorities
402 that the server can use either as input to the action or as input to
403 policy decisions about whether to perform the action.
405 The protocol MUST be run over a secure transport, while the protocol
406 allows for signature operations to occur on sections of the message
407 structure, the secure transport is responsible for providing the
408 confidentiality and integrity protection services over the entire
409 message.
411 Multiple dialogs may be run over a single secure transport. Before a
412 new dialog may be started, the previous dialog MUST have completed to
413 a state of success, failure or not applicable. A new dialog MUST NOT
414 be started after receiving a response with an indeterminate status.
415 This is an indicator that the dialog has not yet completed.[anchor14]
417 5. Plasma Request
419 The specification is written using XACML as the basic structure to
420 frame a request for an operation. The request for operations to
421 occur are written using XACML action items. This specification
422 defines actions specific to Plasma in a CMS environment. Other
423 specifications can define additional action items for other
424 environments (for example the XML encryption environment) or other
425 purposes. (Future work could use this basic structure to standardize
426 the dialogs between PDPs and PAPs or to facilitate legal signatures
427 on emails.)
429 In addition to the XACML action request there is a set of structures
430 to allow for a variety of authentication mechanisms to be used. By
431 allowing for the use of SAML and GSS-API as base authentication
432 mechanisms, the mechanism used is contained in a sub-system and thus
433 does not directly impact the protocol.
435 The request message uses a single XML structure. This structure is
436 the eps:PlasmaRequest object. The XML Schema used to describe this
437 structure is:
439
440
441
442
443
444
445
446
448 The RequestType has two elements in it:
450 Authentication is an optional element that holds the structures used
451 for doing authentication and authorization. Unless no
452 authentication is required by the Plasma server, the element is
453 going to exist for one or more requests in the dialog.
455 xacml:Request is a required element that contains the control
456 information for the action requested. The control information
457 takes the form of an action request plus additional data to be
458 used as part of the action request. The data and actions are to
459 be treated as self-asserted, that is they are deemed not to come
460 from a reliable source even in the event that an authentication is
461 successfully completed. As self-asserted values, Plasma servers
462 need to exercise extreme care about which are included in the
463 policy enforcement decisions. As an example, it makes sense to
464 allow for the action identifier to be included in the policy
465 enforcement, but assertions about the identity of the subject
466 should be omitted. This element is taken from the XACML
467 specification.
469 For some operations, display string values are returned as part of
470 the response from the server. The xml:lang attribute SHOULD be
471 included in the RequestType element to inform the server as to what
472 language client wishes to have the strings in. The server SHOULD
473 attempt to return strings in the language requested or a related
474 language if at all possible.
476 5.1. Authentication Element
478 One of the major goals in the Plasma work is to detach the process of
479 authentication specifics from the Plasma protocol. In order to
480 accomplish this we are specifying the use of two general mechanisms
481 (SAML and GSS-API) which can be configured and expanded without
482 changing the core Plasma protocol itself. The authentication element
483 has two main purposes: 1) to process the authentication being used by
484 the client and 2) to carry authenticated attributes for use in the
485 policy evaluation.
487 When transporting the authentication information, one needs to
488 recognize that there may be a single or multiple messages in the
489 dialog in order to complete the authentication process. In
490 performing the process of authenticating, any or all of the elements
491 in this structure can be used. If there are multiple elements filled
492 out, the server can choose to process the elements in any order.
493 This means that the Plasma protocol itself does not favor any
494 specific mechanism. The current set of mechanisms that are built
495 into the Plasma specification are:
497 o SAML Assertions - many different types of SAML assertions are
498 supported. The specification uses both bearer and holder of key
499 assertions.
501 o X.509 Certificates can be used for the purpose of authentication
502 by creating a signature with the XML Digital Signature standard.
504 o GSS-API - the specification allows for the use of GSS-API in
505 performing the authentication process. The ABFAB mechanism in
506 GSS-API is specifically designed for use in a federated community
507 and allows for both authentication and attribute information to be
508 queried from the identity server.
510 o WS-Trust[anchor16] tokens allow for much of the same type of
511 information to be passed as SAML assertions. The Plasma
512 specification has been designed mailing for the use of WS-Trust
513 tokens to be used for caching prior authentication sessions.
515 More than one authentication element can be present in any single
516 message. This is because a client may need to provide more than one
517 piece of data to a server in order to authenticate, for example a
518 holder of key SAML Assertion along with a signature created with that
519 key. Additionally a client may want to provide the server an option
520 of different ways of doing the authentication. In a federated
521 scenario, an X.509 certificate with a signature can be presented and
522 the server may not be able to build a trust path to it's set of trust
523 anchors. In this case the client may need to use the GSS-API/EAP
524 protocol for doing the authentication. The client may want to
525 provide the server with one or more SAML Assertion that binds a
526 number of attributes to it's identities so that the server does not
527 need to ask for those attributes at a later time. Finally, multiple
528 entities may need to be validated (for example the user and the
529 user's machine).
531 When transporting the attribute information, one needs to recognize
532 that there may be single or multiple messages in the dialog in order
533 to complete the authorization process. The server will return a
534 status code of urn:oasis:names:xacml:1.0:status:missing-attribute in
535 the event that one or more attributes are needed in order to complete
536 the authorization process. The details on how XACML returns missing
537 attribute information is found in Section 7.17.3 of [XACML]. When
538 the list of attributes is returned, the client has two choices: 1) It
539 can close the dialog, look for a source of the missing attributes and
540 then start a new dialog, 2) it can just get an assertion for the
541 missing attributes and send the new assertion as in a new request
542 message within the same dialog. The decision of which process to use
543 will depend in part on how long it is expected to take to get the new
544 attribute assertion to be returned.
546 The same authentication data does not need to be re-transmitted to
547 the server in a subsequent message within a single dialog. The
548 server MUST retain all authenticated assertion information during a
549 single dialog.
551 The schema for the Authentication element directly maps to the
552 ability to hold the above elements. The schema for the
553 Authentication element is:
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
578 The schema allows for multiple authentication elements to occur in
579 any order. It is suggested, but not required, that the ds2:Signature
580 element occur after the authentication element that has an assoicated
581 key. This makes it easier for servers to make a one pass validate of
582 all authentication elements.
584 The Other element is provided to allow for additional authentication
585 elements, include SAML version 1.1, to be used.
587 5.1.1. SAML Assertion
589 SAML Assertions can provide authentication or attribute information
590 to the server. A SAML statement only needs to be provided once
591 during a single dialog, the server MUST remember all attributes
592 during the dialog.
594 When a SAML Assertion contains a SubjectConformation element using
595 the KeyInfoConfirmationDataType as a subject conformation element,
596 the confirmation shall be performed by the creation of an XML
597 Signature authentication element. The signature element shall be
598 created using an appropriate algorithm for the key referenced in the
599 SAML statement.
601 Identify a SAML statement in the delegation/subject/environment space
602 - need text for this
604 5.1.2. WS Trust Tokens
606 WS Trust tokens are used in two different ways by this specification.
607 They can be used as the primary introduction method of a client to
608 the server, or they can be used by the server to allow the client to
609 be re-introduced to the server in such a way that the server can use
610 cached information.
612 WS Trust tokens come in two basic flavors: Bearer tokens[anchor18]
613 and Holder of Key tokens. With the first flavor, presentation of the
614 token is considered to be sufficient to allow the server to validate
615 the identity of the presenter and know the appropriate attributes to
616 make a policy decision. In the second flavor some type of
617 cryptographic operation is needed in addition to just presenting the
618 token. The Signature element Section 5.1.3 provides necessary
619 infrastructure to permit the cryptographic result to be passed to the
620 server.
622 This document does not define the content or structure of any tokens
623 to be used. This is strictly an implementation issue for the servers
624 in question. This is because the client can treat the WS Token value
625 presented to it as an opaque blob.[anchor19] Only the servers need to
626 understand how to process the blob. However there are some
627 additional fields which can be returned in addition to the token that
628 need to be discussed:
630 wst:TokenType SHOULD be returned if more than one type of token is
631 used by the set of servers. If a token type is returned to the
632 client, the client MUST include the element when the token is
633 returned to the server.
635 wst:BinarySecret SHOULD be returned for moderate duration tokens.
636 If a binary secret is returned then the client MUST provide
637 protection for the secret value. When a binary secret has been
638 returned, then the client MUST create either a signature or MAC
639 value and place it into the Signature element Section 5.1.3.
640 [anchor20].
642 wst:Lifetime MUST be returned with the wsu:Expires element set. The
643 wsu:Created element MAY be included. The element provides the
644 client a way to know when a token is going to expire and obtain a
645 new one as needed.
647 5.1.3. XML Signature Element
649 When a holder of key credential is used to determine the attributes
650 associated with an entity, there is a requirement that the key be
651 used in a proof of possession step so that the Plasma server can
652 validate that the entity does hold the key. The credentials can hold
653 either asymmetric keys (X.509 certificates and SAML Assertions) or
654 symmetric keys (WS Trust Tokens and SAML Assertions) which use
655 Digital Signatures or Message Authentication Codes (MACs)
656 respectively to create and validate a key usage statement. The XML
657 signature standard [XML-Signature] provides an infrastructure to for
658 conveying the proof of possession information.
660 The signature is computed over the XACML request element as a
661 detached signature. When a signature element exists in the message,
662 the ChannelBinding attribute (Section 10.1.1) MUST be included in the
663 request. By the use of a value which is derived from the
664 cryptographic keys used in for protecting the tunnel, it is possible
665 for the server to verify that the authentication values computed were
666 done specifically for this specific dialog and are not replayed.
668 When creating either a signature or a MAC, the following statements
669 hold:
671 o The canonicalization algorithm Canonical XML 1.1 [XML-C14N11]
672 without comments MUST be supported and SHOULD be used in preparing
673 the XML node set for hashing. Other canonicalization algorithms
674 MAY be used.
676 o The signature algorithms RSAwithSHA256 and ECDSAwithSHA256 MUST be
677 supported by servers. At least one of the algorithms MUST be
678 supported by clients. The MAC algorithm HMAC-SHA256 MUST be
679 supported by both clients and servers. Other signature and MAC
680 algorithms MAY be supported.
682 o Set the additional attributes that must be included in a signature
683 - what should they be?
685 o If an xacml:Request element is referenced by an XML Signature
686 element, the xacml:Request element MUST include the ChannelBinding
687 token (Section 10.1.1) as one of the attributes.
689 o The keys used in computing the authentication value need to be
690 identified for the recipient. For X509 certificates, the full raw
691 certificate will normally be included as part of the signature,
692 but MAY be referenced instead. For SAML assertions, the specific
693 assertion carrying the asymmetric key can be identified by TBD
694 HERE. In the event that symmetric keys are used by holder of key
695 assertions, the specific assertion will be identified by TBD HERE.
696 In these cases the server is expected to be able to associated the
697 key with the assertion by some means (either locally or perhaps
698 encrypted into the assertion).
700 5.1.4. GSS-API Element
702 TBD - rules for using GSS-API in general and the EAP version from
703 ABFAB particularly.
705 o How to build the name.
707 o Must use a secure tunnel for the outer EAP method and an
708 appropriate inner EAP method(s) to accomplish the required level
709 of authentication.
711 o Server query of attributes and specification of LOA to the EAP
712 IdP.
714 o Any additional Trust model items.
716 o How round trips are accomplished - the only case that a server
717 will send back an Authentication element is on return processing
718 of GSS-API messages.
720 5.2. xacml:Request Element
722 The request for an action to be performed by the Plasma server along
723 with the data that needs to be supplied by the client in order for
724 the server to complete the action are placed into the xacml:Request
725 element of the request. This document defines a set of actions that
726 are to be understood by the Plasma server. One (or more) action is
727 to be placed in the request message.
729 In addition to the request for a specific action to occur, the client
730 can place additional attributes in the request as well. These
731 attributes are provided in order to assist the server either in
732 identifying who the various agents on the client side are or to
733 provide suggestions of attributes for using in making control
734 decisions. Any data provided by the client in this manner is to be
735 considered as a self-asserted value and to be treated as if it comes
736 from the client as oppose to a trusted attribute agent.
738 For convenience the schema for the xacml:Request element is
739 reproduced here:
741
742
743
744
745
746
747
748
749
750
752 The RequestDefaults element of the XACML Request MUST be omitted by
753 the clients. If present servers MUST ignore the RequestDefaults
754 element. The use of the MultiRequest element is current not defined
755 for a Plasma server and SHOULD be omitted by clients.
757 Clients MAY set ReturnPolicyIdList to true in order to find out which
758 policies where used by the server in making the decision. Server MAY
759 ignore this field and not return the policy list even if requested.
761 A number of different entities may need to be identified to Plasma
762 server as part of a request. These entities include:
764 1. The subject making the request to the server.
766 2. The machine on the subject is using.
768 3. The entity the subject is acting for. Converse about Delegation.
770 6. Plasma Response Element
772 There is a single top level structure that is used by the server to
773 respond to a client request.
775 The XML Schema used to describe the top level response is as follows:
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
793 A Plasma Response has two elements:
795 xacml:Response is a mandatory element that returns the status of the
796 access request.
798 PlasmaReturnToken is an optional element to return a token. These
799 tokens represent the answer, for a success, of the request. If
800 multiple tokens are being returned, then the element will occur
801 mutiple times.
803 A Plasma Return Token is a wrapper for the actual token being
804 returned. The returned token may be any content. This document
805 defines the following elements that are to be returned in this
806 location
808 o RoleToken - used to return roles.
810 o CMSMessageToken - used to return one or more CMS RecipientInfo
811 strucutures.
813 o CMSKeyToken - used to return either a CMS RecipientInfo structure
814 or a bare content encryption key.
816 The PlasmaReturneTokenType has an optional attribute DecisionId.
817 This attribute is used when in the case multiple requests are made at
818 the same time in order to assoicate the rquest and the response
819 tokens.
821 6.1. xacml:Response Element
823 The xacml:Response element has the ability to return both a decision,
824 but additionally information about why a decision was not made.
826 The schema for the xacml:Response element is reproduced here for
827 convenience:
829
830
831
832
833
834
836
837
838
839
840
841
842
843
844
845
846
848 The xacml:Response element consists of one child the Result.
850 The xacml:Response element consists of the following elements:
852 xacml:Decision is a mandatory element that returns the possible
853 decisions of the access control decision. The set of permitted
854 values are Permit, Deny, Indeterminate and No Policy.
856 xacml:Status is an optional element returned for the Indeterminate
857 status which provides for the reason that a decision was not able
858 to be reached. Additionally it can contain hints for remedying
859 the situation. This document defines a new set of status values
860 to be returned. Formal declaration may be found in Section 15.
862 * gss-api indicates that a gss-api message has been returned as
863 part of the authentication process.
865 xacml:Obligations is designed to force the PEP to perform specific
866 actions prior to allowing access to the resource. If a response
867 is returned with this element present, the processing MUST fail
868 unless the PEP can perform the required action. A set of Plasma
869 specific obligations are found in Section 10.2. [anchor23]
871 xacml:AssocatedAdvice is designed to give suggestions to the PEP
872 about performing specific actions prior to allowing access to the
873 resource. This element is not used by Plasma and SHOULD be
874 absent. If the response is returned with this element present,
875 processing will succeed even if the PEP does not know how to
876 perform the required action. A set of Plasma specific advice
877 elements are found in Section 10.2.
879 xacml:Attributes provides a location for the server to return
880 attributes used in the access control evaluation process. Only
881 those attributes requested in the Attributes section of the
882 request are to be returned. Since Plasma does not generally
883 supply attributes for the evaluation process, this field will
884 normally be absent.
886 xacml:PolicyIdentifierList provides a location to return the set of
887 policies used to grant access to the resource. This element is
888 expected to be absent for Plasma. [anchor24][anchor25]
890 7. Role Token and Policy Acquisition
892 In order to send an email using a Plasma server, the first step is to
893 obtain a role token that provides the description of the labels that
894 can be applied and the authorization to send an email using one or
895 more of the labels. The process of obtaining the role token is
896 designed to be a request/response round trip to the Plasma server.
897 In practice a number of round trips may be necessary in order to
898 provide all of the identity and attributes to the Plasma server that
899 are needed to evaluate the policies for the labels.
901 When a Plasma server receives a role token request from a client, it
902 needs to perform a policy evaluation for all of the policies that it
903 arbitrates along with all of the options for those policies. In
904 general, the first time that a client requests a role token from the
905 server, it will not know the level of authentication that is needed
906 or the set of attributes that needs to be presented in order to get
907 the set of tokens. A server MUST NOT issue a role token without
908 first attempting to retrieve from an attribute source (either the
909 client or a back end server) all of the attributes required to check
910 all policies. Since the work load required on the server is expected
911 to be potentially extensive for creating the role token, it is
912 expected that the token returned will be valid for a period of time.
913 This will allow for the frequency of the operation to be reduced.
914 While the use of an extant role token can be used for identity proof,
915 it is not generally suggested that a new token be issued without
916 doing a full evaluation of the attributes of the client as either the
917 policy or the set of client attributes may have changed in the mean
918 time.
920 7.1. Role Token Request
922 The process starts by a client sending a server a role token request.
923 Generally, but not always, the request will include some type of
924 identity proof information and a set of attributes. It is suggested
925 that, after the first successful conversation, the client cache hints
926 about the identity and attributes needed for a server. This allows
927 for fewer round trips in later conversations. An example of a
928 request token can be found in Appendix B.
930 The role token request, as with all requests, uses the eps:
931 PlasmaRequest XML structure. The eps:Authentication MAY be included
932 on the first message and MUST be included on subsequent
933 authentication round trips.
935 A role token request by a client MUST include the GetRoleTokens
936 Plasma action request as an attribute of the xacml:Request element.
937 Details on the action can be found in section Section 15.1. When
938 role tokens are requested, no additional data needs to be supplied by
939 the requester.
941 An example of a message requesting the set of policy information is:
943
944 ...
945
946
947
948
950 GetRoleToken
951
952
953
954
956 7.2. Request Role Token Response
958 In response to a role token request, the Plasma server returns a role
959 token response. The response uses the eps:PlasmaResponse XML
960 structure. When a response is create the following should be noted:
962 An xacml:Decision is always included in a response. The values
963 permitted are:
965 Permit is used to signal success. In this case the response MUST
966 include one or more eps:RoleToken element.
968 Deny is used to signal failure. In this case the xacml:Status
969 element MUST be present an contain a failure reason.
971 Indeterminate is used to signal that a final result has not yet been
972 reached. When this decision is reached, the server SHOULD return
973 a list of additional attributes to be returned and SHOULD return
974 the list of role tokens that have been granted based on the
975 attributes received to that point.
977 NotApplicable is returned if the Plasma server does not have the
978 capability to issue role tokens.
980 An example of a response returning the set of policy information is:
982
983
984
985 Permit
986
987
988
989
990 Role Display Name
991 PDP Uri name
992
993
994 Details of a policy
995
996 ... More policies ...
997
998
999 ../myschema#roleToken
1000 ...
1001
1002
1003
1004 ... More Role Tokens ...
1005
1007 The process of getting role tokens has a problem that is not part of
1008 the normal XACML design. It is possible to compute a partial result
1009 based on the current set of attributes that have been supplied by the
1010 client, while having other role tokens that cannot be provided to the
1011 client since required attributes have not been provided. Since this
1012 is not part of the standard XACML model, one only has a single
1013 access/deny decision and if the attributes have not been provided
1014 then the response would be deny, we need to look at it in a bit more
1015 detail here.
1017 In the process of discussions three different solutions to the
1018 problem were considered:
1020 A signal could be added that allows for the client to signal that
1021 it cannot provide any more attributes to the server. This would
1022 allow for a final decision to be provided, but would potentially
1023 involve an additional round trip as the set of attributes can be
1024 determined based on the set of attributes provided. Supplying new
1025 attributes from the client can result in the server asking for new
1026 attributes from the client. This is not currently supported by
1027 the XACML model and there is no clear point where it would go into
1028 our model.
1030 The server can return a partial result on each round trip. This
1031 maps directly onto the XACML model, but leads to some other
1032 problems. It means that all of the policies must be designed such
1033 that adding a new attribute to the policy evaluation process will
1034 not cause a policy that previously had been permitted is now
1035 denied.
1037 A method could be added that allows for the client to state that
1038 it either does not have or does not know what an attribute is.
1039 This method would allow for the server to make a definitive
1040 answer, but it requires that one extra round trip be made to get
1041 the final answer.
1043 The normal mode that Plasma servers are expected to operate in is
1044 returning incremental results, however they can also keep internal
1045 state looking at what additional attributes are being provided by the
1046 client. If the client provides no new attributes, then the server
1047 can return a set of role tokens close down the conversation. If the
1048 server expects to get all attributes from the back end, and just get
1049 authentication from client, then it can return a set of role tokens
1050 immediately without providing a list of attributes to the client for
1051 it to try and satisfy.
1053 7.2.1. RoleToken XML element
1055 The eps:PlasmaReturnToken element is used to return a role token to
1056 the client. Multiple role tokens can be returned by using multiple
1057 eps:PlasmaReturnToken elements. Each role token returned contains
1058 one or more policies that can be asserted, the role token, and
1059 optionally one or more set of obligations or advice that need to be
1060 observed when creating messages. Additionally the name of a Plasma
1061 server to be used with the token can be included as well as
1062 cryptographic information to be used with the token.
1064 The schema used for the PlasmaTokens element is:
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1103 The eps:RoleToken element contains the following items:
1105 FriendlyName This element returns a descriptive name of the role as
1106 a whole. The string returned SHOULD be selected based on the
1107 language attribute on the request message. The string is suitable
1108 for display to the user and should be indicative of the scope of
1109 the role. Examples of role descriptive strings would be "Company
1110 President", "Senior Executive", "Project X Electrical
1111 Engineer".[anchor27]
1113 PDP The element provides one or more URLs to be used for contacting
1114 a Plasma server for the purpose of sending a message. This
1115 element allows for the use of different Plasma servers for issuing
1116 role tokens and message tokens. No ranking of the servers is
1117 implied by the order of the URLs returned.[anchor28]
1119 PolicyList contains the description of one or more policies that can
1120 be asserted using the issued role token. Any of the policies
1121 contained in the list may be combined together using the policy
1122 logic in constructing a label during the send message process.
1124 Policy contains a single simple policy. This element is returned as
1125 part of a read message token. The purposes is to allow for a
1126 recipient to reply to a message that they would not normally be
1127 able to assert.
1129 PolicySet contains a complex policy. This element is returned as
1130 part of a read message token The purpose is to allow for a
1131 recipient to reply to a message that they would not normally be
1132 able to assert.
1134 wst:RequestSecurityTokenResponse contains the actual token itself.
1136 xacml:Obligations This optional element contains a set of
1137 obligations that the client is required to enforce in order to use
1138 any of the policies listed when combined with the returned
1139 security token. These obligations can include items such as
1140 required algorithms or required operational steps such as
1141 requiring a signature to be placed on the content. A policy can
1142 be listed in multiple role tokens and the set of obligations may
1143 be different depending on which role token is used. If the client
1144 is unable to fulfill the obligations then it MUST NOT allow the
1145 role token to be used.
1147 xacml:AssociatedAdvice This optional element contains a set of
1148 advice statements that the client is requested to enforce when
1149 using any of the policies listed when combined with the returned
1150 security token. This advice can include items such as encryption
1151 or signature algorithms or operational steps such as requiring a
1152 signature to be placed on the content. The client is SHOULD
1153 fulfill the advice, however if it cannot fulfill the advice the
1154 role token may still be used.
1156 The eps:PolicyType type is used to represent the elements of a policy
1157 to the client. The elements in this type are:
1159 FriendlyName contains a display string that represents the policy.
1160 This element is localized in response to the xs:lang attribute in
1161 the eps:PlasmaRequest node.
1163 PolicyId contains a "unique" identifier for the policy. This is the
1164 value that identifies the policy to the software. The type for
1165 the value is defined as a URI.
1167 Options This element is used to inform the client what the set of
1168 options that need to be filled in as part of asserting the policy.
1169 If the client software does not understand how to set the options
1170 for the supplied type, then the client software MUST NOT allow the
1171 user to assert the policy. The option structure is identified by
1172 the URI in the optionsType attribute. This document defines one
1173 option structure for holding a list of email addresses (section
1174 Section 7.2.2). This option structure is used in the basic
1175 policies defined in [PlasmaBasicPolicy].
1177 When building the wst:RequestSecurityTokenResponse element, the
1178 following should be noted:
1180 A wst:RequestedSecurityToken element containing the security token
1181 MUST be included. The format of the security token is not
1182 specified and is implementation specific, it is not expected that
1183 clients should be able to get useful information from the token
1184 itself. Information such as lifetimes need to be provided as
1185 addition elements in the response. Examples of items that could
1186 be used as security tokens are SAML statements or encrypted record
1187 numbers in a server database.
1189 A wst:Lifetime giving the life time of the token SHOULD be
1190 included. It is not expected that this should be determinable
1191 from the token itself and thus must be independently provided.
1192 There is no guarantee that the token will be good during the
1193 lifetime as it may get revoked due to changes in the environment
1194 (for example, if the policies are updated then all existing tokens
1195 may need to be re-issued), however the client is permitted to act
1196 as if it were. The token provided may be used for duration. If
1197 this element is absent, it should be assumed that the token is
1198 either a one time token or of limited duration.
1200 Talk about cryptographic information - There are three different
1201 types of crypto information that can be returned and we need to
1202 figure out how to talk about them. These are 1) a symmetric key,
1203 2) a new asymmetric key and 3) a pre-existing asymmetric key - for
1204 example from the certificate used for authentication purposes.
1205 There is probably good ways to do 1 and 2, but I don't know how to
1206 talk about 3 at this point in time.
1208 7.2.2. Email Address List Options
1210 Some policies are designed to be restricted to a set of explicitly
1211 named people by the sender of the message. This policy is used for
1212 the set of basic policies defined in [PlasmaBasicPolicy]. In these
1213 cases the creator of the message specifies a set of recipients by
1214 using email address names without any decoration.
1216 The Email Address List Option is identified by the uri
1217 "urn:ietf:params:xml:ns:plasma:options:emailAddrs". The type
1218 associated with the structure is a string. The string contains a
1219 space separated set of internalized email addresses. Domains SHOULD
1220 be encoded as U-labels rather than using puny code.
1222 All Plasma clients and servers MUST be able to create, parse and use
1223 the Email Address List Option for any policy.
1225 As of the release of this document, Plasma clients and servers are
1226 not expected to understand any other options.
1228 8. Sending An Email
1230 After having obtained a role token from a Plasma server, the client
1231 can then prepare to send an Email by requesting a message token from
1232 the Plasma server. As part of the preparatory process, the client
1233 will construct the label to be applied to the Email from the set of
1234 policies that it can assert, determine the optional elements for
1235 those policies which have options, generate the random key encryption
1236 key and possible create the key recipient structures for the email.
1237 Although this section is written in terms of a CMS Encrypted message,
1238 there is nothing to prevent the specification of different formats
1239 and still use this same basic protocol. An example of a send mail
1240 request token can be found in Appendix D.
1242 8.1. Send Message Request
1244 The send message request is built using the eps:PlasmaRequest XML
1245 structure. When building the request, the following applies:
1247 o The eps:Authentication element MUST be included in the initial
1248 message. The role token that authorizes the use of the label MUST
1249 be included in the initial message. If the role token is
1250 dependent on a cryptographic key for authentication, then that
1251 authentication MUST be included in the initial message.
1253 o The client MUST include an action attribute. This document
1254 defines the GetSendCMSToken action attribute for this purpose.
1256 o The client MUST include a data attribute. This attribute contains
1257 the information that is used to build the CMS Message token to be
1258 returned. There MAY be more than one data attribute, but this
1259 will not be a normal case. More details on this attribute are in
1260 Section 8.1.1.
1262 o If the client is using the XML Digital Signature element in this
1263 message, then the client MUST include the cryptographic channel
1264 binding token (Section 10.1.1) in the set of XACML attributes.
1266 A message requesting that a CMS message token be created looks like
1267 this:
1269
1270
1271
1272 Role Token goes here
1273
1274
1275
1276
1277
1278
1279 GetSendCMSToken
1280
1281
1282
1283
1284
1285
1288 ... Policy Options ...
1289
1290
1291 ... Hash algorithm and hash of encrypted content ...
1292
1293
1294 ... Content Encryption Key ...
1295
1296
1297
1298
1299
1300
1301
1303 8.1.1. CMS Message Token Data Structure
1305 The message token data structure is used as an attribute to carry the
1306 necessary information to issue a CMS message token. The schema that
1307 describes the structure is:
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1344 When used in an xacml:Attribute, the structure is identified by:
1346 Category = "urn:ietf:params:xml:ns:plasma:data"
1347 AttributeId = "urn:ietf:params:xml:ns:plasma:data:CMSTokenRequest"
1348 DataType =
1349 "urn:ietf:params:xml:schema:plasma:1.0#CMSTokenRequestType"
1351 The elements of the structure are used as:
1353 Policy
1354 This element contains a the policy to be applied to the message
1355 when a single policy is used.
1357 PolicySet
1358 This element contains the policy to be applied to the message when
1359 a combination of policies is to be applied.
1361 Hash
1362 This element contains the hash of the encrypted content of the
1363 message that the policy is being applied to. The algorithm used
1364 to compute the hash is contained in the DigestMethod element and
1365 the value is contained in the DigestValue element.
1367 LockBox
1368 This optional element contains a pre-computed CMS recipient info
1369 structure for a message recipient. This element may be repeated
1370 when more than one lock box is pre-computed for recipients by the
1371 message sender. This element is used in those cases where the
1372 sender does not want to share the content encryption key with the
1373 Plasma server and the sender has the ability to retrieve the
1374 necessary keys for all of the recipients. If the #### obligation
1375 was returned for the role token, then a recipient info lock box
1376 MUST be created for the Plasma server and the CEK element MUST
1377 absent. [anchor29]
1379 CEK
1380 This optional element contains the content encryption key (CEK) to
1381 decrypt the message.
1383 One or both of CEK and Recipients elements MUST be present.
1385 The elements of the LockBoxType structure are:
1387 Subject
1388 This element contains a subject identifier. The element can occur
1389 more than one time in situations where a subject has multiple
1390 names or a key is used by multiple subjects. Since a CMS
1391 recipient info structure does not contain a great deal of
1392 information about the recipient, this element contains a string
1393 which can be used to identify the subject. The format of the
1394 subject name is provided by the required type attribute of the
1395 element. All implementations MUST recognize
1396 "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" as a name
1397 type. [anchor30] Other name types MAY be recognized.
1399 CMSLockBox
1400 This element contains a base64 encoded CMS Recipient Info
1401 structure. If the recipient info structure is placed here, it
1402 MUST NOT be placed in the CMS EnvelopedData structure as well.
1404 8.1.2. XML Label Structure
1406 A client is allowed to build a complex label to be sent to the Plasma
1407 server for evaluation. While there are some cases that a simple
1408 single policy is applied to a message, it is expected that many, if
1409 not most, messages will have more than one policy applied to it with
1410 logical statements connected those policies.
1412 The schema for specifying a label is:
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1432 The Policy and the PolicySet elements are used when specifying a
1433 policy for a message depending on whether a single policy or multiple
1434 policies are to be evaluated.
1436 The Policy element is used to specify a single policy to the server
1437 along with any options that are defined for that policy. The Policy
1438 element contains:
1440 PolicyId
1441 Is an attribute that contains the URI which identifies a specific
1442 policy to be evaluated.
1444 inner content
1445 The content of the Policy element can be any XML element. The
1446 content is to be the set of selected options for the policy (if
1447 any exist). The schema applied to the content is based on the
1448 policy selected.
1450 The PolicySet element is used to specify a logical set of policies to
1451 be applied to the message. This element allows one to specify
1452 multiple policies along with a logic operation to combine them
1453 together.
1455 Policy
1456 This element allows for a single policy and any policy specific
1457 options for the policy to be specified. This element can occur
1458 zero or more times.
1460 PolicySet
1461 This element allows for a logical set of policies to be
1462 recursively evaluated. This element can occur zero or more times.
1464 PolicyCombiningAlgId
1465 This attribute specifies the operation to be used in combining the
1466 elements of the tree together. This specification uses the XACML
1467 policy combining algorithms from [XACML]. Servers and clients
1468 MUST support the unordered Deny-Overrides and Permit-Overrides
1469 policy combining rules. Servers SHOULD support all of the policy
1470 combining rules defined in [XACML]. Clients are expected to use a
1471 friendly name when displaying the policy combining rule to users.
1472 When displaying strings to users, the following strings are
1473 suggested:
1475 AND Is used to represent either the ordered or unordered Deny-
1476 Overrides combining algorithm.
1478 OR Is used to represent either the ordered or unordered Permit-
1479 Overrides combining algorithm.
1481 8.2. Send Message Response
1483 In response to a send message request, the Plasma server returns a
1484 send message response message. The response messages uses the eps:
1485 PlasmaResponse XML structure. When the response message is created,
1486 the following should be noted:
1488 o The xacml:Decision is always included in the response. If the
1489 'Permit' value is returned then a CMS Token Response element MUST
1490 be present.
1492 o The PlasmaReturnToken element with a eps:CMSToken content is
1493 included with a permit response. The CMSToken contains one or
1494 more CMS RecipientInfo objects to be included in the message sent.
1496 An example of a message returning the set of policy information is:
1498
1499
1500
1501 Permit
1502
1503
1504
1505 234e34d3...
1506
1507
1509 The schema use for returning a CMS token is:
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1526 This schema fragment extends the Plasma response token type and
1527 allows for the return of one or more base64 encoded RecipientInfo
1528 structures. The Plasma server can return recipient info information
1529 for any recipient that it pre-authorizes to receive the message (see
1530 Section ### of [Plasma] for examples of when this would occur).
1531 Additionally the Plasma server can return a KEKRecipientInfo
1532 structure with the Plasma Other Key attribute. (For details see
1533 [EPS-CMS].) In some extremely rare cases where the Plasma server can
1534 pre-authorize the entire set of recipients , the KEKRecipientInfo
1535 structure with the Plasma Other Key Attribute may not be included in
1536 the returned set of recipients. The recipient info structure for the
1537 plasma server SHOULD be placed last in the list of recipients infos.
1539 The CMSTokenResponse type has the following:
1541 CMSLockBox
1542 This element contains the ASN.1 encoding for a CMS RecipientInfo
1543 structure to be placed in the final message. This element will
1544 occur multiple times if there are multiple CMS RecipientInfo
1545 structures being returned from the server.
1547 CMSType
1548 This attribute of the RecipientInfo structure is an optional text
1549 value that identifies the type of recipient info structure
1550 returned. NOTE: This attribute is currently optional and is
1551 likely to disappear if I do not find it useful.
1553 9. Decoding A Message
1555 When the receiving agent is ready to decrypt the email, it identifies
1556 that there is a KEKRecipientInfo object which contains a key
1557 attribute identified by id-keyatt-eps-token. It validates the
1558 signature, determines that communicating with the Plasma Service is
1559 within local policy, and then sends a request to the service to
1560 obtain the decryption key for the message.
1562 In some cases the recipient of a message is not authorized to use the
1563 same set of labels for sending a message. For this purpose a token
1564 can be returned in the message along with the key so that recipient
1565 of the can reply to the message using the same set of security
1566 labels.
1568 9.1. Requesting Message Key
1570 The client sends a request to the Plasma server that is identified in
1571 the token. For the CMS base tokens, the address of the Plasma server
1572 to use is defined in [EPS-CMS] this is located in the aa-eps-url
1573 attribute.
1575 The request uses the eps:PlasmaRequest XML structure. When building
1576 the request, the following should be noted:
1578 o The xacml:Request MUST be present in the first message of the
1579 exchange.
1581 o The action used to denote that a CMS token should be decrypted is
1582 "ParseCMSToken".
1584 o The CMS token to be cracked is identified by "CMSToken"
1586 o In the event that a reply to role token is wanted as well, then
1587 that is supplied as a separate action. [anchor31] In this case the
1588 action is "GetReplyToken".
1590 o If the client is using the XML Digital Signature element in this
1591 message, then the client MUST include the cryptographic channel
1592 binding token (Section 10.1.1) in the set of XACML attributes.
1594 An example of a message returning the set of policy information is:
1596
1597 ...
1598
1599
1600
1601 ParseCMSToken
1602
1603
1604
1605
1606
1607
1608 Base64 encoded CMS Token Value
1609
1610
1611
1612
1613
1614
1616 When used in an xacml:Attribute, the structure is identified by:
1618 Category = "urn:ietf:params:xml:ns:plasma:data"
1619 AttributeId = "urn:ietf:params:xml:ns:plasma:data:CMSToken"
1620 DataType =
1621 "urn:ietf:params:xml:schema:plasma:1.0#CMSTokenResponseType
1623 9.2. Requesting Message Key Response
1625 In response to a message key request, the Plasma server returns a
1626 decrypted key in the message key response. The response message uses
1627 the eps:Plasma XML structure. When a response message is create the
1628 following should be noted:
1630 o If the value of xacml:Decision is Permit, then response MUST
1631 include an eps:CMSKey element.
1633 o For all other decision types the eps:CMSKey MUST be absent.
1635 o If a reply token was requested and granted, then the response MUST
1636 include an eps:PlasmaToken element. The eps:PlasmaToken element
1637 MUST use the Label option
1639 An example of a message returning the set of policy information is:
1641
1642
1643
1644 Permit
1645
1646
1647
1648 Label TExt
1649 hex based KEK
1650
1651
1653 The schema for returning the decrypted key is:
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1668 This schema extends the Plasma response token type and restricts the
1669 content to the listed elements. The values returned are:
1671 DisplayString returns a localized display string for the policy(s)
1672 which were applied to the message. The lang attribute on the
1673 request is used to determine which language to use for this
1674 string.
1676 CEK returns the base64 encoded content encryption key.
1678 CMSLockBox returns the content encryption key in the form of a CMS
1679 RecipientInfo structure.
1681 RoleToken optionally returns a role token for replying to this
1682 message.
1684 Attributes optionally returns a set of attributes associated with
1685 the message.
1687 10. Plasma Attributes
1689 In this document a number of different XACML attributes have been
1690 defined, this section provides a more detailed description of these
1691 elements.
1693 10.1. Data Attributes
1695 10.1.1. Channel Binding Data Attribute
1697 The channel binding data attribute is used to provide for a binding
1698 of the TLS session that is being used to transport the Plasma
1699 messages with the content of the Plasma requests themselves. There
1700 is a need for the server to be able to validate that the
1701 cryptographic operations related to holder of key statements be made
1702 specifically for the current conversation and not be left over from a
1703 previous one as a replay attack. By deriving a cryptographic value
1704 from the shared TLS session key and signing that value we are able to
1705 do so.
1707 The channel binding value to be used is created by the TLS key
1708 exporter specification defined in RFC 5705 [RFC5705]. This allows
1709 for a new cryptographic value to be derived from the existing shared
1710 secret key with additional input to defined the context in which the
1711 key is being derived. When using the exporter, the label to be input
1712 into the key exporter is "EXPORTER_PLASMA". The value to be derived
1713 will be 512 bits in length, and no context is provided to the
1714 exporter.
1716 When used as an XACML attribute in a request:
1718 The category of the attribute is
1719 "urn:ietf:params:xml:ns:plasma:data".
1721 The AttributeId attribute is
1722 "urn:ietf:params:xml:ns:plasma:data:ChannelBinding".
1724 The Issuer attribute is absent.
1726 The DataType is either base64Binary or hexBinary
1728 The same value is used for both the XACML channel binding data
1729 attribute and the XML channel binding structure defined in
1730 Section 5.1.3.
1732 10.1.2. CMS Signer Info Data Attribute
1734 In many cases a policy states that the client is required to sign the
1735 message before encrypting it. The server cannot verify that a
1736 signature is applied to the message and included, but we can require
1737 that a signature be supplied to the server. This signature can then
1738 be validated by the server (except for the message digest attribute
1739 value), and the server can take a hash of the value and return it as
1740 part of the key returned to a decrypting agent. This agent can then
1741 validate that the signature is a part of the message and complain if
1742 it absent. This means we do not have an enforcement mechanism, but
1743 we do have a way of performing an audit at a later time to see that
1744 the signature operation was carried out correctly.
1746 By requiring that a signature be supplied to the server as part of
1747 the authentication process, the Plasma server can also be setup so
1748 that the supplied signature is automatically setup for archival
1749 operations. One way to do archiving is to use the data records
1750 defined in [RFC4998].
1752 The following applies when this data value is present:
1754 The Category attribute is "urn:ietf:params:xml:ns:plasma:data".
1756 The AttributeId attribute is
1757 "urn:ietf:params:xml:ns:plasma:data:CMSSignerInfo".
1759 The Issuer attribute is absent.
1761 The DataType attribute is either base64Binary or hexBinary.
1763 10.1.3. S/MIME Capabilities Data Attribute
1765 Policies sometimes require that specific algorithms be used in order
1766 to meet the security needs of the policy. This attribute allows for
1767 an S/MIME Capabilities to be carried in a DER encoded
1768 SMIMECapabilities ASN.1 structure to be transmitted to the client.
1769 Details on how the S/MIME Capabilities function can be found in
1770 [SMIME-MSG].
1772 The following attributes are to be set for the data value:
1774 The Category attribute is "urn:ietf:params:xml:ns:plasma:data".
1776 The AttributeId attribute is
1777 "urn:ietf:params:xml:ns:plasma:data:SMIME-Capabilties".
1779 The Issuer attribute is absent.
1781 The DataType attribute is either base64binary or hexBinary.
1783 10.1.4. EMAIL Recipient Addreses
1785 In order for Plasma Servers to do pre-authentication in the Email
1786 environment, it is necessary for the set of recipient addresses to be
1787 delivered to the Plasma Server. The Plasma Server cannot reliably
1788 determine the set of recipients from the policies set on the message
1789 as the set of recipients and the set of people authorized to view the
1790 message may not have a one-to-one correspondance. People may be
1791 authorized to see the content who are not recipients of the message
1792 or visa versa.
1794 The content of the attribute is a space separated list of email
1795 addresses. Each address represents an Email recipient address that
1796 the client will be placing in one or more of the recipient fields in
1797 the message submission.
1799 The following attributes are to be set for the data value:
1801 The Category for the attribute is
1802 "urn:ietf:params:xml:ns:plasma:data".
1804 The AttributeId for the attribute is
1805 "urn:ietf:params:xml:ns:plasma:data:SMTPRecipients".
1807 The Issuer for the attribute is absent.
1809 The DataType for the attribute is
1810 "http://www.w3.org/2001/XMLSchema#string".
1812 10.2. Obligations and Advice
1814 Obligations and advice consist of actions that the Plasma server
1815 either requires or requests that the client PEP perform in order to
1816 gain access or before granting access to the data. These normally
1817 represent actions or restrictions that the PDP itself cannot enforce
1818 and thus are not input attributes to the policy evaluation. The same
1819 set of values can be used either as obligations or advice, the
1820 difference being that if the PEP cannot do an obligation it is
1821 required to change the policy decision.
1823 10.2.1. Signature Required
1825 Many policies require that a message be signed before it is encrypted
1826 and sent. Since the unencrypted version of message is not sent to
1827 the Plasma server, the policy cannot verify that a signature has been
1828 placed onto the signed message. The attribute is not for use as a
1829 returned obligation from an XACML decisions, rather it is for a pre-
1830 request obligations used in role responses (Section 7.2).
1832 When used as an Obligation:
1834 The ObligationId attribute is
1835 "urn:ietf:params:xml:ns:plasma:obligation:signature-required".
1837 A S/MIME Capabilities data value can optionally be included. If
1838 it is included, then it contains the set of S/MIME capabilities
1839 that describes the set of signature algorithms from which the
1840 signature algorithm for the message MUST be selected.
1842 10.2.2. Encryption Required
1844 Occasionally a policy requires a specific set of encryption
1845 algorithms be used for a message, when this is the case then the
1846 encryption required obligation is included in the returned set of
1847 obligations. If the default set of encryption algorithms is
1848 sufficient then the obligation is omitted.
1850 When used as an Obligation:
1852 The ObligationId attribute is
1853 "urn:ietf:params:xml:ns:plasma:obligation:encryption-required".
1855 An S/MIME Capabilities data value MUST be included containing the
1856 set of permitted encryption algorithms. The algorithms included
1857 MUST include a sufficient set of algorithms for the message to be
1858 encrypted. An absolute minimum would be a content encryption
1859 algorithm and key encryption algorithm.
1861 11. Certificate Profiles
1863 We need to put in text to express the following items:
1865 DNS or IPAddr subject alt name to be present
1867 Have one of four EKUs
1869 Plasma Token EKU - Signals that it can sign and/or encrypt a
1870 plasma object
1872 Plasma Secure Session - Use for the TLS session
1874 Plasma CEK Transport - Used for transporting the CEK to the
1875 server in high security situations
1877 MUST NOT have the anyPolicy EKU set
1879 12. Message Transmission
1881 Plasma messages are sent over a TCP connection using port TBD1 on the
1882 server. The client first setups up TLS on the connection, then sends
1883 the UTF8 encoded XML message over the TLS connection as an atomic
1884 message. The XML MUST be encoded as UTF8, however the Byte Order
1885 Mark (BOM) is sent. The response comes back on the same connection.
1886 The client is responsible for closing the TLS session and the TCP
1887 connection when either no more messages are to be sent to the server
1888 or a final indeterminate state has been reached.
1890 If a Plasma server receives an XML request which is not well formed
1891 XML, the server if free to close the connection without first sending
1892 an error reply.
1894 The Plasma server SHOULD support TLS resumption [RFC5077].
1896 Plasma clients and server MUST support TLS 1.1 [RFC4346] and above.
1897 Implementations SHOULD NOT allow for the use of TLS 1.0 or SSL.
1899 13. Plasma URI Scheme
1901 13.1. Plasma URI Schema Syntax
1903 The scheme name for is "plasma".
1905 The syntax for the plasma URI Schema is:
1907 URI = "plasma" ":" "//" authority path-empty
1909 Using the ABNF defined in [RFC3986]. When the port component is
1910 absent, then the value of TBD1 will be used. The userinfo portion of
1911 the authority MUST be absent.
1913 13.2. Definition of Operations
1915 This schema is defined to provide the location of a Plasma server.
1916 The sole operation is to establish a connection to the Plasma server
1917 over which the protocol defined in this document is to run.
1919 14. Security Considerations
1921 To be supplied after we have a better idea of what the document looks
1922 like.
1924 14.1. Plasma URI Schema Considerations
1926 TBD
1928 15. IANA Considerations
1930 We define the following name spaces
1932 New name space for the plasma documents urn:ietf:params:xml:ns:plasma
1934 15.1. Plasma Action Values
1936 A new registry is established for Plasma server action identifiers
1937 using the tag "actions". The full urn for the registry is
1938 "urn:ietf:params:xml:ns:plasma:actions". This registry operates
1939 under a specification required policy. All entries in this registry
1940 require the following elements:
1942 o A string in camel case which identifies the action to be
1943 performed.
1945 o An optional XML data structure used to carry the control data for
1946 the action.
1948 o An optional XML data structure used to return the result of the
1949 action from the server.
1951 o A document reference describing the steps to be taken by the
1952 server.
1954 The registry will be initially populated with the following:
1956 +-----------------+-----------------+------------------+
1957 | Action Id | Input Structure | Output Structure |
1958 +-----------------+-----------------+------------------+
1959 | GetRoleTokens | none | eps:RoleToken |
1960 | | | |
1961 | GetSendCMSToken | eps:GetCMSToken | eps:CMSLockBox |
1962 | | | |
1963 | ParseCMSToken | eps:CMSLockBox | eps:CMSKey |
1964 | | | |
1965 | GetReplyToken | none | eps:RoleToken |
1966 +-----------------+-----------------+------------------+
1968 When these actions are placed in an xacml:Request,
1970 o the Category is
1971 "urn:oasis:names:tc:xacml:3.0:attribute-category:action",
1973 o the AttributeId is "urn:ietf:params:xml:ns:plasma:actions",
1974 o the DataType is "http://www.w3.org/2001/XMLSchema#string"
1976 15.2. non
1978 Define a new data name space urn:ietf:params:xml:ns:plasma:data
1980 CMSToken
1982 ChannelBinding
1984 SMIME-Capabilities
1986 Define a new name space for status codes at
1987 urn:ietf:params:xml:ns:plasma:status. The initial set of values is
1989 authentication-error This identifier indicates that the
1990 authentication methods failed to successfully complete.
1992 Define a new name space for obligations. The same namespace will be
1993 used both for obligations and for advice and the values may appear in
1994 either section.
1996 signature-required This identifier indicates that that the encrypted
1997 body must contain a signature element. The data value of this
1998 type shall be "http://www.w3.org/2001/XMLSchema#hexBinary" and the
1999 data structure shall consist of a DER encoded CMSCapabilities
2000 structure [SMIME-MSG] with the list of permitted signature
2001 algorithms. If there are no restrictions on the algorithms or the
2002 restriction is implicit, then the data value MAY be omitted.
2004 encryption-algorithms see above
2006 ambigous-identity The identity of the client is either not stated in
2007 a form the Plasma server understands, or there are multiple
2008 identities in the authentication data. To remedy this situation,
2009 the client includes an explicit identity in the xacml:Reqeust
2010 element.
2012 We define a schema in appendix A at &PlasmaScheme;:RFCTBD
2014 Define a new Status Code for use in the Status URI field.
2016 urn:ietf:params:xml:ns:plasma:status:gss-api-response - This
2017 status is returned only with Indefinite responses. Indicates a
2018 GSS-API response object was returned in the GSSAPIResponse token
2019 type. Will return until authentication has been completed.
2021 15.3. Port Assignment
2023 We request that IANA assign a new port for the use of this protocol.
2025 Service name: plasma
2027 Port Number: TBD1
2029 Transport Protocol: TCP
2031 Description: Plasma Service Protocol
2033 Reference: This document
2035 Assignee: iesg@ietf.org
2037 Contact: chair@ietf.org
2039 Notes: The protocol requires that TLS be used to communicate over
2040 this port. There is no provision for unsecure messages to be sent to
2041 this protocol.
2043 16. Open Issues
2045 List of Open Issues:
2047 o JLS: Should we require that any SignatureProperty be present for
2048 XML Signature elements?
2050 o JLS: Need to figure out an appropriate way to reference the
2051 assertion from a dig sig element. Could use a special version of
2052 RetrievalMethod with a transform, but that does not seem correct.
2053 May need to define a new KeyInfo structure to do it.
2055 o JLS: Should X.509 certificates and attribute certificates be fully
2056 specified as an authentication method?
2058 o JLS: Should a SignerInfo attribute be placed under the access-
2059 subject Category for a senders version and under Environment for a
2060 machine version? Currently both are under Data
2062 o JLS: Need an obligation to say that CEK must be encrypted. Do we
2063 also need to have recipient info structures encrypted?
2065 17. References
2067 17.1. Normative References
2069 [ABFAB] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
2070 Extensible Authentication Protocol", Work In
2071 Progress draft-ietf-abfab-gss-eap-04, Oct 2011.
2073 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2074 Requirement Levels", BCP 14, RFC 2119, March 1997.
2076 [EPS-CMS] Schaad, J., "Email Policy Service ASN.1 Processing", Work
2077 In Progress draft-schaad-plamsa-cms, Jan 2011.
2079 [XML-Signature]
2080 Roessler, T., Reagle, J., Hirsch, F., Eastlake, D., and D.
2081 Solo, "XML Signature Syntax and Processing (Second
2082 Edition)", World Wide Web Consortium Recommendation REC-
2083 xmldsig-core-20080610, June 2008,
2084 .
2086 [XML-C14N11]
2087 Boyer, J. and G. Marcy, "Canonical XML Version 1.1", World
2088 Wide Web Consortium Recommendation REC-xml-c14n11-
2089 20080502, May 2008,
2090 .
2092 [WS-TRUST]
2093 Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin,
2094 M., Barbir, A., and H. Granqvist, "WS-Trust 1.4", OASIS
2095 Standard ws-trust-200902, March 2007, .
2098 [XACML] Rissanen, E., "eXtensible Access Control Markup Language
2099 (XACML) Version 3.0", OASIS Standard xacml-201008,
2100 August 2010, .
2103 [Plasma] Freeman, T., Schaad, J., and P. Patterson, "Requirements
2104 for Message Access Control", Work in
2105 progress draft-freeman-message-access-control,
2106 October 2011.
2108 [OASIS-CORE]
2109 Cantor, S., Kemp, J., Philpott, R., and E. Maler,
2110 "Assertions and Protocols for the OASIS Security Assertion
2111 Markup Language (SAML) V2.0", OASIS Standard saml-core-
2112 2.0-os, March 2005.
2114 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
2115 Layer Security (TLS)", RFC 5705, March 2010.
2117 [SMIME-MSG]
2118 Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
2119 Mail Extensions (S/MIME) Version 3.2 Message
2120 Specification", RFC 5751, January 2010.
2122 17.2. Informative References
2124 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
2125 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
2127 [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
2128 Record Syntax (ERS)", RFC 4998, August 2007.
2130 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
2131 "Transport Layer Security (TLS) Session Resumption without
2132 Server-Side State", RFC 5077, January 2008.
2134 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2135 Resource Identifier (URI): Generic Syntax", STD 66,
2136 RFC 3986, January 2005.
2138 [SAML-XACML]
2139 Anderson, A. and H. Lockhart, "SAML 2.0 profile of XACML
2140 v2.0", OASIS Standard access_control-xacml-2.0-saml-
2141 profile-spec-os.pdf, February 2005.
2143 [PlasmaBasicPolicy]
2144 Anon, A., "IETF Defined Plasma Policies", February 2005.
2146 [SOAP11] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
2147 Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer,
2148 "Simple Object Access Protocol (SOAP) 1.1", W3C NOTE NOTE-
2149 SOAP-20000508, May 2000.
2151 [SOAP12] Lafon, Y., Gudgin, M., Hadley, M., Moreau, J., Mendelsohn,
2152 N., Karmarkar, A., and H. Nielsen, "SOAP Version 1.2 Part
2153 1: Messaging Framework (Second Edition)", World Wide Web
2154 Consortium Recommendation REC-soap12-part1-20070427,
2155 April 2007,
2156 .
2158 Editorial Comments
2160 [anchor7] Trevor: I don't see Plasma using this type
2162 [anchor8] Trevor: What about attribute match?
2164 [anchor9] Trevor: This sounds like we ignore the mapping on the
2165 wire. There is no reason to mandate the mapping occurs
2166 inside the PDP.
2168 [anchor11] Brian: Should one be able to create a policy on the fly
2169 for specific item where a set of attributes can be
2170 defined by the sender of the message.
2172 [anchor14] jimsch: Remove this?
2174 [anchor16] Trevor: What is the difference between WS-trust SAML
2175 assertions and the SAML assertions above?
2177 [anchor18] Trevor: Would we use bearer tokens to reintroduce the
2178 client? The main protection of bearer tokens is if they
2179 are fresh so you have had little time to stream one
2181 [anchor19] trevor: Is this totally true? Don't we need some kind of
2182 identifier so the server can indicate when the token can
2183 be replayed in a subsequence request? E.g. give me these
2184 attributes or a foo token.
2186 [anchor20] JLS: I don't know of any way to say use the asymmetric
2187 key that you authenticated with originally - can this be
2188 done?
2190 [anchor23] Trevor: What about audit obligatiouns
2192 [anchor24] Trevor: Should we ignore it if present?
2194 [anchor25] JLS: I don't think we need to say anything about looking
2195 at it or ignoring it. While it would be something for
2196 debugging, as a general rule the client does not care
2197 which policies where evaluated and passed to grant
2198 access.
2200 [anchor27] Ed: Change from Name to FriendlyName to match SAML usage.
2201 JLS: I don't really care, although I think that
2202 DisplayName might be a better substitute.
2204 [anchor28] JLS: Should perhaps rename to be more understandable -
2205 perhaps Server
2207 [anchor29] JLS: Do we define this obligation or remove the previous
2208 sentence?
2210 [anchor30] JLS: Call for other mandatory to implement name types
2212 [anchor31] jls: We may want to require that a reply token always be
2213 returned instead of just returning it on demand.
2215 Appendix A. XML Schema
2217 This appendix represents the entirety of the XML Schema for Plasma
2218 documents.
2220 Appendix B. Example: Get Roles Request
2222 This section provides an example of a request message to obtain the
2223 set of roles for an individual named 'bart@simpsons.com'. The
2224 authentication provided in this is a SAML statement included in the
2225 SAML_Collection element.
2227
2228
2233
2234 123456
2235
2236
2237
2238
2239
2240 GetRoleTokens
2241
2242
2243
2244
2245 ABCDEFGH
2246
2247
2248
2249
2250 Appendix C. Example: Get Roles Response
2252 This section provides an example response to a successful request for
2253 a role sets.
2255
2256
2257
2258
2259 Permit
2260
2261
2262
2263
2264 Role #1
2265 plasma://localhost:8080
2266
2267
2268 Schaad Policy 1
2269
2270
2271
2272
2273 MCgMCzxDb250ZXh0IC8+AgEBMBYYFDEvMTAvMjAxMyA0OjIyOjAwIEFN
2274
2275
2276 2013-01-10T04:22:00
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286 Plasma Basic Policy
2287 plasma://localhost:8080
2288
2289
2290 Plasma Basic Policy
2291
2292
2293 Schaad Policy 1
2294
2295
2296
2297
2298 MCgMCzxDb250ZXh0IC8+AgEBMBYYFDEvMTAvMjAxMyA0OjIyOjAwIEFN
2299
2300
2301 2013-01-10T04:22:00
2302
2303
2304
2305
2306
2308 In this example a role is returned that has two different policies
2309 that can be used by that role. Along with the role token, a binary
2310 secret is returned that is to be used in proving that the same entity
2311 is returning to use the roles.
2313 Appendix D. Example: Get CMS Token Request
2315 This section contains an example of a request from a client to a
2316 server for a CMS message token to be issued. The authentication for
2317 the request is provided by using a WS-Trust token previously issued
2318 as part of a role request/response dialog. The request contains the
2319 following elements:
2321 o A complex rule set is requested where permission to is to be
2322 granted to anyone who meets either of the two policies given.
2324 o A specific recipient info structure is provided for a subject
2325 who's name is 'lisa@simpsons.com'. The details of the recipient
2326 info structure are skipped but it would be any encoding of a
2327 RecipientInfo structure from CMS.
2329 o A generic key encryption key is provided for any other subject who
2330 meets the policies specified.
2332
2333
2334
2335
2336 MCgMCzxDb250ZXh0IC8+AgEBMBYYFDEvMTAvMjAxMyAxOjI3OjEyIEFN
2337
2338
2339
2340
2341
2342 GetCMSToken
2343
2344
2345
2346
2347 tls-unique
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359 AQIDBAUGBwgJCg==
2360
2361 0102030405060708090A
2362
2363
2364
2365
2366
2367
2368 Appendix E. Example: Get CMS Token Response
2370 This section contains an example of a response from a server to a
2371 client for a CMS message token to be issued. The token is returned
2372 in the CMSToken element. This element would then be placed into the
2373 CMS message being created by the client.
2375
2376
2377
2378
2379 Permit
2380
2381
2382
2383 MIIQJAYJKoZIhvcNAQcCoIIQFTCCEBECAQExCzAJBgUrDgMCGgUAMIIDOQYJKoZIhvcNAQcDoIIDKjCCAyYGCSqGSIb3DQEHA6CCAxcwggMTAgEAMYIB4TCCAd0CAQAwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDVeeyr0T13xrMgLQj+cJ0iMA0GCSqGSIb3DQEBAQUABIIBAEB7LT/qFbvzz7xxan6Q01By/J8X12Mpq00jLVst0+mGl7cmsBknS6TXC13638r8ow904GMB/1YzmWVYs4Pc+p9l7UJ0MFjhVULuahMbwrpEEFg90GBvZzZXKy8syxTcyh3TwCMTpYHOJxz9DfowvSJi2TPUiXG0mXzzMkbS3yiyJasacbgmG2d9G/cYJpVDlQqMCOVui7UMlQAz3LQLa9GINTzs1I5j8uqPDwPKxKmWNJ5AYj3jb6uLsf0tD1h+mCKotjdVsC0Jx05xZ53UCYPg3K5IoK8v/hu8psH7Njq3aZ6McxgeBFKxswSD3ffipEWkwLyN0heyhvIn3/prEsAwggEnBgsqhkiG9w0BB4aNFzAUBggqhkiG9w0DBwQIirvrkunYtn+AggEAlPZGLqxBvE2sdmmzUfAljJpKredC3fUxXgvPcpf07hcDz+NRf/miOwNTCUNrXg82s1NYfhWAQEuTxDtuGq7Lwd70fohcX0mXgxGbqlaPjEVzhUQwZvJfn1r7oosJ5qzO59sKStEntQdYR5cyYXnHDO2xGE1TdB7X6ibfTubPq52UC/Lt7xRyB1HMz+eeLTl6amF1lO8VOITkAEOeI9noaePDheHMS7k0xMQMEMHYU1TN/09/2RSbMY740MEDNpidtomFv4gvhWWzGrzYNPFNtHQh/4UDhqXl9eJ+MOXRdGupV9vdt6RhGKC6krszfMV9O0vHzh750XwqxtQ38FolZ6CCChEwggSKMIIDcqADAgECAhAn9OoR9HqGxG6du26pFwcHMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOB4TCB3jAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9jYS5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDANBgkqhkiG9w0BAQUFAAOCAQEAGdiJEW8orKYAoueHwZuQA9t+oRL9HvPi8AGplFRCa5oJxKBt15CSBANmeUNx/Phvr9t2ReI3Gj3d5FkEeKwc9ING83rPW4RyLeVGwboYESnzy0l5hzy6bQWdpG1oT61yFDaoubH9v89/8KRqlDVQj8+BbVWx3VkwSt9toJxkH0l87za79ONp9Pg5j1qtS4U6tw7t088NRKL7BL/kL3COJftaVAaz0MS8bY37czIs6ZuEJC3Wf5F6aAJQHw4/TenM9btn6NwcLjv8Ts3+Ao7jqBMKpSZEZekQ8k1Sp67cPsprMlxBbP71XaDq/9H6m4ZYbT2WR+X+LpUEwgDMjqHyuzCCBX8wggRnoAMCAQICEQDVeeyr0T13xrMgLQj+cJ0iMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDUyNzAwMDAwMFoXDTEyMDUyNjIzNTk1OVowKTEnMCUGCSqGSIb3DQEJARYYamltc2NoYWFkQHpzLnBlbmFuZ28ubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBLgJtGWe6ib5nTzwL2QAVPwQCUeTl0ItoLig2/WhKcrZJIcM9c/opX6Mi7V44v38hFxwurjJplF74xLp5IqhaPGXHf0t8Yas/F06UnZyMlXQ197jCIkqChfqnOxDJ+7zASoveRt6aNyFJRy3eJyYasqbURvmdBYom1UOYxfWrIM9VaulvW5TCiJIpbKiEwdIcs+JCLuNs/OgtFXB7C+IjIw1C7ZTxBD9Q8g9RRr/TvmhGQ1Ru1BL7g52+Hs1vrAtjENxwmJwrZSsJHgMw5FfDbVLrwOI97iCWnrQ8acFiS5iRFGqWzQCJyWhJFHYvuw7RzQg761+tin8hpue2OsEwIDAQABo4ICGjCCAhYwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFNltOqTDux3i8fOkK7gnr5Zo/FEfMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAjBgNVHREEHDAagRhqaW1zY2hhYWRAenMucGVuYW5nby5uZXQwDQYJKoZIhvcNAQEFBQADggEBAK9Ndz6RqjMdXDXZ5xrkc1FYcq69Gm/yacR4Lkj35uHZ6kzndhsdcsug06879gOsW1OTFMSRYvHhYkwknLL4PKISxozVmiDvVYzYXqE+Gj4jZaNzbF8suowQCq7dS82Ggoj68C4Hh5+PyUlySmQZKnsyDuE6PxIlFlhLCmFYl9hsgRmgqe4sbB2cxZu03SYWvWI92IwwrouOtrI3JbFXJnn9obKLYj3LMRr9VrAHBd3A99VW6OMNT75b0ScuwcoS96YZutVC/y1Y65mMlGQW+FOr8sIxxFz6lsvTxEul0VXUxbfAZ0MkrRxJH0Mw3W2QUAQ3dRR81Ba/g8GNhawC+jUxggKrMIICpwIBATCBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRANV57KvRPXfGsyAtCP5wnSIwCQYFKw4DAhoFAKCBvDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcDMBwGCSqGSIb3DQEJBTEPFw0xMzAxMDgwNjQ1MTBaMCMGCSqGSIb3DQEJBDEWBBSHHd6eVaOraNTvfMOaBDOIsfS5eDArBgsqhkiG9w0BCYaNGjEcMBowDAYKKhCGSAFlAwQCAQQKAQIDBAUGBwgJCjAwBgsqhkiG9w0BCYaNGTEhDB9wbGFzbWE6cGxhc21hLmF1Z3VzdGNlbGxhcnMuY29tMA0GCSqGSIb3DQEBAQUABIIBAKUc/zlevtNMuRrfnRJA30ecoXgXr33rEsbj9xEgH+xaJwBotwLC/i7wKutjc+Z8sfUt9X+H/jNFyMFZwXYF2fgw6xKtSlkYXgTu9GioK6rpftHSifOd+aRJHMKJTeWAkwamF9XBmaWhQusDVHZmmd9uUEPNkUSo4T6r2atZ8avgMc8DhwKLw8NGf9ZhkNtJciIW76X3AO+XbUr4vIsLT1mTFr4wJ7Tk9rOnk6oyGS/q1jvgVl53xKCTP+xa1usZarYUo2u974JjADN8uGlI4gv1wH1scojgXVYp8HWe6Uh0fYFdFRmefHj5rEkiB4POVVQoq8Bsk4sJUR3+rfaM3QI=
2384
2385
2386 Appendix F. Example: Get CMS Key Request
2388
2389
2390
2391
2392 MCgMCzxDb250ZXh0IC8+AgEBMBYYFDEvMTAvMjAxMyAxOjI3OjEyIEFN
2393
2394
2395
2396
2397
2398 GetCMSKey
2399
2400
2401
2402
2403 tls-unique
2404
2405
2406
2407
2408
2409 MIIQJAYJKoZIhvcNAQcCoIIQFTCCEBECAQExCzAJBgUrDgMCGgUAMIIDOQYJKoZIhvcNAQcDoIIDKjCCAyYGCSqGSIb3DQEHA6CCAxcwggMTAgEAMYIB4TCCAd0CAQAwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDVeeyr0T13xrMgLQj+cJ0iMA0GCSqGSIb3DQEBAQUABIIBAEB7LT/qFbvzz7xxan6Q01By/J8X12Mpq00jLVst0+mGl7cmsBknS6TXC13638r8ow904GMB/1YzmWVYs4Pc+p9l7UJ0MFjhVULuahMbwrpEEFg90GBvZzZXKy8syxTcyh3TwCMTpYHOJxz9DfowvSJi2TPUiXG0mXzzMkbS3yiyJasacbgmG2d9G/cYJpVDlQqMCOVui7UMlQAz3LQLa9GINTzs1I5j8uqPDwPKxKmWNJ5AYj3jb6uLsf0tD1h+mCKotjdVsC0Jx05xZ53UCYPg3K5IoK8v/hu8psH7Njq3aZ6McxgeBFKxswSD3ffipEWkwLyN0heyhvIn3/prEsAwggEnBgsqhkiG9w0BB4aNFzAUBggqhkiG9w0DBwQIirvrkunYtn+AggEAlPZGLqxBvE2sdmmzUfAljJpKredC3fUxXgvPcpf07hcDz+NRf/miOwNTCUNrXg82s1NYfhWAQEuTxDtuGq7Lwd70fohcX0mXgxGbqlaPjEVzhUQwZvJfn1r7oosJ5qzO59sKStEntQdYR5cyYXnHDO2xGE1TdB7X6ibfTubPq52UC/Lt7xRyB1HMz+eeLTl6amF1lO8VOITkAEOeI9noaePDheHMS7k0xMQMEMHYU1TN/09/2RSbMY740MEDNpidtomFv4gvhWWzGrzYNPFNtHQh/4UDhqXl9eJ+MOXRdGupV9vdt6RhGKC6krszfMV9O0vHzh750XwqxtQ38FolZ6CCChEwggSKMIIDcqADAgECAhAn9OoR9HqGxG6du26pFwcHMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDUwNjA3MDgwOTEwWhcNMjAwNTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOB4TCB3jAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUiYJnfcSdJnAAS7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9jYS5jb20vQWRkVHJ1c3RFeHRlcm5hbENBUm9vdC5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9BZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDANBgkqhkiG9w0BAQUFAAOCAQEAGdiJEW8orKYAoueHwZuQA9t+oRL9HvPi8AGplFRCa5oJxKBt15CSBANmeUNx/Phvr9t2ReI3Gj3d5FkEeKwc9ING83rPW4RyLeVGwboYESnzy0l5hzy6bQWdpG1oT61yFDaoubH9v89/8KRqlDVQj8+BbVWx3VkwSt9toJxkH0l87za79ONp9Pg5j1qtS4U6tw7t088NRKL7BL/kL3COJftaVAaz0MS8bY37czIs6ZuEJC3Wf5F6aAJQHw4/TenM9btn6NwcLjv8Ts3+Ao7jqBMKpSZEZekQ8k1Sp67cPsprMlxBbP71XaDq/9H6m4ZYbT2WR+X+LpUEwgDMjqHyuzCCBX8wggRnoAMCAQICEQDVeeyr0T13xrMgLQj+cJ0iMA0GCSqGSIb3DQEBBQUAMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMB4XDTExMDUyNzAwMDAwMFoXDTEyMDUyNjIzNTk1OVowKTEnMCUGCSqGSIb3DQEJARYYamltc2NoYWFkQHpzLnBlbmFuZ28ubmV0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwBLgJtGWe6ib5nTzwL2QAVPwQCUeTl0ItoLig2/WhKcrZJIcM9c/opX6Mi7V44v38hFxwurjJplF74xLp5IqhaPGXHf0t8Yas/F06UnZyMlXQ197jCIkqChfqnOxDJ+7zASoveRt6aNyFJRy3eJyYasqbURvmdBYom1UOYxfWrIM9VaulvW5TCiJIpbKiEwdIcs+JCLuNs/OgtFXB7C+IjIw1C7ZTxBD9Q8g9RRr/TvmhGQ1Ru1BL7g52+Hs1vrAtjENxwmJwrZSsJHgMw5FfDbVLrwOI97iCWnrQ8acFiS5iRFGqWzQCJyWhJFHYvuw7RzQg761+tin8hpue2OsEwIDAQABo4ICGjCCAhYwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFNltOqTDux3i8fOkK7gnr5Zo/FEfMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAjBgNVHREEHDAagRhqaW1zY2hhYWRAenMucGVuYW5nby5uZXQwDQYJKoZIhvcNAQEFBQADggEBAK9Ndz6RqjMdXDXZ5xrkc1FYcq69Gm/yacR4Lkj35uHZ6kzndhsdcsug06879gOsW1OTFMSRYvHhYkwknLL4PKISxozVmiDvVYzYXqE+Gj4jZaNzbF8suowQCq7dS82Ggoj68C4Hh5+PyUlySmQZKnsyDuE6PxIlFlhLCmFYl9hsgRmgqe4sbB2cxZu03SYWvWI92IwwrouOtrI3JbFXJnn9obKLYj3LMRr9VrAHBd3A99VW6OMNT75b0ScuwcoS96YZutVC/y1Y65mMlGQW+FOr8sIxxFz6lsvTxEul0VXUxbfAZ0MkrRxJH0Mw3W2QUAQ3dRR81Ba/g8GNhawC+jUxggKrMIICpwIBATCBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRANV57KvRPXfGsyAtCP5wnSIwCQYFKw4DAhoFAKCBvDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcDMBwGCSqGSIb3DQEJBTEPFw0xMzAxMDgwNjQ1MTBaMCMGCSqGSIb3DQEJBDEWBBSHHd6eVaOraNTvfMOaBDOIsfS5eDArBgsqhkiG9w0BCYaNGjEcMBowDAYKKhCGSAFlAwQCAQQKAQIDBAUGBwgJCjAwBgsqhkiG9w0BCYaNGTEhDB9wbGFzbWE6cGxhc21hLmF1Z3VzdGNlbGxhcnMuY29tMA0GCSqGSIb3DQEBAQUABIIBAKUc/zlevtNMuRrfnRJA30ecoXgXr33rEsbj9xEgH+xaJwBotwLC/i7wKutjc+Z8sfUt9X+H/jNFyMFZwXYF2fgw6xKtSlkYXgTu9GioK6rpftHSifOd+aRJHMKJTeWAkwamF9XBmaWhQusDVHZmmd9uUEPNkUSo4T6r2atZ8avgMc8DhwKLw8NGf9ZhkNtJciIW76X3AO+XbUr4vIsLT1mTFr4wJ7Tk9rOnk6oyGS/q1jvgVl53xKCTP+xa1usZarYUo2u974JjADN8uGlI4gv1wH1scojgXVYp8HWe6Uh0fYFdFRmefHj5rEkiB4POVVQoq8Bsk4sJUR3+rfaM3QI=
2410
2411
2412
2413
2414
2415 Appendix G. Example: Get CMS KeyResponse
2417
2418
2419
2420
2421 Permit
2422
2423
2424
2425
2426 Schaad Policy 1
2427 AQIDBAUGBwgJCg==
2428
2429
2430
2431 Appendix H. Enabling the MultiRequests option
2433 NOTE: RFC Editor please remove this section prior to publication.
2434 This section exists as a note to the author to make sure that it can
2435 be done. It will be published as a separate document if desired.
2437 One of the issues in doing multiple requests in a single message is
2438 the issue of correlation between the request and the results. We
2439 have make this issue even worse by the fact that we are return
2440 results that are not input attributes for the decision and that we
2441 are not returning as attributes of the decision.
2443 The best way to deal with this is by putting tags into the request
2444 and reflect them in the return values for the response. The only
2445 place that this does not work is for the GSS-API response token as
2446 this element would normally be part of the response of multiple
2447 requests. You want to finish that authentication step before issuing
2448 final decisions if the input is needed as part of that decision.
2450 With this in mind what we do is the following:
2452 o Define a new data attribute for plasma as plasma-request-id. The
2453 category for it is urn:ietf:params:xml:ns:plasma:data. The type
2454 will be a string.
2456 o When the new attribute is used, then the return attribute flag
2457 MUST be set on the attribute.
2459 o There MUST be one entity of the new attribute, with a unique
2460 value, for each of the requests in the MultiRequest element.
2462 o Exactly one of the new attributes MUST be referenced in each
2463 request in the MultiRequest element.
2465 o The server copies the value of the attribute into the ***
2466 attribute of the returned token.
2468 We could probably relax the restrictions if we know that the token
2469 can only be returned by one request, however using the token to
2470 correlate the request and the decision is still probably desired so
2471 that those values can be correlated.
2473 Author's Address
2475 Jim Schaad
2476 Soaring Hawk Consulting
2478 Email: ietf@augustcellars.com