idnits 2.17.1 draft-freeman-plasma-requirements-09.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 223 has weird spacing: '...tifiers as th...' == Line 430 has weird spacing: '...) which is a...' == Line 765 has weird spacing: '...ith the expor...' == Line 907 has weird spacing: '... policy when ...' == Line 1147 has weird spacing: '...here to act a...' == (7 more instances...) -- The document date (February 13, 2014) is 3718 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC3198' on line 2041 looks like a reference -- Missing reference section? 'RFC5751' on line 2056 looks like a reference -- Missing reference section? 'RFC5652' on line 2051 looks like a reference -- Missing reference section? 'RFC5750' on line 2053 looks like a reference -- Missing reference section? 'RFC5280' on line 2045 looks like a reference -- Missing reference section? 'RFC3114' on line 2072 looks like a reference -- Missing reference section? 'SAML-core' on line 2059 looks like a reference -- Missing reference section? 'XACML-core' on line 2079 looks like a reference -- Missing reference section? 'RFC5408' on line 2074 looks like a reference -- Missing reference section? 'RFC5322' on line 2049 looks like a reference -- Missing reference section? 'RFC2119' on line 2039 looks like a reference -- Missing reference section? 'RFC5035' on line 2043 looks like a reference -- Missing reference section? 'SAML-over' on line 2077 looks like a reference Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Freeman 3 Internet-Draft Microsoft Corp. 4 Intended status: Informational J. Schaad 5 Expires: August 17, 2014 Soaring Hawk Consulting 6 P. Patterson 7 Carillon Information Security Inc 8 February 13, 2014 10 Requirements for Message Access Control 11 draft-freeman-plasma-requirements-09 13 Abstract 15 S/MIME has a proven track record in delving confidentiality, integrity 16 and data origination authentication for email. However, there are many 17 situations where organizations want robust access control applied to 18 information in messages. The Enhanced Security Services (ESS) RFC5035 19 for S/MIME defines an access control mechanism for email, but the 20 access check happens after the data is decrypted by the recipient 21 which devalues the protection afforded by the cryptography and 22 provides very week guarantees of policy compliance. Another major 23 issues for S/MIME is its dependency on a single type of identity 24 credential, an X.509 certificate. Many users on the Internet today do 25 not have X.509 certificates and therefore cannot use S/MIME. 26 Furthermore, the requirement to discover the X.509 certificate for 27 every recipient of an encrypted message by the sender has proven to be 28 an unreliable process for a number of reasons. 30 This document presents requirements for an alternative model to ESS to 31 address the identified issues with access control to deliver more 32 robust compliance with S/MIME protected messages. This document 33 describes an access control model which uses cryptographic keys to 34 enforce access control policy decisions where the policy check is 35 performed prior to the decryption of the message contents. The model 36 also abstracts the specifics of the authentication technology thereby 37 removing the dependency on X.509 certificate making it possible for 38 other forms of credential to be used for S/MIME enabling much broader 39 adoption. This model can be instantiated in many areas using existing 40 standards, or with only minor updates to existing standards. This 41 model in not intended to be a one off just for email and can also be 42 applied to other data types. The model also removes the dependency on 43 the need to discover encryption certificates at send time. 45 The name Plasma was assigned to this effort as part of the IETF 46 process. It is derived from PoLicy enhAnced Secure eMAil. 48 Status of this Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering Task 53 Force (IETF), its areas, and its working groups. Note that other 54 groups may also distribute working documents as Internet-Drafts. The 55 list of current Internet- Drafts is at 56 http://datatracker.ietf.org/drafts/current/. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 The list of current Internet-Drafts can be accessed at 64 http://www.ietf.org/1id-abstracts.html 66 The list of Internet-Draft Shadow Directories can be accessed at 67 http://www.ietf.org/shadow.html 69 Copyright Notice 71 Copyright (c) 2014 IETF Trust and the persons identified as the 72 document authors. All rights reserved. 74 This document is subject to BCP 78 and the IETF Trust's Legal 75 Provisions Relating to IETF Documents 76 (http://trustee.ietf.org/license-info) in effect on the date of 77 publication of this document. Please review these documents 78 carefully, as they describe your rights and restrictions with respect 79 to this document. Code Components extracted from this document must 80 include Simplified BSD License text as described in Section 4.e of the 81 Trust Legal Provisions and are provided without warranty as described 82 in the Simplified BSD License. 84 Table of Contents 86 1 Policy Based Management Vocabulary . . . . . . . . . . . . . . . 4 87 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 6 88 3. Access Control Models . . . . . . . . . . . . . . . . . . . . . 10 89 3.1 Generic Access Control Model . . . . . . . . . . . . . . . . 11 90 4 Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . . . 14 91 4.1 Consumer to Consumer Secure Email . . . . . . . . . . . . . 14 92 4.2 Business to Consumer Secure Email . . . . . . . . . . . . . 15 93 4.3 Business to Business Ad-Hoc Email . . . . . . . . . . . . . 16 94 4.4 Business to Business Regulated Email . . . . . . . . . . . . 17 95 4.5 Delegation of Access to Email . . . . . . . . . . . . . . . 22 96 4.6 Email Compliance Verification . . . . . . . . . . . . . . . 22 97 4.7 Email Pipeline Inspection . . . . . . . . . . . . . . . . . 23 98 4.8 Distribution List Expansion . . . . . . . . . . . . . . . . 24 99 4.9 Scalable Decision Making . . . . . . . . . . . . . . . . . . 24 100 5 Plasma Security Model . . . . . . . . . . . . . . . . . . . . . 25 101 5.1 Plasma Client/Server Key Exchange Level of Assurance . . . . 32 102 5.2 Policy Data Binding . . . . . . . . . . . . . . . . . . . . 32 103 5.3 Content Creation Workflow . . . . . . . . . . . . . . . . . 34 104 5.4 Content Consumption Workflow . . . . . . . . . . . . . . . . 36 105 5.5 Plasma Proxy Servers . . . . . . . . . . . . . . . . . . . . 37 106 5.6 Policy Types . . . . . . . . . . . . . . . . . . . . . . . . 39 107 6 Message Protection Requirements . . . . . . . . . . . . . . . . 40 108 6.1 General Requirements . . . . . . . . . . . . . . . . . . . . 40 109 6.2 Basic Policy Requirements . . . . . . . . . . . . . . . . . 42 110 6.3 Advanced Policy Requirements . . . . . . . . . . . . . . . . 43 111 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 44 112 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 44 113 Appendix A. References . . . . . . . . . . . . . . . . . . . . . 45 114 A.1. Normative References . . . . . . . . . . . . . . . . . . . 45 115 A.2. Informative References . . . . . . . . . . . . . . . . . . 46 116 Appendix B Authors' Addresses . . . . . . . . . . . . . . . . . . 47 118 Keywords 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119. 124 1 Policy Based Management Vocabulary 126 This document uses the established terminology for policy based 127 management [RFC3198] where applicable. The following list supplements 128 the terms defined in [RFC3198] as well as defining some new 129 combinations of terms used in [RFC3198]. 131 Attribute Based Where the access control policy is specified 132 Access Control by a set of attributes, their values, and any 133 (ABAC) relationship between attributes required to 134 authorize an action on a resource. These 135 attributes may be provided by the subject as part 136 of the decision request (Front End Attribute 137 Exchange) or discovered by the policy decision 138 service itself (Back End Attribute Exchange). The 139 policy, for example, may require attributes about 140 the subject, their device or environment, a 141 resource, or the intended use of the information. 143 Back End Attribute When subject attributes are directly sent from 144 Exchange (BAE) the Policy Information Point (PIP) to the Policy 145 Decision and Enforcement Point (PDEP) i.e. they 146 are not relayed via the Decision Requestor (DR). 148 Capability Based Where access control is via a communicable, 149 Access Control unforgeable token. A capability token is a 150 (CBAC) protected object which, by virtue of its 151 possession by a subject, grants that subject the 152 capability. 154 Decision Requester The service responsible for making policy 155 (DR) decision requests to the PDEP. In this model the 156 policy decision is enforced by the PDEP by its 157 control of cryptographic keys. The DR enforces any 158 obligations the PDEP may require such as signing 159 or encryption of the data, generating audit events 160 etc. A DR is distinct from a PEP in other models 161 such as XACML in that a DR is not by default 162 trusted with the clear text data. Policy 163 enforcement is performed by the PDEP. A DR may 164 establish trust by presentation of attributes 165 about itself and its environment to show it is 166 trustworthy. 168 Front End Attribute When subject attributes are relayed by the DR 169 Exchange (FEE) from the PIP to the PDEP i.e. they are not sent 170 directly. 172 Level of Assurance A quality grade assigned following the completion 173 (LoA) of a security evaluation. For example, it can be 174 used for an Identity where it provides the quality 175 of the identity of a subject. It can also be used 176 to represent the quality of a products or services 177 Common criteria evaluation. 179 Metadata Metadata is data about data. There are three kinds 180 of metadata. 182 (1) Content metadata is metadata about an instance 183 of data, the actual data content. An example of 184 content metadata would be "this data contains 185 Company Foo intellectual Property" or " this is a 186 patient record". 187 (2) Policy metadata is metadata about the policies 188 to apply to an instance of data. An example of 189 policy metadata would be "apply Company Foo XYZ 190 policy". 191 (3) Structural metadata is metadata about the 192 design and specification of the data. An example 193 of structural metadata would be "this is a patient 194 record table". 196 Orthonym The correct or legal name of a place, person or 197 thing. (See Pseudonym.) 199 Policy The system entity that creates, maintains, and 200 Administration publishes policies or policy collections. The 201 Point (PAP) policies define the rules, their conditions, and 202 actions associated with the policy. 204 Policy Collection A collection of one or more policies which is 205 associated with a role. The policy collection may 206 also define the logical relationship between the 207 policies. Each collection is identified by a name 208 known as a role name. 210 Policy Decision The system entity that evaluates the policy 211 and Enforcement criteria published by a PAP, using attributes 212 Point (PDEP) supplied by a PIP to render decisions on requests 213 made by DRs. The PDEP is able to enforce its 214 decision via the use of cryptographic keys. 216 Policy Identifier The tag that is used to identify a policy. For the 217 purposes of this document the focus is on two 218 different types of policy identifiers. Object 219 Identifiers (OIDs) are what are currently used in 220 many security policy systems and are the only 221 method of policy identification supported by ESS 222 security labels. Additionally URIs are supported 223 as policy identifiers as they provide a more 224 user-friendly method to uniquely identify a policy 225 and allow discovery of the policy. 227 Policy Information A service which issues assertions, for example 228 Point (PIP) about a subject, their device, or environment 229 e.g., a LDAP directory or SAML Security Token 230 Service. 232 Policy Label The data structure which holds one or more policy 233 identifiers and their logical relationship. 235 Pseudonym A name that a person or group assumes for a 236 particular purpose, which differs from their 237 original or true name. (See Orthonym.) 239 Role Token A token issued to a subject containing one or more 240 Policy Collections. The role token is used as part 241 of policy discovery and management in Plasma. It 242 is not used as part of access control decisions in 243 any way. 245 2 Introduction 247 The S/MIME standard [RFC5751] provides a method to send and receive 248 secure MIME messages. S/MIME uses CMS[RFC5652] as the means to protect 249 the message. While CMS allows for many types of key exchange 250 mechanisms to be used, S/MIME [RFC5750] exclusively uses X.509 251 certificates [RFC5280] for the security credentials for signing and 252 encryption operations. S/MIME also uses an early binding mechanism 253 for encryption keys where the sender needs to discover the public key 254 for every recipient of an encrypted message before it can be sent. 255 This requires the sender to maintain a cache of all potential 256 recipient certificates (e.g. in a personal address book) and/or have 257 the ability to find an acceptable certificate for every recipient from 258 a repository at message creation. This key management model has 259 limited the use of S/MIME for encryption for a variety of reasons and 260 is a major factor on the lack of adoption for S/MIME. The S/MIME key 261 management model is fragile For example: 263 o The recipient may not have an X.509 encryption certificate 264 o The sender may not have previously received a signed email with the 265 recipient's certificate 266 o The recipient may not have an available repository from which to 267 publish their certificate for senders to discover 268 o The sender may be unaware of the location of the recipient's 269 repository 270 o The recipient's repository may not be accessible to the sender, 271 e.g., it's behind a firewall 272 o The sender may not have a valid certificate path to a trust anchor 273 for the recipient's certificate 275 If one or more recipient certificates are missing, then the sender is 276 left with a stark choice: send the message unencrypted or remove the 277 recipients without valid certificates from the message. 279 The use of secure mailing lists has the ability to provide some relief 280 to the problem. The original sender does not need to know the 281 appropriate encryption information for all of the recipients of the 282 mailing list, just for the mailing list itself. It can thus be 283 thought of as a form of late-binding of recipient information for the 284 originating sender. However it is still early-binding encryption for 285 the mail list agent; as it needs to perform all of the gathering and 286 processing of certificate information for every recipient that the 287 agent will relay the message to. 289 In many regulated environments end-to-end confidentiality between 290 sender and recipients by itself is not enough. The regulatory policy 291 requires some form of access control check before access to the data 292 should be granted. In many inter-organization collaboration scenarios 293 it's impossible for the sender to satisfy the access checks on behalf 294 of all recipients since they don't have, and frequently should not 295 have access to, all the recipient's attributes because to do so may be 296 a breach of the recipients privacy. Indeed to release the attributes 297 to the sender may require that the sender's attributes first be 298 released to the recipient's attributes provider. It's a fundamental 299 tenet of good security practice that users should control the release 300 of data about themselves. 302 ESS Security labels are an optional security service for S/MIME. The 303 ESS security label allows classification of the sensitivity of the 304 message contents using a hierarchical taxonomy in terms of the impact 305 of unauthorized disclosure of the information [RFC3114]. The security 306 label can also indicate access control policy. ESS security labels 307 are authenticated attributes of a CMS signer-info structure in a 308 SignedData object. The label when applied to signed clear text data 309 provides the access control decisions for the plain text. If applied 310 to cipher text such as the outer layer of a triple wrapped S/MIME 311 message the label is used for coarse grained optimization such as 312 routing. 314 ESS Security Labels have been found to have a number of limitations. 316 1. When the label is on the innermost content, access to the plain 317 text is provided to the recipient (in some form) independent of 318 the label evaluation as it will be processed for the purpose of 319 hash computation as part of signature validation. Depending on 320 how a triple wrapped message is processed by the recipient's CMS 321 code, the inner content may be processed for signature validation 322 even before the outer signature is validated. This would happen 323 for a stream based CMS processor which starts processing inner- 324 layers immediately rather than finishing processing of each layer 325 and caching the intermediate results. 327 2. While labels cannot altered, they can be removed in transit. If a 328 signed layer is seen then it can be removed by any agent that 329 processes the message (such as a Message Transfer Agent). If the 330 label is protected by an encryption layer then it can only be 331 removed by any agent that has a decryption key (Encryption Mail 332 List agents or Spam Filtering software would be two such 333 examples). 335 3. Policies are identified by Object Identifiers. This makes for a 336 small tight encoding, but it does not provide any mechanism for an 337 email client to discover how to enforce a access control policy if 338 the message contains a policy the client is unaware of. This 339 provides an impossible choice: ignore the access control policy 340 and grant access to the message or block access to the message. 341 Object identifiers also do not provide a good display name for a 342 user so that they could manually find and download a new policy. 344 4. The current ESS standard only allows for a single policy label in 345 a message; no standardized method of composing multiple policy 346 labels together has been defined. This is adequate for coarse- 347 grained policy binding to express a limited set of choices such as 348 with information sensitivity which typically provides a hierarchy 349 of 3-5 choices. Many data sets need to be subject to multiple 350 access control policies. For instance, a message may contain 351 information that is both propriety and export controlled. Trying 352 to represent combinations of policies via a single policy label 353 would lead to an exponential growth in the number of policy 354 labels. 356 5. ESS Labels do not provide for any robust auditing of who has been 357 granted access to the message. All policy evaluation is local to 358 the recipient's machine; no centralized logging of access to the 359 message can be performed 361 6. The biggest issue with ESS labels is enforcement of the policy 362 occurs on the recipient's machine; the compliance with the policy 363 is dependent on the state of the configuration of every receiving 364 agent. The policy is enforced by whatever module is located on 365 the user's system. For cross corporate systems, this means that 366 the policy provided by Company A must be installed on Company B 367 machines, or Company B must install a policy that Company A will 368 accept as being equivalent to their own policy. Additionally, any 369 time that a new version of the policy module is rolled out, there 370 will be a time lag before every recipients machine will have the 371 updated module. This makes policy compliance practically 372 impossible in anything but a small, closed environment. 374 From a regulatory enforcement perspective, ESS labels are an extremely 375 weak form of access control because cryptographic access to the data 376 is given before the access check. The correct enforcement of the 377 access check is dependent on the configuration of every recipient's 378 email client. Since the cryptographic access is granted before the 379 access policy check, there is no cryptographic impediment for a 380 recipient who is able to decrypt the data but is unauthorized under 381 the policy, to ignore the policy and access the data. A stronger 382 enforcement model is needed for regulatory control for email where 383 cryptographic access is only granted after the access check is 384 successful. 386 S/MIME today can only use X.509 certificates to protect the 387 confidentiality or the data origin authentication and integrity of the 388 messages. There are many users on the Internet today who have other 389 forms of authentication credentials. This means the many users without 390 X.509 certificates cannot use S/MIME. There have been many 391 developments in authentication technology and best practices since 392 S/MIME was developed over a decade ago, and example of which is SAML 393 [SAML-core]. The critical difference between SAML and X.509 394 certificates is that SAML abstracts the details of the authentication 395 protocol from the protocol. The PIP can use a broad range of 396 authentication mechanisms such as passwords, one-time passwords, 397 biometrics, X.509 certificates, etc., to authenticate the subject 398 without impacting the protocol. Adopting the abstraction abstraction 399 model for S/MIME would enable almost anybody with any kind of 400 authentication credential registered with one of the many identity 401 provider on the Internet today to use S/MIME making it possible that 402 S/MIME use may become as pervasive as TLS is today. 404 There are many other non-email use cases which would be subject to the 405 same access policy requirements. Email allows users to create content 406 and distribute it to a set of recipients. Similar use cases can be 407 performed with other data formats or applications such as documents 408 and instant messages. Policy is tied to the information not the data 409 format or application therefore if an organization has a policy 410 relating to a type of information, then that same policy would apply 411 to the same information in any form; email, document, or instant 412 message. While some aspects of this work will be specific to email, 413 there will be many which would be reusable in other areas. 415 3. Access Control Models 417 Access control is the process whereby systems are able to decide 418 whether to grant a request to access a resource from a subject. There 419 are a number of models the system can follow to make the decision. 420 These are two types of models, those based on a subject attributes and 421 those based on a subjects capabilities. For models based on subject 422 attributes, the system obtains a set of attributes about the subject 423 then applies a policy expression using the attributes as input to the 424 policy to determine the result. For model based on subject 425 capabilities, the subject has an unforgeable token or reference to a 426 token attesting to an access to a resource. 428 The simplest model based on subject attributes is Discretionary Access 429 Control (DAC) where attributes are the subjects group membership and 430 the policy is expressed as an Access Control List (ACL) which is a 431 list of groups and grants (or deny's) access to individual groups. The 432 list is evaluated sequentially, and the first match is the result. 433 Role Based Access Control (RBAC) is a refinement of DAC where the roll 434 is an abstract subject which is granted a set of permissions. The role 435 used to simplify management, in essence it is a collection of groups. 436 Attribute Based Access Control (ABAC), where policies are defined in 437 terms of arbitrary attributes of the subject, their device or 438 environment, their intended action on or use of the information. ABAC 439 requires the definition of the policy in a policy expression language 440 e.g. eXtensible Access Control Markup Language [XACML-core]. ABAC 441 also requires a secure way to exchange arbitrary attributes e.g. via 442 the Security Assertion Markup Language [SAML-core] or via an LDAP 443 directory. 445 SAML [SAML-core] defines an XML framework for describing and 446 exchanging assertion tokens containing attributes. The entity issuing 447 the assertion tokens is a Policy Information Point. The entity 448 consuming the assertion with the attributes is known as the relying 449 party (RP). The well-known scenarios for using SAML are: 451 o Single Sign On across systems on different platform technology 452 o Federated Identity between business partners 454 o Web Services and other standards, e.g., -SOAP based protocols 456 SAML tokens can be either Bearer Tokens or Holder-of-Key tokens. 457 Bearer tokens have no cryptographic key and their security is based on 458 the time between when the token was issued and time it was presented 459 to the relying party together with the token being issued for use with 460 the RP. Low value transactions can use Bearer tokens where possession 461 of the token alone is considered acceptable for the transaction risk. 462 Holder-of-Key tokens contain a cryptographic key (either public or 463 symmetric) and like X.509 identity certificates the subject proves 464 their identity to the RP by demonstrating control over the key e.g. 465 signature or HMAC over some data. The RP can therefor have a stronger 466 proof of identity by the demonstration of proof of possession of 467 cryptographic keys. SAML can also be used to express attributes about 468 a subject to a RP where the subject has authenticated to the RP by 469 some means. 471 3.1 Generic Access Control Model 473 The terminology defined in [RFC3198] uses a generic information model 474 for the actors and the way they relate to each other. 476 ------------------ 477 | | 478 | Policy | 479 | Administration | 480 | Point | 481 | | 482 ------------------ 483 ----------------- | 484 | | | 485 | Policy | | Read 486 | Information | | Policy 487 | Point | | 488 | | | 489 ----------------- v 490 | | v 491 | | ----------------- 492 | | | | 493 | | Back end Exchange | Policy | 494 | ------------------------->>| Decision | 495 | Issue | Point | 496 | Attributes | | 497 | ----------------- 498 | ^ 499 | Front End ^ Decision 500 | Exchange | Request + 501 v | Attributes 502 v | 503 ----------------- ----------------- 504 | | Request + | | 505 | Subject | Attributes | Policy | 506 | Decision | -------------->>| Enforcement | 507 | Requestor | | Point | 508 | | | | 509 ----------------- ----------------- 511 Figure 1 Generic Access Control Model 513 o Administrators manage and publish policies using the PAP. The 514 published polices are then available to the PDP 515 o A decision requestor sends a request together with their attributes 516 to the PEP 517 o The PEP sends a decision request to the PDP together with the 518 subject attributes 519 o The PDP obtains the necessary policy from the PAP 520 o The PDP can request additional attributes from the PIP 521 o The PDP returns the decision request to the PEP 522 o The PEP enforces the decision request 523 This generic model assumes the PEP has control over the data i.e. when 524 it gets the permit decision it releases the data to the subject. This 525 works well is client-server situations like access to a web site or 526 database where there is a clear trust boundary between the subject and 527 the PEP with the data. However it does not work well with applications 528 like email were there the data is delivered to the subject prior to 529 the access check. The model need to be extended to allow the data to 530 be encrypted and the access check be performed prior to release of the 531 decryption key. 533 A dependency in the model is the reliability of the policy selection 534 for the request by the PDP. The implementation of the policy selection 535 process can make either a closed or open world assumption. Closed 536 world assumes the policy set on the PDP is complete therefore there is 537 a policy in the store for every request. Open world assumes it is the 538 policy store is incomplete and there is a need to discover new polices 539 as appropriate. Closed world implementations work when there is 540 reasonable control over the sets of data managed by the PEP and 541 policies known to the PDP. However they result in unreliable results 542 with mobile data i.e. if I receive data from a partner and try to 543 process it via my PEP and PDP. There is no linkage between the 544 distribution of the data and the distribution of he polices in closed 545 world models. 547 Access control models based on subject attributes depend availability 548 of assertions with attributes about subjects. The model has PIP 549 issuing attributes about subjects and RP consuming attributes about 550 subjects. A subject can be a human, a device or service. The subject 551 must have a relationship with the PIP since they have been through 552 some form of registration process with the PIP. There is no 553 requirement to have a relationship between the PIP and a RP. The RP 554 must trust the PIP, but not vice versa. This is the same model as 555 exists with X.509. The subject must have a relationship with the CA, 556 the RP must trust the certificates issued by the CA, but there is no 557 requirement for the CA to have any form of relationship or trust with 558 the RP. Release of subject attributes to a RP must be under a policy 559 due to the sensitivity of the data. The subjects themselves can 560 request and give approval for the release of attributes from the PIP 561 and relay them to the RP (Front End Attribute Exchange). If the 562 subject has given prior consent, the RP may receive attributes 563 directly from the PIP(Back end Attribute Exchange). Subject 564 attributes are potentially sensitive data as are similarly subject to 565 access control. SAML has the capability to encrypt sensitive data in 566 the token. The PIP would also develop policy to regulate the set of 567 data it would release to a RP. 569 The challengers for S/MIME is therefore 570 o How to apply this generic access control model to the email 571 scenarios so there is convergence with other applications i.e. 572 email access control is not a one off vertical solution 574 o How to ensure the access check is possible prior to the recipient 575 having access to the clear text so the access check is robust for 576 regulators 578 o How to abstract the authentication credential technology use from 579 the S/MIME protocol to enable use of the many forms of 580 authentication in widespread use today on the Internet. 582 4 Use Case Scenarios 584 This section documents some email based use cases that the new 585 protocol aims to support. Also included are some related scenarios 586 where the same underlying theme of consistent policy enforcement 587 equally applies. 589 4.1 Consumer to Consumer Secure Email 591 One of the issues that is stopping the use of secure email in 592 personal mail is the fact that consumers find X.509 certificates 593 difficult and expensive to obtain and then use - especially across 594 a set of devices (phone, tablet, workstation). One of the possible 595 use cases of Plasma is to try and deal with this by removing the 596 dependency on X.509 certificates. The details of the use case are 597 therefore: Alice wants to send an email message to Bob that 598 contains sensitive, personal data so she is concerted about 599 ensuring only Bob can read it. Bob has a strong credential he can 600 use to identity himself, but it's not an X.509 certificate. Alice 601 needs to ensure the following: 603 (a) Only Bob can read the email. 604 (b) Bob has the ability to verify the email is from Alice. 605 (c) Bob has the ability to verify the email message has not been 606 modified since Alice sent it. 608 The sequence of events could be as follows: 610 1. Alice composes the email to Bob. 611 2. Alice's email client allows here to classify the email. Alice 612 classifies the email as Personal Communication which is a policy 613 provided by her ISP. 614 3. Alice's email client knows the protections to apply to a Personal 615 Communication; it knows to encrypt and sign the message. 616 4. The protected email is able to flow securely and seamlessly 617 through existing email infrastructure to Bob. The data is 618 protected while in transit and rest. 619 5. Bob receives the email and sees that it is a secure message. Bob 620 can verify that the secure message has not been altered. Bob 621 attempts to open and decrypt the email. If Bob is on the same 622 ISP as Alice, then the same username/password as he uses to get 623 his Email is used to obtain the needed keys. If Bob is on an ISP 624 that is federated with Alice's ISP then an infrastructure such as 625 SAML, OpenID, OAUTH or ABFAB could be used to validate Bob's 626 identity and allow the needed decryption keys to be released. 628 4.2 Business to Consumer Secure Email 630 There are many examples of business-to-consumer secure email scenarios 631 where the email could potentially contain sensitive medical or 632 financial data. This would include doctor-patient; bank-account 633 holder; Medical insurance-insured person and mortgage broker-customer 634 communications. This example is illustrative of the many use cases for 635 business to consumer email. 637 A bank (The Bank of Foo) has determined that it will be using email to 638 distribute statements to its customers (Bob). The information is 639 confidential, so any channel of communication the bank selects must 640 protect Bob's privacy. The bank needs to ensure the following: 642 (a) Only Bob (or additional owners of the account) can read the email 643 (b) Bob authenticates with a sufficient level of identity assurance. 644 The same identity assurance authentication level used to do on- 645 line banking would be considered sufficient 646 (c) Bob can verify the statement is from his bank 647 (d) Bob can verify the statement has not been modified since his bank 648 sent it. 650 The sequence of events would be as follows: 652 1. As part of routine end-of-the-month processing, the bank composes 653 an email to Bob. They include the statement of balances and 654 activity either as an attachment or as the body of the message. 655 2. The statement mailer for the Bank of Foo has been configured to 656 apply a specific policy to the email. 657 3. The statement mailer for the Bank of Foo knows the protections to 658 apply based on the policy; it knows to encrypt and integrity 659 protect the message and what level of assurance is required for 660 the recipient's identity. 661 4. The protected email is able to flow securely and seamlessly 662 through existing email infrastructure to Bob. The data is 663 protected while in transit and at rest. 664 5. Bob receives the email and sees it is a secure message from the 665 Bank of Foo. Bob can verify the message has not been altered as 666 it is signed by his bank. Bob uses the same credential as he 667 would for on-line banking to prove his identity to the email 668 system and obtain the keys necessary to decrypt the message. 670 The same process could be used for any messages sent between the 671 business or organization and and its customers. Thus, messages 672 dealing with loan applications and changes in bank policies can be 673 sent out in the same manner, potentially using different policies. In 674 some of these cases it might be in the bank's interests to record in 675 an audit trail if and when the keys were handed out on certain emails. 676 For a statement, the bank would not expect a reply to occur, however, 677 for other types of messages it should be possible for Bob to reply 678 under the same level of protection. Bob is able to use the same 679 credential when sending or replying to a message from the bank, as he 680 uses for accessing the bank's Web site then the bank has the same 681 assurance of Bob's identity for all transactions. 683 4.3 Business to Business Ad-Hoc Email 685 Early in the relationship between two companies, it is frequently 686 necessary to exchange sensitive information as a preliminary to a more 687 formal business relationship e.g., contract negotiations. This is 688 similar guarantees to the security afforded by mail, i.e., you enclose 689 a letter in a envelop which provides a level of security to the 690 contents while in transit, there is a level of expectation that only 691 the recipients or their delegate would open the envelope, once the the 692 recipient has the letter, you trust them to treat the contents 693 appropriately. 695 As an example, Charlie works for Company Foo. He has just met Dave 696 from Company Bar to discuss the prospect of a potential new business 697 opportunity. Following the meeting, Charlie wants to send Dave some 698 sensitive information relating to the new business opportunity. 699 Charlie trusts Dave to treat the information appropriately. When 700 Charlie sends the email to Dave with the sensitive content, he must 701 ensure the following objectives: 703 (a) Only Dave or his delegate can read the email 704 (b) Dave or his delegate is required to authenticate with an identity 705 assurance level 2 or above 706 (c) That Dave can verify the email is from Charlie 707 (d) That Dave can verify the email has not been tampered with 708 (e) Charlie may also need to keep a record of the fact that Dave 709 accessed the message and when it was done. 711 The sequence of events Charlie would use is as follows: 713 1. Charlie composes the email to Dave. He include some sensitive 714 information relating to potential terms and conditions for the 715 new contract that Foo and Bar would sign to form a partnership 716 for the business opportunity. 717 2. Charlie's email client allows him to classify the email. He 718 classifies the email as an ad-hoc pre-contractual communication. 719 3. Charlie's client knows the protections to apply to ad-hoc pre- 720 contractual communication; it knows to encrypt and integrity- 721 protect the message and the level of assurance required for the 722 recipients identity. 723 4. The protected email is able to flow securely and seamlessly 724 through existing email infrastructure to the recipient (Dave in 725 this case). The data is protected while in transit and at rest. 726 5. Dave receives the email and sees it is a secure message from 727 Charlie. (Charlie policy requires level 2 authentication for 728 which, Dave uses a password). Dave is able to prove his identity 729 to the level of assurance requested by Charlie so he is able to 730 read the email. The organization Dave works for has an identity 731 service which he uses to prove his identity for Charlie's email. 732 Dave opens the email. 734 If Dave or his delegate replies to the email from Charlie, the new 735 message inherits the policy from the original messages so the entire 736 message thread has the same policy. The policy also applies to 737 messages forwarded by Dave because it contains information from 738 Charlie and Company Foo wants consistent policy enforcement on its 739 information. 741 4.4 Business to Business Regulated Email 743 As business relationships mature they often result in a formal 744 contractual agreement to work together. Contractual agreements would 745 define a number of work areas and deliverables. These deliverables may 746 be subject to multiple corporate and/or regulatory policies for access 747 control, authentication and integrity. Some classes of email may have 748 information which is legally binding or the sender needs to 749 demonstrate authorization to send some types of message where 750 authority to send the message is derived from their role or function. 751 Also many regulated environments need to be able to verify the 752 information for an extended period - well beyond the typical lifetime 753 of a user's certificate. The set of policies applicable to an email 754 is potentially subject to change as the different user's contribute 755 information to the email thread. 757 4.4.1 Regulated Email Requiring a Confidentiality Policy 759 Company Foo has been awarded a contract to build some equipment 760 (Program X). The equipment is covered by export control which 761 requires information only be released to authorized recipients under 762 the terms of the export control license. Company Bar is a foreign 763 subcontractor to Company Foo working on Program X. Company Foo sets up 764 some business rules for access to program X data to ensure compliance 765 with the export control license requirements. Company Foo also set 766 up separate rules to cover the confidentiality of its intellectual 767 property contributed to Program X. Company Bar also sets up its own 768 policies to protect the confidentiality of its own intellectual 769 property it contributes to Program X. As part of the agreement between 770 Foo and Bar, they have agreed to mutually respect each other's 771 policies. 773 Confidentiality policies can change over time. It is important to be 774 able to implement the changes without the need to update the data 775 itself to reflect the change as finding all instances of the data in 776 an intrinsically impossible problem to solve. 778 Frank is an employee of Company Foo. He has been assigned as a design 779 team leader on Program X and as an individual contributor on Program X 780 integration. Frank wants to send some email as a team leader to 781 colleagues working on Program X in both Companies Foo and Bar. 783 Grace is an employee of Company Bar. She has also been assigned to the 784 design team of Program X. 786 When Frank sends the email with Program X regulated content he must 787 ensure compliance with the export control policies. When Frank sends a 788 Program X email he must ensure recipients are authorized to read the 789 contents to ensure Company Foo remains in compliance with its export 790 control license. 792 If Frank also includes Company Foo intellectual property in an email, 793 he must also ensure recipients are authorized to read the 794 intellectual property contents. 796 When Grace receives a Program X email, she must provide attributes 797 about herself to prove compliance with the export control policy. If 798 the email also contains Company Foo intellectual property, she must 799 also provide attributes to show she is authorized to read the 800 information under the agreement between Company Foo and Company Bar. 801 Grace would not know the complete set of attributes, so would start 802 with a basic set to identify herself. The PDEP may be able to discover 803 more attributes about Grace, and if it is still missing some, it can 804 request those from Grace. 806 If Grace sends an email with Company Bar intellectual property, she 807 must ensure recipients are authorized to read the contents under the 808 agreement between Company Bar and Company Foo. 810 When Frank sends a Program X email he must ensure the following 811 objectives: 813 (a) Only recipients who meet the Program X export control policy 814 and/or Company Foo's intellectual property protection policy can 815 read the email. 816 (b) Recipients authenticate with a identity assurance level 3 or 817 above. 818 (c) Recipients present all other attributes about themselves 819 necessary to verify compliance with the applicable policies 820 (their program assignment, nationality, professional or industry 821 certifications, etc.). 822 (d) Recipients can verify the email is from Frank to the level of 823 identity assurance as defined by the message policy (i.e., level 824 3 or above). 826 (e) Recipients can verify the email has not been tampered with to the 827 level of identity assurance as defined by the message policy. 828 (f) Recipients are made aware that the message is a Program X email 829 (and the contents can only be shared with other Program X 830 workers) and/or the message contains Company Foo's intellectual 831 property. 833 The sequence of events Frank would use is as follows: 835 (1) Frank composes the email and includes a Program X distribution 836 list as a recipient. He include some information related to 837 Program X. Frank also includes some information which is Company 838 Foo's Intellectual Property. 839 (2) Frank's email client allows him to select the Program X role. The 840 client then allows Frank to select from a set of policies 841 appropriate for Program X. 842 (3) Frank selects the Program X content and Company Foo IP policies 843 from the list of available policies. 844 (4) The email client knows to encrypt the message, the key size and 845 algorithm to use. It also knows that the message needs to be 846 signed with a level 3 or above private key. 847 (5) Frank clicks the "send email" button. The client signs the email 848 using his smart card private key and includes the certificate 849 with the appropriate public key for verification of the signature 850 by recipients. The Client then encrypts the message and obtains 851 data from a server that will enforce the access control 852 requirements for Frank, and sends it to his email server. 854 The email is able to flow securely and seamlessly through existing 855 email infrastructure to recipients of the distribution list. Grace is 856 on the distribution list so she receives the email from Frank. 858 (6) Grace receives the email. Grace's client provides the attributes 859 necessary to comply with the policy which includes her level 3 860 encryption certificate to the PDEP. 861 (7) Once Grace has shown she passes the policy requirements, the PDEP 862 releases the message CEK to Grace using her level 3 encryption 863 certificate. 864 (8) Grace uses her smart card to open the message. She sees the 865 message is signed by Frank and marked with both the Program X and 866 Company Foo IP policies 868 If Grace replies to the email from Frank, the new message inherits the 869 policy from the original message. If Grace includes some information 870 which is Company Bar's IP she also adds her company's IP protection 871 policy requirements to the message. 873 Frank receives the reply from Grace. Frank is able to prove his 874 identity to the level requested by Grace and provides the requested 875 attributes about himself to satisfy both the Program X export control, 876 the Company Foo IP protection policies, as well as the Company Bar IP 877 protection policies. Frank opens the email. 879 The policy also applies to messages forwarded by Frank and Grace 880 because they contain information from Company Foo and Company Bar and 881 both companies wants consistent policy enforcement on their 882 information. 884 After some time, Company Bar fails an audit to show they are complying 885 which all the requirements for Program X. As a result, Company Foo 886 updates its policies for Program X to remove Company Bar as an entity 887 approved to access Program X data. Grace will no longer be able to 888 receive CEKs for Program X email as she can no longer satisfy the 889 Program X policy requirements. 891 4.4.2 Regulated Email Requiring an Integrity Policy 893 Company Foo has been awarded a contract to build some equipment 894 (Program X). This equipment is regulated by the National Aviation 895 Authority (NAA) that has oversight of Company Foo. The NAA requires 896 strict procedures at a number of significant events for Program X such 897 as in the design and maintenance of the Program X (e.g., when a design 898 is complete and released to manufacturing). The sign-off process 899 requires personal be suitability qualified and that the documentation 900 needs to be maintained for the service life of the project (25 years 901 for Program X). 903 Company Foo has instigated an email-based sign off procedure to 904 simplify sign-off and reduce costs. It also has authored a policy for 905 compliance with the NAA requirements. At the appropriate time, signoff 906 email is sent to the designated program members. Recipients apply the 907 NAA policy when they reply to the sign-off request message. 909 Frank is the lead on the Program X design team. They have a design 910 which they believe can be released to the integration team. Frank 911 initiates the sign-off process for the design. 913 Grace is one of the sign-off design team members for Program X. She 914 receives the sign-off email. Grace responds and applies the sign-off 915 signature policy to the email. The policy requires Grace to 916 authenticate with the required level of assurance, present attributes 917 about herself, her work effort assignments and professional 918 qualifications to demonstrate compliance with the policy to send the 919 message. The message is signed to indicate Grace met the policy. It is 920 a matter of the LoA of the sign off process if Grace signs fist, 921 followed by the policy compliance signature or just the policy 922 compliance signature which attests that Grace initiated the process. 924 When Frank initiates a Program X sign-off email the system must ensure 925 the following objectives: 927 (a) Frank was authenticated to the level of identity assurance 928 required under the policy to initiate the sign-off process. 929 (b) Frank possessed the necessary attributes as required by policy to 930 initiate the sign-off process. 931 (c) The contents of the email are accurate to the level of integrity 932 assurance required by the policy. 933 (d) Frank was fully aware and intended to initiate the sign-off 934 process. 935 (e) The state of Frank's system was known to the level of assurance 936 required under the policy to be free from agents which might 937 interfere with the sign off process. 938 (f) Recipients can easily confirm over the lifetime of the design as 939 required by the policy that the sign-off process met the policy 940 without having to know the specifics of what the policy 941 entailed. 943 The sequence of events Grace would use is as follows: 945 (1) Grace receives the sign-off request email. 946 (2) Grace replies to the email and completes the form data in the 947 email to show she is approving the sign-off. 948 (3) Grace clicks the send button to send the email. 949 (4) Grace receives a sign-off confirmation dialogue before the email 950 is sent where she is able to confirm her intent is to approve the 951 sign-off of the component. 953 Grace's system submits the decision request to send the sign-off 954 email. Her system is asked to provide attributes about Grace, the 955 state of her system and the data being authenticated as part of the 956 decision request. Grace would not know the complete set of attributes 957 required to submit and would start with a basic set to identify 958 herself. The PDEP may be able to discover additional attributes about 959 Grace, and if is still missing some, can request those from Grace. If 960 Grace's request meets the policy, her system receives a signed 961 statement that the message meets the policy which is attached to the 962 email and the message sent. 964 4.5 Delegation of Access to Email 965 There are a number of times when others are given access to a 966 recipient's mailbox or email is forwarded to other recipients based on 967 the original recipient's rules. This may be a long-standing 968 relationship such as when an assistant is given access to an 969 executive's mailbox. Alternatively, it may be a temporary relationship 970 due to short-term needs (e.g., to cover for a vacation). There are 971 also organizational role mailboxes where the recipient is a role and 972 one or more users are assigned to the role. 974 Grace is going on vacation. While Grace is away, Brian will act as a 975 delegate for Grace. Grace configures a mailbox rule to forward Program 976 X email to Brian for the duration of her vacation. Brian is able to 977 satisfy the policy requirements for the Program X email as outlined 978 above and is therefore able to open the protected email sent to Grace. 979 Frank does not need to take any actions to allow Brian to access the 980 email. 982 4.6 Email Compliance Verification 983 Verification is an essential part of compliance. Verification may be 984 conducted by internal staff or external auditors. The verification 985 need to confirm that the policy rules are being enforced. Auditing 986 relies on the generation of artifacts to capture information about 987 events. Typically, this is done via some form of logging. A challenge 988 here is that for distributed system, the set of logs which completely 989 describes the transaction are scattered across many systems so 990 consistency of the audit settings and correlating all the audit data 991 is problematic. Another consideration is accurately capturing only the 992 set of desired data, i.e., accurately targeting the set of events that 993 needs to be logged 995 Jerry is the compliance officer for Company Foo. He has a procedure 996 for ensuring compliance for Program X. The procedure defines what to 997 log and when to audit access to Program X data. Jerry has tools to 998 collect the audit data and run an analysis to verify the polices are 999 being followed. 1001 The sequence of events Jerry would use is as follows: 1003 (1) Jerry configures an audit obligation for access to Program X 1004 data. The obligation defines the set of attributes to capture 1005 when Program X data is accessed. The obligation is part of the 1006 Program X policy. Part of the Program X policy is the set of 1007 PDEPs which can process policy decisions on Program X data. 1008 (2) Jerry configures his audit log collection to download Program X 1009 audit log entries from the designated PDEPs. 1010 (3) Jerry also has an audit confirmation tool which "pings" the PDEPs 1011 for access to Program X data. Jerry's audit log analysis tool 1012 looks for these pings to confirm that auditing is taking place as 1013 expected. 1015 4.7 Email Pipeline Inspection 1017 Organizations have a huge incentive to inspect emails entering or 1018 leaving the organization. Such inspection is desired for many 1019 different reasons. Inspection of mail leaving an organization is 1020 targeted towards making sure that it does not leak confidential 1021 information. It also behooves organizations to check that they are not 1022 a source of malicious content or spam. Inbound mail is checked 1023 primarily for malicious content and phishing attempts as well as spam. 1024 For domains with a high volume of messages there is a strong need to 1025 process email with minimal overhead. Such domains may mandate that 1026 they be pre-authorized to process an email due to the overhead a per- 1027 message request to an external service would add to message 1028 processing. 1030 Company Foo has a policy to scan all inbound and outbound email to 1031 ensure it is free from malware. Company Foo also wants to ensure email 1032 is not spam. Company Foo can own their scanning servers or such checks 1033 may be outsourced to a third party service. Company Foo wants to 1034 ensure that its policy of scanning message contents also applies to 1035 encrypted email. 1037 The ability to decrypt and check the message content for malicious 1038 content is highly desirable. There are a number of methods that can 1039 accomplish this: 1041 1. When a Company Foo client requests to send a Plasma email, the 1042 PDEP is able to check to see if the policy allows email content 1043 inspection by MTA for this policy, and if it does, that Company 1044 Foo has an outbound email scanning, and that the scanning servers 1045 meet the policy requirements. It is able to pre-authorize the 1046 Company Foo email scanning servers to access the email. 1047 2. The scanning MTA authenticates to the PDEP as an entity doing 1048 virus and malware scanning on a protected message. If the PDEP 1049 has specific policy that allows for access to such a scanning MTA 1050 service, the appropriate decryption keys will be released and the 1051 server will scan the mail and take appropriate action. 1052 3. The policy server is configured with information about various 1053 gateways (both internal and external) and has certificates for 1054 the known gateways. The policy server can then return a normal 1055 X.509 recipient info structure (cryptographic lockbox) to the 1056 sender of the message for direct inclusion in the recipient info 1057 list of the message. This allows normal S/MIME processing by the 1058 scanning MTA without the necessity to query the PDEP server for 1059 keys for specific messages. 1060 4. If the scanning MTA server cannot gain access to the decrypted 1061 content using one of the two proceeding methods, it either passes 1062 the encrypted mail on to the recipient(s) without scanning it or 1063 it rejects the mail. This decision is based on local policy of 1064 the scanning MTA. If the message is passed to the recipient(s), 1065 then the necessary scanning either will not be done, done by a 1066 downstream MTA, or done on the recipient's system after the 1067 message has been decrypted. 1069 4.8 Distribution List Expansion 1071 A distribution list (DL) is a function of an MTA that allows a user to 1072 send an email to a group of recipients without having to address all 1073 the recipients individually. The membership of the DL may be 1074 confidential so the sender may not know all the recipients. The DL may 1075 be maintained by an external organization. Since a DL is identified by 1076 an email address, the user may be unaware they are sending to a DL. 1078 Plasma polices may have the list of recipients as a parameter, thus 1079 the fact that the message is being process by the distribution list 1080 means the MTA processing the message needs to update the policy to 1081 allow the new recipients to access the message. Organizations may also 1082 require inbound scanning of email and have thus published keys to 1083 enable pre-authentication of the MTA by the sender to expedite 1084 processing. For both scenarios the DL MTA has to notify the Plasma 1085 server that it is adding recipients to the message and supply the list 1086 of new recipients. The Plasma server can then take appropriate action 1087 on the message token and return an updated token if required. 1089 4.9 Scalable Decision Making 1091 Collaboration involves working with external organizations; e.g., 1092 partners and suppliers. These collaborations may be short or long- 1093 lived, with a small or very large number of participants. 1094 Organizations therefore need flexibility in deployment and scaling. 1095 Organizations do not want to be forced into having to provide capacity 1096 themselves for all decision making over their data. Senders would be 1097 happy to delegate decisions where appropriate to partners or external 1098 services provided those decisions use the rules they define for their 1099 data. Likewise, recipients might be happy to leverage their local 1100 decision capacity providing they don't have to duplicate the rules of 1101 the partners, and can simply and easily use policies published by 1102 their partners. An organization may also want to use cloud based PDEPs 1103 where appropriate as a cost effective way to add capacity and to be 1104 able to respond to transient capacity fluctuations. 1106 See section 3.4.1 for a description of the scenario. 1108 The Program Managers for Program X at Companies Foo and Bar agree to a 1109 series of roles which are used to manage personnel and their assigned 1110 policy groups. The policy administrators for Company Foo and Bar 1111 respectively publish the roles and a policy collection for each role. 1112 There are rules associated with the policy collection, for example 1113 every roles uses the Program X policies published by Company Foo. 1114 Employees from Company Foo also get the Company Foo Intellectual 1115 Property polices for those roles, whereas employees from Company Bar 1116 get the Company Bar intellectual property polices for Program X. 1117 Company Foo has also decided to allow enforcement of Program X 1118 policies by decision engines in both Company Foo and Company Bar. 1119 Company Foo has also decided to use a cloud-based decision engine for 1120 Program X to allow lower cost capacity and scaling. Company Foo is 1121 able to add new instances of the cloud-based decision services as the 1122 program scales up and more uses start working on the program. Each 1123 decision engine dynamically discovers the policies it needs from the 1124 set published by Company Foo and Company Bar. Both Company Foo and 1125 Company Bar can add new polices to the policy collections at any time 1126 and they are dynamically discovered by all the policy decision 1127 engines. 1129 5 Plasma Security Model 1131 A common theme from these scenarios is the need to closely tie the 1132 information asset to the set of technical controls via the data 1133 owner's policies in such a way so it is possible to consistently apply 1134 the technical controls across a broad set of applications (not just 1135 email), for a broad set of users (not just those within an 1136 organization), and in a broad set of environments. Assumptions based 1137 on closed-world, enterprise security models are increasingly breaking 1138 down. Perimeter security continues to diminish in relevance and focus 1139 needs to be shifted to self-protecting data as opposed to protecting 1140 the machines that stores such data. The binding between the data and 1141 the applicable polices needs to happen as close to the data creation 1142 time as possible so ad-hoc trust decisions are not required. 1144 The delivery of the documented use cases will require the integration 1145 of many existing and some new protocols. In order to ensure the right 1146 overall direction for Plasma as each part of the work proceeds, a high 1147 level data model is documented here to act as a guide. While this is 1148 technically informative to the developments of each individual 1149 component, it is normative to the work overall. 1151 This Data Centric Security model is based on a well-established set of 1152 actors for policy enforcement used elsewhere [RFC3198] [XACML-core]. 1154 Figure 2 shows the relationship between the actors. 1156 ------------------ 1157 | | 1158 | Policy | 1159 | Administration | 1160 | Point | 1161 | | 1162 ------------------ 1163 | 1164 ----------------- | ----------------- 1165 | | | | | 1166 | Policy | | Read | Policy | 1167 | Information | | Policy | Information | 1168 | Point | | | Point | 1169 | | | | | 1170 ----------------- v ----------------- 1171 | | v | | 1172 | |Issue ----------------- Issue | | 1173 | |Attributes | | Attributes| | 1174 | |(BAE) | Policy | (BAE) | | 1175 | -------------->>| Decision |<<--------------- | 1176 | | and | | 1177 | | Enforcement | | 1178 | -------------->>| Point |<<----------- | 1179 | |Protect | | Consume | | 1180 | |Content ----------------- Content | | 1181 | |Request+ Request+ | | 1182 | |Attributes Attributes| | 1183 | |(FAE) (FAE) | | 1184 v | v v 1185 v | v v 1186 ----------------- ----------------- 1187 | | | | 1188 | Content | Distribute | Content | 1189 | Creation | Content | Consumption | 1190 | Decision | ---------------------------->>| Decision | 1191 | Requestor | | Requestor | 1192 | | | | 1193 ----------------- ----------------- 1194 Figure 2 General Scheme for Publishing and Consuming Protected Content 1195 The Plasma model is applicable to any type data (email, documents, 1196 databases, IM, VoIP, etc.). This is to facilitate consistent policy 1197 enforcement for data across multiple applications. Another objective 1198 is to not require the data holder to have access to the plain text 1199 data in order to be able to make decision requests to the PDEP. The 1200 policy decision is complex so the content creation DR in Plasma just 1201 uses policy pointers or labels to indicate the set of policies 1202 applicable to content. The content consuming DR dynamically discovers 1203 the PDEP's that are authoritative for the decisions on protected 1204 content in question. The PDEP's dynamically discover the specifics of 1205 a policy from a PAP using the policy references. The specifics of 1206 policy authoring and policy decision logic modules are matters beyond 1207 the scope of this document. It is important to note that the actors in 1208 this model are logical entities and as such can be combined physically 1209 in different configurations. 1211 o The Plasma model uses references to bind the data and the policy. 1212 When information is created, it is encrypted and a list of 1213 policies that must be enforce by the PDEP is bound to the 1214 protected data. 1215 O The Plasma model includes policy discovery capability for 1216 subjects. This enables subjects to interact with one or more PDEP 1217 to discover the set of polices the set of polices each PDEP would 1218 permit the subject to use to protect new content. ?The PDEP 1219 issues a role token to subject which contains one or more policy 1220 collections. Each policy collection is identified by a role name. 1221 Subjects can pick any combination of polices from a policy 1222 collection, but cannot mix polices from different policy 1223 collections. The token issued to subjects containing the policy 1224 collections is known as a role token. 1225 o The Plasma model is an Attribute-Based Access Control (ABAC) 1226 model where the ABAC policy is specified in terms of a set of 1227 attributes, their values, and their relationships. The policy may 1228 specify attributes about the subject, their device, or their 1229 environment, or attributes about a resource. 1230 o The ABAC policy does not require the subject provide their 1231 orthonym. Subjects could be anonymous or pseudonymous. What is 1232 required is the presentation of a set of attributes that 1233 satisfies the policy. 1234 o The subject can be required to bind the supplied attributes to 1235 the channel with the PDEP to a level of assurance as required by 1236 the PDEP. If the PDEP only requires low assurance, bearer tokens 1237 over TLS would be suitable. If the PDEP requires higher 1238 assurance, then the holder of key tokens over TLS would be 1239 required where the token key is bound to the TLS channel. 1240 o This model also supports Capability-Based Access Control (CBAC) 1241 where security tokens represent a capability to meet a policy. 1242 Once a subject has proven compliance with a policy, they can be 1243 issued a capability token. The client can subsequently present 1244 this capability token in lieu of a token or tokens with the set 1245 of subject attributes. The net result is that the model can 1246 transition to a Capability-Based Access Control because the 1247 capability token is an un-forgeable token of compliance with a 1248 policy. The token can be used with any resource tagged with the 1249 same policy. 1250 o Plasma has a baseline of a secure transport between the DR and 1251 the PDEP. One of the decisions the PDEP has to make is the level 1252 of assurance on the release of the CEK to the subject. For 1253 example, the PDEP can release a clear text CEK over the secure 1254 transport to the DR. Alternatively, the PDEP could require the 1255 production of a high-assurance X.509 encryption certificate as a 1256 subject attribute to generate an encrypted CEK. 1258 For the purpose of the Plasma work, it is desirable that the DR and 1259 PDEP be clearly defined as separate services which may be on separate 1260 systems. This allows for a generalization of the model and makes it 1261 less dependent on any specific deployment model, policy representation 1262 or implementation method. It also allows for a greater degree of 1263 control of the PDEP by an organization such that it is possible to 1264 keep all of the PDEP resources directly under it's control and 1265 independent of the data storage location. 1267 The base set of information for a Plasma client is as follows: 1269 o The address of one or more IdP(s) able to issue identity attributes 1270 to the subject 1271 o A means to authenticate to the IdP(s)and issue attributes to the 1272 subject 1273 o The address of zero or more AtP(s) able to issue additional 1274 attributes to the subject 1275 o The address of one or more Plasma PDEPs able to issue role tokens 1276 to the subject to initiate Plasma policy discovery. 1278 From this base set of data, the subject is able to authenticate to 1279 each Plasma PDEP in turn using the identity token from the IdP and 1280 discover the set of assigned roles. Each role has a set of policies 1281 which can be applied to data. A subject may be assigned to multiple 1282 roles and therefore has the ability to select the most appropriate 1283 role for the content being created. Once a role is selected, the 1284 subject is able to choose one or more policies from the policy 1285 collection for that role. Role assignment is dynamic so the role 1286 discovery needs to be done on a regular (but not frequent) basis. 1287 Policy selection during content creation can be either manual or 1288 automatic. A DR may have sufficient context to be able to select the 1289 role and policies for the subject or have some rules that facilitate 1290 policy selection. 1292 The model allows the content creation DR to discover the role 1293 assignments from multiple PDEP which would allow the subject to access 1294 policies based on roles from within their organization and from any 1295 partner organization due to cross-organization collaboration. The 1296 PDEP's that are authoritative for the role assignment for a subject 1297 may be different from the PDEP that are authoritative for enforcement 1298 of a policy collection in question. The DR uses the role token to 1299 authenticate the content creation request. The PDEP will check that 1300 the requested list of policies for the information is a subset of the 1301 policies in the role token. If the set of policies is a subset of the 1302 policies in the role token, then it will issue the policy metadata 1303 token to be attached to the protected data. 1305 The policy metadata token is an signed data structure created by the 1306 PDEP which is bound to the protected data. It contains public policy 1307 metadata attributes which are used by the DR. An example of a public 1308 policy metadata attribute is a list of one or more URLs which 1309 represent the PDEPs that can make policy decisions using the policy 1310 metadata token. The DR can submit the decision request to any PDEP in 1311 the list. The policy metadata token also has a confidential payload 1312 containing private policy metadata attributes used by the PDEP to make 1313 policy decisions. An examples of a confidential policy metadata 1314 attribute is the list of CEKs for the protected data which would be 1315 released to the DR if it passes the policy checks. 1317 Policy rule processing and distribution is complex, so the Plasma 1318 model does not require policy rules to be distributed to the DR. The 1319 DR submits the policy metadata token as part of the decision request. 1320 The confidential portion of the policy metadata token contains a logic 1321 tree of policy references. The PDEP uses the policy references to 1322 discover the policy rules to apply to the request. The logic tree 1323 defines the relationship between the polices. The tree has a series of 1324 nodes where each node represents a set of polices and the relationship 1325 for the polices at the node e.g., are they combined via and AND clause 1326 or an OR clause. The pinnacle of the tree represents the decision from 1327 all the polices in the tree. The use of policy references minimizes 1328 any policy maintenance issues relating to the protected data due to 1329 policy updates. The policy rues can be updated and the new rules 1330 discovered on subsequent decision requests. 1332 The DR and PDEP are required to carry out obligations of the policy 1333 such as specific encryption requirements, e.g., key size or algorithm, 1334 data integrity requirements, time-to-live of the CEK, or audit record 1335 creation requirements. It is a matter for the policy on how to 1336 determine if the DR or PDEP is trusted to carry out the obligations. 1337 This could be achieved by devise type and state attributes. 1339 The PDEP makes its decisions based on the requested action from the 1340 DR, the policy requirements from the PAP(s), and the information from 1341 the PIP(s) about the subject, the subject's device, and the subject's 1342 environment. The information about the subject may be exchanged 1343 directly between the PIP(s) and the PDEP (Back End Attribute Exchange) 1344 or indirectly via the DR (Front End Attribute Exchange) or both. The 1345 content creator can also include attributes in the policy metadata. 1347 There is no guarantee that identity and attribute providers will 1348 consistently use the same name to identity a specific attribute or 1349 attribute data. For example they may use different schemas to identify 1350 an email address or use localized names to describe job functions or 1351 roles. These kinds of values may be standardized within communities of 1352 interest, but not globally across all identity and attribute 1353 providers. Therefore it is necessary to canonicalize the attribute 1354 names and values before processing by the policy. The attribute name 1355 and value mapping is part of the policy data set, i.e., it is in 1356 addition to the policy processing rules. 1358 --------------- ----------------- ----------------- 1359 | | | | | | 1360 | | | Policy | | Policy | 1361 | Policy | | Decision and | | Decision and | 1362 | Decision | | Enforcement | | Enforcement | 1363 | Point | | Point | | Point | 1364 | | | | | | 1365 --------------- ----------------- ----------------- 1366 | | | 1367 | T | T | 1368 | TTTTTTT|TTTTTTT | 1369 V V V 1370 V V V 1371 --------------- --------------- --------------- 1372 | | | | | | 1373 | Policy | | Decision | | Decision | 1374 | Enforcement | | Requestor | | Requestor | 1375 | Point | | | | | 1376 | | | | | | 1377 --------------- --------------- --------------- 1378 | | | 1379 T | T | | 1380 TTTTTTT|TTTTTT | | 1381 V V V 1382 V V V 1383 --------------- --------------- --------------- 1384 | | | | | | 1385 | End | | End | | End | 1386 | User | | User | | User | 1387 | Application | | Application | | Application | 1388 | | | | | | 1389 --------------- --------------- --------------- 1390 (a) (b) (c) 1392 Figure 3 Options For Trusted Actors with Data. 1394 When drawing a line where the actors in the model are full trusted 1395 with the clear text data there are three possibilities (see figure 2). 1397 Figure 2a shows the full trust line between the user application and 1398 the Policy Enforcement Point(PEP). This is the model for current 1399 standard access control mechanism, e.g., XACML [XACML-core]. In 2a, 1400 the PEP has full access to the plain text data. It makes decision 1401 requests to the PDP and if the decision is affirmative, allows the PEP 1402 to release the data to the application. To use figure 2a for secure 1403 email would require every MTA and MUA to be fully trusted with plain 1404 text data which is impossible. 1406 Figure 2b shows the full trust line between the PDEP and the DR. In 1407 2b, the DR only has cipher text data. The data is encrypted with a 1408 content encryption key (CEK) and the PDEP has access to the CEK. The 1409 PDEP releases the CEK to the end-user application when access is 1410 granted so the application can recover the plain text. This mode is 1411 viable for secure email as it does not require the MTA to be trusted 1412 with the plain text data and either the MTA or MUA can act as a DR. 1414 In figure 2c, no actor is given full trust. When the data is 1415 encrypted, the CEK is encrypted for each recipient just as S/MIME does 1416 today. The encrypted CEKs are given to the PDEP and the PDEP releases 1417 the encrypted CEK when access is granted. This mode is also viable for 1418 secure email as the sender can use either conventional public key 1419 cryptography or Identity-Based Encryption[RFC5408] to protect the CEK 1420 for each recipient. 1422 5.1 Plasma Client/Server Key Exchange Level of Assurance 1424 There are a number of mechanisms by which a client and servers can 1425 exchange CEKs. As a baseline, Plasma is establishing a secure 1426 transport between the client and server via TLS. However the client 1427 may be a proxy acting on behalf of the subject, therefore transporting 1428 a clear text CEK over the TLS transport would expose the key to the 1429 proxy. There also may be a proxy at the server which is terminating 1430 the TLS transports and forwarding the requests to another server which 1431 would mean a clear text CEK sent over the transport would be exposed 1432 to the server proxy. Policies may require a higher level of assurance 1433 that the CEK is not exposed to unauthorized principals. This requires 1434 encrypting the CEK for the subject before transport. This would 1435 further require the client or the server to provide a public key to 1436 the other party to be used to protect the CEK before sending it over 1437 the secure transport. 1439 5.2 Policy Data Binding 1441 There are three ways to bind policy to data:- 1443 o By value. This is where a copy of the machine-readable rule set is 1444 directly associated with the data, e.g., where a file system has an 1445 Access Control List for the file or directory, or where a rights 1446 management agent embeds a copy of the policy expressed in a policy 1447 expression language in the rights-protected data. When an access 1448 request is made to the data, the PDEP compares the access request 1449 to the policy on the data itself. 1451 o By reference. This is where a reference to the policy is directly 1452 associated with the data, e.g., a URI or a URN which identifies the 1453 policy to be enforced or points to where the policy is published. 1455 For example with S/MIME, the ESS label identifies the applicable 1456 policy by an OID. When an decision request is made to the data, the 1457 PDP finds the policy based on the identifier and then compares the 1458 access request to the referenced policy. 1460 o By inference. This is where the policy has a target description in 1461 terms of resource attributes the policy applies to. When a decision 1462 request is made, a set of attributes describing the resource which 1463 is the subject of the decision request is included in the request 1464 by a PEP. The PDP then compares the resource attributes to the set 1465 of target descriptions of the policies in its policy store to 1466 determine the set of policies to apply to the request. For example 1467 when an XACML policy is authored, a target description in terms of 1468 the attributes of the resource for the policy is also defined. When 1469 an XACML decision request is made, the PDP finds the policy set to 1470 apply to the request by matching the set of attributes in the 1471 request against the target description associated with the policies 1472 in its store. It then processes the decision request using the 1473 identified policy set. 1475 The chief strength of binding policy by value is its simplicity. The 1476 policy, being local to the data, can easily and quickly be read by the 1477 PDP. The chief weakness in binding policy by value is maintaining 1478 policy over time as binding by value results in the policy being 1479 replicated for every instance of data the policy is applied to. Many 1480 policies have a multi-year life span and over the course of time, 1481 there is a very high probability that the policy would need to be 1482 updated. Given the high number of copies, updating a value-bound 1483 policy has proven to be a very costly and imperfect process both from 1484 an enforcement and audit perspective. This process is complicated by 1485 the fact that because only the result is stored and not an identifier, 1486 it is hard to identify the policy that has to be updated. 1488 The chief strength of binding by names is that once the policies are 1489 bound to the data, the same policies continue to be applied regardless 1490 of PDEP configuration or state. These policies may change their rules 1491 over time, but there is no doubt which policies would be enforced on 1492 the data. Another strength of binding policy by reference is it has a 1493 clear result as to the set of policies the PDEP has to apply. It the 1494 PDP does not have a policy, the reference allows the PDEP to discover 1495 the missing policy. If the PDEP is unable to access a policy for 1496 whatever reason, it knows to fail the decision request with a 1497 different error, i.e., "don't know", which means the DR can reasonably 1498 try other PDEPs. The chief weakness in binding by name is adding or 1499 removing policies requires updating the policy metadata. Adding or 1500 removing policies has the same difficulties as maintaining policies by 1501 value. 1503 The chief strength of binding by inference is it can often be applied 1504 to data without impacting the storage format providing the data 1505 already has rich and well defined set of metadata such as the 1506 structural metadata of an SQL table. It also allows new policies to be 1507 applied to the data without updating the metadata. Unstructured data 1508 such as documents have the ability to store metadata but the challenge 1509 here is what metadata to capture. The nature of the metadata is also 1510 context specific, e.g., the policy target description required to 1511 match structural metadata from an SQL query would be different from 1512 the policy target description for matching content metadata for a 1513 document. The chief weakness in binding by inference is the 1514 reliability of the matching of the metadata to the policy target 1515 description. There are a number of factors which affects the policy 1516 matching process: 1518 * The set of available metadata varies with different data types 1519 which makes the policy target definition more complex, e.g., 1520 structured data such as SQL databases have structural metadata 1521 whereas unstructured data such as documents have content metadata. 1522 * There is a relationship between the metadata you need to capture 1523 and the policies you need to enforce. It's therefore hard to 1524 generalize the rules for what metadata is necessary independent of 1525 knowing what metadata policies require. 1526 * The resultant set of policies to enforce for a decision request is 1527 dependent on the PDP having a complete the set of policies. It is 1528 impossible, however, to detect missing policies based on the 1529 request. Likewise, it is also impossible to detect if erroneous 1530 policies have been selected based on the request. If data moves 1531 from store to store and thereby uses a different PDPs, it's 1532 impossible to determine the correctness of the result of the 1533 policy matching process by the new PDP. 1535 The Plasma model is choosing to use binding by name for two 1536 reasons: 1538 1 The overarching need to consistently enforce the policies selected 1539 at creation time over the lifetime of the data. The typical use 1540 case is that the set of policies to be enforced on the data may 1541 change their rules over time but it is the same set of policies 1542 that are enforced over the lifetime of the data. 1543 2 Data in many cases is mobile and travels between users and 1544 organizations. Any dependency on consistency of the decision 1545 making entity would be difficult to enforce or verify. 1547 5.3 Content Creation Workflow 1549 The content creation DR bootstraps itself via the following 1550 sequence of events: 1552 (1) The content creation DR is configured with the set PIPs and PDEPs 1553 it trusts. 1554 (2) The content creation DR submits a request for a role token to all 1555 the trusted PDEPs. The role token defines the set of roles the 1556 PDEP allows for the subject. The subject is authenticated and the 1557 contents of the role token authorized by the PDEP via attributes 1558 from the PIP(s). The PIP attributes can be obtained by the PDEP 1559 either via front-end (relayed to the PDEP from the PIP via the 1560 subject) or back-end (direct exchange between the PDEP and the 1561 PIP) processing. 1562 (3) The content creation DR receives zero or more roles tokens from 1563 each of the PDEP. Each role token has a one or more policy 1564 collections defining the set of allowed policies for that role 1565 when creating new content. 1567 the DR is now initialized with a list of roles and role tokens. It is 1568 now ready to create content and request protection of that content 1569 from PDEPs. This role token request process would typically be 1570 performed as part of the application initialization process. Role 1571 tokens can be cached to reduce the number of times the application has 1572 to invoke the role token request process. When the user wants to 1573 create new content, they use the following sequence of events: 1575 (i) The user creates the new content 1576 (ii) The user selects the appropriate role for the content, then 1577 selects one or more policies from the policy collection that are 1578 applicable to the content. When the content creation process is 1579 complete, the DR: 1580 (iii) Encrypts the content with one or more locally-generated CEKs 1581 (iv) Submits a policy metadata token request to the PDEP together 1582 with the CEK(s), the set of required policies to be applied, the 1583 role token from the PDEP, and the hash of the encrypted content. 1584 The CEK(s) in the request can be either raw key(s) or CEK(s) 1585 encrypted by a KEK if the policy does not allow the PDEP to have 1586 the ability to access the plain text data. 1587 (v) The PDEP verifies the set of requested policies is a subset of 1588 the policy set in the role token. In addition to the role 1589 token, the PDEP may also require any other attributes from the 1590 subject as defined by policy to process the creation request. 1592 If the request satisfies the policy requirements, the PDEP generates 1593 the encrypted policy metadata which contains the list of policies and 1594 the CEKs. The metadata is encrypted by the PDEP for all the PDEPs 1595 allowed to make decision requests for the data (the content creation 1596 PDEP does not have to be in the set of PDEPS allowed to make access 1597 control decisions). The PDEP includes a list of URLs for all of the 1598 PDEPs allowed to process decision requests and the hash of the 1599 protected content as signed authenticated attributes in the policy 1600 metadata token, then it signs the encrypted metadata. 1602 (vi) The PDEP returns the policy metadata token to the DR 1603 (vii) The DR attaches the policy metadata token to the protected 1604 content and distributes the content. 1606 5.4 Content Consumption Workflow 1608 When a user wants to open some protected content they would use the 1609 following workflow. 1611 (a) The DR verifies the certificate in the signed policy metadata 1612 then determines via local policy if it wants to process the 1613 protected information based on the identity of the PDEP. 1614 (b) The DR verifies the signature on the policy metadata token and 1615 the binding to the encrypted data by hashing the encrypted 1616 information and comparing it to the authenticated attribute in 1617 the policy metadata 1618 (c) The DR creates read token request. The request contains the 1619 signed metadata from the content together with one or more 1620 authentication tokens issued by a PIP. The request may also 1621 contain attributes about the request such as the purpose of use 1622 of the data. 1623 (d) The DR sends the read token request to one of the of the URL's 1624 of the PDEPs in the authenticated attributes of the signed 1625 metadata 1626 (e) The PDEP decrypts the policy metadata, de-references the policy 1627 pointers, and determines the set of rules to apply to the 1628 request based on the policy published by the PAP. The PDEP then 1629 determines the set of attributes it needs to evaluate the policy 1630 rules. The PDEP can use PIPs is has direct relationships with to 1631 query attributes about the subject. If the PDEP is missing 1632 attributes it need to process the policy, it returns a list of 1633 the missing attributes to the DR. 1634 (f) If the DR receives a list of missing attributes from the PDEP, 1635 it obtains the missing attributes requested by the PDEP from a 1636 PIP and sends them to the PDEP in a new read token request. 1637 (g) Once the PDEP has a complete set of attributes, and the 1638 attribute values match those required under the access policy, 1639 the PDEP releases the CEK to the DR along with a TTL which 1640 defines how long the DR can use the CEK before it must discard 1641 the CEK and reapply for access. 1642 (h) Once the DR has the CEK it decrypts the information. It caches 1643 the CEK until the TTL expires. 1645 5.5 Plasma Proxy Servers 1647 There are two separate use cases for proxy servers in Plasma. The 1648 forward proxy use case where a DR client needs to connect to a PDEP 1649 outside of its organization and the reverse proxy use case where a DR 1650 client outside an organization, needs to connect to a PDEP. 1652 A recipient has no control over senders creating Plasma email (or any 1653 other type of Plasma protected content) and sending it to them. 1654 Malicious senders can craft harmful payloads and protect it in a 1655 Plasma envelope. Therefore, Plasma recipients need a policy to 1656 determine the set of Plasma DPEP services they are willing to interact 1657 with. This can be a local policy i.e., a policy for the allowed set of 1658 PDEPs a DR client can interact with. This policy would need to be 1659 distributed to every DR client. An alternate approach is to have a 1660 forward proxy manage the policy on behalf of the DR client. A forward 1661 proxy would eliminate the need to distribute policy by mediating the 1662 connection requests from the DR clients to the PDEP services. The 1663 forward proxy could be a server belonging to the DR client 1664 organization or a cloud service. 1666 In the no-proxy use case the DR client would connect via TLS directly 1667 to the URL contained in the policy metadata. The DR would thus need 1668 local policy to determine whether to connect to the PDEP URL. If a 1669 forward proxy is preset, the DR client would attempt to connect via 1670 TLS to the forward proxy. The forward proxy would then connect to the 1671 PDEP if its policy allowed. 1673 Internet | DMZ | Intranet 1674 | | 1675 | | 1676 | | --------------- 1677 | | | | 1678 TLS | | TLS | DR | 1679 ----------|<------------------------|------| Client | 1680 | | | | 1681 (a) | | --------------- 1682 no proxy | | 1683 | | 1684 | | 1685 | --------------- | --------------- 1686 | | | | | | 1687 TLS | | Plasma | | TLS | DR | 1688 ----------|<-----| Forward |<---|------| Client | 1689 | | Proxy | | | | 1690 (b) | | | | --------------- 1691 Forward | --------------- | 1692 Proxy | | 1694 Figure 4 Forward Plasma Proxy 1696 Since the Plasma service has sensitive cryptographic keys used to 1697 protect the data CEKs, it would be unwise to host those servers 1698 directly connected to the Internet. However, PDEPs will need to be 1699 Internet addressable for requests from DR clients outside the 1700 organization. The simplest possible configuration would be to have a 1701 passive reverse proxy in front of the Plasma server. Since Plasma is 1702 using TLS, a passive proxy cannot inspect the data inside the TLS 1703 session. The passive proxy has therefore a limited function and would 1704 be only able to filter based on session characteristics e.g., source 1705 IP addresses. The Plasma protocol is a series of request-response 1706 messages, so an active reverse proxy can be implemented like other 1707 store-and-forward message based services (e.g., SMTP). The Internet- 1708 facing proxy server would terminate the TLS connections from the 1709 external DRs. The active proxy can then scan submitted requests to 1710 ensure they are not malformed and are free from malicious content 1711 before relaying messages to a full PDEP server further inside the 1712 network for processing of the request. 1714 Internet | DMZ | Intranet 1715 | | 1716 | | 1717 | --------------- | --------------- 1718 | | | | | | 1719 TLS | | Passive | | TLS | Full | 1720 ----------|------|-------------|----|----->| PDEP | 1721 | | Reverse | | | Server | 1722 | | Proxy | | | | 1723 (a) | | | | | | 1724 | --------------- | | TLS Keys, | 1725 | | | Message | 1726 | | | Encryption | 1727 | | | Keys | 1728 | | | | 1729 | | --------------- 1730 | | 1731 | --------------- | --------------- 1732 | | | | | | 1733 TLS | | Active | | TLS | Full | 1734 ----------|----->| Reverse |----|----->| PDEP | 1735 | | Proxy | | | Server | 1736 (b) | | | | | | 1737 | | TLS keys | | | TLS Keys, | 1738 | | | | | Message | 1739 | --------------- | | Encryption | 1740 | | | Keys | 1741 | | | | 1742 | | --------------- 1743 | | 1744 | | 1745 Figure 5 Reverse Plasma Proxy 1747 5.6 Policy Types 1749 Policies range from very simple to very complex. Policies have 1750 dependencies not only on the technical implementation of the software 1751 but on the range of attributes a PIP would issue to subjects. This is 1752 likely constrained by the physical procedures a PIP could support to 1753 capture and verify the information about the subject. To manage this 1754 range of requirements, this model uses two type types of policy. 1756 5.6.1 Basic Policies 1758 Basic policies are intended to be universally usable by employing a 1759 small, fixed set of attributes that are available from all PIPs. For 1760 example, basic policies are intended to be equivalent to sending 1761 encrypted email with S/MIME today i.e., authenticated recipients of 1762 the email get access to the message. Basic policies target scenarios 1763 involving consumers and small businesses who are using public PIPs 1764 which issue a limited set of attributes. It is expected that all 1765 Plasma clients and commercial IdPs would be capable of supporting 1766 basic policies due to the finite set of attribute set required which 1767 will simplifies development, testing and deployment. Later standards 1768 may expand the set of attributes supported by basic policies and hence 1769 define richer basic policies. 1771 5.6.2 Advanced Policies 1773 Advanced policies are intended to be used where one or more policies 1774 are required on the content that require an expanded set of attributes 1775 from an IdP. They are intended to target more complex policy 1776 requirements such as content with regulated information or content 1777 subject to organizational and contractual policies. The input set of 1778 attributes are defined by the policies. These attributes are, in 1779 theory, unbounded and can be either primordial such as date of birth, 1780 or derived attributes such as age, or both. In practice, advanced 1781 policies are constrained by the set of attributes available under the 1782 IdP Trust Framework for the subjects. A data object may require 1783 multiple policies and any instance of multiple policies requires a 1784 logical relationships between the policies, e.g., they can be AND-ed 1785 or OR-ed together. It is not expected that all Plasma clients will 1786 support the rich set of attributes necessary for advanced policies. 1788 6 Message Protection Requirements 1790 6.1 General Requirements 1792 Confidentiality policy protected data MUST be protected from 1793 unauthorized disclosure, protected from unauthorized alteration and 1794 provide data origin authentication. 1796 Integrity policy protected data MUST be integrity protected from 1797 unauthorized alteration and provide data origin authentication. 1799 Every authentication has a level of identity assurance associated with 1800 it depending on attributes such as the identity checks made about the 1801 subject and the authentication technology used by the subject. The 1802 authentication of content creators and content consumers MUST support 1803 the multiple levels of identity assurance framework(see sections 3.1, 1804 3.2, 3.3, and 3.4.) 1806 The specifics of every possible authentication mechanism or every 1807 detail about how the subject's identity was proofed by the IdP cannot 1808 be known to the DR and PDEP, therefore the specifics of how the sender 1809 or recipient achieves the required level of identity assurance MUST be 1810 abstracted from the PDEP and DR by use of a simple numeric scale, 1811 e,g., 0-n where n is linked to an identity assurance framework that 1812 defines the specifics of how to derive the LoA(See sections 3.1, 3.2, 1813 3.3, and 3.4.) 1815 Access policies are complex and subject to change over time. For this 1816 reason, policies MUST be identified by reference rather than inclusion 1817 of the actual policy with the data so the policy change can be 1818 implemented without updating the data.(See section 3.4.1.) 1820 Access to the plaintext of the content MUST only be provided after the 1821 recipient has either provided suitable valid attributes to the PDEP or 1822 the PDEP finds attributes about recipient directly from a PIP, thus 1823 satisfying the policy as defined by the sender.(See sections 3.1 3.2, 1824 3.3, 3.4.1, and 3.5.) 1826 The sender MUST be provided with a list of policies applicable to 1827 content they create and scoped to their current role, i.e., what tasks 1828 they are currently assigned to deliver.(see sections 3.1, 3.2, and 1829 3.3.) 1831 The specifics of the access control policy used by the PDEP MUST be 1832 abstracted from both the sender's and the recipient's DR, i.e., the DR 1833 MUST NOT make the access control decision or need specifics of the 1834 access policy requirements.(See sections 3.1, 3.2, 3.3, and 3.4.) 1836 A content consumer DR MUST receive authenticated attributes of the 1837 identity of the creator, the level of identity assurance of the 1838 creator, and the cryptographic fingerprint of the original content so 1839 that the DR can confirm who created the content and that the content 1840 has not been altered.(see sections 3.1, 3.2, 3.3, and 3.4) 1842 The key exchange between content creator and content consumer and the 1843 PDEP MUST support multiple levels of assurance so an appropriate 1844 strength of mechanism can be selected based on the level of assurance 1845 required. For example, for low assurance situations this could be via 1846 a plan text CEK over a secure transport such as TLS. For high 1847 assurance situations, the recipient MAY be required to provide a 1848 suitable key exchange key such as an X.509 certificate to encrypt the 1849 CEK.(see sections 3.3 and 3.4) 1851 The level of key exchange assurance required MUST be selected by the 1852 sender's policy and enforced by the PDEP. (See sections 3.1, 3.2, 3.3, 1853 and 3.4.) 1855 If the recipient is unable to initially comply with the sender's 1856 policy, then if they are subsequently able to get the required 1857 credentials or attributes it MUST be possible for to retry access to 1858 the content without intervention from the content creator. 1860 A time-to-live (TTL) MUST be provided to content consumers when access 1861 is granted by the PDEP to define when the DR MUST discard the message 1862 CEK and submit a new access request to the PDEP. The TTL value MUST be 1863 based on the message policy and optional attributes about the content 1864 consumer and its environment. 1866 The PDEP MUST be stateless for processing policy requests from content 1867 creators and consumers with respect to any instance of protected 1868 content. It MUST be possible to have multiple instances of a PDEP 1869 service and load balance requests across all instances of the service 1870 transparently to the client and not require synchronization of state 1871 about requests between instances of the service. 1873 A PDEP MUST be capable of generating audit events associated with 1874 access to protected content using policy defined by the PAP. 1876 6.1.1 Email Specific General Requirements 1878 It MUST be possible for domains to publish keys and attributes about 1879 the boundary inspection agents. This allows senders to pre-authorize 1880 the inspection agents of recipients for access to messages. 1882 It MUST be possible for MTAs to request access to protected messages 1883 for which they have not been authorized by the sender (See section 1884 3.8). 1886 Is should be possible for an MTA to pre-authorize another to access a 1887 protected message (See section 3.8). 1889 6.2 Basic Policy Requirements 1891 The use of a Basic policy MUST be backwards compatible with existing 1892 S/MIME. 1894 A sender's agent MAY discover some recipients' encryption certificates 1895 and create recipient info structures using the existing S/MIME 1896 standard (unless specifically forbidden by the selected policy). 1898 A sender's agent MAY elect to use a Basic Policy mechanism for 1899 recipients for whom encryption certificates cannot be discovered. 1901 Four Basic policies are to be defined by this work. These Basic 1902 policies MUST map to the LoA of NIST 800-63-1. This does not preclude 1903 other Basic policies to be defined by other groups, trust frameworks, 1904 or even within the context of the IETF. 1906 When using a Basic policy defined by this work, the sending agent MUST 1907 define which Basic policy is required and the list of rfc5322[RFC5322] 1908 recipients. 1910 A sender using Basic policy MUST be able to send protected messages 1911 without discovering a recipient's encryption key. 1913 A sender using Basic policy MUST NOT require a bilateral agreement 1914 between sender and recipients as a prerequisite to sending the 1915 message. 1917 6.2.1 Email Specific Basic Policy Requirements 1919 The use of Basic Policy MUST be backwards compatible with existing 1920 S/MIME encryption. 1922 A sender's agent MAY discover some recipient's certificates and create 1923 recipient info structures as per the existing S/MIME standard and 1924 elect to use the new mechanism for recipients it cannot discover keys 1925 for rather than remove the recipient's without certificates. 1927 6.3 Advanced Policy Requirements 1929 A Basic policy MAY be combined with Advanced policies 1931 It MUST be possible to apply one or more Advanced policies to content. 1933 Where two or more policies are applied to content, the logical 1934 relationship between the policies MUST also be expressed e.g., are the 1935 policies a logical AND or a logical OR. (See section 3.3) 1937 An advanced policy MAY require attributes about: 1939 o The content consumer 1940 o The device the content consumer is using 1941 o The environment of the device that is attempting to access the 1942 protected content 1943 o The content being accessed 1945 Advanced policy MUST support an extensible list of obligations on the 1946 DR or PDEP such as use of the policy requires some specific action on 1947 the part of the content creator, e.g., signing content with two-factor 1948 smart card and/or that the signature complies with the legal 1949 requirements for the transaction, or the signature needs to be able to 1950 be verified for an extended period.(See sections 3.3 and 3.4.) 1952 Advanced policies MUST support the ability to verify the content for 1953 an extended period as required by policy. For example policy may 1954 require signatures to be verifiable for a period of 10 years. 1956 Advanced policies MUST support the ability to resign the data to 1957 support the verification over the extended period. 1959 7 IANA Considerations 1961 This document describes the requirements for message access control. 1962 As such, no action by IANA is necessary for this document 1964 8 Security Considerations 1966 Authentication by itself is not a good trust indicator. Authentication 1967 raises the level of assurance the identity is correct but does not 1968 address whether the identity is trustworthy or noteworthy to the 1969 recipient. Authentication should be coupled with some form of 1970 reputation e.g. the domain is on a white list or is not or a black 1971 list. Malicious actors may attempt to "legitimize" a message if an 1972 indication of authentication is not coupled with some form of 1973 reputation. 1975 Malicious actors could attempt to use encrypted email as a way to 1976 bypass existing message pipeline controls or to mine information from 1977 a domain. Domains should have sufficient granularity of policy to 1978 handle situations where their email pipeline agents are not able to 1979 inspect the contents. 1981 It must be possible for a third party to, upon correctly presenting a 1982 legitimate legal justification, to recover the content of a message. 1983 This includes the Sender's and Recipient's companies for business 1984 continuity purposes, as well as Law Enforcement. If the entity 1985 requesting the information and the entity controlling the access are 1986 in different jurisdictions, then the process would be subject to some 1987 form of rendition. 1989 The use of a security label type that requires the recipient of a 1990 message to query a PDEP in order to obtain the contents of a message 1991 opens an additional method for adversaries to confirm that an email 1992 address does or does not exist. 1994 Additionally it allows for a new channel for materials to be delivered 1995 to the recipient's mail processor that is not checked for malware or 1996 viruses by the standard mail scanning methods in place. 1998 Email is frequently used as part of a password reset ceremony by an 1999 identity provider. This is problematic when combined with access to 2000 sensitive email. This could be part of an escalation attack e.g. 2002 compromise low value email account password, initiate password reset 2003 via email for higher value account. This would then give access to any 2004 email protected using the higher value identity. 2006 Providing differential access to different parts of a message based on 2007 different policies should only be done via use of different encryption 2008 keys. All data protected by the same key is the same access control 2009 policy. 2011 It would be desirable to be able to indicate the times and other data 2012 like request location when a user has asked for access (successful or 2013 otherwise) to some content as a means to show malicious activity to 2014 the user. 2016 Part of the policy are obligations on how to protect the data e.g. 2017 algorithms and parameters required. This can change over time, 2018 therefore a client may become obligated to re-encrypt or re-digest the 2019 data if it encounters data which does not meet the current mandate. 2021 The act of requesting access to messages is a potential privacy issue 2022 as it allows the sender to gather data about the recipient. For 2023 business to business transaction, disclose of employee information is 2024 handled by the organization. For consumers, there is a need to be able 2025 to consent to the privacy obligations associated with disclosure of 2026 information. This would include information the consumer releases to 2027 the PDPE as well as information the PEDP is able to gather such as 2028 time and location of access requests. 2030 The fact the PDEP is able to grant access to the data could be used by 2031 law enforcement to access information. One of the parameters the 2032 sender needs to be aware of is the jurisdiction the PDPE is under so 2033 they can make an informed choice. 2035 Appendix A. References 2037 A.1. Normative References 2039 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2040 Requirement Levels", BCP 14, RFC 2119, March 1997. 2041 [RFC3198] Westerinen et. al., "Terminology for Policy Based 2042 Management", November 2001. 2043 [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update", 2044 August 2007. 2045 [RFC5280] Cooper, D, et al, "Internet X.509 Public Key 2046 Infrastructure Certificate and Certificate Revocation 2047 List (CRL) Profile", RFC5280, May 2008 2049 [RFC5322] Resnick, P., "Internet Message Format", RFC5322, October 2050 2008. 2051 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 2052 5652, September 2009. 2053 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2054 Mail Extensions (S/MIME) Version 3.2 Certificate 2055 Handling", RFC 5750, January 2010. 2056 [RFC5751] Ramsdell B., Turner S., "Secure/Multipurpose Internet 2057 Mail Extensions (S/MIME) Version 3.2 Message 2058 Specification", January 2010 2059 [SAML-core] OASIS, Assertions and Protocols for the Security 2060 Assertion Markup Language (SAML) Version 2.0, March 2005 2061 [sp800-63-1] NIST SP 800-63-1 "Electronic Authentication Guideline", 2062 December 2008 2064 A.2. Informative References 2066 [bc-iaf] Province of British Columbia; Electronic Credential And 2067 Authentication Standard, version 1.0 2068 [kan-iaf] Kantara Initiative; Identity Assurance Framework: 4 2069 Assurance Levels, version 2.0 2070 [lib- iaf] Liberty Alliance; Liberty Identity Assurance Framework, 2071 version 1.1 2072 [RFC3114] Nicolls, W., "Implementing Company Classification Policy 2073 with the S/MIME Security Label", RFC 3114, May 2002. 2074 [RFC5408] Appenzeller, G., "Identity-Based Encryption Architecture 2075 and Supporting Data Structures", RFC5408, January 2009. 2077 [SAML-over] OASIS, Security Assertion Markup Language (SAML) Version 2078 2.0 Technical Overview 2079 [XACML-core] OASIS, eXtensible Access Control Markup Language (XACML) 2080 Version 3.0 Core Specification 2082 Appendix B Authors' Addresses 2084 Trevor Freeman 2086 Microsoft Corp. 2088 Email: trevorf@microsoft.com 2090 Jim Schaad 2092 Soaring Hawk Consulting 2094 Email: ietf@augustcellars.com 2096 Patrick Patterson 2098 Carillon Information Security Inc 2100 Email: ppatterson@carillon.ca