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