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