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