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