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