idnits 2.17.1
draft-schaad-plasma-service-05.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 74 instances of too long lines in the document, the longest
one being 5487 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 302 has weird spacing: '...Service is th...'
== Line 310 has weird spacing: '...r Agent is th...'
== Line 315 has weird spacing: '...g Agent is th...'
== Line 317 has weird spacing: '...g Agent is th...'
== Line 462 has weird spacing: '...ication is an...'
== (29 more instances...)
-- The document date (February 14, 2014) is 3724 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: 'XML-Schema2' is mentioned on line 171, but not
defined
== Unused Reference: 'ABFAB' is defined on line 2333, but no explicit
reference was found in the text
== Unused Reference: 'SOAP11' is defined on line 2423, but no explicit
reference was found in the text
== Unused Reference: 'SOAP12' is defined on line 2428, 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.
'I-D.schaad-plasma-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.
'I-D.freeman-plasma-requirements'
-- Possible downref: Non-RFC (?) normative reference: ref. 'OASIS-CORE'
** Obsolete normative reference: RFC 5751 (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)
== Outdated reference: A later version (-10) exists of
draft-ietf-emu-eap-tunnel-method-09
Summary: 2 errors (**), 0 flaws (~~), 13 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 February 14, 2014
5 Expires: August 18, 2014
7 Plasma Service Trust Processing
8 draft-schaad-plasma-service-05
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 August 18, 2014.
44 Copyright Notice
46 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
62 1.1. XML Nomenclature and Name Spaces . . . . . . . . . . . . 4
63 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 4
64 2. Components . . . . . . . . . . . . . . . . . . . . . . . . . 4
65 2.1. XACML 3.0 . . . . . . . . . . . . . . . . . . . . . . . . 5
66 2.2. SAML . . . . . . . . . . . . . . . . . . . . . . . . . . 5
67 2.3. WS-Trust 1.4 . . . . . . . . . . . . . . . . . . . . . . 6
68 3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
69 3.1. Sender Processing . . . . . . . . . . . . . . . . . . . . 7
70 3.2. Recieving Agent Processing . . . . . . . . . . . . . . . 8
71 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
72 5. Plasma Request . . . . . . . . . . . . . . . . . . . . . . . 10
73 5.1. Authentication Element . . . . . . . . . . . . . . . . . 11
74 5.1.1. SAML Assertion . . . . . . . . . . . . . . . . . . . 13
75 5.1.2. WS Trust Tokens . . . . . . . . . . . . . . . . . . . 14
76 5.1.3. XML Signature Element . . . . . . . . . . . . . . . . 15
77 5.1.4. GSS-API Element . . . . . . . . . . . . . . . . . . . 16
78 5.2. xacml:Request Element . . . . . . . . . . . . . . . . . . 18
79 6. Plasma Response Element . . . . . . . . . . . . . . . . . . . 19
80 6.1. xacml:Response Element . . . . . . . . . . . . . . . . . 20
81 7. Role Token and Policy Acquisition . . . . . . . . . . . . . . 22
82 7.1. Role Token Request . . . . . . . . . . . . . . . . . . . 22
83 7.2. Request Role Token Response . . . . . . . . . . . . . . . 23
84 7.2.1. RoleToken XML element . . . . . . . . . . . . . . . . 25
85 7.2.2. Email Address List Options . . . . . . . . . . . . . 29
86 8. Sending An Email . . . . . . . . . . . . . . . . . . . . . . 29
87 8.1. Send Message Request . . . . . . . . . . . . . . . . . . 29
88 8.1.1. CMS Message Token Data Structure . . . . . . . . . . 30
89 8.1.2. XML Label Structure . . . . . . . . . . . . . . . . . 33
90 8.2. Send Message Response . . . . . . . . . . . . . . . . . . 35
91 8.3. XML Message Send Request . . . . . . . . . . . . . . . . 36
92 8.4. XML Message Send Response . . . . . . . . . . . . . . . . 37
93 9. Decoding A Message . . . . . . . . . . . . . . . . . . . . . 37
94 9.1. Requesting Message Key . . . . . . . . . . . . . . . . . 37
95 9.2. Requesting Message Key Response . . . . . . . . . . . . . 39
96 10. Plasma Attributes . . . . . . . . . . . . . . . . . . . . . . 40
97 10.1. Data Attributes . . . . . . . . . . . . . . . . . . . . 41
98 10.1.1. Channel Binding Data Attribute . . . . . . . . . . . 41
99 10.1.2. CMS Signer Info Data Attribute . . . . . . . . . . . 41
100 10.1.3. S/MIME Capabilities Data Attribute . . . . . . . . . 42
101 10.1.4. EMAIL Recipient Addreses . . . . . . . . . . . . . . 42
102 10.1.5. Return Lockbox Key Information . . . . . . . . . . . 43
103 10.2. Obligations and Advice . . . . . . . . . . . . . . . . . 44
104 10.2.1. Signature Required . . . . . . . . . . . . . . . . . 45
105 10.2.2. Content Encryption Algorithm Required . . . . . . . 45
106 10.2.3. Lock Box Required . . . . . . . . . . . . . . . . . 45
107 11. Certificate Profiles . . . . . . . . . . . . . . . . . . . . 46
108 12. Message Transmission . . . . . . . . . . . . . . . . . . . . 47
109 13. Plasma URI Scheme . . . . . . . . . . . . . . . . . . . . . . 47
110 13.1. Plasma URI Schema Syntax . . . . . . . . . . . . . . . . 47
111 13.2. Definition of Operations . . . . . . . . . . . . . . . . 47
112 14. Security Considerations . . . . . . . . . . . . . . . . . . . 47
113 14.1. Plasma URI Schema Considerations . . . . . . . . . . . . 48
114 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
115 15.1. Plasma Action Values . . . . . . . . . . . . . . . . . . 48
116 15.2. non . . . . . . . . . . . . . . . . . . . . . . . . . . 49
117 15.3. Port Assignment . . . . . . . . . . . . . . . . . . . . 50
118 16. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 50
119 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
120 17.1. Normative References . . . . . . . . . . . . . . . . . . 51
121 17.2. Informative References . . . . . . . . . . . . . . . . . 52
122 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 53
123 Appendix B. Example: Get Roles Request . . . . . . . . . . . . . 57
124 Appendix C. Example: Get Roles Response . . . . . . . . . . . . 58
125 Appendix D. Example: Get CMS Token Request . . . . . . . . . . . 59
126 Appendix E. Example: Get CMS Token Response . . . . . . . . . . 61
127 Appendix F. Example: Get CMS Key Request . . . . . . . . . . . . 61
128 Appendix G. Example: Get CMS KeyResponse . . . . . . . . . . . . 62
129 Appendix H. Enabling the MultiRequests option . . . . . . . . . 62
130 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 63
132 1. Introduction
134 RFC TBD [I-D.freeman-plasma-requirements] describes a new model and
135 set of requirements to implement a labeling system on Cryptographic
136 Message Syntax (CMS) objects where the entity in charge of doing the
137 label enforcement is under the control of a central authority rather
138 than the recipient of the object.
140 This document describes a protocol to be used by senders and
141 recipients of CMS objects to communicate with a centralized label
142 enforcement server. The document outlines how a client will get the
143 set of labels or policies that it can use for sending messages,
144 composes a secure CMS object with a label on it and gets the
145 necessary keys to decrypt a CMS object from the server. This
146 document is designed to be used with RFC TBD [I-D.schaad-plasma-cms]
147 which describes the extensions used in CMS objects to hold the label
148 information.
150 1.1. XML Nomenclature and Name Spaces
152 The following name spaces are used in this document:
154 +-----+------------------------------------------+------------------+
155 | Pre | Namespace | Specification(s) |
156 | fix | | |
157 +-----+------------------------------------------+------------------+
158 | eps | http://ietf.org/2011/plasma/ | This |
159 | | | Specification |
160 | | | |
161 | wst | http://docs.oasis-open.org/ws-sx/ws- | [WS-TRUST] |
162 | | trust/200512 | |
163 | | | |
164 | xac | http://docs.oasis- | [XACML] |
165 | ml | open.org/xacml/3.0/xacml-3.0-core-spec- | |
166 | | cs-01-en.html | |
167 | | | |
168 | ds2 | http://www.w3.org/2000/09/xmldsig# | [XML-Signature] |
169 | | | |
170 | xs | http://www.w3.org/2001/XMLSchema | [XML-Schema1 |
171 | | | ][XML-Schema2] |
172 +-----+------------------------------------------+------------------+
174 1.2. Requirements Terminology
176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
178 document are to be interpreted as described in [RFC2119].
180 When the words appear in lower case, their natural language meaning
181 is used.
183 2. Components
185 In designing this specification we used a number of pre-existing
186 specifications as building blocks. In some cases we use the entirety
187 of the specification and in other case we use only select pieces.
189 2.1. XACML 3.0
191 The XACML specification (eXtensible Access Control Markup Language)
192 [XACML] provides a framework for writing access control policies and
193 for creating standardized access control queries and responses. The
194 request and response portion of the specification is used to build
195 the request (Section 5.2) and response (Section 6.1) messages in this
196 specification. The structure for writing the access control policies
197 is out of scope for this document, but XACML is one of the
198 possibilities that can be used for that purpose.
200 2.2. SAML
202 A number of different methods for carrying both identification and
203 attributes of the party requesting access is permitted in this
204 specification. SAML is one of the methods that is permitted for that
205 purpose.
207 SAML has defined three different types of assertions in it's core
208 specification [OASIS-CORE]:
210 o Authentication: The assertion subject was authenticated by a
211 particular means at a particular time.
213 o Attribute: The assertion subject is associated with the supplied
214 attributes.
216 o Authorization Decision:[[CREF1: I don't see Plasma using this type
217 --Trevor]] A request to allow the assertion subject to access the
218 specified resource has been granted or denied.
220 While a PDP can use an Authorization Decision as input, this is
221 unexpected and MAY be supported. In addition there are three
222 different ways that the subject of a SAML statement can be
223 identified:
225 o A bearer statement: These statements are belong to anybody who
226 presents them. The owner is required to take the necessary
227 precautions to protect them.
229 o A holder of key statement: These statements belong to anybody who
230 can use the key associated with the statement.
232 o Subject match:[[CREF2: What about attribute match? --Trevor]]
233 These statements can be associated to an identity by matching the
234 name of the entity.
236 We cannot pass a SAML assertion with attributes as a single attribute
237 in the XACML request as XACML wants each of the different attributes
238 to be individually listed in the request. This greatly simplifies
239 the XACML code, but means that one needs to do a mapping process from
240 the SAML attributes to the XACML attributes. This process has been
241 discussed in Section 2 of [SAML-XACML]. This mapping process MUST be
242 done by a trusted agent, as there are a number of steps that need to
243 be done including the validation of the signature on the SAML
244 assertion. This process cannot be done by the PEP that is residing
245 on the Plasma client's system as this is considered to be an
246 untrusted entity by the Plasma system as a whole. One method for
247 this to be addressed is to treat the Plasma server as both a PDP (for
248 the Plasma client) and a PDP for the true XACML policy evaluator. In
249 this model, the Plasma server becomes the trusted PEP party and has
250 the ability to do the necessary signature validation and mapping
251 processes. A new XACML request is then created and either re-
252 submitted to itself for complete evaluation or to a third party which
253 does the actual XACML processing.[[CREF3: This sounds like we ignore
254 the mapping on the wire. There is no reason to mandate the mapping
255 occurs inside the PDP. --Trevor]]
257 2.3. WS-Trust 1.4
259 The WS-Trust 1.4 [WS-TRUST] standard provides for methods for
260 issuing, renewing, and validating security tokens. This
261 specification uses only a small portion of that standard,
262 specifically the structure that returns a trust token from the issuer
263 to the requester.
265 This specification makes no statements on the content and format of
266 the token returned from the Plasma server to the Plasma client in the
267 wst:RequestSecurityTokenResponse field. These tokens may be
268 parseable by the client, but there is no requirement that the client
269 be able to understand the token. The token can always be treated as
270 an opaque blob by the client which is simply reflected back to the
271 server at a later time. The attributes that client needs to
272 understand in order to use the token, such as the life time, are
273 returned as fields of the token response.
275 TODO: need to discuss the content model and say what elements need to
276 be supported and what elements can be ignored -- safely.
278 3. Model
280 To be supplied from the problem statement document. [[CREF4: Should
281 one be able to create a policy on the fly for specific item where a
282 set of attributes can be defined by the sender of the message.
283 --Brian]]
284 (1)(3) +----------+
285 +----------->|Sending |<------------+
286 | |Agent | |
287 (2) v +----------+ v
288 +----------+ ^ +---------+
289 |Email | | |Mail |
290 |Policy |<----------+ |Transfer |
291 |Service | |Agent |
292 +----------+ +---------+
293 () ^ +----------+ ^
294 | |Receiving | |
295 +----------->|Agent |<------------+
296 ()() +----------+
298 Figure 1: Message Access Control Actors
300 List the boxes above and give some info about them.
302 Email Policy Service is the gateway controller for accessing a
303 message. Although it is represented as a single box in the
304 diagram, there is no reason for it to be in practice. Each of the
305 three protocols could be talking to different instances of a
306 common system. This would allow for a server to operated by
307 Company A, but be placed in Company B's network thus reducing the
308 traffic sent between the two networks.
310 Mail Transfer Agent is the entity or set of entities that is used to
311 move the message from the sender to the receiver. Although this
312 document describes the process in terms of mail, any method can be
313 used to transfer the message.
315 Receiving Agent is the entity that consumes the message.
317 Sending Agent is the entity that originates the message.
319 3.1. Sender Processing
321 We layout the general steps that need to be taken by the sender of an
322 EPS message. The numbers in the steps below refer to the numbers in
323 the upper half of Figure 1. A more detailed description of the
324 processing is found in Section 7 for obtaining the security policies
325 that can be applied to a messages and Section 8 for sending a
326 message.
328 1. The Sending Agent sends a message to one or more Email Policy
329 Services in order to obtain the set of policies that it can apply
330 to a message along with a security token to be used in proving
331 the authorization. Details of the message send can be found in
332 Section 7.1.
334 2. The Email Policy Service examines the set of policies that it
335 understands and checks to see if the requester is authorized to
336 send messages with the policy.
338 3. The Email Policy Service returns the set of policies and an
339 security token to the Sending Agent. Details of the message sent
340 can be found in Section 7.2.
342 4. The Sending Agent selects the Email Policy(s) to be applied to
343 the message, along with the set of recipients for the message.
345 5. The Sending Agent relays the selected information to the Email
346 Policy Service along with the security token. Details of this
347 message can be found in Section 8.1.
349 6. The Email Policy Service creates the recipient info attribute as
350 defined in [I-D.schaad-plasma-cms].
352 7. The Email Policy Service returns the created attribute to the
353 Sending Agent. Details of this message can be found in
354 Section 8.2.
356 8. The Sending Agent composes the CMS EnvelopedData content type
357 placing the returned attribute into a KEKRecipientInfo structure
358 and then send the message to the Mail Transport Agent.
360 3.2. Recieving Agent Processing
362 We layout the general steps that need to be taken by the sender of an
363 EPS message. The numbers in the steps below refer to the numbers in
364 the lower half of Figure 1. A more detailed description of the
365 processing is found in Section 9.
367 1. The Receiving Agent obtains the message from the Mail Transport
368 Agent.
370 2. The Receiving Agent starts to decode the message and in that
371 process locates an EvelopedData content type which has a
372 KEKRecipientInfo structure with a XXXX attribute.
374 3. The Receiving Agent processes the SignedData content of the XXXX
375 attribute to determine that communicating with it falls within
376 accepted policy.
378 4. The Receiving Agent transmits the content of the XXXX attribute
379 to the referenced Email Policy Service. The details of this
380 message can be found in Section 9.1.
382 5. The Email Policy Service decrypts the content of the message and
383 applies the policy to the credentials provided by the Receiving
384 Agent.
386 6. If the policy passes, the Email Policy Service returns the
387 appropriate key or RecipientInfo structure to the Receiving
388 Agent. Details of this message can be found in Section 9.2.
390 7. The Receiving Agent proceeds to decrypt the message and perform
391 normal processing.
393 4. Protocol Overview
395 The protocol defined in this document is designed to take place
396 between a Plasma server and a Plasma client. The protocol takes
397 place in terms of a request/response dialog from the client to the
398 server. A single dialog can consist of more than one request/
399 response message pair. Multiple round trips within allow a client to
400 provide additional authentication, authorization and attribute
401 information to the server.
403 Each dialog contains one or more action attributes specifying what
404 actions the client wishes the server to take. Depending on the
405 action requested, additional attributes may be present providing data
406 for the action to use as input. Finally, each dialog will contain
407 authentication and attributes supplied by one or more authorities
408 that the server can use either as input to the action or as input to
409 policy decisions about whether to perform the action.
411 The protocol MUST be run over a secure transport, the secure
412 transport is responsible for providing the confidentiality and
413 integrity protection services over the entire message. The protocol
414 allows for signature operations to occur on sub-sections of the
415 message structure, howewever this is used for creation of identity
416 proofs and not for integrity protection.
418 Multiple dialogs may be run over a single secure transport session.
419 Before a new dialog may be started, the previous dialog MUST have
420 completed to a state of success, failure or not applicable. A new
421 dialog MUST NOT be started after receiving a response with an
422 indeterminate status. If a new dialog is desired in these
423 circumstances, then the transport session MUST to be closed and re-
424 opened. [[CREF5: --- I want to say that TLS reconnect using caching
425 is OK here. Is that a reasonable statement? I don't think we want
426 to say that the server will keep Plasma session data across TLS
427 sessions. --JLS]]
429 5. Plasma Request
431 The specification is written using XACML as the basic structure to
432 frame a request for an operation. The request for operations to
433 occur are written using XACML action items. This specification
434 defines actions specific to Plasma in a CMS environment. Other
435 specifications can define additional action items for other
436 environments (for example the XML encryption environment) or other
437 purposes. (Future work could use this basic structure to standardize
438 the dialogs between PDPs and PAPs or to facilitate legal signatures
439 on emails.)
441 In addition to the XACML action request there is a set of structures
442 to allow for a variety of authentication mechanisms to be used. By
443 allowing for the use of SAML and GSS-API as base authentication
444 mechanisms, the mechanism used is contained in a sub-system and thus
445 does not directly impact the protocol.
447 The request message uses a single XML structure. This structure is
448 the eps:PlasmaRequest object. The XML Schema used to describe this
449 structure is:
451
452
453
454
455
456
457
458
460 The RequestType has two elements in it:
462 Authentication is an optional element that holds the structures used
463 for doing authentication and authorization. Unless no
464 authentication is required by the Plasma server, the element is
465 going to exist for one or more requests in the dialog.
467 xacml:Request is a required element that contains the control
468 information for the action requested. The control information
469 takes the form of an action request plus additional data to be
470 used as part of the action request. The data and actions are to
471 be treated as self-asserted, that is they are deemed not to come
472 from a reliable source even in the event that an authentication is
473 successfully completed. As self-asserted values, Plasma servers
474 need to exercise extreme care about which are included in the
475 policy enforcement decisions. As an example, it makes sense to
476 allow for the action identifier to be included in the policy
477 enforcement, but assertions about the identity of the subject
478 should be omitted. This element is taken from the XACML
479 specification.
481 For some operations, display string values are returned as part of
482 the response from the server. The xml:lang attribute SHOULD be
483 included in the RequestType element to inform the server as to what
484 language client wishes to have the strings in. The server SHOULD
485 attempt to return strings in the language requested or a related
486 language if at all possible.
488 5.1. Authentication Element
490 One of the major goals in the Plasma work is to detach the process of
491 authentication specifics from the Plasma protocol. In order to
492 accomplish this we are specifying the use of two general mechanisms
493 (SAML and GSS-API) which can be configured and expanded without
494 changing the core Plasma protocol itself. The authentication element
495 has two main purposes: 1) to process the authentication being used by
496 the client and 2) to carry authenticated attributes for use in the
497 policy evaluation.
499 When transporting the authentication information, one needs to
500 recognize that there may be a single or multiple messages in the
501 dialog in order to complete the authentication process. In
502 performing the process of authenticating, any or all of the elements
503 in this structure can be used. If there are multiple elements filled
504 out, the server can choose to process the elements in any order.
505 This means that the Plasma protocol itself does not favor any
506 specific mechanism. The current set of mechanisms that are built
507 into the Plasma specification are:
509 o SAML Assertions - many different types of SAML assertions are
510 supported. The specification uses both bearer and holder of key
511 assertions.
513 o X.509 Certificates can be used for the purpose of authentication
514 by creating a signature with the XML Digital Signature standard.
516 o GSS-API - the specification allows for the use of GSS-API in
517 performing the authentication process. The ABFAB mechanism in
518 GSS-API is specifically designed for use in a federated community
519 and allows for both authentication and attribute information to be
520 queried from the identity server.
522 o WS-Trust tokens allow for much of the same type of information to
523 be passed as SAML assertions. The Plasma specification has been
524 designed mainly for the use of WS-Trust tokens to be used for
525 caching prior authentication sessions.
527 More than one authentication element can be present in any single
528 message. This is because a client may need to provide more than one
529 piece of data to a server in order to authenticate, for example a
530 holder of key SAML Assertion along with a signature created with that
531 key. Additionally a client may want to provide the server an option
532 of different ways of doing the authentication. In a federated
533 scenario, an X.509 certificate with a signature can be presented and
534 the server may not be able to build a trust path to it's set of trust
535 anchors. In this case the client may need to use the GSS-API/EAP
536 protocol for doing the authentication. The client may want to
537 provide the server with one or more SAML Assertion that binds a
538 number of attributes to it's identities so that the server does not
539 need to ask for those attributes at a later time. Finally, multiple
540 entities may need to be validated (for example the user and the
541 user's machine).
543 When transporting the attribute information, one needs to recognize
544 that there may be single or multiple messages in the dialog in order
545 to complete the authorization process. The server will return a
546 status code of urn:oasis:names:xacml:1.0:status:missing-attribute in
547 the event that one or more attributes are needed in order to complete
548 the authorization process. The details on how XACML returns missing
549 attribute information is found in Section 7.17.3 of [XACML]. When
550 the list of attributes is returned, the client has two choices: 1) It
551 can close the dialog, look for a source of the missing attributes and
552 then start a new dialog, 2) it can just get an assertion for the
553 missing attributes and send the new assertion as in a new request
554 message within the same dialog. The decision of which process to use
555 will depend in part on how long it is expected to take to get the new
556 attribute assertion to be returned.
558 The same authentication data does not need to be re-transmitted to
559 the server in a subsequent message within a single dialog. The
560 server MUST retain all authenticated assertion information during a
561 single dialog.
563 The schema for the Authentication element directly maps to the
564 ability to hold the above elements. The schema for the
565 Authentication element is:
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
590 The schema allows for multiple authentication elements to occur in
591 any order. It is suggested, but not required, that the ds2:Signature
592 element occur after the authentication element that has an assoicated
593 key. This makes it easier for servers to make a one pass validate of
594 all authentication elements.
596 The Other element is provided to allow for additional authentication
597 elements, include SAML version 1.1, to be used.
599 5.1.1. SAML Assertion
601 SAML Assertions can provide authentication or attribute information
602 to the server. A SAML statement only needs to be provided once
603 during a single dialog, the server MUST remember all attributes
604 during the dialog.
606 When a SAML Assertion contains a SubjectConformation element using
607 the KeyInfoConfirmationDataType as a subject conformation element,
608 the confirmation shall be performed by the creation of an XML
609 Signature authentication element. The signature element shall be
610 created using an appropriate algorithm for the key referenced in the
611 SAML statement.
613 Identify a SAML statement in the delegation/subject/environment space
614 - need text for this [[CREF6: I don't remember what this is supposed
615 to be anymore. --JLS]]
617 5.1.2. WS Trust Tokens
619 WS Trust tokens are used in two different ways by this specification.
620 They can be used as the primary introduction method of a client to
621 the server, or they can be used by the server to allow the client to
622 be re-introduced to the server in such a way that the server can use
623 cached information.
625 WS Trust tokens come in two basic flavors: Bearer tokens and Holder
626 of Key tokens. With the first flavor, presentation of the token is
627 considered to be sufficient to allow the server to validate the
628 identity of the presenter and know the appropriate attributes to make
629 a policy decision. In the second flavor some type of cryptographic
630 operation (usually a signature or MAC computation) is needed in
631 addition to just presenting the token. The Signature element
632 (Section 5.1.3) provides necessary infrastructure to permit the
633 cryptographic result to be passed to the server.
635 This document does not define the content or structure of any tokens
636 to be used. This is strictly an implementation issue for the servers
637 in question. This is because the client can treat the WS Token value
638 presented to it as an opaque blob.[[CREF7: Is this totally true?
639 Don't we need some kind of identifier so the server can indicate when
640 the token can be replayed in a subsequence request? E.g. give me
641 these attributes or a foo token. --trevor]] Only the servers need to
642 understand how to process the blob. However there are some
643 additional fields which can be returned in addition to the token that
644 need to be discussed:
646 wst:TokenType SHOULD be returned if more than one type of token is
647 used by the set of servers. If a token type is returned to the
648 client, the client MUST include the element when the token is
649 returned to the server.
651 wst:BinarySecret SHOULD be returned for moderate duration tokens.
652 If a binary secret is returned then the client MUST provide
653 protection for the secret value. When a binary secret has been
654 returned, then the client MUST create either a signature or MAC
655 value and place it into the Signature element Section 5.1.3.
656 [[CREF8: I don't know of any way to say use the asymmetric key
657 that you authenticated with originally - can this be done?
658 --JLS]].
660 wst:Lifetime MUST be returned with the wsu:Expires element set. The
661 wsu:Created element MAY be included. The element provides the
662 client a way to know when a token is going to expire and obtain a
663 new one as needed.
665 5.1.3. XML Signature Element
667 When a holder of key credential is used to determine the attributes
668 associated with an entity, there is a requirement that the key be
669 used in a proof of possession step so that the Plasma server can
670 validate that the entity does hold the key. The credentials can hold
671 either asymmetric keys (X.509 certificates and SAML Assertions) or
672 symmetric keys (WS Trust Tokens and SAML Assertions) which use
673 Digital Signatures or Message Authentication Codes (MACs)
674 respectively to create and validate a key usage statement. The XML
675 signature standard [XML-Signature] provides an infrastructure to for
676 conveying the proof of possession information.
678 The signature is computed over the XACML request element as a
679 detached signature. When a signature element exists in the message,
680 the ChannelBinding attribute (Section 10.1.1) MUST be included in the
681 request. By the use of a value which is derived from the
682 cryptographic keys used in for protecting the tunnel, it is possible
683 for the server to verify that the authentication values computed were
684 done specifically for this specific dialog and are not replayed.
686 When creating either a signature or a MAC, the following statements
687 hold:
689 o The canonicalization algorithm Canonical XML 1.1 [XML-C14N11]
690 without comments MUST be supported and SHOULD be used in preparing
691 the XML node set for hashing. Other canonicalization algorithms
692 MAY be used.
694 o The signature algorithms RSAwithSHA256 and ECDSAwithSHA256 MUST be
695 supported by servers. At least one of the algorithms MUST be
696 supported by clients. The MAC algorithm HMAC-SHA256 MUST be
697 supported by both clients and servers. Other signature and MAC
698 algorithms MAY be supported.
700 o Set the additional attributes that must be included in a signature
701 - what should they be?
703 o If an xacml:Request element is referenced by an XML Signature
704 element, the xacml:Request element MUST include the ChannelBinding
705 token (Section 10.1.1) as one of the attributes.
707 o The keys used in computing the authentication value need to be
708 identified for the recipient. For X509 certificates, the full raw
709 certificate will normally be included as part of the signature,
710 but MAY be referenced instead. For SAML assertions, the specific
711 assertion carrying the asymmetric key can be identified by TBD
712 HERE. In the event that symmetric keys are used by holder of key
713 assertions, the specific assertion will be identified by TBD HERE.
714 In these cases the server is expected to be able to associated the
715 key with the assertion by some means (either locally or perhaps
716 encrypted into the assertion).
718 5.1.4. GSS-API Element
720 GSS-API [RFC2743] provides a security services to callers in a
721 generic fasion, supportable with a range of underlying mechanisms and
722 technologies. GSS-API has been extended by providing a mechanism for
723 EAP [RFC7055] which is designed to work in a federated environment.
724 This effort was done by the Application Bridging for Federated Access
725 Beyond web (ABFAB) working group. In this document the mechanism is
726 referred to as ABFAB. This is the same type of environment that the
727 Plasma protocol is expected to operate as well.
729 GSS-API offers a number of security services that are not currently
730 used by the Plasma system. At this point in time we are only looking
731 at the initial authentiction methods and not using the message
732 encryption or encryption services.
734 TBD - rules for using GSS-API in general and the EAP version from
735 ABFAB particularly.
737 o How to build the name.
739 o Must use a secure tunnel for the outer EAP method and an
740 appropriate inner EAP method(s) to accomplish the required level
741 of authentication.
743 o Server query of attributes and specification of LOA to the EAP
744 IdP.
746 o Any additional Trust model items.
748 o How round trips are accomplished - the only case that a server
749 will send back an Authentication element is on return processing
750 of GSS-API messages.
752 5.1.4.1. Generic Requirements
754 Not all GSS-API mechanisms have the required features to support the
755 necessary security that is needed by Plasma. GSS-API mechanisms need
756 to support the following features:
758 o The mechanism MUST support the binding of the TLS tunnel to the
759 authentication via channel binding.
761 o Either the mechanism MUST support mutual authentication or the TLS
762 tunnel MUST be usable to authenticate the server being talked to.
763 Anonymous TLS sessions can be use when mutual authentication is
764 provided by the GSS-API mechanism.
766 5.1.4.2. GSS-EAP Requirements
768 When forming a mechnism name for GSS-API the following guidelines
769 SHOULD be followed:
771 o The user-or-service string is "plasma" (all in lower case).
773 o The host name is to be provided. When obtained from the URL, the
774 host name is to be the entire host name in the URL.
776 o There are currently no service-specific options defined.
778 o The realm name is OPTIONAL. When obtained from the URL, the realm
779 name is omitted.
781 o Realm and host names should be prepared according to [RFC5891]
782 prior to passing them into GSS-API.
784 Clients MUST use a tunneling EAP method that supports channel binding
785 between the tunnel and the inner EAP methods. At this point in time
786 only the TEAP method [I-D.ietf-emu-eap-tunnel-method] provides the
787 necessary support. While any inner EAP method can be used, it is
788 strongly recommended that only those methods that support generation
789 of EMSK (extended master session keys) be used, however methods tht
790 only support generation of a MSK (master session key) can be used.
791 (A discussion of why EMSKs should be generated can be found in
792 [RFC7029].)
794 IdPs MUST support the EAP channel binding that is part of TEAP. At a
795 minimum the service name, host name and real names MUST be checked
796 for matches between the information provided by the TEAP channel
797 binding and the RADIUS attributes.
799 5.1.4.3. GSS-API Channel Bindings
801 The calls to GSS_Init_sec_content and GSS_Accept_sec_context take a
802 chan_bindings parameter. The value is a GSS_CHANNEL_BINDINGS
803 structure [RFC5554].
805 The initiator-address-type and acceptor-address-type fields of the
806 GSS-CHANNEL-BINDINGS structure MUST be set to 0. The initiator-
807 address and acceptor-address fields MUST be the empty string.
809 The application-data field MUST be set to the channel binding value
810 defined in Section 10.1.1.
812 5.2. xacml:Request Element
814 The request for an action to be performed by the Plasma server along
815 with the data that needs to be supplied by the client in order for
816 the server to complete the action are placed into the xacml:Request
817 element of the request. This document defines a set of actions that
818 are to be understood by the Plasma server. One (or more) action is
819 to be placed in the request message.
821 In addition to the request for a specific action to occur, the client
822 can place additional attributes in the request as well. These
823 attributes are provided in order to assist the server either in
824 identifying who the various agents on the client side are or to
825 provide suggestions of attributes for using in making control
826 decisions. Any data provided by the client in this manner is to be
827 considered as a self-asserted value and to be treated as if it comes
828 from the client as oppose to a trusted attribute agent.
830 For convenience the schema for the xacml:Request element is
831 reproduced here:
833
834
835
836
837
838
839
840
841
842
844 The RequestDefaults element of the XACML Request MUST be omitted by
845 the clients. If present servers MUST ignore the RequestDefaults
846 element. The use of the MultiRequest element is current not defined
847 for a Plasma server and SHOULD be omitted by clients.
849 Clients MAY set ReturnPolicyIdList to true in order to find out which
850 policies where used by the server in making the decision. Server MAY
851 ignore this field and not return the policy list even if requested.
853 A number of different entities may need to be identified to Plasma
854 server as part of a request. These entities include:
856 1. The subject making the request to the server.
858 2. The machine on the subject is using.
860 3. The entity the subject is acting for. Converse about Delegation.
862 6. Plasma Response Element
864 There is a single top level structure that is used by the server to
865 respond to a client request.
867 The XML Schema used to describe the top level response is as follows:
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
885 A Plasma Response has two elements:
887 xacml:Response is a mandatory element that returns the status of the
888 access request.
890 PlasmaReturnToken is an optional element to return a token. These
891 tokens represent the answer, for a success, of the request. If
892 multiple tokens are being returned, then the element will occur
893 mutiple times.
895 A Plasma Return Token is a wrapper for the actual token being
896 returned. The returned token may be any content. This document
897 defines the following elements that are to be returned in this
898 location
900 o RoleToken - used to return roles.
902 o CMSMessageToken - used to return one or more CMS RecipientInfo
903 strucutures.
905 o CMSKeyToken - used to return either a CMS RecipientInfo structure
906 or a bare content encryption key.
908 The PlasmaReturneTokenType has an optional attribute DecisionId.
909 This attribute is used when in the case multiple requests are made at
910 the same time in order to assoicate the rquest and the response
911 tokens.
913 6.1. xacml:Response Element
915 The xacml:Response element has the ability to return both a decision,
916 but additionally information about why a decision was not made.
918 The schema for the xacml:Response element is reproduced here for
919 convenience:
921
922
923
924
925
926
928
929
930
931
932
933
934
935
936
937
938
940 The xacml:Response element consists of one child the Result.
942 The xacml:Response element consists of the following elements:
944 xacml:Decision is a mandatory element that returns the possible
945 decisions of the access control decision. The set of permitted
946 values are Permit, Deny, Indeterminate and No Policy.
948 xacml:Status is an optional element returned for the Indeterminate
949 status which provides for the reason that a decision was not able
950 to be reached. Additionally it can contain hints for remedying
951 the situation. This document defines an additional set of status
952 values to be returned. Formal declaration may be found in
953 Section 15.
955 * gss-api indicates that a gss-api message has been returned as
956 part of the authentication process.
958 xacml:Obligations is designed to force the PEP to perform specific
959 actions prior to allowing access to the resource. If a response
960 is returned with this element present, the processing MUST fail
961 unless the PEP can perform the required action. A set of Plasma
962 specific obligations are found in Section 10.2. [[CREF9: What
963 about audit obligatiouns --Trevor]]
965 xacml:AssocatedAdvice is designed to give suggestions to the PEP
966 about performing specific actions prior to allowing access to the
967 resource. This element is not used by Plasma and SHOULD be
968 absent. If the response is returned with this element present,
969 processing will succeed even if the PEP does not know how to
970 perform the required action. A set of Plasma specific advice
971 elements are found in Section 10.2.
973 xacml:Attributes provides a location for the server to return
974 attributes used in the access control evaluation process. Only
975 those attributes requested in the Attributes section of the
976 request are to be returned. Since Plasma does not generally
977 supply attributes for the evaluation process, this field will
978 normally be absent.
980 xacml:PolicyIdentifierList provides a location to return the set of
981 policies used to grant access to the resource. This element is
982 expected to be absent for Plasma. [[CREF10: Should we ignore it
983 if present? --Trevor]][[CREF11: I don't think we need to say
984 anything about looking at it or ignoring it. While it would be
985 something for debugging, as a general rule the client does not
986 care which policies where evaluated and passed to grant access.
987 --JLS]]
989 7. Role Token and Policy Acquisition
991 In order to send an email using a Plasma server, the first step is to
992 obtain a role token that provides the description of the labels that
993 can be applied and the authorization to send an email using one or
994 more of the labels. The process of obtaining the role token is
995 designed to be a request/response round trip to the Plasma server.
996 In practice a number of round trips may be necessary in order to
997 provide all of the identity and attributes to the Plasma server that
998 are needed to evaluate the policies for the labels.
1000 When a Plasma server receives a role token request from a client, it
1001 needs to perform a policy evaluation for all of the policies that it
1002 arbitrates along with all of the options for those policies. In
1003 general, the first time that a client requests a role token from the
1004 server, it will not know the level of authentication that is needed
1005 or the set of attributes that needs to be presented in order to get
1006 the set of tokens. A server MUST NOT issue a role token without
1007 first attempting to retrieve from an attribute source (either the
1008 client or a back end server) all of the attributes required to check
1009 all policies. Since the work load required on the server is expected
1010 to be potentially extensive for creating the role token, it is
1011 expected that the token returned will be valid for a period of time.
1012 This will allow for the frequency of the operation to be reduced.
1013 While the use of an extant role token can be used for identity proof,
1014 it is not generally suggested that a new token be issued without
1015 doing a full evaluation of the attributes of the client as either the
1016 policy or the set of client attributes may have changed in the mean
1017 time.
1019 7.1. Role Token Request
1021 The process starts by a client sending a server a role token request.
1022 Generally, but not always, the request will include some type of
1023 identity proof information and a set of attributes. It is suggested
1024 that, after the first successful conversation, the client cache hints
1025 about the identity and attributes needed for a server. This allows
1026 for fewer round trips in later conversations. An example of a
1027 request token can be found in Appendix B.
1029 The role token request, as with all requests, uses the
1030 eps:PlasmaRequest XML structure. The eps:Authentication MAY be
1031 included on the first message and MUST be included on subsequent
1032 authentication round trips.
1034 A role token request by a client MUST include the GetRoleTokens
1035 Plasma action request as an attribute of the xacml:Request element.
1036 Details on the action can be found in section Section 15.1. When
1037 role tokens are requested, no additional data needs to be supplied by
1038 the requester.
1040 An example of a message requesting the set of policy information is:
1042
1043 ...
1044
1045
1046
1047
1049 GetRoleToken
1050
1051
1052
1053
1055 7.2. Request Role Token Response
1057 In response to a role token request, the Plasma server returns a role
1058 token response. The response uses the eps:PlasmaResponse XML
1059 structure. When a response is create the following should be noted:
1061 An xacml:Decision is always included in a response. The values
1062 permitted are:
1064 Permit is used to signal success. In this case the response MUST
1065 include one or more eps:RoleToken element.
1067 Deny is used to signal failure. In this case the xacml:Status
1068 element MUST be present an contain a failure reason.
1070 Indeterminate is used to signal that a final result has not yet been
1071 reached. When this decision is reached, the server SHOULD return
1072 a list of additional attributes to be returned and SHOULD return
1073 the list of role tokens that have been granted based on the
1074 attributes received to that point.
1076 NotApplicable is returned if the Plasma server does not have the
1077 capability to issue role tokens.
1079 An example of a response returning the set of policy information is:
1081
1082
1083
1084 Permit
1085
1086
1087
1088
1089
1090
1091 Details of a policy
1092
1093 ... More policies ...
1094
1095 urn:...:plasma:roleToken
1096 ...
1097
1098
1099
1100
1101
1103 The process of getting role tokens has a problem that is not part of
1104 the normal XACML design. It is possible to compute a partial result
1105 based on the current set of attributes that have been supplied by the
1106 client, while having other role tokens that cannot be provided to the
1107 client since required attributes have not been provided. Since this
1108 is not part of the standard XACML model, one only has a single access
1109 /deny decision and if the attributes have not been provided then the
1110 response would be deny, we need to look at it in a bit more detail
1111 here.
1113 In the process of discussions three different solutions to the
1114 problem were considered:
1116 A signal could be added that allows for the client to signal that
1117 it cannot provide any more attributes to the server. This would
1118 allow for a final decision to be provided, but would potentially
1119 involve an additional round trip as the set of attributes can be
1120 determined based on the set of attributes provided. Supplying new
1121 attributes from the client can result in the server asking for new
1122 attributes from the client. This is not currently supported by
1123 the XACML model and there is no clear point where it would go into
1124 our model.
1126 The server can return a partial result on each round trip. This
1127 maps directly onto the XACML model, but leads to some other
1128 problems. It means that all of the policies must be designed such
1129 that adding a new attribute to the policy evaluation process will
1130 not cause a policy that previously had been permitted is now
1131 denied.
1133 A method could be added that allows for the client to state that
1134 it either does not have or does not know what an attribute is.
1135 This method would allow for the server to make a definitive
1136 answer, but it requires that one extra round trip be made to get
1137 the final answer.
1139 The normal mode that Plasma servers are expected to operate in is
1140 returning incremental results, however they can also keep internal
1141 state looking at what additional attributes are being provided by the
1142 client. If the client provides no new attributes, then the server
1143 can return a set of role tokens close down the conversation. If the
1144 server expects to get all attributes from the back end, and just get
1145 authentication from client, then it can return a set of role tokens
1146 immediately without providing a list of attributes to the client for
1147 it to try and satisfy.
1149 7.2.1. RoleToken XML element
1151 The eps:PlasmaReturnToken element is used to return a role token to
1152 the client. Multiple role tokens can be returned by using multiple
1153 eps:PlasmaReturnToken elements. Each role token returned contains
1154 one or more policies that can be asserted, the role token, and
1155 optionally one or more set of obligations or advice that need to be
1156 observed when creating messages. Additionally the name of a Plasma
1157 server to be used with the token can be included as well as
1158 cryptographic information to be used with the token.
1160 The schema used for the PlasmaTokens element is:
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1199 The eps:RoleToken element contains the following items:
1201 FriendlyName This element returns a descriptive name of the role as
1202 a whole. The string returned SHOULD be selected based on the
1203 language attribute on the request message. The string is suitable
1204 for display to the user and should be indicative of the scope of
1205 the role. Examples of role descriptive strings would be "Company
1206 President", "Senior Executive", "Project X Electrical Engineer".
1208 PDP The element provides one or more URLs to be used for contacting
1209 a Plasma server for the purpose of sending a message. This
1210 element allows for the use of different Plasma servers for issuing
1211 role tokens and message tokens. No ranking of the servers is
1212 implied by the order of the URLs returned.[[CREF12: Should perhaps
1213 rename to be more understandable - perhaps Server --JLS]]
1215 PolicyList contains the description of one or more policies that can
1216 be asserted using the issued role token. Any of the policies
1217 contained in the list may be combined together using the policy
1218 logic in constructing a label during the send message process.
1220 Policy contains a single simple policy. This element is returned as
1221 part of a read message token. The purposes is to allow for a
1222 recipient to reply to a message that they would not normally be
1223 able to assert.
1225 PolicySet contains a complex policy. This element is returned as
1226 part of a read message token The purpose is to allow for a
1227 recipient to reply to a message that they would not normally be
1228 able to assert.
1230 wst:RequestSecurityTokenResponse contains the actual token itself.
1232 xacml:Obligations This optional element contains a set of
1233 obligations that the client is required to enforce in order to use
1234 any of the policies listed when combined with the returned
1235 security token. These obligations can include items such as
1236 required algorithms or required operational steps such as
1237 requiring a signature to be placed on the content. A policy can
1238 be listed in multiple role tokens and the set of obligations may
1239 be different depending on which role token is used. If the client
1240 is unable to fulfill the obligations then it MUST NOT allow the
1241 role token to be used.
1243 xacml:AssociatedAdvice This optional element contains a set of
1244 advice statements that the client is requested to enforce when
1245 using any of the policies listed when combined with the returned
1246 security token. This advice can include items such as encryption
1247 or signature algorithms or operational steps such as requiring a
1248 signature to be placed on the content. The client is SHOULD
1249 fulfill the advice, however if it cannot fulfill the advice the
1250 role token may still be used.
1252 The eps:PolicyType type is used to represent the elements of a policy
1253 to the client. The elements in this type are:
1255 FriendlyName contains a display string that represents the policy.
1256 This element is localized in response to the xs:lang attribute in
1257 the eps:PlasmaRequest node.
1259 PolicyId contains a "unique" identifier for the policy. This is the
1260 value that identifies the policy to the software. The type for
1261 the value is defined as a URI.
1263 Options This element is used to inform the client what the set of
1264 options that need to be filled in as part of asserting the policy.
1265 If the client software does not understand how to set the options
1266 for the supplied type, then the client software MUST NOT allow the
1267 user to assert the policy. The option structure is identified by
1268 the URI in the optionsType attribute. This document defines one
1269 option structure for holding a list of email addresses (section
1270 Section 7.2.2). This option structure is used in the basic
1271 policies defined in [PlasmaBasicPolicy].
1273 When building the wst:RequestSecurityTokenResponse element, the
1274 following should be noted:
1276 A wst:RequestedSecurityToken element containing the security token
1277 MUST be included. The format of the security token is not
1278 specified and is implementation specific, it is not expected that
1279 clients should be able to get useful information from the token
1280 itself. Information such as lifetimes need to be provided as
1281 addition elements in the response. Examples of items that could
1282 be used as security tokens are SAML statements or encrypted record
1283 numbers in a server database.
1285 A wst:Lifetime giving the life time of the token SHOULD be
1286 included. It is not expected that this should be determinable
1287 from the token itself and thus must be independently provided.
1288 There is no guarantee that the token will be good during the
1289 lifetime as it may get revoked due to changes in the environment
1290 (for example, if the policies are updated then all existing tokens
1291 may need to be re-issued), however the client is permitted to act
1292 as if it were. The token provided may be used for duration. If
1293 this element is absent, it should be assumed that the token is
1294 either a one time token or of limited duration.
1296 Talk about cryptographic information - There are three different
1297 types of crypto information that can be returned and we need to
1298 figure out how to talk about them. These are 1) a symmetric key,
1299 2) a new asymmetric key and 3) a pre-existing asymmetric key - for
1300 example from the certificate used for authentication purposes.
1301 There is probably good ways to do 1 and 2, but I don't know how to
1302 talk about 3 at this point in time.
1304 7.2.2. Email Address List Options
1306 Some policies are designed to be restricted to a set of explicitly
1307 named people by the sender of the message. This policy is used for
1308 the set of basic policies defined in [PlasmaBasicPolicy]. In these
1309 cases the creator of the message specifies a set of recipients by
1310 using email address names without any decoration.
1312 The Email Address List Option is identified by the uri
1313 "urn:ietf:params:xml:ns:plasma:options:emailAddrs". The type
1314 associated with the structure is a string. The string contains a
1315 space separated set of internalized email addresses. Domains SHOULD
1316 be encoded as U-labels rather than using puny code.
1318 All Plasma clients and servers MUST be able to create, parse and use
1319 the Email Address List Option for any policy.
1321 As of the release of this document, Plasma clients and servers are
1322 not expected to understand any other options.
1324 8. Sending An Email
1326 After having obtained a role token from a Plasma server, the client
1327 can then prepare to send an Email by requesting a message token from
1328 the Plasma server. As part of the preparatory process, the client
1329 will construct the label to be applied to the Email from the set of
1330 policies that it can assert, determine the optional elements for
1331 those policies which have options, generate the random key encryption
1332 key and possible create the key recipient structures for the email.
1333 Although this section is written in terms of a CMS Encrypted message,
1334 there is nothing to prevent the specification of different formats
1335 and still use this same basic protocol. An example of a send mail
1336 request token can be found in Appendix D.
1338 8.1. Send Message Request
1340 The send message request is built using the eps:PlasmaRequest XML
1341 structure. When building the request, the following applies:
1343 o The eps:Authentication element MUST be included in the initial
1344 message. The role token that authorizes the use of the label MUST
1345 be included in the initial message. If the role token is
1346 dependent on a cryptographic key for authentication, then that
1347 authentication MUST be included in the initial message.
1349 o The client MUST include an action attribute. This document
1350 defines the GetSendCMSToken action attribute for this purpose.
1352 o The client MUST include a data attribute. This attribute contains
1353 the information that is used to build the CMS Message token to be
1354 returned. There MAY be more than one data attribute, but this
1355 will not be a normal case. More details on this attribute are in
1356 Section 8.1.1.
1358 o If the client is using the XML Digital Signature element in this
1359 message, then the client MUST include the cryptographic channel
1360 binding token (Section 10.1.1) in the set of XACML attributes.
1362 A message requesting that a CMS message token be created looks like
1363 this:
1365
1366
1367
1368 Role Token goes here
1369
1370
1371
1372
1373
1374 GetSendCMSToken
1375
1376
1377
1378
1379
1380
1381 Label and keys
1382
1383
1384
1385
1386
1387
1389 8.1.1. CMS Message Token Data Structure
1391 The message token data structure is used as an attribute to carry the
1392 necessary information to issue a CMS message token. The schema that
1393 describes the structure is:
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1434 When used in an xacml:Attribute, the structure is identified by:
1436 Category = "urn:ietf:params:xml:ns:plasma:data"
1437 AttributeId = "urn:ietf:params:xml:ns:plasma:data:CMSTokenRequest"
1438 DataType =
1439 "urn:ietf:params:xml:schema:plasma:1.0#CMSTokenRequestType"
1441 The elements of the structure are used as:
1443 Policy
1444 This element contains a the policy to be applied to the message
1445 when a single policy is used.
1447 PolicySet
1448 This element contains the policy to be applied to the message when
1449 a combination of policies is to be applied.
1451 Hash
1452 This element contains the hash of the encrypted content of the
1453 message that the policy is being applied to. The algorithm used
1454 to compute the hash is contained in the DigestMethod element and
1455 the value is contained in the DigestValue element.
1457 LockBox
1458 This optional element contains a pre-computed CMS recipient info
1459 structure for a message recipient. This element may be repeated
1460 when more than one lock box is pre-computed for recipients by the
1461 message sender. This element is used in those cases where the
1462 sender does not want to share the content encryption key with the
1463 Plasma server and the sender has the ability to retrieve the
1464 necessary keys for all of the recipients. If the #### obligation
1465 was returned for the role token, then a recipient info lock box
1466 MUST be created for the Plasma server and the CEK element MUST
1467 absent. [[CREF13: Do we define this obligation or remove the
1468 previous sentence? --JLS]]
1470 CEK
1471 This optional element contains the content encryption key (CEK) to
1472 decrypt the message.
1474 One or both of CEK and Recipients elements MUST be present.
1476 The elements of the LockBoxType structure are:
1478 Subject
1479 This element contains a subject identifier. The element can occur
1480 more than one time in situations where a subject has multiple
1481 names or a key is used by multiple subjects. Since a CMS
1482 recipient info structure does not contain a great deal of
1483 information about the recipient, this element contains a string
1484 which can be used to identify the subject. The format of the
1485 subject name is provided by the required type attribute of the
1486 element. All implementations MUST recognize
1487 "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" as a name
1488 type. [[CREF14: Call for other mandatory to implement name types
1489 --JLS]] Other name types MAY be recognized.
1491 CMSLockBox
1492 This element contains a base64 encoded CMS Recipient Info
1493 structure. If the recipient info structure is placed here, it
1494 MUST NOT be placed in the CMS EnvelopedData structure as well.
1496 XMLLockBox
1497 This element contains an EncryptedKeyType structure as defined by
1498 the XML Encryption standard [W3C.WD-xmlenc-core1-20101130]. If
1499 this recipien structure is placed here, it MUST NOT placed in the
1500 XML EncryptedType struture as well.
1502 In addition, the structure allows for other formats of encrypted data
1503 structures to be included as well. Servers which do not recognize
1504 the name space and data structure MUST return an unrecognized data
1505 structure error and not process the request.
1507 8.1.2. XML Label Structure
1509 A client is allowed to build a complex label to be sent to the Plasma
1510 server for evaluation. While there are some cases that a simple
1511 single policy is applied to a message, it is expected that many, if
1512 not most, messages will have more than one policy applied to it with
1513 logical statements connected those policies.
1515 The schema for specifying a label is:
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1535 The Policy and the PolicySet elements are used when specifying a
1536 policy for a message depending on whether a single policy or multiple
1537 policies are to be evaluated.
1539 The Policy element is used to specify a single policy to the server
1540 along with any options that are defined for that policy. The Policy
1541 element contains:
1543 PolicyId
1544 Is an attribute that contains the URI which identifies a specific
1545 policy to be evaluated.
1547 inner content
1548 The content of the Policy element can be any XML element. The
1549 content is to be the set of selected options for the policy (if
1550 any exist). The schema applied to the content is based on the
1551 policy selected.
1553 The PolicySet element is used to specify a logical set of policies to
1554 be applied to the message. This element allows one to specify
1555 multiple policies along with a logic operation to combine them
1556 together.
1558 Policy
1559 This element allows for a single policy and any policy specific
1560 options for the policy to be specified. This element can occur
1561 zero or more times.
1563 PolicySet
1564 This element allows for a logical set of policies to be
1565 recursively evaluated. This element can occur zero or more times.
1567 PolicyCombiningAlgId
1568 This attribute specifies the operation to be used in combining the
1569 elements of the tree together. This specification uses the XACML
1570 policy combining algorithms from [XACML]. Servers and clients
1571 MUST support the unordered Deny-Overrides and Permit-Overrides
1572 policy combining rules. Servers SHOULD support all of the policy
1573 combining rules defined in [XACML]. Clients are expected to use a
1574 friendly name when displaying the policy combining rule to users.
1575 When displaying strings to users, the following strings are
1576 suggested:
1578 AND Is used to represent either the ordered or unordered Deny-
1579 Overrides combining algorithm.
1581 OR Is used to represent either the ordered or unordered Permit-
1582 Overrides combining algorithm.
1584 8.2. Send Message Response
1586 In response to a send message request, the Plasma server returns a
1587 send message response message. The response messages uses the
1588 eps:PlasmaResponse XML structure. When the response message is
1589 created, the following should be noted:
1591 o The xacml:Decision is always included in the response. If the
1592 'Permit' value is returned then a CMS Token Response element MUST
1593 be present.
1595 o The PlasmaReturnToken element with a eps:CMSToken content is
1596 included with a permit response. The CMSToken contains one or
1597 more CMS RecipientInfo objects to be included in the message sent.
1599 An example of a message returning the set of policy information is:
1601
1602
1603
1604 Permit
1605
1606
1607 234e34d3
1608
1610 The schema use for returning a CMS token is:
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1627 This schema fragment extends the Plasma response token type and
1628 allows for the return of one or more base64 encoded RecipientInfo
1629 structures. The Plasma server can return recipient info information
1630 for any recipient that it pre-authorizes to receive the message (see
1631 Section ### of [I-D.freeman-plasma-requirements] for examples of when
1632 this would occur). Additionally the Plasma server can return a
1633 KEKRecipientInfo structure with the Plasma Other Key attribute. (For
1634 details see [I-D.schaad-plasma-cms].) In some extremely rare cases
1635 where the Plasma server can pre-authorize the entire set of
1636 recipients , the KEKRecipientInfo structure with the Plasma Other Key
1637 Attribute may not be included in the returned set of recipients. The
1638 recipient info structure for the plasma server SHOULD be placed last
1639 in the list of recipients infos.
1641 The CMSTokenResponse type has the following:
1643 CMSLockBox
1644 This element contains the ASN.1 encoding for a CMS RecipientInfo
1645 structure to be placed in the final message. This element will
1646 occur multiple times if there are multiple CMS RecipientInfo
1647 structures being returned from the server.
1649 CMSType
1650 This attribute of the RecipientInfo structure is an optional text
1651 value that identifies the type of recipient info structure
1652 returned. NOTE: This attribute is currently optional and is
1653 likely to disappear if I do not find it useful.
1655 8.3. XML Message Send Request
1657 It is possible to do a send message request for an XML rather than a
1658 CMS message structure. The send message request is built using the
1659 eps:PlasmaRequest XML structure. When building the request, the
1660 following applies:
1662 o The eps:Authentication element MUST be included in the initial
1663 message. The role token that authorizes the use of the label MUST
1664 be included in the initial message. If the role token is
1665 dependent on a cryptographic key for authentication, then that
1666 authentication MUST be included in the initial message.
1668 o The client MUST include an action attribute. This document
1669 defines the GetSendXMLToken action attribute for this purpose.
1671 o The client MUST include a data attribute. This attribute contains
1672 the information that is used to build the XML Message token to be
1673 returned. There MAY be more than one data attribute but that is
1674 not a normal case. More details on this attribute are in
1675 Section 8.1.1.
1677 o If the client using the XML Digital Signature element in this
1678 message, then the client MUST include the cryptographic channel
1679 binding token (Section 10.1.1) in the set of the XACML attributes.
1681 8.4. XML Message Send Response
1683 In response to a send message request, the Plasma server returns a
1684 send message response message. The response messages uses the
1685 eps:PlasmaResponse XML structure. When the response message is
1686 created, the following should be noted:
1688 o The xacml:Decision is always included in the response. If the
1689 'Permit' value is returned then a XML Token Response element MUST
1690 be present.
1692 o The PlasmaReturnToken element with a eps:XMLToken content is
1693 included with a permit response. The XMLToken contains one or
1694 more XML EncyptedKey objects to be included in the message sent.
1696
1697
1698
1699
1700
1701
1703 9. Decoding A Message
1705 When the receiving agent is ready to decrypt the email, it identifies
1706 that there is a KEKRecipientInfo object which contains a key
1707 attribute identified by id-keyatt-eps-token. It validates the
1708 signature, determines that communicating with the Plasma Service is
1709 within local policy, and then sends a request to the service to
1710 obtain the decryption key for the message.
1712 In some cases the recipient of a message is not authorized to use the
1713 same set of labels for sending a message. For this purpose a token
1714 can be returned in the message along with the key so that recipient
1715 of the can reply to the message using the same set of security
1716 labels.
1718 9.1. Requesting Message Key
1720 The client sends a request to the Plasma server that is identified in
1721 the token. For the CMS base tokens, the address of the Plasma server
1722 to use is defined in [I-D.schaad-plasma-cms] this is located in the
1723 aa-eps-url attribute.
1725 The request uses the eps:PlasmaRequest XML structure. When building
1726 the request, the following should be noted:
1728 o The xacml:Request MUST be present in the first message of the
1729 exchange.
1731 o The action used to denote that a CMS token should be decrypted is
1732 "ParseCMSToken".
1734 o The CMS token to be cracked is identified by "CMSToken"
1736 o In the event that a reply to role token is wanted as well, then
1737 that is supplied as a separate action. [[CREF15: We may want to
1738 require that a reply token always be returned instead of just
1739 returning it on demand. --jls]] In this case the action is
1740 "GetReplyToken".
1742 o If the client is using the XML Digital Signature element in this
1743 message, then the client MUST include the cryptographic channel
1744 binding token (Section 10.1.1) in the set of XACML attributes.
1746 An example of a message returning the set of policy information is:
1748
1749 ...
1750
1751
1752
1753 ParseCMSToken
1754
1755
1756
1757
1758
1759 Hex encoded CMS Token Value
1760
1761
1762
1763
1764
1766 When used in an xacml:Attribute, the structure is identified by:
1768 Category = "urn:ietf:params:xml:ns:plasma:data"
1769 AttributeId = "urn:ietf:params:xml:ns:plasma:data:CMSToken"
1770 DataType =
1771 "urn:ietf:params:xml:schema:plasma:1.0#CMSTokenResponseType
1773 9.2. Requesting Message Key Response
1775 In response to a message key request, the Plasma server returns a
1776 decrypted key in the message key response. The response message uses
1777 the eps:Plasma XML structure. When a response message is create the
1778 following should be noted:
1780 o If the value of xacml:Decision is Permit, then response MUST
1781 include an eps:CMSKey element.
1783 o For all other decision types the eps:CMSKey MUST be absent.
1785 o If a reply token was requested and granted, then the response MUST
1786 include an eps:PlasmaToken element. The eps:PlasmaToken element
1787 MUST use the Label option
1789 o Only the CEK and CMSLockBox elements in the choice are permitted
1790 for the CMSKey tag name.
1792 An example of a message returning the set of policy information is:
1794
1795
1796
1797 Permit
1798
1799
1800
1801 Label TExt
1802 hex based KEK
1803
1804
1806 The schema for returning the decrypted key is:
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1823 This schema extends the Plasma response token type and restricts the
1824 content to the listed elements. The values returned are:
1826 DisplayString returns a localized display string for the policy(s)
1827 which were applied to the message. The lang attribute on the
1828 request is used to determine which language to use for this
1829 string.
1831 CEK returns the base64 encoded content encryption key.
1833 CMSLockBox returns the content encryption key in the form of a CMS
1834 RecipientInfo structure.
1836 XMLLockBox returns the content encryption key in the form of an XML
1837 Encrypted Key type.
1839 RoleToken optionally returns a role token for replying to this
1840 message.
1842 Attributes optionally returns a set of attributes associated with
1843 the message.
1845 The structure allows for additional key types to be defined in other
1846 schemas and returned in this structure as well. The set of allows
1847 lock boxes to be returned is restricted by the XML tag nd not the
1848 schema.
1850 10. Plasma Attributes
1852 In this document a number of different XACML attributes have been
1853 defined, this section provides a more detailed description of these
1854 elements.
1856 10.1. Data Attributes
1858 10.1.1. Channel Binding Data Attribute
1860 The channel binding data attribute is used to provide for a binding
1861 of the TLS session that is being used to transport the Plasma
1862 messages with the content of the Plasma requests themselves. There
1863 is a need for the server to be able to validate that the
1864 cryptographic operations related to holder of key statements be made
1865 specifically for the current conversation and not be left over from a
1866 previous one as a replay attack. By deriving a cryptographic value
1867 from the shared TLS session key and signing that value we are able to
1868 do so.
1870 The channel binding value to be used is created by the TLS key
1871 exporter specification defined in RFC 5705 [RFC5705]. This allows
1872 for a new cryptographic value to be derived from the existing shared
1873 secret key with additional input to defined the context in which the
1874 key is being derived. When using the exporter, the label to be input
1875 into the key exporter is "EXPORTER_PLASMA". The value to be derived
1876 is 512 bits in length, and no context is provided to the exporter.
1878 When used as an XACML attribute in a request:
1880 The category of the attribute is
1881 "urn:ietf:params:xml:ns:plasma:data".
1883 The AttributeId attribute is
1884 "urn:ietf:params:xml:ns:plasma:data:ChannelBinding".
1886 The Issuer attribute is absent.
1888 The DataType is either base64Binary or hexBinary
1890 The same value is used for both the XACML channel binding data
1891 attribute and the XM1L channel binding structure defined in
1892 Section 5.1.3.
1894 10.1.2. CMS Signer Info Data Attribute
1896 In many cases a policy states that the client is required to sign the
1897 message before encrypting it. The server cannot verify that a
1898 signature is applied to the message and included, but we can require
1899 that a signature be supplied to the server. This signature can then
1900 be validated by the server (except for the message digest attribute
1901 value), and the server can take a hash of the value and return it as
1902 part of the key returned to a decrypting agent. This agent can then
1903 validate that the signature is a part of the message and complain if
1904 it absent. This means we do not have an enforcement mechanism, but
1905 we do have a way of performing an audit at a later time to see that
1906 the signature operation was carried out correctly.
1908 By requiring that a signature be supplied to the server as part of
1909 the authentication process, the Plasma server can also be setup so
1910 that the supplied signature is automatically feed into archival
1911 operations. One way to do archiving is to use the data records
1912 defined in [RFC4998].
1914 The following applies when this data value is present:
1916 The Category attribute is "urn:ietf:params:xml:ns:plasma:data".
1918 The AttributeId attribute is
1919 "urn:ietf:params:xml:ns:plasma:data:CMSSignerInfo".
1921 The Issuer attribute is absent.
1923 The DataType attribute is either base64Binary or hexBinary.
1925 The data value is a CMSSignerInfo ASN.1 encoded object.
1927 10.1.3. S/MIME Capabilities Data Attribute
1929 Policies sometimes require that specific algorithms be used in order
1930 to meet the security needs of the policy. This attribute allows for
1931 an S/MIME Capabilities to be carried in a DER encoded
1932 SMIMECapabilities ASN.1 structure to be transmitted to the client.
1933 Details on how the S/MIME Capabilities function can be found in
1934 [RFC5751].
1936 The following attributes are to be set for the data value:
1938 The Category attribute is "urn:ietf:params:xml:ns:plasma:data".
1940 The AttributeId attribute is "urn:ietf:params:xml:ns:plasma:data
1941 :SMIME-Capabilties".
1943 The Issuer attribute is absent.
1945 The DataType attribute is either base64binary or hexBinary.
1947 10.1.4. EMAIL Recipient Addreses
1949 In order for Plasma Servers to do pre-authentication in the Email
1950 environment, it is necessary for the set of recipient addresses to be
1951 delivered to the Plasma Server. The Plasma Server cannot reliably
1952 determine the set of recipients from the policies set on the message
1953 as the set of recipients and the set of people authorized to view the
1954 message may not have a one-to-one correspondance. People may be
1955 authorized to see the content who are not recipients of the message
1956 or visa versa.
1958 The content of the attribute is a space separated list of email
1959 addresses. Each address represents an Email recipient address that
1960 the client will be placing in one or more of the recipient fields in
1961 the message submission.
1963 The following attributes are to be set for the data value:
1965 The Category for the attribute is
1966 "urn:ietf:params:xml:ns:plasma:data".
1968 The AttributeId for the attribute is
1969 "urn:ietf:params:xml:ns:plasma:data:SMTPRecipients".
1971 The Issuer for the attribute is absent.
1973 The DataType for the attribute is "http://www.w3.org/2001/
1974 XMLSchema#string".
1976 10.1.5. Return Lockbox Key Information
1978 Some policies require that the content encryption key be transported
1979 wrapped by another key rather than being sent in plain text. This
1980 data value allows for this state to be indicated by the Plasma Server
1981 to the Plasma Client, and for the client to provide the necessary key
1982 information to the server.
1984 This data attribute is returned as a missing attribute under the
1985 circumstances where it is required by the policy and has not been
1986 provided the client. This is an indication that the content
1987 encryption key needs to be returned in a lock box rather than as
1988 plain text. The Plasma Server MAY ignore this data value if it is
1989 provided in a situation where the policy does not require that the
1990 content encryption key be returned in an encrypted form.
1992 The following attributes are to be set for this data value:
1994 The Category for the attribute is
1995 "urn:ietf:params:xml:ns:plasma:data".
1997 The AttributeId for the attribute is
1998 "urn:ietf:params:xml:ns:plasma:data:LockboxKey".
2000 The issue for the attribute is absent.
2002 The DataType for the attribute is
2003 "urn:ietf:params:xml:schema:plasma:1.0LockboxKey".
2005 The schema for the type LockboxKey is:
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2018 The fields of this structure are as follows:
2020 X509Certificate holds a certificate with the public key to be used
2021 in building the CMS Lockbox returned containing the content
2022 encryption key.
2024 PGPKey holds a PGP public key to be used in building the PGP lock
2025 box returned containing the content encryption key.
2027 ds2:KeyInfo holds a public key to be used in building a CMS lock box
2028 returned containing the content encryption key.
2030 Capabilities contains a base64 encoded SMimeCapablities ASN.1
2031 structure allowing the client to advertise to the server which
2032 algorithms are supported for building the lockbox structure. This
2033 element is optional. If the element is omitted then the server
2034 will make the selection of algorithms to be used based solely on
2035 the pubic key.
2037 10.2. Obligations and Advice
2039 Obligations and advice consist of actions that the Plasma server
2040 either requires or requests that the client PEP perform in order to
2041 gain access or before granting access to the data. These normally
2042 represent actions or restrictions that the PDP itself cannot enforce
2043 and thus are not input attributes to the policy evaluation. The same
2044 set of values can be used either as obligations or advice, the
2045 difference being that if the PEP cannot do an obligation it is
2046 required to change the policy decision.
2048 10.2.1. Signature Required
2050 Many policies require that a message be signed before it is encrypted
2051 and sent. Since the unencrypted version of message is not sent to
2052 the Plasma server, the policy cannot verify that a signature has been
2053 placed onto the signed message. The attribute is not for use as a
2054 returned obligation from an XACML decisions, rather it is for a pre-
2055 request obligations used in role responses (Section 7.2).
2057 When used as an Obligation:
2059 The ObligationId attribute is
2060 "urn:ietf:params:xml:ns:plasma:obligation:signature-required".
2062 A S/MIME Capabilities data value can optionally be included. If
2063 it is included, then it contains the set of S/MIME capabilities
2064 that describes the set of signature algorithms from which the
2065 signature algorithm for the message MUST be selected.
2067 10.2.2. Content Encryption Algorithm Required
2069 Occasionally a policy requires a specific set of encryption
2070 algorithms be used for a message, when this is the case then the
2071 encryption required obligation is included in the returned set of
2072 obligations. If the default set of encryption algorithms is
2073 sufficient then the obligation is omitted.
2075 When used as an Obligation:
2077 The ObligationId attribute is
2078 "urn:ietf:params:xml:schema:plasma:1.0:obligation:content-
2079 encryption".
2081 An S/MIME Capabilities data value MUST be included containing the
2082 set of permitted encryption algorithms. The algorithms included
2083 MUST include a sufficient set of algorithms for the message to be
2084 encrypted. An absolute minimum would be a content encryption
2085 algorithm and key encryption algorithm.
2087 10.2.3. Lock Box Required
2089 This obligation will be used in one of two situations:
2091 1. The policy requires that the plain content encryption key not be
2092 given to the Plasma server, but instead the Plasma client is
2093 required to locate the appropriate certificates and create lock
2094 boxes for each of the message recipients. In this situation, the
2095 Plasma server would never have any access to the content
2096 encryption key and thus would be unable to provide the key to any
2097 entity. The Plasma server in this case is responsible only for
2098 the enforcement of the policy enforcement on the message access.
2100 2. The policy requires that the content encryption key not be given
2101 to the Plasma server as a base64 encoded blob, but instead the
2102 Plasma client is required to use the provided certificate to
2103 create a lock box for the Plasma server. In this situation, the
2104 Plasma server does have access to the content encryption key and
2105 thus has the ability to do late binding. The Plasma server is
2106 also still responsible for the enforcement of the policy on
2107 message access.
2109 When used as an Obligation:
2111 The ObligationId attribute is
2112 "urn:ietf:params:xml:schema:plasma:1.0:obligation:lockbox-
2113 required".
2115 There is no data value when the client is required to create lock
2116 boxes for every recipient, i.e. early binding.
2118 The data value is an X509 certificate when the Plasma client is
2119 required to create a lock box for the Plasma server. The
2120 certificate provided MUST have the Plasma CEK Transport EKU
2121 specified.
2123 11. Certificate Profiles
2125 We need to put in text to express the following items:
2127 DNS or IPAddr subject alt name to be present
2129 Have one of four EKUs
2131 Plasma Token EKU - Signals that it can sign and/or encrypt a
2132 plasma object
2134 Plasma Secure Session - Use for the TLS session
2136 Plasma CEK Transport - Used for transporting the CEK to the
2137 server in high security situations
2139 MUST NOT have the anyPolicy EKU set
2141 12. Message Transmission
2143 Plasma messages are sent over a TCP connection using port TBD1 on the
2144 server. The client first setups up TLS on the connection, then sends
2145 the UTF8 encoded XML message over the TLS connection as an atomic
2146 message. The XML MUST be encoded as UTF8, however the Byte Order
2147 Mark (BOM) is sent. The response comes back on the same connection.
2148 The client is responsible for closing the TLS session and the TCP
2149 connection when either no more messages are to be sent to the server
2150 or a final indeterminate state has been reached.
2152 If a Plasma server receives an XML request which is not well formed
2153 XML, the server if free to close the connection without first sending
2154 an error reply.
2156 The Plasma server SHOULD support TLS resumption [RFC5077].
2158 Plasma clients and server MUST support TLS 1.1 [RFC4346] and above.
2159 Implementations SHOULD NOT allow for the use of TLS 1.0 or SSL.
2161 13. Plasma URI Scheme
2163 13.1. Plasma URI Schema Syntax
2165 The scheme name for is "plasma".
2167 The syntax for the plasma URI Schema is:
2169 URI = "plasma" ":" "//" authority path-empty
2171 Using the ABNF defined in [RFC3986]. When the port component is
2172 absent, then the value of TBD1 will be used. The userinfo portion of
2173 the authority MUST be absent.
2175 13.2. Definition of Operations
2177 This schema is defined to provide the location of a Plasma server.
2178 The sole operation is to establish a connection to the Plasma server
2179 over which the protocol defined in this document is to run.
2181 14. Security Considerations
2183 To be supplied after we have a better idea of what the document looks
2184 like.
2186 14.1. Plasma URI Schema Considerations
2188 TBD
2190 15. IANA Considerations
2192 We define the following name spaces
2194 New name space for the plasma documents urn:ietf:params:xml:ns:plasma
2196 15.1. Plasma Action Values
2198 A new registry is established for Plasma server action identifiers
2199 using the tag "actions". The full urn for the registry is
2200 "urn:ietf:params:xml:ns:plasma:actions". This registry operates
2201 under a specification required policy. All entries in this registry
2202 require the following elements:
2204 o A string in camel case which identifies the action to be
2205 performed.
2207 o An optional XML data structure used to carry the control data for
2208 the action.
2210 o An optional XML data structure used to return the result of the
2211 action from the server.
2213 o A document reference describing the steps to be taken by the
2214 server.
2216 The registry will be initially populated with the following:
2218 +-----------------+-----------------+------------------+
2219 | Action Id | Input Structure | Output Structure |
2220 +-----------------+-----------------+------------------+
2221 | GetRoleTokens | none | eps:RoleToken |
2222 | | | |
2223 | GetSendCMSToken | eps:GetCMSToken | eps:CMSLockBox |
2224 | | | |
2225 | ParseCMSToken | eps:CMSLockBox | eps:CMSKey |
2226 | | | |
2227 | GetReplyToken | none | eps:RoleToken |
2228 +-----------------+-----------------+------------------+
2230 When these actions are placed in an xacml:Request,
2232 o the Category is "urn:oasis:names:tc:xacml:3.0:attribute-
2233 category:action",
2235 o the AttributeId is "urn:ietf:params:xml:ns:plasma:actions",
2237 o the DataType is "http://www.w3.org/2001/XMLSchema#string"
2239 15.2. non
2241 Define a new data name space urn:ietf:params:xml:ns:plasma:data
2243 CMSToken
2245 ChannelBinding
2247 SMIME-Capabilities
2249 Define a new name space for status codes at
2250 urn:ietf:params:xml:ns:plasma:status. The initial set of values is
2252 authentication-error This identifier indicates that the
2253 authentication methods failed to successfully complete.
2255 Define a new name space for obligations. The same namespace will be
2256 used both for obligations and for advice and the values may appear in
2257 either section.
2259 signature-required This identifier indicates that that the encrypted
2260 body must contain a signature element. The data value of this
2261 type shall be "http://www.w3.org/2001/XMLSchema#hexBinary" and the
2262 data structure shall consist of a DER encoded CMSCapabilities
2263 structure [RFC5751] with the list of permitted signature
2264 algorithms. If there are no restrictions on the algorithms or the
2265 restriction is implicit, then the data value MAY be omitted.
2267 encryption-algorithms see above
2269 ambigous-identity The identity of the client is either not stated in
2270 a form the Plasma server understands, or there are multiple
2271 identities in the authentication data. To remedy this situation,
2272 the client includes an explicit identity in the xacml:Reqeust
2273 element.
2275 We define a schema in appendix A at
2276 urn:ietf:params:xml:schema:plasma:1.0:RFCTBD
2278 Define a new Status Code for use in the Status URI field.
2280 urn:ietf:params:xml:ns:plasma:status:gss-api-response - This
2281 status is returned only with Indefinite responses. Indicates a
2282 GSS-API response object was returned in the GSSAPIResponse token
2283 type. Will return until authentication has been completed.
2285 15.3. Port Assignment
2287 We request that IANA assign a new port for the use of this protocol.
2289 Service name: plasma
2291 Port Number: TBD1
2293 Transport Protocol: TCP
2295 Description: Plasma Service Protocol
2297 Reference: This document
2299 Assignee: iesg@ietf.org
2301 Contact: chair@ietf.org
2303 Notes: The protocol requires that TLS be used to communicate over
2304 this port. There is no provision for unsecure messages to be sent to
2305 this protocol.
2307 16. Open Issues
2309 List of Open Issues:
2311 o JLS: Should we require that any SignatureProperty be present for
2312 XML Signature elements?
2314 o JLS: Need to figure out an appropriate way to reference the
2315 assertion from a dig sig element. Could use a special version of
2316 RetrievalMethod with a transform, but that does not seem correct.
2317 May need to define a new KeyInfo structure to do it.
2319 o JLS: Should X.509 certificates and attribute certificates be fully
2320 specified as an authentication method?
2322 o JLS: Should a SignerInfo attribute be placed under the access-
2323 subject Category for a senders version and under Environment for a
2324 machine version? Currently both are under Data
2326 o JLS: Need an obligation to say that CEK must be encrypted. Do we
2327 also need to have recipient info structures encrypted?
2329 17. References
2331 17.1. Normative References
2333 [ABFAB] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
2334 Extensible Authentication Protocol", Work In Progress
2335 draft-ietf-abfab-gss-eap-04, Oct 2011.
2337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
2338 Requirement Levels", BCP 14, RFC 2119, March 1997.
2340 [I-D.schaad-plasma-cms]
2341 Schaad, J., "Email Policy Service ASN.1 Processing", Work
2342 In Progress draft-schaad-plamsa-cms, Jan 2011.
2344 [XML-Signature]
2345 Roessler, T., Reagle, J., Hirsch, F., Eastlake, D., and D.
2346 Solo, "XML Signature Syntax and Processing (Second
2347 Edition)", World Wide Web Consortium Recommendation REC-
2348 xmldsig-core-20080610, June 2008,
2349 .
2351 [XML-C14N11]
2352 Boyer, J. and G. Marcy, "Canonical XML Version 1.1", World
2353 Wide Web Consortium Recommendation REC-xml-
2354 c14n11-20080502, May 2008,
2355 .
2357 [WS-TRUST]
2358 Lawrence, K., Kaler, C., Nadalin, A., Goodner, M., Gudgin,
2359 M., Barbir, A., and H. Granqvist, "WS-Trust 1.4", OASIS
2360 Standard ws-trust-200902, March 2007,
2361 .
2364 [XACML] Rissanen, E., Ed., "eXtensible Access Control Markup
2365 Language (XACML) Version 3.0", OASIS Standard
2366 xacml-201008, August 2010, .
2369 [I-D.freeman-plasma-requirements]
2370 Freeman, T., Schaad, J., and P. Patterson, "Requirements
2371 for Message Access Control", Work in progress draft-
2372 freeman-message-access-control, October 2011.
2374 [OASIS-CORE]
2375 Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E.
2376 Maler, Ed., "Assertions and Protocols for the OASIS
2377 Security Assertion Markup Language (SAML) V2.0", OASIS
2378 Standard saml-core-2.0-os, March 2005.
2380 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport
2381 Layer Security (TLS)", RFC 5705, March 2010.
2383 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
2384 Mail Extensions (S/MIME) Version 3.2 Message
2385 Specification", RFC 5751, January 2010.
2387 [RFC7055] Hartman, S. and J. Howlett, "A GSS-API Mechanism for the
2388 Extensible Authentication Protocol", RFC 7055, December
2389 2013.
2391 17.2. Informative References
2393 [RFC5554] Williams, N., "Clarifications and Extensions to the
2394 Generic Security Service Application Program Interface
2395 (GSS-API) for the Use of Channel Bindings", RFC 5554, May
2396 2009.
2398 [RFC2743] Linn, J., "Generic Security Service Application Program
2399 Interface Version 2, Update 1", RFC 2743, January 2000.
2401 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
2402 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
2404 [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
2405 Record Syntax (ERS)", RFC 4998, August 2007.
2407 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
2408 "Transport Layer Security (TLS) Session Resumption without
2409 Server-Side State", RFC 5077, January 2008.
2411 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
2412 Resource Identifier (URI): Generic Syntax", STD 66, RFC
2413 3986, January 2005.
2415 [SAML-XACML]
2416 Anderson, A., Ed. and H. Lockhart, Ed., "SAML 2.0 profile
2417 of XACML v2.0", OASIS Standard access_control-xacml-2.0
2418 -saml-profile-spec-os.pdf, February 2005.
2420 [PlasmaBasicPolicy]
2421 Anon, A., "IETF Defined Plasma Policies", February 2005.
2423 [SOAP11] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
2424 Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer,
2425 "Simple Object Access Protocol (SOAP) 1.1", W3C NOTE NOTE-
2426 SOAP-20000508, May 2000.
2428 [SOAP12] Lafon, Y., Gudgin, M., Hadley, M., Moreau, J., Mendelsohn,
2429 N., Karmarkar, A., and H. Nielsen, "SOAP Version 1.2 Part
2430 1: Messaging Framework (Second Edition)", World Wide Web
2431 Consortium Recommendation REC-soap12-part1-20070427, April
2432 2007,
2433 .
2435 [I-D.ietf-emu-eap-tunnel-method]
2436 Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
2437 "Tunnel EAP Method (TEAP) Version 1", draft-ietf-emu-eap-
2438 tunnel-method-09 (work in progress), September 2013.
2440 [RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible
2441 Authentication Protocol (EAP) Mutual Cryptographic
2442 Binding", RFC 7029, October 2013.
2444 [RFC5891] Klensin, J., "Internationalized Domain Names in
2445 Applications (IDNA): Protocol", RFC 5891, August 2010.
2447 [W3C.WD-xmlenc-core1-20101130]
2448 Roessler, T., Reagle, J., Hirsch, F., and D. Eastlake,
2449 "XML Encryption Syntax and Processing Version 1.1", World
2450 Wide Web Consortium LastCall WD-xmlenc-core1-20101130,
2451 November 2010,
2452 .
2454 Appendix A. XML Schema
2456 This appendix represents the entirety of the XML Schema for Plasma
2457 documents.
2459
2460
2461
2462
2463
2464 The PlasmaRequest element is one of two top level elements defined by this XSD schema.
2465 The PlasmaRequest element is sent from the client to the server in order to
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2650 Appendix B. Example: Get Roles Request
2652 This section provides an example of a request message to obtain the
2653 set of roles for an individual named 'bart@simpsons.com'. The
2654 authentication provided in this is a SAML statement included in the
2655 SAML_Collection element.
2657
2658
2663
2664 123456
2665
2666
2667
2668
2669
2670 GetRoleTokens
2671
2672
2673
2674
2675 ABCDEFGH
2676
2677
2678
2679
2681 Appendix C. Example: Get Roles Response
2683 This section provides an example response to a successful request for
2684 a role sets.
2686
2687
2688
2689
2690 Permit
2691
2692
2693
2694
2695 Role #1
2696 plasma://localhost:8080
2697
2698
2699 Schaad Policy 1
2700
2701
2702
2703
2704 MCgMCzxDb250ZXh0IC8+AgEBMBYYFDEvMTAvMjAxMyA0OjIyOjAwIEFN
2706
2707
2708 2013-01-10T04:22:00
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718 Plasma Basic Policy
2719 plasma://localhost:8080
2720
2721
2722 Plasma Basic Policy
2723
2724
2725 Schaad Policy 1
2726
2727
2728
2729
2730 MCgMCzxDb250ZXh0IC8+AgEBMBYYFDEvMTAvMjAxMyA0OjIyOjAwIEFN
2731
2732
2733 2013-01-10T04:22:00
2734
2735
2736
2737
2738
2740 In this example a role is returned that has two different policies
2741 that can be used by that role. Along with the role token, a binary
2742 secret is returned that is to be used in proving that the same entity
2743 is returning to use the roles.
2745 Appendix D. Example: Get CMS Token Request
2747 This section contains an example of a request from a client to a
2748 server for a CMS message token to be issued. The authentication for
2749 the request is provided by using a WS-Trust token previously issued
2750 as part of a role request/response dialog. The request contains the
2751 following elements:
2753 o A complex rule set is requested where permission to is to be
2754 granted to anyone who meets either of the two policies given.
2756 o A specific recipient info structure is provided for a subject
2757 who's name is 'lisa@simpsons.com'. The details of the recipient
2758 info structure are skipped but it would be any encoding of a
2759 RecipientInfo structure from CMS.
2761 o A generic key encryption key is provided for any other subject who
2762 meets the policies specified.
2764
2765
2766
2767
2768 MCgMCzxDb250ZXh0IC8+AgEBMBYYFDEvMTAvMjAxMyAxOjI3OjEyIEFN
2769
2770
2771
2772
2773
2774 GetCMSToken
2775
2776
2777
2778
2779 tls-unique
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791 AQIDBAUGBwgJCg==
2792
2793 0102030405060708090A
2794
2795
2796
2797
2798
2799
2800 Appendix E. Example: Get CMS Token Response
2802 This section contains an example of a response from a server to a
2803 client for a CMS message token to be issued. The token is returned
2804 in the CMSToken element. This element would then be placed into the
2805 CMS message being created by the client.
2807
2808
2809
2810
2811 Permit
2812
2813
2814
2815 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=
2816
2817
2819 Appendix F. Example: Get CMS Key Request
2821
2822
2823
2824
2825 MCgMCzxDb250ZXh0IC8+AgEBMBYYFDEvMTAvMjAxMyAxOjI3OjEyIEFN
2826
2827
2828
2829
2830
2831 GetCMSKey
2832
2833
2834
2835
2836 tls-unique
2837
2838
2839
2840
2841
2842 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=
2843
2844
2845
2846
2847
2848 Appendix G. Example: Get CMS KeyResponse
2850
2851
2852
2853
2854 Permit
2855
2856
2857
2858
2859 Schaad Policy 1
2860 AQIDBAUGBwgJCg==
2861
2862
2863
2865 Appendix H. Enabling the MultiRequests option
2867 NOTE: RFC Editor please remove this section prior to publication.
2868 This section exists as a note to the author to make sure that it can
2869 be done. It will be published as a separate document if desired.
2871 One of the issues in doing multiple requests in a single message is
2872 the issue of correlation between the request and the results. We
2873 have make this issue even worse by the fact that we are return
2874 results that are not input attributes for the decision and that we
2875 are not returning as attributes of the decision.
2877 The best way to deal with this is by putting tags into the request
2878 and reflect them in the return values for the response. The only
2879 place that this does not work is for the GSS-API response token as
2880 this element would normally be part of the response of multiple
2881 requests. You want to finish that authentication step before issuing
2882 final decisions if the input is needed as part of that decision.
2884 With this in mind what we do is the following:
2886 o Define a new data attribute for plasma as plasma-request-id. The
2887 category for it is urn:ietf:params:xml:ns:plasma:data. The type
2888 will be a string.
2890 o When the new attribute is used, then the return attribute flag
2891 MUST be set on the attribute.
2893 o There MUST be one entity of the new attribute, with a unique
2894 value, for each of the requests in the MultiRequest element.
2896 o Exactly one of the new attributes MUST be referenced in each
2897 request in the MultiRequest element.
2899 o The server copies the value of the attribute into the ***
2900 attribute of the returned token.
2902 We could probably relax the restrictions if we know that the token
2903 can only be returned by one request, however using the token to
2904 correlate the request and the decision is still probably desired so
2905 that those values can be correlated.
2907 Author's Address
2909 Jim Schaad
2910 Soaring Hawk Consulting
2912 Email: ietf@augustcellars.com