idnits 2.17.1 draft-freeman-plasma-requirements-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 346 has weird spacing: '...tifiers as th...' == Line 351 has weird spacing: '...ronment e.g. ...' == Line 363 has weird spacing: '...ributes e.g....' == Line 385 has weird spacing: '...rrently funct...' == Line 406 has weird spacing: '...ack end attri...' == (27 more instances...) -- The document date (February 25, 2013) is 4078 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC5652' on line 2415 looks like a reference -- Missing reference section? 'RFC2634' on line 2408 looks like a reference -- Missing reference section? 'SAML-overview' on line 206 looks like a reference -- Missing reference section? 'XACML-core' on line 2443 looks like a reference -- Missing reference section? 'RFC5751' on line 2420 looks like a reference -- Missing reference section? 'RFC5750' on line 2417 looks like a reference -- Missing reference section? 'RFC3114' on line 2436 looks like a reference -- Missing reference section? 'SAML-core' on line 2423 looks like a reference -- Missing reference section? 'SAML-QUERY' on line 636 looks like a reference -- Missing reference section? 'SP800-63-1' on line 713 looks like a reference -- Missing reference section? 'I-D.ietf-abfab-arch' on line 940 looks like a reference -- Missing reference section? 'RFC3198' on line 2410 looks like a reference -- Missing reference section? 'RFC5408' on line 2438 looks like a reference -- Missing reference section? 'RFC2119' on line 2406 looks like a reference -- Missing reference section? 'RFC5280' on line 2412 looks like a reference -- Missing reference section? 'SAML-over' on line 2441 looks like a reference Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Freeman 3 Internet-Draft Microsoft Corp. 4 Intended status: Informational J. Schaad 5 Expires: August 29, 2013 Soaring Hawk Consulting 6 P. Patterson 7 Carillon Information Security Inc 8 February 25, 2013 10 Requirements for Message Access Control 11 draft-freeman-plasma-requirements-04 13 Abstract 15 There are many situations where organizations want to protect 16 information with robust access control, either for implementation of 17 intellectual property right protections, enforcement of contractual 18 confidentiality agreements or because of legal regulations. The 19 Enhanced Security Services (ESS) for S/MIME defines an access control 20 mechanism for email which is enforced by the recipient's client after 21 decryption of the message. The ESS mechanism therefore is dependent 22 on the correct access policy configuration of every recipient's 23 client. This mechanism also provides full access to the data to all 24 recipients prior to the access control check, this is considered to 25 be inadequate due to the difficulty in demonstrating policy 26 compliance. 28 This document lays out the deficiencies of the current ESS security 29 label, and presents requirements for a new model for doing/providing 30 access control to messages where the access check is performed prior 31 to message content decryption. This new model also does not require 32 policy configuration on the client to simplify deployment and 33 compliance verification. 35 The proposed model additionally provides a method where non-X.509 36 certificate credentials can be used for encryption/decryption of 37 S/MIME messages. 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on January 20, 2012. 99 56 Copyright Notice 58 Copyright (c) 2013 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1 Data Access Control . . . . . . . . . . . . . . . . . . . . 4 75 1.2 Encrypted E-Mail Using Web-based Credentials . . . . . . . 5 76 1.3 Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . 6 77 1.4 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 2.1. ESS Security Labels . . . . . . . . . . . . . . . . . . . 11 80 2.2. Access Control and the Web . . . . . . . . . . . . . . . . 13 81 2.3. Information Asset Protection . . . . . . . . . . . . . . . 15 82 2.4. Authentication Assurance Frameworks . . . . . . . . . . . 16 83 2.5 Electronic Signatures: Authentication vs. Authorization . . 16 84 3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . . 18 85 3.1 Consumer to Consumer Secure Email . . . . . . . . . . . . . 18 86 3.2. Business to Consumer Secure Email . . . . . . . . . . . . 19 87 3.3 Business to Business Ad-Hoc Email . . . . . . . . . . . . . 22 88 3.4 Business to Business Regulated Email . . . . . . . . . . . 23 89 3.5 Delegation of Access to Email . . . . . . . . . . . . . . . 27 90 3.6 Regulated Industry Email . . . . . . . . . . . . . . . . . . 28 91 3.7 Email Compliance Verification . . . . . . . . . . . . . . . 29 92 3.8 Email Pipeline Inspection . . . . . . . . . . . . . . . . . 30 93 3.9 Distribution List Expansion . . . . . . . . . . . . . . . . 31 94 3.10 Scalable Decision Making . . . . . . . . . . . . . . . . . 32 95 3.11 Related scenarios . . . . . . . . . . . . . . . . . . . . 33 96 4. Plasma Data Centric Security Model . . . . . . . . . . . . . . 37 97 4.1 Plasma Client Server Key Exchange Level of Assurance . . . . 44 98 4.2 Policy Data Binding . . . . . . . . . . . . . . . . . . . . 44 99 4.3 Content Creation Workflow . . . . . . . . . . . . . . . . . 46 100 4.4 Content Consumption Workflow . . . . . . . . . . . . . . . . 47 101 4.5 Plasma Proxy Servers . . . . . . . . . . . . . . . . . . . . 47 102 4.6 Policy Types . . . . . . . . . . . . . . . . . . . . . . . . 49 103 5. Message Protection Requirements . . . . . . . . . . . . . . . 50 104 5.1. General Requirements . . . . . . . . . . . . . . . . . . . 50 105 5.2. Basic Policy Requirements . . . . . . . . . . . . . . . . 52 106 5.3. Advanced Policy Requirements . . . . . . . . . . . . . . . 53 107 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55 108 7. Security Considerations . . . . . . . . . . . . . . . . . . . 56 109 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . 57 110 Appendix A. References . . . . . . . . . . . . . . . . . . . . . 58 111 A.1. Normative References . . . . . . . . . . . . . . . . . . . 58 112 A.2. Informative References . . . . . . . . . . . . . . . . . . 58 113 Appendix B Authors' Addresses . . . . . . . . . . . . . . . . . . 59 114 Appendix C Document Change History . . . . . . . . . . . . . . . . 60 116 1 Introduction 118 The S/MIME (Secure/Multipurpose Internet Mail Extensions) standard 119 [RFC5652] today provides digital signatures (for message integrity 120 and data origination) and encryption (for data confidentiality). The 121 Enhanced Security Services (ESS) for S/MIME [RFC2634] provides for 122 additional services including security labels (eSSSecurityLabel) 123 which represent the access control policy. The label is a signed 124 attribute in the signed data block of a message. The recipient of 125 the message is then responsible for checking that the recipient has a 126 legitimate right to see the message based on the label. This type of 127 security labeling is similar to that of stamping "Top Secret" on the 128 cover of a document. It relies on the reader to not open and read 129 the document when discovered. 131 The Cryptographic Message Syntax (CMS) [RFC5652] allows for a variety 132 of different types of lock boxes to be applied to an encrypted 133 message. This allows for a variety of different type of security 134 mechanisms to be used by the sender, and the recipient to process the 135 message. However the S/MIME standard is currently solely based on 136 X.509 certificates. This means anyone without an X.509 certificate is 137 unable to leverage the S/MIME protocol for securing Email. The vast 138 majority of users on the Internet have other forms of credentials 139 (passwords, one time passwords, GPG/PGP keys etc.). 141 1.1 Data Access Control 143 There are many situations where organizations want to include 144 information which is subject to regulatory or other complex access 145 control policy in Email. Regulated information requires some form of 146 robust access control to protect the confidentiality of the 147 information. While ESS for S/MIME [RFC2634] defines an access 148 control mechanism for S/MIME (eSSSecurityLabel), it is an extremely 149 weak form of access control as the recipient is responsible for the 150 enforcement and is given access to the data even if they fail to meet 151 the access criteria as defined by the label. 153 An Access Control Policy defines a set of criteria and evaluation 154 logic that must be satisfied in order to grant access to the 155 information. These criteria are defined in terms of attributes about 156 the subject, their device or environment, their intended action on or 157 use of the information or about a resource . Examples of the types 158 of attributes would include what roles the subject is assigned to 159 (Role Based Access Control) or one or more attributes about the 160 subject (Attribute Based Access Control). While an ESS Security 161 Label provides a standardized representation of an access policy 162 identity, it does not define any methods of obtaining the necessary 163 attributes or policy description in order to enforce the policy. 165 Standards now exist that enable the transport of subject attributes 166 [SAML-overview]. Adoption of these subject attribute protocols would 167 allow a rich set of access control policies to be supported by S/MIME 168 in line with other applications. 170 An ESS Security label is a signed attribute of a SignedData object 171 which indicates the access control policy for the message. The fact 172 that this is a signed attribute protects the integrity of the label 173 and provides a tamper evident binding of the label to the message but 174 does not protect the confidentiality of the body. At the point where 175 you learn the access control policy to enforce on the data you 176 already have access to the data. While the signature provides a 177 tamper evident integrity for the label over the clear text, it is not 178 tamper proof because it is susceptible to unauthorized removal if you 179 only have a SignedData message, i.e. any Message Transport Agent 180 (MTA) in the path can remove a signature layer of a SignedData 181 message therefore altering the access control data. Encrypting the 182 signed message protects the confidentiality of the data and protects 183 the SignedData from tampering from users unable to decrypt the 184 message. However encrypting the message means that no intermediate 185 agent can enforce the label policy and it does not protect the label 186 from any entity who has the ability to decrypt the message. 188 From a regulatory enforcement perspective this is an extremely weak 189 form of access control because cryptographic access to the data is 190 given before the access check. The correct enforcement of the access 191 check is dependent on the configuration of every recipient's Email 192 client. Since the cryptographic access is granted before the access 193 checks, there is no cryptographic impediment for a recipient who is 194 able to decrypt the data but unauthorized under the policy to access 195 the data. A stronger enforcement model is needed for regulatory 196 control for Email where cryptographic access is only granted after 197 the access check is successful. 199 1.2 Encrypted E-Mail Using Web-based Credentials 201 There are many users on the Internet today who have forms of 202 authentication credential other than X.509 certificates. S/MIME today 203 can only use X.509 certificates to protect the confidentiality or the 204 data origination authentication of the messages. This means the many 205 users without X.509 certificates cannot use S/MIME. Standard based 206 services (e.g. [SAML-overview])are now available which abstract the 207 specifics of an authentication technology used to identify a subject 208 from the application itself (S/MIME in this case). Adoption of this 209 abstraction model would enable a broader set of authentication 210 technologies to be able to use S/MIME to secure Email for 211 confidentiality or data origination authentication. It also allows 212 for new authentication technology to be deployed without impacting 213 the core S/MIME protocol. 215 1.3 Vocabulary 217 Some of these terms are the same as used by RFC3198. While the Plasma 218 actors are fundamentally the same as rfc3198, there are some minor 219 differences in the responsibilities of each actor with models such as 220 XACML[XACML-core]. 222 Attribute Based Where the policy is specified by the set 223 Access Control (ABAC) of attributes, their values and and any 224 relationship between attributes required to 225 authorize an action on a resource. These 226 attributes may be provided by the subject as 227 part of the decision request (Front End 228 Attribute Exchange) or discovered by the policy 229 decision service itself (Back End Attribute 230 Exchange). The policy for example may require 231 attributes about the subject, their device or 232 environment, a resource or the intended use of 233 the information. 235 Back End Attribute When subject attributes are directly sent 236 Exchange (BEE) from the attribute issuer to the PDEP. 238 Cipher text Plain text which has been processed by an 239 encryption algorithm to render it unreadable by 240 a program of human without the appropriate 241 cryptographic key. 242 Confidential A message has been protected to a known level 243 of confidence so that the contents are not 244 decipherable by unauthorized users. 246 Content Encryption Key A key used to encrypt protected end user data. 247 (See Key Encryption Key) 249 Cryptographic Lock Box A per recipient data structure which holds a 250 content encryption key encrypted for a specific 251 user. CMS implements lock boxes as 252 RecipientInfo structures. 254 Data Origination Enables the recipient to verify that data or 255 Authentication messages have not been tampered with in transit 256 and that the originator is the expected sender. 258 Decision Requester (DR) The service responsible for making policy 259 decision requests to the PDEP. In this model 260 the policy decision is enforced by the PDEP by 261 its control of cryptographic keys. The DR 262 enforces any obligations the PDEP may require 263 such as signing or encryption of the data, 264 generating audit events etc. An DR is distinct 265 from a Policy Enforcement Point in other models 266 such as XACML in that an DR is not by default 267 trusted with the clear text data. Policy 268 enforcement is performed by the PDEP. An DR may 269 establish trust by presentation of attributes 270 about itself and its environment to show it is 271 trustworthy. 273 Early Binding The concept of creating the cryptographic lock 274 box for a recipient at the time the message is 275 sent. (See to Late Binding). 277 Front End Attribute When subject attributes are relayed from the 278 Exchange (FEE) attribute issuer to the PDEP party by the 279 plasma client. 281 Integrity Protected A recipient of a message can determine to a 282 known level of confidence that a message has 283 not been modified between the time that it was 284 created and it was received by the recipient. 286 Key Encryption Key A key used to encrypt a cryptographic key, 287 (KEK) often a CEK. (See Content Encryption Key) 289 Late Binding The concept of creating the cryptographic lock 290 box for a recipient when the recipient attempts 291 to decrypt the message. Late binding has a 292 potential downside because the sender cannot 293 know what symmetric algorithms the recipient 294 supports which can lead to interoperability 295 issues. (See Early Binding) 297 Mail Transfer Agent A program that transfers email from one 298 (MTA) computer to another. An MTA implements both the 299 sending and receiving of email. 301 Mail User Agent A program or service used to manage a user's 302 (MUA) email. The MUA may be a program run on the 303 users computer or a Web service accessed via 304 the users browser. 306 Orthonym The correct name of a place or person or thing 307 Plain text The information in a state which can be 308 directly read by a human or an appropriate 309 application. 311 Policy (1) A human readable statement which defines a 312 course of action by an individual or 313 organization. These human readable statements 314 may be in the form of legislation, regulation, 315 a legal contract or organization goals. 316 (2) Technical controls for implementation of 317 the human readable policies. Policies may 318 stipulate many forms of technical controls 319 requirements such as data protection, access 320 control, data integrity, data origination, data 321 retention, etc. 323 Policy Administration The system entity that creates, maintains and 324 Point (PAP) publishes policies or policy collections. The 325 policies define the rules, their conditions and 326 actions associated with the policy. 328 Policy Collection A collection of one or more policies which is 329 associated with a role.. The policy collection 330 may also defines the logical relationship 331 between the policies. 333 Policy Decision and The system entity that evaluates the policy 334 Enforcement Point (PDEP)criteria published by a PAP, using attributes 335 supplied by a PIP to render decisions from 336 request made by DRs. 338 Policy Identifier The tag that is used to identify a policy. For 339 the purposes of our document we are focusing on 340 two different types of policy identifiers. 341 Object Identifiers (OIDs) are what are 342 currently used in many security policy systems 343 and are the only method of policy 344 identification supported by ESS security 345 labels. Additionally we will support URIs as 346 policy identifiers as they provide a more user 347 friendly method of uniquely identify a policy 348 and allow discovery of the policy. 350 Policy Information A service with issues assertions about subjects 351 Point (PIP) or the subject's environment e.g. a SAML 352 Security Token Service. This model supports 353 both front end and back end exchange of 354 assertions between the PIP and the PDEP. 356 Attributes can be distributed directly between 357 the PIP and the PDEP (Backbend Attribute 358 Exchange;BAE). Alternatively attributes may be 359 distributed via the DR (Front End Attribute 360 Exchange; FAE) There are two types of PIP based 361 on the types of attribute the PIP would assert 362 about the subject. A Identity Provider (IdP) 363 PIP will issue authentication attributes e.g. 364 information about how and when the subject 365 authenticated to the IdP. An IdP may also issue 366 attributes about the subject themselves e.g. 367 their full name, age or citizenship. An 368 attribute provider (AtP)PIP only issues 369 attributes about the subject or the subject's 370 environment. 372 Policy Label The data structure which holds one or more 373 policy identifiers and their logical 374 relationship. 376 Pseudonym A name that a person or group assumes for a 377 particular purpose, which differs from their 378 original or true name 380 Role An abstract principal which has a series of 381 authorizations assigned to it. Users as 382 assigned to roles to perform the duties of the 383 role. Users typically select a role to perform 384 a function to disambiguate which role they are 385 currently functioning as. A role is distinct 386 from a group because a group is a collection of 387 subjects which has no intrinsic authorizations. 389 Role Based Access Access control based on the assignment of 390 Control (RBAC) a role. Subjects are then allowed to assume 391 one or more roles based on their job needs. 393 We additional make use of the following terms: 395 Attribute The act of a client requesting and obtaining a 396 Request/Issuance set of attributes for a subject. The issuance 397 of attributes will itself be controlled by 398 policy and thus recursively embeds this same 399 picture in that process. For simplicity we use 400 SAML as the format for both requesting and 401 receiving attributes and would suggest the use 402 of the SAML 2.0 Assertion Query and Request 403 Protocol as one method for requesting the 404 necessary attributes. The attributes can be 405 requested either by the AR (front end attribute 406 exchange) or the PDEP (back end attribute 407 exchange). 409 Content Protection The protocol to be run by the DR to get the set 410 Request/Response of decisions and information required to 411 successfully create and encode a data block 412 with appropriate labeling. This protocol is 413 part of the work to be defined by this group. 415 Content Consumption The protocol to be run by the DR to obtain the 416 Request/Response permissions and information needed to decode 417 and access a data block with appropriate 418 labeling. This protocol is part of the work to 419 be defined by this group. 421 Content Distribution Can be any of a number of methods by which the 422 content is transmitted from the Content Creator 423 to the Content Consumer. These methods 424 include, but are limited to: Email, FTP, XMPP, 425 HTTP and SneakerNet. 427 1.4 Keywords 429 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 430 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 431 document are to be interpreted as described in RFC 2119. 433 2 Background 435 The S/MIME standard [RFC5751] provides a method to send and receive 436 secure MIME messages. While CMS allows for other types of security 437 credentials to be used, S/MIME exclusively uses X.509 certificates 438 [RFC5750] for the security credentials used for signing and 439 encryption operations. S/MIME uses an early binding mechanism for 440 encryption keys where the sender needs to discover the public key for 441 each recipient of an encrypted message before it can be sent. This 442 requires the sender to maintain a cache of all potential recipient 443 certificates (e.g. in a personal address book) and/or have the 444 ability to find an acceptable certificate for every recipient from a 445 repository at message creation. This key management model has 446 limited the use of S/MIME for encryption for a variety of reasons. 447 For example: 449 o The recipient may not have an X.509 encryption certificate 450 o The sender may not have received a signed Email with the recipient 451 certificate 453 o The recipient may not have an available repository 455 o The sender may be unaware of the location of the recipient's 456 repository 458 o The recipient's repository may not be accessible to the sender 459 e.g. it's behind a firewall 461 o The sender may not implement the algorithms supported by the 462 recipient 464 o The sender may not have a valid certificate path to a trust anchor 465 for the recipients certificate 467 If one or more recipient certificates are missing, then the sender is 468 left with a stark choice: send the message unencrypted or remove the 469 recipients without certificates from the message. 471 The use of secure mailing lists has the ability to provide some 472 relief to the problem. The original sender does not need to know the 473 appropriate encryption information for all of the recipients of the 474 mailing list, just for the mailing list itself. It can thus be 475 thought of as a form of late-binding of recipient information for the 476 originating sender. However it is still early-binding encryption for 477 the mail list agent; as it needs to perform all of the gathering and 478 processing of certificate information for every recipient that the 479 agent will relay the message to. The use of a mailing list also means 480 that the originating sender has no chance to perform any sender side 481 filtering on who should receive an Email based on the recipient's 482 attributes as they do not know the full list of the recipients. 484 In many regulated environments end-to-end confidentiality between 485 sender and recipients by itself is not enough. The regulatory policy 486 requires some form of access control checks before access to the data 487 should be granted. In many inter-organization collaboration 488 scenarios it's impossible for the sender to satisfy the access checks 489 on behalf of the recipients since they don't have, and frequently 490 should not have access to, all the recipient's attributes because to 491 do so may be a breach of the recipients privacy. Indeed to release 492 the attributes to the sender may require that the sender's attributes 493 first be released to the recipient's attributes provider. It's a 494 fundamental tenet of good security practice that users should control 495 the release of data about themselves. 497 2.1. ESS Security Labels 498 Security labels are an optional security service for S/MIME defined 499 in Enhanced Security Services for S/MIME [RFC2634]. The ESS security 500 label allows classification of the sensitivity of the message 501 contents using a hierarchical taxonomy in terms of the impact of 502 unauthorized disclosure of the information [RFC3114]. The security 503 label can also indicate access control such as full time employees 504 only or US nationals only. ESS security labels are authenticated 505 attributes of a signer-info structure in a SignedData object. The 506 label when applied to signed clear text data provides the access 507 control decisions for the plain text. If applied to cipher text such 508 as the outer layer of a triple wrapped S/MIME message the label is 509 used for course grained optimization such as routing. 511 2.1.1. Problems With ESS Security Labels 513 ESS Security Labels have been found to have a number of limitations. 515 1. If the label is on the innermost content, access to the plain 516 text is provided to the recipient (in some form) independent of 517 the label evaluation as it will be processed for the purpose of 518 hash computation as part of signature validation. Depending on 519 how a triple wrapped message is processed by the recipient's CMS 520 code, the inner content may be processed for signature validation 521 even before the outer signature is validated. This would happen 522 for a stream based CMS processor which starts processing inner- 523 layers immediately rather than finishing processing of each layer 524 and caching the intermediate results. 526 2. Labels applied can be removed in transit. If a signed layer is 527 seen then it can be removed by any agent that processes the 528 message (such as a Message Transit Agent). If the label is 529 protected by an encryption layer then it can be removed by any 530 agent that has key access to the message (Encryption Mail List 531 agents or Spam Filtering software would be two such examples). 533 3. Policies are identified by Object Identifiers. This makes for a 534 small tight encoding, but it does not provide any mechanism for 535 an Email client to discover how to enforce a new access control 536 policy if the message contains a policy the client is unaware of. 537 This provides a stark choice: ignore the access control policy 538 and grant access to the message or block access to the message. 539 Object identifiers also do not provide a good display name for a 540 user so that they could manually find and download a new policy. 542 4. The current ESS standard only allows for a single policy label in 543 a message, no standardized method of composing multiple policy 544 labels together has been defined. This is adequate for course 545 grained policy binding to express a limited set of choices such 546 as with information sensitivity which typically provides a 547 hierarchy of 3-5 choices. Many data sets need to be subject to 548 multiple access control policies. For instance, a message may 549 contain information that is both propriety and export controlled. 550 Trying to represent combinations of policies via a single policy 551 label would lead to an exponential growth in the number of policy 552 labels. 554 5. ESS Labels do not provide for any auditing of who has been 555 granted accessed the message. All policy evaluation is local to 556 the recipient's machine, no centralized logging of access to the 557 message can be performed 559 6. Enforcement of the policy occurs on the recipient's machine, the 560 compliance with the policy is dependent on the state of the 561 configuration of every receiving agent. The policy is enforce by 562 whatever module is located on the user's system, and updates to 563 the policy may be eradicate. For cross cooperate systems, this 564 means that the policy provided by Company A must be installed on 565 Company B machines, or Company B must install a policy that 566 Company A will accept as being equivalent to their own policy 567 enforcement module. Additionally any time that a new version of 568 the policy module is rolled out; there will be a time lag before 569 every recipient machine will have the updated module. This makes 570 policy compliance practically impossible in anything but a small 571 closed environment. 573 7. Access to the message cannot be granted or removed after the 574 message has been sent. Therefore is a recipient has a designated 575 alternate recipient they will not be able to read the message. 576 Also if the sender subsequently learns one of the recipients was 577 in error, they cannot correct the mistake. 579 2.2. Access Control and the Web 581 A prerequisite for many web transactions is the disclosure of 582 attributes about the subject such as name, age, Email address, 583 physical location, address, credit card number, social security 584 number etc. Some attributes lend themselves to easy verification but 585 many do not. An assertion of an Email address can be verified by 586 sending an Email to the address containing a secret ephemeral 587 challenge. Subsequent demonstration of knowledge of the ephemeral 588 challenge verifies the Email address assertion. Other assertions 589 such as "this is my credit card account number" are not easily 590 verified. The fact that it is a valid credit card number can be 591 verified but not the binding to the subject attempting to use it. 592 Where a claim is not easily verified it is often combined with other 593 assertions under the assumption that knowledge of this larger data 594 set verifies all the assertions in the data set. If you know the 595 account number, billing address, etc., 'of course' you must be the 596 account holder. This is a very weak form of verification as is often 597 demonstrated by the growth of identity theft; much of this bigger 598 data set is often publicly available via social networks or easily 599 guessed e.g. the most popular professions for a parent is dead or 600 retired. Many of the assertions which are harder to verify are based 601 on government issued documents such as a birth certificates, driver's 602 license, identity card or passport. This requires an exchange of the 603 documents between the relying party and the subject. For a small 604 number of high value transactions (e.g. opening a new account) with 605 relying parties that have widespread physical presence (e.g. a bank 606 or Post Office) this is acceptable because the applicant can present 607 themselves with the required documentation in person. However,web 608 based relying parties cannot perform an in person exchange of 609 documents to verify information on government issued documents. The 610 approach taken with such relying parties is to have trusted assertion 611 providers where the assertion provider can perform an in person 612 exchange of documents with the subject then vouch for the set of 613 assertions they have verified. 615 SAML [SAML-core] defines an XML framework for describing and 616 exchanging attributes about subjects. The entity making the 617 assertions about the subject is known as the assertion provider, the 618 entity consuming the assertions is known as the relying party. The 619 well-known scenarios for using SAML are: 621 o Single Sign On across systems on different platform technology 623 o Federated Identity between business partners 625 o Web Services and other standards e.g. SOAP based protocols 627 The critical difference between SAML and pure authentication 628 protocols such as mutually authenticated TLS is that SAML is able to 629 exchange the rich and variable set of assertions which are necessary 630 for authorizing transactions. X.509 certificates can exchange a 631 limited and fixed set of identity assertions such as an x.500 632 distinguished name, Email address, Kerberos principal name, etc. 633 SAML is able to do this in addition to an extensible set of other 634 assertions about the subject such as: date of birth, business sign- 635 off limits levels, etc. SAML additionally defines a number of 636 query/response style profiles [SAML-QUERY] that allow for a relying 637 party to specify the type of attributes that are required to evaluate 638 a policy. 640 SAML also abstracts the details of the authentication protocol from 641 the relying party. The assertion provider can use a broad range of 642 authentication mechanisms such as passwords, one time passwords, 643 biometrics, X.509 certificates, etc., without impacting the relying 644 party. The assertion provider can include the details of the 645 authentication mechanism or its strength using an established 646 strength scale such as NIST SP800-63-1 [SP800-63-1]. The relying 647 party can then inspect the claims about how or how strongly the 648 subject authenticated to the identity provider to determine if it 649 complies with its access policy. Low value transactions can use 650 simple short lived assertions where possession of the assertion alone 651 is considered acceptable for the transaction risk. These are known 652 as Bearer assertions. Higher value transactions can require proof of 653 possession keys (either symmetric or asymmetric cryptographic keys) 654 where the subject demonstrates knowledge of a cryptographic secret to 655 the relying party via a HMAC or digital signature. These are defined 656 by the SAML specification as Holder of Key assertions. The subject 657 has to demonstrate possession of the key to the relying party. Holder 658 of key assertions can be either symmetric or asymmetric keys. 660 2.3. Information Asset Protection 662 Information Asset Protection (IAP) is a concept developed by the 663 Transglobal Secure Collaboration Program (TSCP), a working group 664 comprised of the major players in the western Aerospace and Defense 665 industry. The industry is highly regulated and operates in an 666 environment with many policies governing the access to information 667 assets. These policies may be motivated by the desire to protect 668 intellectual property, the confidentiality of information, or are 669 imposed by government regulators such as the US International Traffic 670 in Arms Regulations (ITAR) from the US Department of State. They 671 apply to the information assets in whatever form the asset may take 672 and are independent of the application used to create the 673 information. These policies take many forms, e.g. verification the 674 recipient has demonstrated a need to know the information because 675 they are working on a specific project, that they have passed the 676 appropriate background and nationality checks, or that they have 677 signed the appropriate non-disclosure agreement. What is needed is a 678 policy driven information centric protection where the applicable 679 policies either is manually or automatically attached to the 680 information and based on the policy the system understands what 681 access control and data protection is necessary. 683 Email is an application widely used in the Aerospace and Defense 684 industry. S/MIME is widely used today and provides sender to 685 recipient confidentiality. This protects the contents of the message 686 from discloser to unauthorized third parties e.g. while it is in 687 transit between MTA's or while at rest in a MTA message queue or 688 recipient's mailbox. However it does not impose any finer grained 689 access control such as those required by many policies. S/MIME does 690 define an extension mechanism for access control via an ESS security 691 label [RFC2634] thou this mechanism has drawbacks (see above). 693 2.4. Authentication Assurance Frameworks 695 A number of organizations have created taxonomies to define the 696 possible levels of identity assurance for electronic authentication. 697 The objective of the framework is to provide a simple abstraction the 698 details of 700 o Identity proofing and registration of subjects 702 o Tokens used by subjects for providing electronic identity 704 o The token management mechanisms 706 o Protocols used for subject to use tokens to authenticate to an 707 identity provider 709 o Protocols used by subjects to authenticate and pass attributes 710 to a relying party 712 These frameworks have been drafted by industry organizations [lib- 713 iaf][kan-iaf] and governments [SP800-63-1]. While all of these 714 frameworks may not agree on every aspect, at a macro level they do 715 exhibit many similarities. A common theme in many is the adoption of 716 a small number of levels of identity assurance, typically between 3- 717 5. A simplified description of the levels is: 719 Level 1 Negligible confidence in the asserted identity 721 Level 2 Some confidence in the asserted identity 723 Level 3 Significant confidence in the asserted identity 725 Level 4 High confidence in the asserted identity 727 The framework defines broad characteristics in the area of identity 728 proofing, credential type and management, identity provider 729 authentication and relying party authentication. 731 2.5 Electronic Signatures: Authentication vs. Authorization 733 Electronic signatures on email are used today to show data 734 origination so only authentication is required. However with 735 transactions that are legally or regulatory significant, 736 authentication alone if frequently insufficient. Policy requires 737 other factors to be considered to ensure the transaction meets policy 738 requirements. 740 The state of the system generating the signature 742 An indication of the signers intent 744 Attributes about the signer to indicate for example, job function 745 in the company, job assignments professional qualifications, 746 signing authority etc. 748 Many organizations would like email based work flows to be an option 749 for these transactions. 751 3. Use Case Scenarios 753 This section documents some email based use case scenarios the new 754 protocol aims to support. Also included are some related scenarios 755 where the same underlying theme of consistent policy enforcement 756 equally applies. 758 3.1 Consumer to Consumer Secure Email 760 One of the issues that is stopping the use of secure Email in 761 personal mail is the fact that consumers find X.509 certificates 762 difficult to obtain and then use - especially across a set of devices 763 (phone, tablet, workstation). One of the possible use cases of PLASMA 764 is to try and deal with this by removing the dependency on X.509 765 certificates. The details of the use case are therefore: Alice wants 766 to send an Email message to Bob that contains sensitive, personal 767 data so she is concerted to ensure only Bob can read it. Bob has a 768 strong credential he can use to identity himself, but is is not an 769 X.509 certificate. Alice needs to ensure the following: 771 (a) Only Bob can read the Email. 773 (b) Bob has the ability to verify the Email is from Alice. 775 (c) Bob has the ability to verify the Email message has not been 776 modified since Alice sent it. 778 The sequence of events could be as follows: 780 1. Alice composes the Email to Bob. 782 2. Alice's Email client allows here to classify the Email. Alice 783 classifies the Email using Personal Communication which is a 784 basic policy provided by her ISP. 786 3. Alice's Email client knows the protections to apply to a Personal 787 communication; it knows to encrypt and sign the message. 789 4. The protected Email is able to flow securely and seamlessly 790 through existing Email infrastructure to Bob. The data is 791 protected while in transit or at rest. 793 5. Bob receives the Email and sees that it is a secure message. Bob 794 can verify that the secure message has not been altered. Bob 795 attempts to open and decrypt the Email. If Bob is on the same 796 ISP as Alice, then the same username/password as he uses to get 797 his Email to obtain the needed keys. If Bob is on an ISP that 798 is federated with Alice's ISP then an infrastructure such as 799 SAML, OpenID, OAUTH or ABFAB could be used to validate Bob's 800 identity and allow the needed keys to be released. 802 3.2. Business to Consumer Secure Email 803 There are many examples of business to consumer secure Email 804 scenarios where the Email could potentially contain sensitive medical 805 or financial data. This would include doctor, patient; bank, account 806 holder; Medical insurance, insured person, mortgage broker, customer. 807 Two examples are presented here. 809 3.2.1 Bank Statement Email 811 In the first example, a bank (The Bank of Foo) has determined that it 812 will be using Email to distribute statements to its customers (Bob). 813 The information is confidential, so any channel of communication the 814 Bank selects must protect Bob's privacy. The bank needs to ensure 815 the following: 817 (a) Only Bob (or additional owners of the account) can read the 818 Email 820 (b) Bob authenticates with a sufficient level of identity assurance. 821 The same identity assurance authentication level used to do on- 822 line banking would be considered sufficient 824 (c) Bob can verify the statement is from his bank 826 (d) Bob can verify the statement has not been modified since his 827 bank sent it. 829 The sequence of events would be as follows: 831 1. As part of routine end of the month processing, the Bank composes 832 an Email to Bob. They includes the statement of balances and activity 833 either as an attachment or as the body of the message. 835 2. The statement mailer for the Bank of Foo has been configured to 836 use a specific policy on the Email. 838 3. The statement mailer for the Bank of Foo knows the protections to 839 apply based on the policy; it knows to encrypt and integrity-protect 840 protects the message and what level of assurance required for the the 841 recipients identity 843 4. The protected email is able to flow securely and seamlessly 844 through existing email infrastructure to Bob. the data is protected 845 while in transit or at rest. 847 5. Bob receives the email as sees it is a secure message from the 848 Bank of Foo. Bob can verify the message has not been altered as it is 849 signed by the his Bank. Bob uses the same credential as he would for 850 on-line banking to prove his identity to the email system and obtain 851 the keys necessary to decrypt the message. 853 The same process could be used for any messages sent between the bank 854 and its customer. Thus messages dealing with loan applications and 855 changes in bank policies can be sent out in the same manner, 856 potentially using slightly different policies. In some of these 857 cases it might be in the bank's interests to record in an audit trail 858 if and when the keys were handed out on some Emails. For a 859 statement, the Bank would not expect a reply to occur, however for 860 other types of messages it should be possible for Bob to reply under 861 the same level of protection. If Bob uses his on-line credentials 862 when obtaining the policy description blob sent with the message 863 there is a degree of assurance that the bank has similar to using 864 web-based messaging today that it was Bob who sent the message. 866 3.2.2 Doctor-Patient Communications 868 In the second example, let's say that Alice is a doctor and has 869 received test results for her patient Bob. This information is 870 confidential and regulated, so any channel of communication she 871 selects must protect Bob's privacy and comply with regulatory 872 requirements. Alice elects to use Email to reach Bob quickly with 873 news of the results. In this respect it is similar to the previous 874 use case; however there are some additional complications that might 875 need to be dealt with as well. Depending on who Bob is and where is 876 currently is there are additional people that may also need to be 877 automatically informed of the same information, or need to have the 878 ability to access the contents of the message. Examples of these 879 would be Bob's spouse, an individual who is making care decisions for 880 Bob (i.e. Bob's parent), and an individual in charge of dealing with 881 Bob's day-to-day health care (i.e. a charge nurse in a hospital or a 882 visiting nurse). All of these people may have the same need to know 883 as Bob. There is also the possibility that some parts of the message 884 may need to be released to some individuals but not to others. As an 885 example, the mail message could contain a prescription, that specific 886 portion of the message may need to be read by Bob's pharmacist. 887 Alice needs to ensure the following: 889 (a) Only authorized individuals can read the Email. However, the 890 definition of authorized will vary with the content of the 891 message and thus the policy applied. (General health issues will 892 certainly be treated differently than mental health issues, even 893 by a General Practitioner.) 895 (b) The Bob is required to authenticate with a identity assurance 896 level 2 or above level. 898 (c) The Bob can verify the Email is from Alice. 900 (d) The Bob can verify the Email has not been modified after Alice 901 sent it. 903 The sequence of events would be as follows: 905 1. Alice composes the Email to Bob. She includes some comments and 906 suggestions for Bob and attaches the test results. 908 2. Alice's Email client allows her to classify the Email. Alice 909 classifies the Email as a Doctor-Patient communication. (a) As a 910 side effect of classifying the Email message, the policy may 911 suggest or mandate additional individuals that the communication 912 should be addressed to. 914 3. Alice's Email client knows the protections to apply to Doctor- 915 Patient communication; it knows to encrypt and integrity-protect 916 the message. 918 4. The protected Email is able to flow securely and seamlessly 919 through existing Email infrastructure to Bob. The data is 920 protected while in transit or at rest. 922 5. Bob receives the Email as sees it is a secure message from Alice. 923 Bob can verify the message has not been altered. Bob attempts to 924 opens the Email. Bob provides a Level 2 password to retrieve 925 the necessary decryption keys. After Bob has proved his 926 identity, he is able to read the Email. 928 There are number of different places where the identity provider for 929 Bob could live. The first is at Alice's office, Bob already has a 930 face-to-face relationship with Alice and the credential could be 931 setup in her office. A second could be Bob's insurance provider. 932 Bob has a relationship with his insurance provider as does Alice, 933 thus it can serve as an trusted identity provider to healthcare 934 providers. A third location could be a federation of doctors in an 935 area, potentially with other health providers (such as hospitals and 936 convalescent centers), Bob has setup an identity with Alice, but if 937 he gets referred to Charlie by Alice for some procedures, Charlie 938 would not need to setup a new identity for Bob but instead could just 939 refer to Alice for the necessary identity proof. Many of these 940 types of situations could be dealt with by [I-D.ietf-abfab-arch]. 942 There are a number of other additional services that could be 943 provided by the policy system. One example would be that if the 944 information was time critical, if Bob does not access his message 945 within a given time period, the policy server could notify Alice of 946 this fact so that an alternate method of communication can be 947 attempted with the same information. 949 3.3 Business to Business Ad-Hoc Email 951 Early in the relationship between two companies, it is frequently 952 necessary to exchange sensitive information as a preliminary to 953 business relationship e.g. contract negotiations. This needs to 954 occur before the relationship has matured to the point that a formal 955 relationship is reflected through a specific legal agreement. 956 Business owners need the agility to interact with potential partners 957 without having to engage their respective IT staffs as a prerequisite 958 of the communication. As example, the IT staff might need to provide 959 cross certifications or federation and exposure of certificate 960 repositories. 962 As an example, Charlie works for Company Foo. He has just met Dave 963 from Company Bar to discuss the prospect of a potential new business 964 opportunity. Following the meeting, Charlie wants to send Dave some 965 sensitive information relating to the new business opportunity. When 966 Charlie sends the Email to Dave with the sensitive content, he must 967 ensure the following objectives: 969 (a) Only Dave can read the Email 971 (b) Dave is required to authenticate with a identity assurance level 972 2 or above 974 (c) The Dave can verify the Email is from Charlie 976 (d) The Dave can verify the Email has not been tampered with 978 (e) Charlie may also need to keep a record of the fact that Dave 979 accessed the message and when it was done. 981 The sequence of events Charlie would use is as follows: 983 1. Charlie composes the Email to Dave. He include some sensible 984 information relating to potential terms and conditions for the 985 new contract that Foo and Bar would sign to form a partnership 986 for the business opportunity. 988 2. Charlie's Email client allows him to classify the Email. He 989 classifies the Email as an Ad-hoc pre-contractual communication. 991 3. Charlie's client knows the protections to apply to Ad-hoc pre- 992 contractual communication; it knows to encrypt and integrity- 993 protect the message and the level of assurance required for the 994 recipients identity. 996 4. The protected Email is able to flow securely and seamlessly 997 through existing Email infrastructure to the recipients (Dave in 998 this case). The data is protected while in transit or at rest. 1000 5. Dave receives the Email as sees it is a secure message from 1001 Charlie. (Charlie requires level 2, Dave uses a password) Dave 1002 is able to prove his identity to the level of assurance 1003 requested by Charlie so is able to read the Email. The 1004 organization Dave work for has an identity service which he uses 1005 to prove his identity for Charlie's Email. Dave opens the Email. 1007 If Dave or his delegate replies to the Email from Charlie, the new 1008 message inherits the policy from the original messages so the entire 1009 message thread has the same policy. The policy also applies to 1010 messages forwarded by Dave because it contains information from 1011 Charlie and Company Foo wants consistent policy enforcement on its 1012 information. 1014 3.4 Business to Business Regulated Email 1016 As business relationship mature they often result in a formal 1017 contractual agreement to work together. Contractual agreements would 1018 define a number of work areas and deliverables. These deliverables 1019 may be subject to multiple corporate and or regulatory policies for 1020 access control, authentication and integrity. Some classes of Email 1021 may have information which is legally binding or the sender needs to 1022 demonstrate authorization to send some types of message where 1023 authority to send the message is derives from their role or function. 1024 Also many regulated environments need to be able to verify the 1025 information for a extended period - well beyond the typical lifetime 1026 of a users certificate. The set of policies applicable to an Email 1027 is potentially subject to change as the different users contribute 1028 information to the Email thread. 1030 3.4.1 Regulated Email Requiring a Confidentiality Policy 1032 Company Foo has been awarded a contract to build some equipment 1033 (Program X). The equipment is covered by export control which 1034 requires information only be released to authorized recipients under 1035 the terms of the export control licence. Company Bar is a foreign 1036 subcontractor to company Foo working on Program X. Company Foo sets 1037 up some business rules for access to program X data to ensure 1038 compliance with the export control licence requirements. Company 1039 Foo also set up separate rules to cover the confidentiality of its 1040 intellectual property contributed to Program X. Company Bar also sets 1041 up its own policies to protect the confidentiality its own 1042 intellectual property it contributes to Program X. As part of the 1043 agreement between Foo and Bar, they have agreed to mutually respect 1044 each other's policies. 1046 Confidentiality policies can change over time. It is important to be 1047 able to implement the changes without the need to update the data 1048 object itself to reflect the change as finding all instances of the 1049 data in an intrinsically impossible problem to solve. . 1051 Frank is an employee of Company Foo. He has been assigned as a 1052 design team leader on Program X and an individual contributor on 1053 Program X integration. Frank wants to send some mail as a team 1054 leader to colleagues working on Program X in both Companies Foo and 1055 Bar. 1057 Grace is an employee of Company Bar. She has also been assigned to 1058 the design team of Program X. 1060 When Frank sends the Email with Program X regulated content he must 1061 ensure compliance with the export control policies. When Frank 1062 sends a Program X email, recipient's are authorized to read the 1063 contents to ensure Company Foo remains in compliance with its 1064 export control licence. 1066 If Frank also includes Company Foo intellectual property in an 1067 email, he must also ensure recipients are authorized to read the 1068 contents. 1070 When Grace receives a Program X email, she must provide attributes 1071 about herself to prove compliance with the export control policy. 1072 If the email also contains Company Foo intellectual property, she 1073 must also provide attributes to show she is authorized to read the 1074 information under the agreement between Company Foo and Company 1075 Bar. 1077 If Grace sends an email with Company Bar intellectual property, she 1078 must ensure recipients are authorized to read the contents under 1079 the agreement between Company Bar and Company Foo. 1081 When Frank sends a Program X Email he must ensure the following 1082 objectives: 1084 (a) Only recipients who meet the Program X policy and or Company 1085 Foo's intellectual property protection policy can read the Email 1086 (b) Recipients authenticate with a identity assurance level of level 1087 3 or above 1088 (c) Recipients present any other attributes about themselves 1089 necessary to verify compliance with the applicable policies 1090 (theirs program assignment, nationality, professional or 1091 industry certifications, etc.) 1093 (d) Recipients can verify the Email is from Frank to the level of 1094 identity assurance as defined by the message policy (i.e. level 1095 3 or above) 1097 (e) Recipients can verify the Email has not been tampered with the 1098 level of identity assurance as defined by the message policy 1100 (f) Recipients are made aware that the message is a Program X Email 1101 and the contents can only be shared with other Program X workers 1102 and/or the message contains Company Foo's intellectual property 1104 The sequence of events Frank would use is as follows: 1106 (1) Frank composes the Email and includes a Program X distribution 1107 list as a recipient. He include some information relation to 1108 Program X. Frank also includes some information which is Company 1109 Foo's Intellectual Property. 1110 (2) Frank's Email client allows him to select the Program X role. 1111 The client then allows Frank to select from a set of policies 1112 appropriate for Program X. 1113 (3) Frank selects the Program X content and Company Foo IP policies 1114 from the list of available policies. 1116 The Email client knows to encrypt the message, the key size and 1117 algorithm to use to use; the message needs to be be signed with a 1118 level 3 or above certificate. 1120 (4) Frank clinks the send Email button. The client signs the Email 1121 using his smart card and a certificate indicating the signature. 1122 The Client then encrypts the message and obtains data from a 1123 server that will enforce the access control requirements for 1124 Frank, and sends it to his Email server. 1126 The Email is able to flow securely and seamlessly through existing 1127 Email infrastructure recipients of the distribution list. Grace is on 1128 the distribution list so receives the Email from Frank. 1130 (5) Grace receives the Email, Grace's client provides the attributes 1131 necessary to comply with the policy which includes her level 3 1132 encryption certificate to the PDEP. 1133 (6) Once Grace has shown she passes the policy requirements, the 1134 PDEP releases the message CEK to Grace using her level 3 1135 encryption certificate. 1136 (7) Grace uses her smart card to open the message. She sees the 1137 message is signed by Frank and marked with both the Program X 1138 andor Company Foo IP policies 1140 If Grace replies to the Email from Frank, the new message inherits 1141 the policy from the original messages. If Grace includes some 1142 information which is Company Bar's IP she also adds her companies IP 1143 protection policy requirements to the message. 1145 Frank receives the reply from Grace. Frank is able to prove his 1146 identity to the level requested by Grace and provides the requested 1147 attributes about himself to satisfy both the Program X export 1148 control, the Company Foo IP protection policies as well as the 1149 Company Bar IP protection policies. Frank opens the Email. 1151 The policy also applies to messages forwarded by Frank and Grace 1152 because it contains information from Company Foo and Company Bar both 1153 companies wants consistent policy enforcement on its information. 1155 After some time, Company Bar fails an audit to show they are 1156 complying which all the requirements for Program X. As a result, 1157 Company Foo updates its policies for Program X to remove company Bar 1158 as an approved to access Program X data. Grace will no longer be able 1159 to access the Program X email as she can no longer satisfy the 1160 Program X policy requirements. 1162 3.4.2 Regulated Email Requiring an Integrity Policy 1164 Company Foo has been awarded a contract to build some equipment 1165 (Program X). This equipment is regulated by the National Aviation 1166 Authority (NAA) for Company Foo. The NAA requires strict procedures 1167 at a number of significant events for Program X such as in the 1168 design, and maintenance of the Project X e.g. when a design is 1169 complete and released to manufacturing. The sign of process requires 1170 personal be suitability qualified and that the documentation needs to 1171 be maintained for the service life of the project (25 years for 1172 Program X) 1174 Company Foo has instigated an email based sign off procedure to 1175 simplify sign off and reduce costs. It also has authored a policy for 1176 compliance with the NAA requirements. At the appropriate time, 1177 signoff email is sent to the designated program members. Recipient 1178 apply the NAA policy when they reply to the sign off request 1179 message. 1181 Frank is a the lead on the Program X design team. They have a design 1182 which they believe can be released to the integration team. Frank 1183 instigates the sign off process for the design. 1185 Grace is one of the sign-off design team members for Program X. She 1186 receives the sign off email. Grace responds and applies the sign-off 1187 policy to the email. The policy requires Grace to authenticate with 1188 the required level of assurance, present attributes about herself, 1189 her work effort assignments and professional qualifications to 1190 demonstrate compliance with the policy to send the message. The 1191 message is signed to indicate Grace passed the policy. 1193 When Frank sends a Program X Sign Off Email the system must ensure 1194 the following objectives: 1196 (a) Frank was authenticated to the level of identity assurance under 1197 the policy as the originator of the email 1198 (b) Frank possessed the necessary attributes as required to 1199 authorize Frank to send the sign-off email 1200 (c) The contents of the email are accurate to the level of integrity 1201 assurance required by the policy 1202 (d) Frank was fully aware and intended to send the sign off email to 1203 the level of identity assurance as required by the policy 1204 (e) The state of Franks system was known to the level of assurance 1205 required under the policy to be free from agents which might 1206 interfere with the sign off process 1207 (f) Recipients can easily confirm over the lifetime as required by 1208 the policy that Frank passed the policy without having to know 1209 specifics of what the policy entailed. 1211 The sequence of events Frank would use is as follows: 1213 (1) Frank receives the sign off request email. 1214 (2) Frank's replies to the email and completes the form data in the 1215 email so show he is approving the sign-off 1216 (3) Frank clicks the send button to send the email 1217 (4) Frank receives a sign-off confirmation dialogue before the email 1218 is sent where he has to confirm his intent is to approve the 1219 sign off of the component. 1221 Franks system submits the decision request to send the sign-off 1222 email. His system is asked to provide data about Frank, the state of 1223 Franks system, and the data being authenticated. If Frank's passes 1224 the policy, his system receives a signed statement the message passes 1225 the policy which is attached to the email and the message sent. 1227 3.5 Delegation of Access to Email 1228 There are a number of times when either others are given access to a 1229 recipients mailbox or Email is forwarded to other recipients based on 1230 recipients rules. This may be a long standing relationship such as 1231 when an assistant is given access to an executives mailbox. 1232 Alternatively it may be a temporary relationship due to short term 1233 needs e.g. to cover for a vacation. There are also organizational 1234 role mailboxes where the recipient is a role and one or more users 1235 are assigned to the role. 1237 Grace is going on vacation. While grace is away, Brian will act as a 1238 delegate for Grace. Grace configures a mailbox rule to forward 1239 Program X Email to Brian for the duration of her vacation. Brian is 1240 able to satisfy the policy requirements for the Program X Email as 1241 outlined above and is therefore able to open the protected Email sent 1242 to Grace. Frank does not need to take any actions to allow Brian to 1243 access the Email. 1245 3.6 Regulated Industry Email 1247 Some organizations work in area which are intrinsically subject to 1248 policy such as regulatory policy e.g. healthcare. In such 1249 environments the policies are often tied to the roles of the 1250 participates, the institution they are working at and the subject of 1251 the exchange. 1253 Hanna is a primary care physician working for FooBar Healthcare. She 1254 has a patient which she is referring to a specialist Ida for further 1255 investigations. Ida works at the Bar Hospital. Hanna needs to send 1256 the relevant patient notes, test results and comments to Ida. Hanna 1257 knows she needs to comply with the confidentiality regulations and 1258 needs to respect her patients consent decree for the privacy of their 1259 Healthcare information. When Hanna sends the referral message she 1260 must ensure: 1262 (a) Only recipients who meet the healthcare regulatory policy and 1263 the patients consent decree can read the Email 1264 (b) The message has the appropriate level of integrity and data 1265 origination as required by the policies 1266 (c) The recipients authenticate with an acceptable level of 1267 assurance (i.e. level 3 or above) 1268 (d) Recipients present attributes about themselves necessary to 1269 verify compliance with the policies (e.g. their professional 1270 qualification, professional registration, affiliated healthcare 1271 facility and department) 1272 (e) Recipients can verify the Email is from the sender (Hanna) to 1273 the level of assurance as defined by the message policy (i.e. 1274 level 3 or above) 1275 (f) Recipients can verify the Email has not been tampered with the 1276 level of assurance as defined by the message policy 1277 (g) Recipients are made aware that the message is a Patient referral 1278 and contains sensitive patient data. workers. 1280 The sequence of events Frank would use is as follows: 1282 (1) Hanna composes the Email and includes Ida as a recipient. She 1283 includes the patient information, test results and comments in 1284 the Email 1285 (2) Hanna's Email client allows her to select a business context 1286 which is appropriate for her work. Hanna selects a Patient 1287 Consultation context. 1288 (3) Hanna selects the Patient Referral and Patient Consent decree 1289 policies from the list of available policies. 1291 The Email client knows the protections to apply to the Email; to 1292 encrypt and integrity-protect the message, the level of assurance 1293 required for the recipient's identity and what recipient attributes 1294 are necessary to access the message. 1296 (4) Hanna clinks the send Email button. The client signs the Email 1297 using Hanna smart card. The Client then encrypted the message 1298 and sends it to his Email server. 1300 The Email is able to flow securely and seamlessly through existing 1301 Email infrastructure to recipients of the distribution list. Grace is 1302 on the distribution list so receives the Email from Frank. 1304 (5) Ida receives the Email as sees it is a secure message from 1305 Hanna. Ida's client provides the attributes necessary to comply 1306 with the policy which includes her level 3 encryption 1307 certificate to the PDEP. 1308 (6) Once Ida has shown she passes the policy requirements, the PDEP 1309 releases the message CEK to Ida using her level 3 encryption 1310 certificate. 1311 (7) Ida uses her smart card to open the message. She sees the 1312 message is marked with both the Patient Referral and Sensitive 1313 Patient Data policies 1315 3.7 Email Compliance Verification 1316 Verification is an essential part of compliance. Verification may be 1317 conducted by internal staff or external auditors. The verification 1318 need to confirm that the policy rules are actually being enforced. 1319 Auditing relies on the generation of artifacts to capture information 1320 about events. Typically this is does via some form of logging. A 1321 challenge here is that for distributed system the set of logs which 1322 completely descries the transaction are scattered across many systems 1323 so consistently of the audit setting and correlating all the audit 1324 data is problematic. Another consideration accurately capturing only 1325 the set of desired data i.e. accurately targeting the set of events 1326 that needs to be logged 1328 Jerry is the compliance officer for Company Foo. He has a procedure 1329 for ensuring compliance for Program X. The procedure defines what and 1330 when to audit access to Program X data. Jerry has tools to collect 1331 the audit data and run analysis to verify the polices are being 1332 followed. 1334 The sequence of events Jerry would use is as follows: 1336 (1) Jerry configures an audit obligation for access to Program X 1337 data. The obligation defines the set of attributes to capture 1338 when Program X data is accessed. The obligation is part of the 1339 Program X policy. PArt of the Program X policy is the set of 1340 PDEPs which can process policy decisions on Program X data. 1342 (2) Jerry configures his audit log collection to download Program X 1343 audit log entries from the designated PDEPs. 1345 (3) Jerry also has an audit confirmation tool which pings the PDEPs 1346 for access to Program X data. Jerry's audit log analysis tool 1347 looks for these pings to confirm that auditing is taking place 1348 as expected. 1350 3.8 Email Pipeline Inspection 1352 Organizations have a huge incentive to inspect on emails entering or 1353 leaving the organization. This is desired for many different 1354 reasons. Inspection of mail leaving an organization is targeted 1355 towards making sure that it does not leak confidential information. 1356 It also behooves them to check that they are not a source of 1357 malicious content or spam. Inbound mail is checked primarily for 1358 malicious content, phishing attempts as well as spam. For domain with 1359 a high volume of messages there is a strong need to process email 1360 with minimal overhead. Such domains may mandate that they be pre- 1361 authorized to process an email due to the overhead a per-message call 1362 to an external service would add to message processing. 1364 Company Foo has a policy to scan all inbound and outbound email to 1365 ensure it is free from malware. Company Foo also want to ensure email 1366 is not spam. Company Foo can own their own scanning servers or it may 1367 be outsourced to a third party service. Company Foo wants to ensure 1368 that its policy of scanning also appliers to Plasma protected email. 1370 The ability to decrypt and check the content for malicious content is 1371 highly desirable even when a PLASMA encrypted Email message is 1372 encountered. The methods that this can be dealt with using on of the 1373 following methods: 1375 1. When a Company Foo client requests to send a Plasma email from a 1376 PDEP, the PDEP is able to check to see if the policy allows email 1377 content inspection by MTA, and if it does, that Company Foo has an 1378 outbound email scanning, and that the scanning servers meet the 1379 policy requirements. It is abbe to pre-authorize the Company Foo 1380 email scanning servers to access the email. 1382 2. The scanning MTA authenticates to the PDEP as an entity doing 1383 virus and malware scanning on a protected message. If the PDEP has 1384 specific policy that allow for access to be granted to such a 1385 scanning service, the appropriate decryption keys will be released 1386 and the server will scan the mail and take appropriate action. 1388 3. The policy server is configured with information about the 1389 server took various gateways (both internal and external) and has 1390 certificates for the known gateways. The policy server can then 1391 return a normal X.509 recipient info structure (lockbox) to the 1392 sender of the message for direct inclusion in the recipient info 1393 list. This allows normal processing by the scanning software 1394 without the necessity to stop and query the policy server for 1395 keying information at a cost of needing wider configuration. 1397 4. If the scanning server cannot gain access to the decrypted 1398 content using one of the two proceeding methods, it either passes 1399 the encrypted mail on the the recipient(s) without scanning it or 1400 it rejects the mail. This decision is based on local policy. If 1401 the message is passed to the recipient, then the necessary scanning 1402 either will not be done or needs to be done on the client's system 1403 after the message has been decrypted. 1405 3.9 Distribution List Expansion 1407 A distribution list is a function of an MTA that allows a user to 1408 send an email to a group of recipients without having to address all 1409 the recipients individually. Membership of the DL may be confidential 1410 so the sender may not know all the recipients. THe DL may be 1411 maintained by an external organization. Since a DL is identified by 1412 an email address, the user may be unaware they are sending to a DL. 1414 Plasma polices may have the list of recipients as a parameter 1415 therefor the fact the message is being process by the distribution 1416 list means the MTA processing the message needs to update the policy 1417 to allow the new recipients to access the message. Organization may 1418 also require inbound scanning of email and have therefore published 1419 keys to enable pre-authentication of the MTA by the sender to 1420 expedite processing. For both scenarios the DL MTA has to notify the 1421 Plasma server that it is adding recipients to the message and supply 1422 the list of new recipients. The Plasma server can then take 1423 appropriate action on the message token and return an updated token 1424 if required. 1426 3.10 Scalable Decision Making 1428 Collaboration involvers working with partners and suppliers. These 1429 collaborations may be short or long lived, with small or very large 1430 number of participants. Organizations therefore need flexibility in 1431 deployment and scaling. Organizations do not want to be locked into 1432 having to provide capacity themselves. Senders would be happy to 1433 delegate decisions to partners providing those decisions use the sets 1434 of rules they define for their data. Likewise partners would be happy 1435 to leverage their local decision capacity providing they don't have 1436 to duplicate rules themselves, and can simply and easily use policies 1437 published by their partners. Also organization may want to use cloud 1438 based decision services as a cost effective way to add capacity and 1439 to be able to respond to transient capacity fluctuations. 1441 Company Foo has been awarded a contract to build some equipment 1442 (Program X). The equipment is covered by export control which 1443 requires information only be released to authorized recipients under 1444 the terms of the export control licence. Company Bar is a foreign 1445 subcontractor to company Foo working on Program X. Company Foo sets 1446 up some business rules for access to program X data to ensure 1447 compliance with the export control licence requirements. Company 1448 Foo also set up separate rules to cover the confidentiality of its 1449 intellectual property contributed to Program X. Company Bar also sets 1450 up its own policies to protect the confidentiality its own 1451 intellectual property it contributes to Program X. As part of the 1452 agreement between Foo and Bar, they have agreed to mutually respect 1453 each other's policies. 1455 The Program Manages for Program X at Companies Foo and Bar agree a 1456 series of roles which are used to manage personal and their assigned 1457 policy groups. The policy administrators for Company Foo and Bar 1458 respectively publishes the roles and a policy collection for each 1459 role. There are rules associated with the policy collection, for 1460 example every roles uses the Program X policies published by Company 1461 Foo. Employees from Company Foo also get the company Foo Intellectual 1462 Property polices for that roles, whereas employees from company Bar 1463 get the company Bar intellectual property polices for Program X. 1464 Company Foo has also decided to allow enforcement of Program X 1465 policies by decision engines in both Company Foo and Company Bar. 1466 Company Foo has also decided to use a cloud decision engine for 1467 Program X to allow lower cost capacity and scaling. Company Foo is 1468 able to add new instances of the cloud decision services as the 1469 program scales up and more uses start working on the program. Each 1470 decision engine dynamically discovers the policies it needs from the 1471 set published by Company Foo and Company Bar. Both company Foo and 1472 Company bar can add new polices to the policy collections at any time 1473 and they are dynamically discovered by all the policy decision 1474 engines 1476 3.11 Related scenarios 1478 There are other scenarios which are related to the Email cases 1479 because they would be subject to the same policy requirements. Email 1480 allows users to create content and transport it to a set of 1481 recipients. You can perform similar actions with other formats such 1482 as documents and instant messages. Policy is agnostic to the 1483 underlying technology therefore if an organization has a policy 1484 relating to a type of information, then that policy would apply to 1485 the same content in an Email, a document an instant message, etc. 1487 3.11.1. Document Protection 1489 This scenario is very similar to 3.4 and 3.6 above. The difference 1490 is that the information being generated is in the form of a document 1491 not an Email. It could be as part of an ad-hoc sharing or a 1492 regulated sharing or information. 1494 Frank is an employee of Company Foo. He has been assigned to Program 1495 X. Grace is an employee of Company Bar. She has been assigned to 1496 Program X. Frank creates a document for the program. He also 1497 includes some Company Foo IP in the document. When Frank creates the 1498 document he must ensure compliance with export control regulations 1499 and his corporate IP protection policies. Frank must ensure: 1501 1. Only users who meet the Program X policy or Company Foo's 1502 intellectual property protection policy can open the document 1504 2. Users authenticates with an acceptable level of assurance as 1505 defined by the set of policies applied to the document 1507 3. Users present any other attributes about themselves necessary to 1508 verify compliance with the applicable policies. 1510 4. Users can verify who the author was to an acceptable level of 1511 assurance as defined by the document policy 1513 5. Users can verify the document has not been tampered with to an 1514 acceptable level of assurance as defined by the document policy 1516 6. They can also tell it is a Program X document and the contents 1517 can only be shared with other Program X workers. 1519 Frank creates a document for Program X. He include some information 1520 relation to Program X. Frank also includes some information which is 1521 Company Foo's IP. 1523 Franks word processor client allows him to classify the document. 1524 Frank classifies the document as Program X and Company Foo 1525 proprietary information. 1527 The word processor client knows the protections to apply to the 1528 document; to encrypt and integrity-protect the document, the level of 1529 assurance required for the users identity and what user attributes 1530 are necessary to access the document. 1532 The document is able to be published on a cloud based Web portal. The 1533 document is protected while in transit to the portal or at rest on 1534 the portal. The document is also protected on any backup or replica 1535 of the portal data. Frank does not to worry about where on the 1536 portal he publishes the document. He can make the most appropriate 1537 choose based on the project and the document content. 1539 Grace sees the document on the portal and tries to open the document. 1540 Grace is able to prove her identity to the level requested by Frank 1541 and provides the requested attributes about herself to satisfy both 1542 the Program X export control and the Company Foo IP protection 1543 policies. Grace opens the document. 1545 If Grace edits the document and includes some information which is 1546 Company Bar's IP so adds her companies IP protection policy 1547 requirements to the document. Grace saves the updated document to 1548 the same location on the portal. 1550 Frank sees that Grace has updated the document on the portal. Frank 1551 is able to prove his identity to the level requested by both the 1552 Company Foo and company Bar policies and provides the requested 1553 attributes about himself to satisfy both the Program X export 1554 control, the Company Foo IP protection policies as well as the 1555 Company Bar IP protection policies. Frank opens the document. 1557 3.11.2 Instant Message Protection 1559 This scenario is very similar to 3.4 and 3.6 above. The difference 1560 is that the information being generated is in the form of a instant 1561 message not an Email. It could be as part of an ad-hoc sharing or a 1562 regulated sharing or information. 1564 Frank is an employee of Company Foo. He has been assigned to Program 1565 X. Grace and Hank are employees of Company Bar and also has been 1566 assigned to Program X. Frank want to discuss an urgent topic with 1567 Grace and Hank. The topic necessitates discussion of Company Foo IP. 1568 Because of the urgency, Frank want to use IM. Frank must ensure: 1570 (a) Only users who meet the Program X policy or Company Foo's 1571 intellectual property protection policy can join the IM session 1573 (b) Users authenticates with an acceptable level of assurance as 1574 defined by the set of policies applied to the IM session 1576 (c) Users present any other attributes about themselves necessary to 1577 verify compliance with the applicable policies. 1579 (d) Users can verify who IM initiator was to an acceptable level of 1580 assurance as defined by the session policy 1582 (e) Users can verify the IM data has not been tampered with to an 1583 acceptable level of assurance as defined by the session policy 1585 (f) They can also tell the session is a Program X session and the 1586 contents can only be shared with other Program X workers. 1588 The sequence of events Frank would use is as follows: 1590 (1) Frank initiate the IM session and includes Grace as a 1591 participant. 1592 (2) Frank's IM client allows him to select a role a role which is 1593 appropriate for the session. Frank then selects a Program X and 1594 Company Foo IP policies for the session. 1596 The IM client knows the protections to apply to the IM session; to 1597 end to end encrypt and integrity-protect the session, the level of 1598 assurance required for participant's identity and what participant's 1599 attributes are necessary to join the session. 1601 The IM is able to flow securely and seamlessly through existing IM 1602 infrastructure to session participants. Grace a session participant 1603 so her client attempts to join the IM session with Frank. Hank is in 1604 a meeting so does not join the IM session at that time. 1606 (5) Grace receives the IM and sees it is a secure IM from Frank. 1607 Grace's client provides the attributes necessary to comply with 1608 the policy which includes her level 3 encryption certificate to 1609 the PDEP. 1610 (6) Once Grace has shown she passes the policy requirements, the 1611 PDEP releases the IM session CEK to Grace using her level 3 1612 encryption certificate. 1613 (7) Grace uses her smart card to open the IM session. She sees the 1614 from Frank is marked with both the Program X and Company Foo IP 1615 policies 1617 (8) Grace composes a response to Frank's question and hits send 1619 (9) When Hank's meeting is finished, he joins the IM session because 1620 he to passes the policy requirements and sees the the messages 1621 from Frank and Grace. 1623 4. Plasma Data Centric Security Model 1625 A common theme from these scenarios is the need to closely tie 1626 the information asset to the set of technical controls via the 1627 data owners policies in such a way as it is possible to 1628 consistently apply the technical controls across a broad set of 1629 applications (not just email); for a broad set of users; (not 1630 just those within a organization) and in a broad set of 1631 environments. Assumptions based on closed world enterprise 1632 security models are increasingly breaking down. Perimeter 1633 security continues to diminish in relevance, and focus need to 1634 be shifted to self protecting data as opposed to protecting the 1635 machines that store such data. The binding between the data and 1636 the applicable polices needs to happen as early to creation time 1637 as possible so ad-hoc trust decisions are not required. 1639 The delivery of the documented use cases will require the 1640 integration of many existing and some new protocols. In order to 1641 ensure the right overall direction for Plasma as each part of 1642 the work proceeds, a high level data model is documented here to 1643 act as a guide. While this is technically informative to the 1644 developments of each individual component, it is normative to 1645 the work overall. 1647 This Data Centric Security model is based on a well established 1648 set of actors for policy enforcement used elsewhere [RFC3198] 1649 [XACML-core]. 1651 Figure 1 shoes the relationship between the actors. 1653 ------------------ 1654 | | 1655 | Policy | 1656 | Administration | 1657 | Point | 1658 | | 1659 ------------------ 1660 | 1661 ----------------- | ----------------- 1662 | | | | | 1663 | Policy | | Read | Policy | 1664 | Information | | Policy | Information | 1665 | Point | | | Point | 1666 | | | | | 1667 ----------------- v ----------------- 1668 | | v | | 1669 | |Issue ----------------- Issue | | 1670 | |Attributes | | Attributes| | 1671 | |(BAE) | Policy | (BAE) | | 1672 | -------------->>| Decision |<<--------------- | 1673 | | and | | 1674 | | Enforcement | | 1675 | -------------->>| Point |<<----------- | 1676 | |Protect | | Consume | | 1677 | |Content ----------------- Content | | 1678 | |Request+ Request+ | | 1679 | |Attributes Attributes| | 1680 | |(FAE) (FAE) | | 1681 v | v v 1682 v | v v 1683 ----------------- ----------------- 1684 | | | | 1685 | Content | Distribute | Content | 1686 | Creation | Content | Consumption | 1687 | Decision | ---------------------------->>| Decision | 1688 | Requestor | | Requestor | 1689 | | | | 1690 ----------------- ----------------- 1691 Figure 1 General Scheme for Publishing and Consuming Protected Content 1693 The Plasma model is applicable to any type data (Email, documents, 1694 databases, IM, VoIP etc). This is to facilitate consistent policy 1695 enforcement for data across multiple applications. Another objective 1696 is to not require the data holder to have access to the plain text 1697 data in order to be able to make decision requests to the PDEP. The 1698 policy decision is complex so the content creation DR in Plasma just 1699 uses policy pointers or labels to indicate the set of policies 1700 applicable to content. The Content consuming DR dynamically discover 1701 the PDEP's who are authoritative for the decisions on protected 1702 content in question. The PDEP's dynamically discover the specifics of 1703 a policy from a PAP using the policy references. The specifics of 1704 policy authoring, policy decision logic modules are matters beyond 1705 the scope of this document. It is important to note that the actors 1706 in this model are logical entities and as such can be combined 1707 physically in different configurations. 1709 o The Plasma model uses references to bind the data and the policy. 1710 When information is created, it is encrypted and a list of policies 1711 that must be enforce by the PDEP is bound to the protected data. 1713 o The Plasma model is an Attribute-Based Access Control (ABAC) 1714 model where the ABAC policy is specified in terms of a set of 1715 attributes, their values and relationships. The policy may specify 1716 attributes about the subject, their device or environment, or 1717 attributes about a resource. 1719 o The ABAC policy does not require the subject provide their 1720 orthonym. Subjects could be anonymous or use pseudonymous. What is 1721 required is presentation of a set of attributes that satisfies the 1722 policy. 1724 o The requestor is required to bind the attributes to the channel 1725 with the PDEP to a level of assurance as required by the PDEP. If 1726 the PDEP only requires low assurance, bearer token over SSL would 1727 be suitable. If the PDEP requires higher assurance, then holder of 1728 key tokens over SSL would be required. 1730 o This model also supports Capability-Based Access Control (CBAC) 1731 where security tokens represent a capability to meet a policy. Once 1732 a subject has proven compliance with a policy, they can be issued a 1733 capability token. The client can subsequently present this 1734 capability token in lieu of a token or tokens with the set of 1735 subject attributes. The net result is the model can transition to 1736 a Capability Based Access Control because the capability token is 1737 an un-forgeable token of compliance with a policy. The token can be 1738 used with any resource tagged with the same policy. 1740 o Plasma has a baseline of a secure transport between the DR and 1741 the PDEP. One of the decisions the PDEP has to make is the level of 1742 assurance on the release of the DEK to the subject. For example the 1743 PDEP can release a clear text DEK over the secure transport to the 1744 DR. Alternatively the could require the production of a high 1745 assurance X.509 encryption certificate as a subject attribute to 1746 generate an encrypted DEK. 1748 For the purpose of the Plasma work, it is desirable that the DR and 1749 PDEP be clearly defined as separate services which may be on separate 1750 systems. This allows for a generalization of the model and makes it 1751 less dependent on any specific deployment model or policy represent, 1752 logic or implementation method. It also allows for a greater degree 1753 of control of the PDEP by an organization as all of the PDEP 1754 resources more directly under it's control and independent of the 1755 data storage location. 1757 The base set of information for a Plasma client is as follows: 1759 o The address of one or more IdP able to issue identity attributes 1760 to the subject 1762 o A means to authenticate to the IdP(s) 1764 o THe address of zero or more AtP(s) able to issue attributes to 1765 the subject 1767 o The address of one or more Plasma PDEPs able to issue role tokens 1768 to the subject 1770 From this base set of data, the subject is able to authenticate to 1771 each Plasma PDEP in tern using the identity token from the IdP and 1772 discover the set of assigned roles. Each role has a set of policies 1773 which can be applied to data. A subject may be assigned to multiple 1774 roles and therefore has the ability to select the most appropriate 1775 role for the content being created. Once a role is selected the 1776 subject is able to select from the policy collection for that role. 1777 Role assignment is dynamic so the role discovery needs to be done on 1778 a regular (but not frequent) basis. Policy selection during content 1779 creation can be either manual or automatic. An DR may have sufficient 1780 context to be able to select the role and policies for the subject or 1781 have some rules that facilitate policy selection. 1783 The model allows the content creation DR to discover the role 1784 assignments from multiple PDEP which would allow the subject to asset 1785 policies based on roles from within their organization and from any 1786 partner organization due to cross organization collaboration. The 1787 PDEP's who are authoritative for the role assignment for a subject 1788 may be different from the PDEP who are authoritative for enforcement 1789 of a policy collection in question. The DR uses the role token to 1790 authenticate the content creation request. The PDEP will check the 1791 requested list of policies for the information is a subset of the 1792 policies in the role token. If the set of policies are a subset of 1793 the policies in the role, then it will issue the metadata token to be 1794 attached to the protected information. 1796 Policy rules processing and distribution is complex so Plasma model 1797 does not require policy rules to be distributed to the DR. The DR 1798 just uses opaque references to the policies. The references are bound 1799 to the content to reflect the set of policies that are applicable to 1800 the data in such a way as they will travel with the data. The use of 1801 policy references minimizes any policy maintenance issues due to 1802 policy updates. The DR can be required to carry out obligations of 1803 the policy such as specific encryption requirements such as key size 1804 or algorithm; or data integrity requirements such as signing or 1805 creating audit records. 1807 The PDEP makes its decisions based on the requested action from the 1808 DR, the policy requirements from the PAP and the information from the 1809 PIP about the subject and the subjects environment. The information 1810 about the subject may be exchanged direly between the PIP and the 1811 PDEP (Back end Attribute Exchange) or indirectly via the DR (Front 1812 end Attribute Exchange) or both. 1814 There is no guarantee that Identity and Attribute providers will 1815 consistently use the same name to identity a specific attributes or 1816 attribute data. For example they may use different schemas to 1817 identify an email address or use localized names to describe job 1818 functions or roles. These kinds of values may be standardized within 1819 communities of interest, but not globally across all identity and 1820 attribute providers. 1822 --------------- ----------------- ----------------- 1823 | | | | | | 1824 | | | Policy | | Policy | 1825 | Policy | | Decision and | | Decision and | 1826 | Decision | | Enforcement | | Enforcement | 1827 | Point | | Point | | Point | 1828 | | | | | | 1829 --------------- ----------------- ----------------- 1830 | | | 1831 | T | T | 1832 | TTTTTTT|TTTTTTT | 1833 V V V 1834 V V V 1835 --------------- --------------- --------------- 1836 | | | | | | 1837 | Policy | | Decision | | Decision | 1838 | Enforcement | | Requestor | | Requestor | 1839 | Point | | | | | 1840 | | | | | | 1841 --------------- --------------- --------------- 1842 | | | 1843 T | T | | 1844 TTTTTTT|TTTTTT | | 1845 V V V 1846 V V V 1847 --------------- --------------- --------------- 1848 | | | | | | 1849 | End | | End | | End | 1850 | User | | User | | User | 1851 | Application | | Application | | Application | 1852 | | | | | | 1853 --------------- --------------- --------------- 1854 (a) (b) (c) 1856 Figure 2 Options For Trussed Actors With Data. 1858 When drawing a line where the actors in the model are full trusted 1859 with the clear text data there are three possibilities (see figure 1860 2). 1862 Figure 2a shows the full trust line between the user application and 1863 the Policy Enforcement Point(PEP). This is the model for current 1864 standard access control e.g. XACML [XACML-core]. In 2a, the PEP has 1865 full access to the plain text data. It makes decision requests to the 1866 PDP and if the decision is allow the PEP releases the data to the 1867 application. To use fig 2a for secure Email would require every MTA 1868 and MUA to be fully trusted with plain text data which is 1869 impossible. 1871 Figure 2b shows the full trust line between the PDEP and the DR. In 1872 2b, the DR only has cipher text data. The data is encrypted with a 1873 content encryption key (CEK) and the PDEP has the CEK. THe PDEP 1874 releases the CEK to the end user application when access is granted 1875 so the application can recover the plain text. This mode is viable 1876 for secure Email as it does not require the MTA to be trusted wit the 1877 plain text data and either the MTA or MUA can act as a DR. 1879 In figure 2c, no actor is given full trust. When the data is 1880 encrypted, the CEK is encrypted for each recipient just as S/MIME 1881 does today. The encrypted CEKs are given to the PDEP and the PDEP 1882 releases the encrypted CEK when access is granted. This mode is also 1883 viable for secure Email as the sender can use either conventional 1884 Public key cryptography or Identity Based Encryption[RFC5408] to 1885 protect the CEK for each recipient. 1887 4.1 Plasma Client Server Key Exchange Level of Assurance 1889 There are a number of mechanisms by which a client and servers can 1890 exchange keys. As a baseline, Plasma is establishing a secure 1891 transport between the client and server. However the client may be a 1892 proxy acting on behalf of the subject, therefore transporting a clear 1893 text key over the TLS transport would expose the key to the proxy. 1894 There also may be a proxy at the server which is terminating the TLS 1895 transports and forwarding the requests to another server which would 1896 mean a clear text key over the transport would be exposed to the 1897 server proxy. Policies may require a higher level of assurance that 1898 the key is not exposed to unauthorized principals. This requires 1899 encrypting the KEK for the subject before transport. This would 1900 require the client or the server to provide a public key to the other 1901 party to be used to protect the KEK before sending over the secure 1902 transport. 1904 4.2 Policy Data Binding 1906 There are three ways to bind policy to data. 1908 o By value. This is where a copy of the machine readable rule set 1909 is directly associated with the data e.g. where a file system has a 1910 Access Control List for the file or directory or where a rights 1911 management agent has embedded a copy of the policy expressed in a 1912 policy expression language in the rights protects data. When an 1913 access request is made to the data, the PDEP compares the access 1914 request to the policy on the data itself. 1916 o By reference. This is where a reference to the policy is directly 1917 associated with the data. e.g. a URI or a URN which identifies the 1918 policy to be enforced or points to where the policy is published. 1920 For example with S/MIME the ESS label identifies the applicable 1921 policy by an OID. When an access request is made to the data, the 1922 PDEP finds the policy based on the identifier and then compares the 1923 access request to the referenced policy. 1925 o By inference. This is where the policy has a target description 1926 in terms of resource attributes the policy applies to. When an 1927 access request is made, a set of attributes describing the resource 1928 which is the subject of the access request are included in the 1929 request by a PEP. The PDP then evaluates the set of policies in its 1930 policy store to determine the set of policies to apply to the 1931 request. For example when you author a XACML policy, you also 1932 define a target for the policy. When an access request is made to 1933 the data, the PDP finds the policy using the set of attributes of 1934 the resource looking for any policies that match the target 1935 description associated with the policy. It then compares the access 1936 request to the identified policy. 1938 The chief strength of binding policy by value is its simplicity. The 1939 policy is local to the data can can easily and quickly be read. The 1940 chief weakness in binding policy by value is maintaining policy over 1941 time as binding by value results in the policy being replicated for 1942 every instance of data the policy is applied to. Many policies have a 1943 multi-year life span and during the course of that time there is a 1944 very high probability that the policy would need to be updated. Given 1945 the high number of copies, it has proven to be an very costly and 1946 imperfect process both from an enforcement and audit perspective. 1947 This process is complicated by the fact that because only the result 1948 is stored and not an identifier, it is hard to identify the policy 1949 which has to be updated. 1951 The chief strength of binding by names is once bound to the data the 1952 association with the policy travels with the data. The chief weakness 1953 in binding by name is it requires the reference to be strongly bound 1954 to the data. This is possible using cryptography but then process of 1955 persisting the binding impacts the storage format. This can break 1956 backwards compatibility. 1958 The chief strength of binding by inference is it can often be applied 1959 to data without impacting the storage format providing the data 1960 already has resource attributes such as with a SQL table. The chief 1961 weakness in binding by inference is the reliability of the matching 1962 in in part due to the assumption the necessary policy is in the 1963 policy store. Any matching process must have a false positive and 1964 falsie negative rate. This rate has to be evaluated on a case by case 1965 basis over time as it can change making compliance expensive. The set 1966 of available attributes also varies with different data types e.g. 1967 structured database information has a rich set of attributes whereas 1968 unstructured data such as documents and files have a poor set of 1969 resource attributes. This inconsistently over available attributes 1970 impacts matching reliability. The resultant set of policies for a 1971 policy target is also dependent on the correctness of the set of 1972 policies evaluated. Its also impossible to detect if a policy is 1973 missing from the policy store which again would mean incorrect policy 1974 enforcement 1976 The Plasma model is choosing to use binding by name because we need 1977 to encrypt the data which means we will impacting the storage format 1978 anyway which negates the main weakness of binding my name. We get the 1979 reliability of policy enforcement which is independent of location 1980 and we get low maintenance since we are only storing a reference to 1981 the policy and not the policy with the data.. 1983 4.3 Content Creation Workflow 1985 The Content Creation DR bootstraps itself via the following sequence 1986 of events: 1988 (1) The content creation DR is configured with the set PIP's and 1989 PDEP's it trusts. 1990 (2) The content creation DR summits a request to all the trusted 1991 PDEPs for the set of roles it allows for the subject. The 1992 subject is authenticated and authorized for the roles via 1993 attributes from the PIP. The PIP attributes can be obtained by 1994 the PDEP either via front-end (related to the PDEP from the PIP 1995 via the subject) or back-end (direct exchange between the PDEP 1996 and the PIP) processing. 1998 (3) The content creation DR receives a list of roles the PDEP can 1999 configured for the subject 2000 (4) The DR submits a request for the policy collection for each 2001 role. Additional attributes may be required from the PIP to 2002 authorize the release of the BCPC token. 2004 Now the DR is bootstrapped with a list of BCs and for each BC a list 2005 of policies associated with each BC. Now the DR is ready to create 2006 content. When the user wants to release protected content, they use 2007 the following sequence of events 2009 (i) The user creates the new content 2010 (ii) The user select the appropriate business context for the 2011 content, then selects one or more policies applicable to the 2012 content 2013 (iii) The DR encrypts the content with one or more locally generated 2014 CEKs 2016 (iv) The DR submits the CEK, the set of requires policies to be 2017 applied and the hash of the encrypted content to the PDEP. THe 2018 CEK can be a raw key or a CEK key encrypted by a KEK if the 2019 user does not want the PDEP to have the ability to access the 2020 plain text data. 2021 (v) The PDEP generates the encrypted metadata which contains the 2022 list of policies and the CEKs. The metadata is encrypted by 2023 the PDEP for itself. The PDEP includes a URL for itself and 2024 the hash of the protected content as authenticated attributes 2025 then signs the encrypted metadata. 2026 (vi) The PDEP returns the metadata to the DR 2027 (vii) The DR attaches the PDEP metadata to the protected content and 2028 distributes the content. 2030 4.4 Content Consumption Workflow 2032 When a user want to open some protected content they would follow the 2033 following workflow. 2034 (A) The DR verifies the certificate in the signed metadata then 2035 determines via local policy if it want to process the 2036 protected information based on the identity of the PDEP 2037 (B) The DR verifies the signature on the metadata token and the 2038 binding to the encrypted data by hashing the encrypted 2039 information and comparing it to the authenticated attribute in 2040 the metadata 2041 (C) The DR forwards the signed metadata and requests a read token 2042 from the PDEP using the location in the authenticated 2043 attribute in the metadata 2044 (D) The PDEP decrypts the metadata, de-references the policy 2045 pointers and determines the set of access rules based on the 2046 policy published by the PAP. The PDEP then determines the set 2047 of subject attributes it needs to evaluate the access rules. 2048 The PDEP can the use PIP is has relationships with to query 2049 attributers about the subject. The list of attributes the PDEP 2050 is missing is then returned to the DR 2051 (E) The DR obtains the missing attributes requested by the PDEP 2052 and sends them to the PDEP 2053 (F) Once the PDEP has a complete set of attributes, and the 2054 attribute values match those required under the access policy, 2055 the PDEP releases the CEK to the DR along with a TTL which 2056 defines how long the DR can use the CEK before it must discard 2057 the CEK and reapply for access. 2058 (G) Once the DR has the CEK it decrypts the information. It caches 2059 the CEK until the TTL expires. 2061 4.5 Plasma Proxy Servers 2062 There are two separate use cases for Plasma Proxy servers. Forward 2063 proxy use cases where the Plasma client needs to connect to a Plasma 2064 server outside its organization and reverse proxy use cases where 2065 Plasma clients outside an organization, need to connect to a Plasma 2066 server. 2068 A client has no control over senders creating Plasma email and 2069 sending to them. Malicious sender can craft harmful payloads and 2070 protect it in a Plasma envelope. Therefore a Plasma clients needs a 2071 policy to determine the set of Plasma server they are willing to 2072 interact with. This can be as a local policy which is pushed down to 2073 every client. An alternate approach is to have a forward proxy manage 2074 the policy on behalf of the client. A forward proxy would eliminate 2075 the need to push policy about the set of trusted Plasma server by 2076 mediating the connection requests from the plasma clients to the 2077 plasma servers. The forward proxy could be a server belonging to the 2078 client organization or a cloud service. 2080 Internet | DMZ | Intranet 2081 | | 2082 | | 2083 | | --------------- 2084 | | | | 2085 TLS | | TLS | Plasma | 2086 ----------|<------------------------|------| Client | 2087 | | | | 2088 (a) | | --------------- 2089 no proxy | | 2090 | | 2091 | | 2092 | --------------- | --------------- 2093 | | | | | | 2094 TLS | | Forward | | TLS | Plasma | 2095 ----------|<-----| Plasma |<---|------| Client | 2096 | | Proxy | | | | 2097 (b) | | | | --------------- 2098 Forward | --------------- | 2099 Proxy | | 2101 Forward Plasma Proxy 2103 For the reverse proxy case, Plasma servers will need to be Internet 2104 addressable to service Plasma requests from DR's outside the 2105 organization. Since the Plasma service has sensitive cryptographic 2106 keys used to protect the message CEKs, it would be unwise to host 2107 those directly connected to the Internet. The simplest possible 2108 configuration (a) would be to have a passive reverse proxy in front 2109 of the Plasma server. Since Plasma is using TLS with channel binding, 2110 the proxy has a limited function and would be only able filter based 2111 on IP addresses. The Plasma protocol is a series of requestresponse 2112 messages, so an active reverse proxy can be implemented like other 2113 store and forward message based services (e.g. SMTP), with an 2114 Internet facing server which would terminate the TLS from the 2115 external DRs, ensure DR can authenticate the TLS connection. Because 2116 the active proxy terminates the TLS session, it can scan submitted 2117 messages to ensure they are not malformed and are free from malicious 2118 content before relaying messages to a full Plasma server further 2119 inside the network for processing of the request. 2121 Internet | DMZ | Intranet 2122 | | 2123 | | 2124 | --------------- | --------------- 2125 | | | | | | 2126 TLS | | Passive | | TLS | Full | 2127 ----------|------|-------------|----|----->| Plasma | 2128 | | Reverse | | | Server | 2129 | | Proxy | | | | 2130 (a) | | | | | | 2131 | --------------- | | TLS Keys | 2132 | | | Message | 2133 | | | Encryption | 2134 | | | Keys | 2135 | | | | 2136 | | --------------- 2137 | | 2138 | --------------- | --------------- 2139 | | | | | | 2140 TLS | | Active | | TLS | Full | 2141 ----------|----->| Reverse |----|----->| Plasma | 2142 | | Proxy | | | Server | 2143 (b) | | | | | | 2144 | | TLS keys | | | TLS Keys | 2145 | | | | | Message | 2146 | --------------- | | Encryption | 2147 | | | Keys | 2148 | | | | 2149 | | --------------- 2150 | | 2151 | | 2152 Reverse Plasma Proxy 2153 4.6 Policy Types 2155 Policies range from very simple to very complex. Policies have 2156 dependencies not only on the technical implementation of the software 2157 but on the range of attributes a PIP would would issue to subjects. 2159 This is likely constrained by the physical procedures a PIP would 2160 support to capture and verify the information about the subject. To 2161 manage this range of requirements, this model uses two type types of 2162 policy. 2164 4.6.1 Basic Policy 2166 Basic policy is intended to be universally usable by using a small 2167 fixed set of attributes. For example, basic policy is intended to be 2168 equivalent to sending encrypted Email with S/MIME today. It is a 2169 simple policy that authenticated recipients of the Email get access 2170 to the message. Its intended target is simple scenarios involving 2171 consumers and small businesses who are using public PIP which issue a 2172 limited set of attributes. It is expected that all Plasma clients and 2173 commercial IdP would be capable of supporting basic policy due to 2174 their simplicity and basic attribute set required by basic polices. 2175 As the available set of attributes increases over time, later 2176 standards may define more basic polices which a bigger set of 2177 attributes types. 2179 4.6.2 Advanced Policy 2181 Advanced policy is intended to be used where one or more arbitrary 2182 policies are required on the content. It is intended to target more 2183 complex scenarios such as content with regulated information or 2184 content subject to other organization and contractual policies. The 2185 input set of attributes is defined by the policies are in theory 2186 unbounded and can be either primordial such as date of birth or 2187 derived attributes such as age or both. A data object may require 2188 multiple policies and any instance of multiple policies requires a 2189 logical relationship between the polices e.g. they can be AND or ORed 2190 together. It is not expected that all Plasma clients support the rich 2191 set of attributes necessary for advances policy. 2193 5. Message Protection Requirements 2195 5.1. General Requirements 2197 Confidentiality policy protected data MUST be where the data is 2198 confidential, integrity protected AND provide data origination 2199 authentication and recipients are allowed to alter the data. 2201 Integrity protected is where the data MUST be integrity protected 2202 AND provide data origination authentication and recipients are NOT 2203 allowed to alter the data. 2205 Every authentication has a level of identity assurance associated 2206 with it depending on attributes such as the identity checks made 2207 about the subject and the authentication technology used by the 2208 subject. The authentication of content creator and content consumers 2209 MUST support the multiple levels of identity assurance framework. 2210 (see scenarios 3.1, 3.2, 3.3 and 3.4) 2212 The specifics of every possible authentication mechanism or every 2213 detail about how the subject's identity was proofed by the IdP cannot 2214 be known to the DR and PDEP, therefore the specifics of how sender or 2215 recipient achieve the required level of identity assurance MUST be 2216 abstracted from the PDEP and DR by use of a simple numeric scale ( 2217 e,g, 0-4, or 1-6) liked to an identity assurance framework identifier 2218 which defines the specifics of how to derive the LoA.(See section 2219 3.1, 3.2, 3.3 and 3.4) 2221 Access policies are complex and subject to change over time. For 2222 this reason, policies MUST be identified by reference rather than 2223 inclusion of the actual policy with the data so the policy change can 2224 be implemented without updating the data. (See section 3.4.1) 2226 Access to the plaintext of the content MUST only be provided after 2227 the recipient has either provided suitable valid attributes to the 2228 PDEP or the PDEP was able to find attributes about recipient directly 2229 from a PIP, to satisfy the policy as defined by the sender (See 2230 section 3.1 3.2, 3.3, 3.4.1, 3.5) 2232 The sender MUST be provided with a list of policies applicable to 2233 content they create and scoped to their current role i.e. what tasks 2234 they are currently assigned to deliver(see scenarios 3.1, 3.2, 3.3). 2236 The specifics of the access control policy used by the PDEP MUST be 2237 abstracted from both the sender and recipients i.e. the DR MUST NOT 2238 make the access control decision or need specifics of the access 2239 policy(see scenarios 3.1, 3.2, 3.3 and 3.4). 2241 Content consumers DR MUST receive authenticated attributes of the 2242 identity of the creator, the level of identity assurance of the 2243 creator and the cryptographic fingerprint of the original content so 2244 the DR can confirm who created the content and that the content has 2245 not been altered (see section 3.1, 3.2, 3.3 and 3.4) 2247 The key exchange between content creator and content consumer and the 2248 PDEP MUST support multiple levels of assurance so an appropriate 2249 strength of mechanism can be selected based on the level of assurance 2250 required. For example, for low assurance situations this could be via 2251 a plan text CEK over a secure transport such as SSL. For high 2252 assurance situations recipient MAY be required to provide a suitable 2253 key exchange key such as an X.509 certificate to encrypt the CEK. 2254 (See scenarios 3.3 and 3.4) 2255 The level of key exchange assurance requited MUST be selected by the 2256 sender and enforced by the PDEP (See section 3.1, 3.2, 3.3 and 3.4). 2258 If the content consumers is unable to initially comply with the 2259 content creators policy, they MUST be able resolve any issues by 2260 getting the suitable credentials or attributes and gain access to the 2261 content without intervention from the content creator. 2263 A time-to-live MUST be provided to content consumers when access is 2264 granted by the PDEP to define when the DR MUST discard the message 2265 CEK and submit a new access request to the PDEP. The TTL value MUST 2266 be based on the message policy and optional attributes about the 2267 content consumer and their environment. 2269 The PDEP MUST be stateless for processing policy requests from 2270 content creators and consumers with respect to any instance of 2271 protected content. It MUST be possible to have multiple instances of 2272 a PDEP service and load balance requests across all instances of the 2273 service transparently to the client and not require synchronization 2274 of state about requests between instances of the service. 2276 A PDEP MUST be capable of generating audit events associated with 2277 access to protected content using policy defined by the PAP. 2279 5.1.1 Email Specific General Requirements 2281 It MUST be possible for domains to publish keys and attributes about 2282 the boundary inspection agents. This allows senders to pre-authorize 2283 the inspection agents of recipients for access to the message. It 2284 MUST be possible for boundary inspection agents to request access to 2285 protected messages which have not been preauthorized by the sender. 2287 It MUST be possible for MTAs to request access to protected messages 2288 which have not been preauthorized by the sender (see section 3.5). 2290 5.2. Basic Policy Requirements 2292 The use of Basic Policy MUST be backwards compatible with existing 2293 S/MIME. A sender's agent MAY discover some recipient's certificates 2294 and create recipient info structures using the existing standard 2295 (unless specifically forbidden by the selected policy). A sender's 2296 agent MAY elect to use this mechanism for recipients for whom keys 2297 cannot be discovered. 2299 One Basic Policy is to be defined by this work. The Basic to map to 2300 NIST 800-63-1. This process does not preclude other Basic Policies 2301 to be defined by other groups or even within the context of the 2302 IETF. 2304 When using Basic Policy, the sending agent MUST define which basic 2305 policy is required and the list of recipients. 2307 Basic policy MUST support multiple levels of identity assurance. The 2308 levels of identity assurance MUST map to an existing identity 2309 authentication assurance framework e.g. to NIST 800-63-1 or 2310 equivalent. 2312 A sender using Basic policy MUST be able to send protected messages 2313 without discovering any recipient's encryption key. 2315 Using basic policy MUST NOT require bilateral agreements between 2316 sender and recipients a priori to sending the message. 2318 5.2.1 Email Specific Basic Policy Requirements 2320 The use of Basic Policy MUST be backwards compatible with existing 2321 S/MIME. 2323 A sender's agent MAY discover some recipient's certificates and 2324 create recipient info structures as per the existing S/MIME standard 2325 and elect to use the new mechanism for recipients it cannot discover 2326 keys for rather than remove the recipient's without certificates. 2328 5.3. Advanced Policy Requirements 2330 A basic policy MAY be combined with advanced policies 2332 It MUST be possible to apply one or more Advanced Policies to a 2333 protected content. Where 2 or more policies are applied to protected 2334 content, the logical relationship between the policies MUST also be 2335 expressed i.e. are the policies a logical AND or a logical OR. (See 2336 section 3.3) 2338 An advanced policy MAY require attributes about: 2340 o The content consumer 2341 o The device the content consumer is using 2342 o The environment of the device is attempting to access the 2343 protected content from 2344 o The content being accessed 2346 Advances policy MUST support an extensible list of obligations on the 2347 content creator where use of the policy requires some specific action 2348 on the part of the content creator e.g. sign content with 2 factor 2349 smart card and/or that the signature is legally binding, or the 2350 message needs to be verified for an extended period(see scenarios 3.3 2351 and 3.4). 2353 Advanced policies must support the ability to verify the content for 2354 an extended period (10 or more years) 2356 6. IANA Considerations 2358 This document describes the requirements for message access control. 2359 As such no action by IANA is necessary for this document 2361 7. Security Considerations 2363 Authentication by itself is not a good trust indicator for users. 2364 Authentication raises the level of assurance the identity is correct 2365 but does not address whether the identity is trustworthy or 2366 noteworthy to the recipient. Authentication should be coupled with 2367 some form of reputation e.g. the domain is on a white list or is not 2368 or a black list. Malicious actors may attempt to "legitimize" a 2369 message if an indication of authentication is not coupled with some 2370 form of reputation. 2372 Malicious actors could attempt to use encrypted Email as a way to 2373 bypass existing message pipeline controls or to mine information from 2374 a domain. Domain should have sufficient granularity of policy to 2375 handle situations where their Email pipeline agents have not been 2376 authorized to inspect the contents. 2378 It must be possible for a third party to, upon correctly presenting a 2379 legitimate legal justification, to recover the content of a message. 2380 This includes the Sender's and Recipient's companies for business 2381 continuity purposes, as well as Law Enforcement. If the entity 2382 requesting the information and the entity controlling the access are 2383 in different jurisdictions, then the process would be subject to some 2384 form of rendition. 2386 The use of a security label type that requires the recipient of a 2387 message to query a PDEP in order to obtain the contents of a message 2388 opens an additional method for adversaries to confirm that an Email 2389 address does or does not exist. Additionally it allows for a new 2390 channel for materials to be delivered to the recipient's mail 2391 processor that is not checked for malware or viruses by the standard 2392 mail scanning methods in place. For these reasons recipient 2393 processing systems need to implement the following counter-measures: 2395 1) The pointer to the PDEP MUST be checked against some policy 2396 before attempting to query the PDEP for a policy decision. 2) Care 2397 MUST be taken when processing the responses from a PDEP check that 2398 they are well-formed and meet local policy before using the 2399 responses. 2401 Editorial Comments 2402 Appendix A. References 2404 A.1. Normative References 2406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2407 Requirement Levels", BCP 14, RFC 2119, March 1997. 2408 [RFC2634] Hoffman, P. Ed., "Enhanced Security Services for S/MIME", 2409 RFC 2634, June 1999. 2410 [RFC3198] Westerinen et. al., "Terminology for Policy Based 2411 Management", November 2001. 2412 [RFC5280] Cooper, D, et al, "Internet X.509 Public Key 2413 Infrastructure Certificate and Certificate Revocation 2414 List (CRL) Profile", RFC 5280, May 2008 2415 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 2416 5652, September 2009. 2417 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2418 Mail Extensions (S/MIME) Version 3.2 Certificate 2419 Handling", RFC 5750, January 2010. 2420 [RFC5751] Ramsdell B., Turner S., "Secure/Multipurpose Internet 2421 Mail Extensions (S/MIME) Version 3.2 Message 2422 Specification", January 2010 2423 [SAML-core] OASIS, Assertions and Protocols for the Security 2424 Assertion Markup Language (SAML) Version 2.0, March 2005 2425 [sp800-63-1] NIST SP 800-63-1 "Electronic Authentication Guideline", 2426 December 2008 2428 A.2. Informative References 2430 [bc-iaf] Province of British Columbia; Electronic Credential And 2431 Authentication Standard, version 1.0 2432 [kan-iaf] Kantara Initiative; Identity Assurance Framework: 4 2433 Assurance Levels, version 2.0 2434 [lib- iaf] Liberty Alliance; Liberty Identity Assurance Framework, 2435 version 1.1 2436 [RFC3114] Nicolls, W., "Implementing Company Classification Policy 2437 with the S/MIME Security Label", RFC 3114, May 2002. 2438 [RFC5408] Appenzeller, G., "Identity-Based Encryption Architecture 2439 and Supporting Data Structures", RFC5408, January 2009. 2441 [SAML-over] OASIS, Security Assertion Markup Language (SAML) Version 2442 2.0 Technical Overview 2443 [XACML-core] OASIS, eXtensible Access Control Markup Language (XACML) 2444 Version 3.0 Core Specification 2446 Appendix B Authors' Addresses 2448 Trevor Freeman 2450 Microsoft Corp. 2452 Email: trevorf@microsoft.com 2454 Jim Schaad 2456 Soaring Hawk Consulting 2458 Email: ietf@augustcellars.com 2460 Patrick Patterson 2462 Carillon Information Security Inc 2464 Email: ppatterson@carillon.ca 2466 Appendix C Document Change History 2468 Added general data model (section 4) Added regulated industry Email 2469 scenario (section 3.4 Split requirements into general requirements 2470 and Email specific requirements Cleaned up scenarios to differentiate 2471 requirements and workflow Fixed multiple document nits from Jim 2472 Schaad Need a paRAGRAPH on namespaces to deal with SAML attributes of 2473 different names with same semantics Don't use a proxyf5 tls offload. 2474 Define a proxy in arch Made changes from XACML TC to better align 2475 terminology Cleaned up integrity scenario Merged the two vocabulary 2476 sections into a single section Added LOA for key exchange Added the 2477 forward proxy to the architecture addressed [anchor21] comment by 2478 clarifying text in paragraph 1.2 Addressed [anchor22] comment by 2479 clarifying text in paragraph 2.4 Addresses [anchor23] comments by 2480 clarifying text in section 4. Addresses [anchor24] comment by 2481 clarifying text in section 3. Completed the scalable policy decision 2482 making scenario (3.10) Added Email compliance scenario (3.7)