Network Work Group Trevor Freeman Internet-Draft Microsoft Corp. Intended status: Informational Jim Schaad Expires: November 28, 2011 Soaring Hawk Consulting Patrick Patterson Carillon Information Security Inc May 27, 2011 Requirements for Message Access Control draft-freeman-message-access-control-req-01 Abstract There are many situations where organizations want to include information which is subject to regulatory or other complex access control policy in email. Regulated information requires some form of robust access control to protect the confidentiality of the information. The Enhanced Security Services for S/MIME [rfc2634] defines an access control mechanism for S/MIME (eSSSecurityLabel). This is a signed attribute of a SignedData object which indicates the access control policy for the message. The fact that this is a signed attribute protects the integrity of the data and the binding of the label to the message but does not protect the confidentiality of the information i.e. at the point where you lean the access control policy to the data you also have access to the data. While the signature provides integrity for the label over the clear text, it is susceptible to unauthorized removal i.e. if you only have SignedData message, any MTA in the mail path can remove a signature layer and therefore remove the access control data. Encrypting the signed message protects the confidentiality of the data and protects the SignedData from unauthorized removal but this hides the ESS security label. From a regulatory enforcement perspective this is an extremely weak form of access control because cryptographic access to the data is given before the access check. The correct enforcement of the access check totally depends on the configuration of the recipients email client. Since the cryptographic access is granted before the access checks, there is no significant impediment for a recipient who is unauthorized under the policy to access the data. A stronger enforcement model is needed for regulatory control for email where cryptographic access is only granted after the access check. There are also many users on the Internet today who have some form of authentication credential but they are not X.509 certificates and who therefore cannot use S/MIME. There are now available, standard based services (e.g. [SAML-overview]) which abstract the specifics of a technology used to authenticate uses from the application itself Freeman et al. Expires November 28, 2011 [Page 1] Internet-Draft Requirements for Message Access Control May 27, 2011 (S/MIME in this case). Adoption of this abstraction model would enable a broader set of users who have other types to authentication credentials to be able to use S/MIME to secure email. It also allows for new authentication technology to be deployed without impacting the core S/MIME protocol. This document specifies the requirements for:- Providing robust access control for S/MIME An abstraction layer for supporting other types of credentials for using S/MIME. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 29, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Freeman et al. Expires November 28, 2011 [Page 2] Internet-Draft Requirements for Message Access Control May 27, 2011 Freeman et al. Expires November 28, 2011 [Page 3] Internet-Draft Requirements for Message Access Control May 27, 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 ESS Security Labels . . . . . . . . . . . . . . . . . . . . 6 3.2 Access Control and the Web . . . . . . . . . . . . . . . . . 7 3.3 Information Asset Protection . . . . . . . . . . . . . . . . 8 3.4 Authentication Assurance Frameworks . . . . . . . . . . . . 9 4 Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Business to Consumer Secure Email . . . . . . . . . . . . . 10 4.2 Business to Business Ad-Hoc Email . . . . . . . . . . . . . 10 4.3 Business to Business Regulated Email . . . . . . . . . . . . 11 4.4 Email Pipeline Inspection . . . . . . . . . . . . . . . . . 13 4.5 Related scenarios . . . . . . . . . . . . . . . . . . . . . 14 5 Message Protection Requirements . . . . . . . . . . . . . . . . 16 5.1 General Requirements . . . . . . . . . . . . . . . . . . . . 16 5.2 Basic Policy Requirements . . . . . . . . . . . . . . . . . 17 5.3 Advanced Policy Requirements . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction The S/MIME (Secure/Multipurpose Internet Mail Extensions) standard today provides digital signatures for message integrity, authentication, and non-repudiation of origin and encryption for data confidentiality. These security services are currently solely based on X.509 certificates. This means anyone without an X.509 certificate is unable to leverage the S/MIME protocol for securing email. The vast majority of users on the Internet have other forms of credentials (passwords, one time passwords, GPG/PGP keys etc.). An access control policy defines a set of criteria which is required in order to grant access to the information. These criteria are defined in terms of attributes about the subject requesting access. Examples of the types of attributes would include what roles the subject is assigned to (Role Based Access Control) or one or more attributes about the subject (attribute Based Access Control). Standards now exist to exchange subject attributes [SAML-overview]. Adoption of these subject attribute protocols would allow a rich set of access control polices to be supported by S/MIME in line with other applications. Freeman et al. Expires November 28, 2011 [Page 4] Internet-Draft Requirements for Message Access Control May 27, 2011 1.2 Keywords The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 3. Background The S/MIME standard [rfc5751] provides a method to send and receive secure MIME messages. While CMS (Cryptographic Message Syntax) allows for other types of security credentials to be used, S/MIME exclusively uses X.509 certificates [rfc5750] for the security credentials used for signing and encryption operations. S/MIME uses an early binding mechanism for encryption keys where the sender needs to discover the public key for every recipient of encrypted messages before they can send the encrypted message. The sender needs to maintain a cache of all potential recipient certificates (e.g. in a personal address book) and/or find an acceptable certificate for the recipient from a repository. This key management model has limited the use of S/MIME for encryption for a variety of reasons. For example: o The recipient may not have an X.509 encryption certificate o The sender may not have received a signed email with the recipient certificate o The recipient may not have an available repository o The sender may be unaware of the location of the recipients repository o The recipient's repository may not be accessible to the sender e.g. it's behind a firewall If one or more recipient certificates are missing then the sender is left with a stark choice: send the message unencrypted or remove the recipients without certificates from the message. The use of secure mailing lists can be thought of as a form of late- binding of recipient information as the originating sender does not need to know the set of recipients or the security information for the recipients. However it is still early-binding for the mail list agent as it needs to perform all of the gathering and processing of certificate information for every recipient that it will be sending the message to. In many regulated environments end-to-end confidentiality between sender and recipients by itself is not enough. The regulatory policy requires some form of access control checks before access to the data should be granted. In many inter-organization collaboration scenarios it's impossible for the sender to satisfy the access checks on behalf Freeman et al. Expires November 28, 2011 [Page 5] Internet-Draft Requirements for Message Access Control May 27, 2011 of the recipients since they don't have and should not have access to all the attributes about the recipients because to do so may be a breach of the recipients privacy. It's a fundamental tenet of good security practice that users must be in control of the release of data about themselves. 3.1 ESS Security Labels Security labels are an optional security service for S/MIME defined in Enhanced Security Services for S/MIME [rfc2634]. The ESS security label allows classification of the sensitivity of the message contents using a hierarchical taxonomy in terms of the impact of unauthorized disclosure of the information [rfc3114]. The security label can also indicate access control such as full time employees only or US nationals only. ESS security labels are authenticated attributes of a signer-info structure in a SignedData object. The label when applied to signed clear text data provides the access control decisions for the plain text. If applied to cipher text such as with the other layer of a triple wrapped S/MIME message the label is used for course grained optimization such as routing. 3.1.1 Problems With ESS Security Labels ESS Security Labels have been found to have a number of limitations. 1. They do not provide a mechanism for an email client to discover a new access control policy if the message contains a policy the client is unaware of. This provides a stark choice: ignore the access control policy and grant access to the message or block access to the message. 2. The current ESS standard only allows a single policy label. This is adequate for course grained policy binding to express a limited set of choices such as with sensitivity which typically a hierarchy of 3-5 choices. Many data sets are subject to multiple fine-grained access control polices. For instance, a message may contain information that is both proprietary and export controlled. Trying to represent combinations of polices via a single policy label would lead to an exponential growth in the number of policy labels. 3. They do not provide for any auditing of who has been granted accessed the message. 4. The authoritative label for the access control is a signed attribute inside the enveloped data. The envelope is decrypted by the client who then reads and hopefully enforces the access control. What that means is users who under the policy are not allowed access to the information have no cryptographic impediment to access the information. Compliance with the policy is dependent on the state of the configuration of every receiving agent. This Freeman et al. Expires November 28, 2011 [Page 6] Internet-Draft Requirements for Message Access Control May 27, 2011 makes policy compliance practically impossible anything but a small closed environment. 5. Access to the message cannot be granted or removed after the message has been sent, but before it has been received. The policy is implemented and enforced solely by the receiving agent. This means that all access polices have to be distributed to all recipients receiving agents. This again makes policy compliance practically impossible anything but a small closed environment. 3.2 Access Control and the Web A prerequisite for many web transactions is the disclosure of attributes about the subject such as name, age, email address, physical location, address, credit card number, social security number etc. Some attributes lend themselves to easy verification but many do not. An assertion of an email address can be verified by sending an email to the address containing a secret ephemeral challenge. Subsequent demonstration of knowledge of the ephemeral challenge verifies the email address assertion. Other assertions such as "this is my credit card account number" are not easily verified. The fact it is a valid credit card number can be verified but not the binding to the subject attempting to use it. Where a claim is not easily verified they are often combined with other assertions under the assumption that knowledge of this larger data set verifies all the assertions in the data set if you know the account number, billing address etc., of course you must be the account holder. This is a very weak form of verification as is often demonstrated via the growth of identity theft much of this bigger data set data set is often publicly via social networks or easily guessed e.g. the most popular professions for a parent is dead or retired. Many of these assertions which are harder to verify are based on government issued documents such as a birth certificates, driver's license, identity card or passport. This requires an exchange of the documents between the relying party and the subject. For a small number of high value transactions (e.g. opening a new account) with relying parties that have widespread physical presence (a bank) this is acceptable because the applicant can present themselves with the required documentation in person. However with web based relying parties they cannot perform an in person exchange of documents to verify information on government issued documents. The approach taken with such relying parties is to have trusted assertion providers where the assertion provider can perform an in person exchange of documents with the subject then vouch for the set of assertions they have verified. SAML [SAML-core] defines an XML framework for describing and exchanging attributes about subjects. The entity making the assertions about the subject is known as the assertion provider, the entity Freeman et al. Expires November 28, 2011 [Page 7] Internet-Draft Requirements for Message Access Control May 27, 2011 consuming the assertions is known as the relying party. The well-known scenarios for using SAML are: o Single Sign On across systems on different platform technology o Federated Identity between business partners o Web Services and other standards e.g. SOAP based protocols The critical difference between SAML and pure authentication protocols such as mutually authenticated TLS is that SAML is able to exchange a rich set of assertions which are frequently necessary for authorizing transactions. X.509 certificate can exchange a limited set of identity assertions such as an x.500 distinguished name, email address, Kerberos principal name, etc. SAML is able to do this plus an extensible set of other assertions about the subject such as, date of birth or business sign-off limits levels etc., etc. SAML also abstracts the details of the authentication protocol from the relying party. The assertion provider can use a broad range of authentication mechanisms such as passwords, one time passwords, biometrics, X.509 etc., without impacting the relying party. The assertion provider can include the details of the authentication mechanism or its strength using an established strength scale such as NIST SP800-63-1[sp800-63-1]. The relying party can then inspect the claims about how or how strongly the subject authenticated to the identity provider to determine if it complies with its access policy. Low value transactions can use simple short lived assertions where possession of the assertion alone is considered acceptable for the transaction risk. These are known as Bearer assertions. Higher value transaction can require proof of possession keys (either symmetric or asymmetric cryptographic keys) where the subject demonstrates knowledge of a cryptographic secret to the relying party via a HMAC or digital signature. These are defined by the SAML specification as Holder of Key assertions. The subject has to demonstrate possession of the key to the relying party. Holder of key assertions can be either symmetric or asymmetric keys. 3.3 Information Asset Protection Information Asset Protection (IAP) is a concept developed by the Trasglobal Secure Collaboration Program (TSCP), a working group comprised of the major players in the western Aerospace and Defense industry. The industry is highly regulated and operates in an environment with many policies governing the access to information assets. These policies may be motivated by the desire to protect intellectual property, the confidentiality of information, or are Freeman et al. Expires November 28, 2011 [Page 8] Internet-Draft Requirements for Message Access Control May 27, 2011 imposed by government regulators such as the US International Trafficking Arms Regulations (ITAR). They apply to the information assets in whatever form the asset may take and are independent of the application used to create the information. These policies take many forms, e.g. verification the recipient has demonstrated a need to know the information because they are working on a specific project, that they have passed the appropriate background and nationality checks, or that they have signed the appropriate non-disclosure agreement. What is needed is a policy driven information centric protection where the applicable policies either is manually or automatically attached to the information and based on the policy the system understands what access control and data protection is necessary. Email is an application widely used in the Aerospace and Defense industry. S/MIME is widely used today and provides sender to recipient confidentiality. This protects the contents of the message from discloser to unauthorized third parties e.g. while it is in transit between MTA's or while at rest in a MTA message queue or recipients mailbox. However it does not impose any finer grained access control such as those required by many policies. S/MIME does define an extension mechanism for access control via an ESS security label [rfc2634] thou this mechanism has drawbacks (see above). 3.4 Authentication Assurance Frameworks A number of organizations have created taxonomies to define the possible levels of identity assurance for electronic authentication. These taxonomies have been drafted by industry organizations [lib- iaf][kan-iaf] and governments [sp800-63-1]. The objective of the framework is to define a simple abstraction for use between identity providers and relying parties which more easily maps to the business requirements. While all of these frameworks may not agree on every aspect, at a macro level they do exhibit many similarities. A common theme in many is the adoption of 4 levels of identity assurance. 1. Negligible confidence in the asserted identity 2. Some confidence in the asserted identity 3. Significant confidence in the asserted identity 4. High confidence in the asserted identity The framework defines broad characteristics in the area of identity proofing, credential type and management, identity provider authentication and relying party authentication. 4 Use Case Scenarios This section documents some use case scenarios the new protocol aims to support. Freeman et al. Expires November 28, 2011 [Page 9] Internet-Draft Requirements for Message Access Control May 27, 2011 4.1 Business to Consumer Secure Email There are many examples of business to consumer secure email scenarios where the email would contain potentially sensitive data. This would include doctor, patient; bank, account holder, Medical insurance, insured person. Alice is a doctor and has received test results for her patient Bob. The information is confidential so any channel of communication she selects must protect the Bob's privacy. Alice elects to use email to reach Bob quickly with news of the results. She must ensure that: 1. Only Bob can read the email 2. The Bob authenticates with an acceptable level of identity assurance to ensure its actually Bob reading the message 3. The Bob can verify the email is from Alice 4. The Bob can verify the email has not been tampered with Alice composes the email to Bob. She include some comments and suggestions for Bob and attaches the test results. Alice's email client allows her to classify the email. Alice classifies the email as a Doctor-Patient communication. Alice's email client knows the protections to apply to Doctor-Patient communication; it know to encrypt and integrity-protects the me and what level of assurance required for the recipients identity. The protected email is able to flow securely and seamlessly through existing email infrastructure to Bob. The data is protected while in transit or at rest. Bob receives the email as sees its a secure message from Alice. Bob opens the email. Bob is able to prove his identity to the level requested by Alice so is is able to read the email. If Bob reply's to the email from Alice, the new message inherits the policy from the original message so doctor-patient messages and replies to doctor-patient messages have the same policy. The doctor- patient policy does not apply to messages forwarded by Bob because is allowed to make his own choices for protecting of the continents when sharing with others. 4.2 Business to Business Ad-Hoc Email Early in the relationship between two companies there may be an exchange of sensitive information before the relationship has matured to the point where the relationship may be formally reflected in some Freeman et al. Expires November 28, 2011 [Page 10] Internet-Draft Requirements for Message Access Control May 27, 2011 form of agreement. Business owners want the agility to interact with potential partners without having to engage there IT staff as a prerequisite of the transaction. Charlie works for Company Foo. He has just met Dave from Company Bar to discuss the prospect of a potential new business opportunity. Following the meeting, Charlie want to send Dave some sensitive information relating to the new business opportunity. When Charlie sends the email to Dave with the sensitive content, Charlie must ensure:- 1. Only Dave can read the email 2. The Dave authenticates with an acceptable level of identity assurance to ensure its actually Dave reading the message 3. The Dave can verify the email is from Charlie 4. The Dave can verify the email has not been tampered with Charlie composes the email to Dave. He include some sensible information relating to potential terms and conditions for the new contract that Foo and Bar would sign to form a partnership for the business opportunity. Charlie's email client allows him to classify the email. Her classifies the email as an Ad-hoc pre-contractual communication. Charlie's client knows the protections to apply to Ad-hoc pre- contractual communication; it know to encrypt and integrity-protect the message and the level of assurance required for the recipients identity. The protected email is able to flow securely and seamlessly through existing email infrastructure to the colleague. The data is protected while in transit or at rest. Dave receives the email as sees its a secure message from Charlie. Dave is able to prove his identity to the level requested by Charlie so is is able to read the email. Dave opens the email. If Dave reply's to the email from Charlie, the new message inherits the policy from the original messages so the entire message thread has the same policy. The policy also applies to messages forwarded by Dave because it contains information from Charlie and Company Foo wants consistent policy enforcement on its information. 4.3 Business to Business Regulated Email As business relationship mature they often result in a formal Freeman et al. Expires November 28, 2011 [Page 11] Internet-Draft Requirements for Message Access Control May 27, 2011 contractual agreement to work together. The agreement would define a number of work areas and deliverables. These deliverables may be subject to multiple corporate and or regulatory policies for access control, authentication and integrity. The set of policies applicable to an email is potentialy subject to change as the different users contribute information to the email thread. Company Foo has been awarded a contract to build some equipment (Program X). The equipment is covered by export control. Company Bar is a subcontractor to company Foo working on Program X. Company Foo sets up some business rules for access to program X data to ensure compliance with export control requirements. Company Foo also set up separate rules to cover the protection of its intellectual property contributed to Program A. Company Bar also sets up its own polices to protect its own intellectual property it contributes to Program X. As part of the agreement between Foo and Bar, they have agreed to mutually respect each others policies. Frank is an employee of Company Foo. He has been assigned to Program X and wants to send some mail to colleagues working on Program X in both Companies Foo and Bar. Grace is an employee of Company Bar. She has been assigned to Program X. When Frank sends the email with Program X regulated content he must ensure compliance with the export control polices. If Frank includes Company Foo intellectual property, he must also ensure compliance with his corporate IP protection policies. When Frank sends a Program X email he must ensure: 1. Only recipients who meet the Program X policy or Company Foo's intellectual property protection policy can read the email 2. The recipients authenticates with an acceptable level of assurance as defined by the set of policies applied to the message 3. Recipients present any other attributes about themselves necessary to verify compliance with the applicable policies. 3. The recipients can verify who the email is from to an acceptable level of assurance as defined by the message policy 4. The recipients can verify the email has not been tampered with to an acceptable level of assurance as defined by the message policy 5. They can also tell it is a Program X email and the contents can only be shared with other Program X workers. Frank composes the email and includes a set of recipients in both Companies Foo and Bar. He include some information relation to Program Freeman et al. Expires November 28, 2011 [Page 12] Internet-Draft Requirements for Message Access Control May 27, 2011 X. Frank also includes some information which is Company Foo's IP. Franks email client allows him to classify the message. Frank classifies the email as Program X and Company Foo proprietary information. The email client knows the protections to apply to the email; to encrypt and integrity-protect the message, the level of assurance required for the recipients identity and what recipient attributes are necessary to access the message. The email is able to flow securely and seamlessly through existing email infrastructure to Grace. The data is protected while in transit or at rest. Grace receives the email as sees its a secure message from Frank. Grace is able to prove her identity to the level requested by Frank and provides the requested attributes about herself to satisfy both the Program X export control and the Company Foo IP protection policies. Grace opens the email. If Grace reply's to the email from Frank, the new message inherits the policy from the original messages. Grace includes some information which is Company Bar's IP so add her companies IP protection policy requirements to the message. Frank receives the reply from Grace. Frank is able to prove his identity to the level requested by Grace and provides the requested attributes about him,self to satisfy both the Program X export control, the Company Foo IP protection policies as well as the Company Bar IP protection policies. Frank opens the email. The policy also applies to messages forwarded by Frank because it contains information from Company Foo and Company Bar both companies wants consistent policy enforcement on its information. 4.4 Email Pipeline Inspection Unsolicited bulk email (aka spam) is a problem for organizations. Email can also contain malicious content such as viruses or attempts at phishing. To combat these threats, server side scanning of the email messages before they reach the recipient is an effective countermeasure. Authorized agents must be capable of getting access to the message. Company Foo receives email from the Internet. Company Foo has a policy to scan inbound email with a view to remove inappropriate or malicious Freeman et al. Expires November 28, 2011 [Page 13] Internet-Draft Requirements for Message Access Control May 27, 2011 content. They have a server which scans email from the Internet. The server has the ability to identify itself as a subject for Foo who is authorized to scan email on behalf of Foo recipients. It has or can request access to encrypted email. It has a local policy on what content to remove and on to reject email which is cannot scan. 4.5 Related scenarios There are other scenarios which are related to the email cases because they would be subject to the same policy requirements. Email allows users to create content and transport it to a set of recipients. You can perform similar actions with other formats such as documents and instant messages. Policy is agnostic to the underlying technology therefore if an organization has a policy relating to a type of information, then that policy would apply to the same content in an email, a document an instant message, etc, etc. The following diagram depicts a generalized scheme for publishing ----------------- | | | Policy | ----------->> | Decision | <<-------- | | Point | | | | | | | ----------------- | | Protect Request | | Content Access | | | | Distribute | --------------- Content ----------------- | | | | | Content | --------------------->> | Content | | Creation | | Consumption | | | | | --------------- ----------------- Freeman et al. Expires November 28, 2011 [Page 14] Internet-Draft Requirements for Message Access Control May 27, 2011 Figure 1 General Scheme for Publishing Protected Content 4.5.1 Document Protection This scenario is very similar to 4.2 and 4.3 above. The difference is that the information being generated is in the form of a document not an email. It could be as part of an ad-hoc sharing or a regulated sharing or information. Frank is an employee of Company Foo. He has been assigned to Program X. Grace is an employee of Company Bar. She has been assigned to Program X. Frank creates a document for the program. He also includes some Company Foo IP in the document. When Frank creates the document he must ensure compliance with export control regulations and his corporate IP protection policies. Fran must ensure: 1. Only users who meet the Program X policy or Company Foo's intellectual property protection policy can open the document 2. Users authenticates with an acceptable level of assurance as defined by the set of policies applied to the document 3. Users present any other attributes about themselves necessary to verify compliance with the applicable policies. 3. Users can verify who the author was to an acceptable level of assurance as defined by the document policy 4. Users can verify the document has not been tampered with to an acceptable level of assurance as defined by the document policy 5. They can also tell it is a Program X document and the contents can only be shared with other Program X workers. Frank creates a document for Program X. He include some information relation to Program X. Frank also includes some information which is Company Foo's IP. Franks word processor client allows him to classify the document. Frank classifies the document as Program X and Company Foo proprietary information. The word processor client knows the protections to apply to the document; to encrypt and integrity-protect the document, the level of assurance required for the users identity and what user attributes are necessary to access the document. Freeman et al. Expires November 28, 2011 [Page 15] Internet-Draft Requirements for Message Access Control May 27, 2011 The document is able to be published on a cloud based Web portal. The document is protected while in transit to the portal or at rest on the portal. The document is also protected on any backup or replica of the portal data. Frank does not to worry about where on the portal he publishes the document. He can make the most appropriate choose based on the the project and the document content. Grace sees the document on the portal and tries to open the document. Grace is able to prove her identity to the level requested by Frank and provides the requested attributes about herself to satisfy both the Program X export control and the Company Foo IP protection policies. Grace opens the document. If Grace edits the document and includes some information which is Company Bar's IP so adds her companies IP protection policy requirements to the document. Grace saves the updated document to the same location on the portal. Frank see that Grace has updated the document on the portal. Frank is able to prove his identity to the level requested by both the Company Foo and company Bar policies and provides the requested attributes about himself to satisfy both the Program X export control, the Company Foo IP protection policies as well as the Company Bar IP protection policies. Frank opens the document. 5 Message Protection Requirements 5.1 General Requirements Protected email MUST be where messages can be considered "secure" which means confidential, integrity protected AND authenticated. Every authentication has a level of assurance associated with it depending on attributes such as the identity checks made about the subject and the authentication technology used. The authentication of senders and recipients MUST allow for the multiple levels of identity assurance. The specifics of how the recipient achieves the required level of identity assurance MUST be abstracted from the email system e.g. by the use of SAML [SAML-core] attributes. Cryptographic access the message MUST only be provided after the recipient has provided suitable valid attributes as defined by the sender. If the sender has not signed the message themselves i.e. the message is signed on behalf of the sender, Recipients MUST receive Freeman et al. Expires November 28, 2011 [Page 16] Internet-Draft Requirements for Message Access Control May 27, 2011 authenticated attributes from the signer about the identity of the sender, the level of identity assurance of the sender with the signer and the cryptographic fingerprint of the senders' message so the recipient can confirm the signed messages is the same as the senders message. The decryption key exchange MUST support multiple levels of assurance. The level of assurance requited MUST be selected by the sender. Recipients MUST securely receive the message decryption key(s). A range of assurance levels MUST be provides for the key exchange. For example, for low assurance situations this could be over a secure transport such as SSL. For high assurance situations recipient MAY be required to provide a suitable key exchange key such as an X.509 certificate. Mail pipeline agents MUST be able to get access to encrypted content under the control of policy of the sender. It MUST be possible for domains to publish keys for such agents so senders can pre-authorize agents of recipient domains at send time for email scanning. It MUST be possible for domains to request access to protected messages which have not been preauthorized by the sender. If a third party is used to arbitrate the message access control, the third party MUST NOT be required to maintain per message state. 5.2 Basic Policy Requirements Basic policy is intended to be equivalent to sending encrypted email with S/MIME today. It is a simple policy that authenticated recipients of the email get access to the message. Its intended target is simple scenarios involving consumers and small businesses. When using Basic Policy, the sending agent MUST define the list of recipients AND the level of authentication assurance required. The recipient MUST be required to provide at least two attributes, their email address and the level of authentication assurance of the identity. Basic policy MUST support multiple levels of identity assurance. The levels of identity assurance MUST map to an existing identity authentication assurance framework e.g. to NIST 800-63-1 or equivalent. A sender using Basic policy MUST be able to send protected messages without discovering any recipient's encryption key. Freeman et al. Expires November 28, 2011 [Page 17] Internet-Draft Requirements for Message Access Control May 27, 2011 Using basic policy MUST NOT require bilateral agreements between sender and recipients a priori to sending the message. The use of Basic Policy MUST be backwards compatible with existing S/MIME. A sender's agent MAY discover some recipient's certificates and create recipient info structures as per the existing standard and elect to use the new mechanism for recipients it cannot discover keys for rather than remove the recipients without certificates. 5.3 Advanced Policy Requirements Advanced policy is intended to be used where one or more arbitrary access control policies are required on the content of the message. It is intended to target more complex scenarios such as email with regulated content or content subject to organization policies. It MUST be possible to apply one or more Advanced Policies to a message. Where 2 or more policies are applied to a message, the logical relationship between the policies MUST also be expressed i.e. are the policies a logical AND or a logical OR. The specifics of the access control policy MUST be abstracted from the client i.e. the recipients client MUST NOT make the access control decision. Advanced policy can use either early or late key binding. The choice MUST be defined by the message access control policy. If using early key binding, the binding data can only be disclosed to the recipient after they have successfully passed the access check. The recipient's client MUST NOT be expected to have received a priori of the message arrival any access control policies or configuration specific to an access control policy. Upon each access of the content of the email, the attributes MUST be verified anew prior to cryptographic access being granted to the content of the email. 5. IANA Considerations This document describes the requirements for message access control. As such no action by IANA is necessary for this document 6. Security Considerations Authentication by itself is not a good trust indicator for users. Authentication raises the level of assurance the identity is correct but does not address whether the identity is trustworthy or noteworthy Freeman et al. Expires November 28, 2011 [Page 18] Internet-Draft Requirements for Message Access Control May 27, 2011 to the recipient. Authentication should be coupled with some form of reputation e.g. the domain is on a white list or is not or a black list. Malicious actors may attempt to "legitimize" a message if an indication of authentication is not coupled with some form of reputation. Malicious actors could attempt to use encrypted email as a way to bypass existing message pipeline controls or to mine information from a domain. Domain should have sufficient granularity of policy to handle situations where their email pipeline agents have not been authorized to inspect the contents. It must be possible for a third party to, upon correctly presenting a legitimate legal justification, to recover the content of a message. This includes the Senders and Recipients companies for business continuity purposes, as well as Law Enforcement. If the entity requesting the information and the entity controlling the access are in different jurisdictions, then the process would be subject to some form of rendition. 7. References 7.1. Normative References [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [rfc2634] Hoffman, P. Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999. [rfc5280] Cooper, D, et al, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008 [rfc5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009. [rfc5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, January 2010. [rfc5751] Ramsdell B., Turner S., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, January 2010 [SAML-core] OASIS, Assertions and Protocols for the Security Assertion Markup Language (SAML) Version 2.0, March Freeman et al. Expires November 28, 2011 [Page 19] Internet-Draft Requirements for Message Access Control May 27, 2011 2005 [sp800-63-1] NIST SP 800-63-1 "Electronic Authentication Guideline", December 2008 7.2. Informative References [bc-iaf] Province of British Columbia; Electronic Credential And Authentication Standard, version 1.0 [kan-iaf] Kantara Initiative; Identity Assurance Framework: 4 Assurance Levels, version 2.0 [lib-iaf] Liberty Alliance; Liberty Identity Assurance Framework, version 1.1 [rfc3114] Nicolls W., "Implementing Company Classification Policy with the S/MIME Security Label, RFC 3114, May 2002. [SAML-overview] OASIS, Security Assertion Markup Language (SAML) V2.0 Technical Author's Address Trevor Freeman Microsoft Corporation Email: trevorf@microsoft.com Jim Schaad Soaring Hawk Consulting Email: ietf@augustcellars.com Patrick Patterson Carillon Information Security Inc Email: ppatterson@carillon.ca Freeman et al. Expires November 28, 2011 [Page 20]