Network Working Group T. Freeman
Internet-Draft Microsoft Corp.
Intended status: Informational J. Schaad
Expires: February 4, 2012 Soaring Hawk Consulting
P. Patterson
Carillon Information Security Inc
August 3, 2011
Requirements for Message Access Control
draft-freeman-message-access-control-req-02
Abstract
There are many situations where organizations want to protect
information with robust access control, either for implementation of
intellectual property right protections, enforcement of information
contractual confidentiality agreements or because of externally
imposed legal regulations. The Enhanced Security Services (ESS) for
S/MIME defines an access control mechanism which is enforced by the
recipient's client after decryption of the message. The ESS mechanism
therefore is dependent on the correct access policy configuration of
every recipient's client. This mechanism also provides full access to
the data to all recipients prior to the access control check which is
considered to be inadequate for due to the difficulty in
demonstrating policy compliance.
This document lays out the deficiencies of the current ESS security
label, and presents requirements for new model for doing access
control to messages where the access check is performed prior to
message content decryption. This new model also does not require
policy configuration on the client to simplify deployment and
compliance verification.
The proposed model additionally provides a method where non-X.509
certificate credentials can be used for encryption/decryption of
S/MIME messages.
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Freeman, et al. Expires February 4, 2012 [Page 1]
Internet-Draft Requirements for Message Access Control July 2011
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."
This Internet-Draft will expire on January 20, 2012.
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 February 4, 2012 [Page 2]
Internet-Draft Requirements for Message Access Control July 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Restricting Access to Data (need better title) . . . . . . 4
1.2. Encrypted E-Mail Using Web-based Credentials . . . . . . . 5
1.3. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. ESS Security Labels . . . . . . . . . . . . . . . . . . . 8
2.2. Access Control and the Web . . . . . . . . . . . . . . . . 10
2.3. Information Asset Protection . . . . . . . . . . . . . . . 11
2.4. Authentication Assurance Frameworks . . . . . . . . . . . 12
3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Consumer to Consumer Secure Email . . . . . . . . . . . . 13
3.2. Business to Consumer Secure Email . . . . . . . . . . . . 14
3.3. Business to Business Ad-Hoc Email . . . . . . . . . . . . 17
3.4. Business to Business Regulated Email . . . . . . . . . . . 18
3.5. Email Pipeline Inspection (Security Boundary Inspection) . 20
3.6. Related scenarios . . . . . . . . . . . . . . . . . . . . 21
4. General Data Model . . . . . . . . . . . . . . . . . . . . . . 24
4.1 Policy Types . . . . . . . . . . . . . . . . . . . . . . . . 26
5. Message Protection Requirements . . . . . . . . . . . . . . . 27
5.1. General Requirements . . . . . . . . . . . . . . . . . . . 27
5.2. Email Requirements . . . . . . . . . . . . . . . . . . . . 28
5.2. Basic Policy Requirements . . . . . . . . . . . . . . . . 29
5.3. Advanced Policy Requirements . . . . . . . . . . . . . . . 29
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
Appendix A. References . . . . . . . . . . . . . . . . . . . . . 32
A.1. Normative References . . . . . . . . . . . . . . . . . . . 32
A.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Freeman, et al. Expires February 4, 2012 [Page 3]
Internet-Draft Requirements for Message Access Control July 2011
1. Introduction
The S/MIME (Secure/Multipurpose Internet Mail Extensions) standard
[rfc5652] today provides digital signatures (for message integrity
and data origination) and encryption (for data confidentiality). The
Enhanced Security Services (ESS) for S/MIME [rfc2634] provides for
additional services including security labels (eSSSecurityLabel)
which represent the access control policy. These labels are placed as
a signed attribute in the signed data block of a message. The
recipient of the message is then responsible for checking that the
recipient has a legitimate right to see the message based on the
label on the message. This type of security labeling is similar to
that of stamping top-secret on the cover of a document. It relies on
the reader to not open and read the document when discovered.
The Cryptographic Message Syntax (CMS) [rfc5652] allows for a variety
of different types of lock boxes to be applied to an encrypted
message. This allows for a variety of different security mechanisms
to be used by the sender and the recipient to process the message.
However the S/MIME standard is 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.).
1.1. Restricting Access to Data (need better title)
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. While ESS for S/MIME [rfc2634] defines an access
control mechanism for S/MIME (eSSSecurityLabel), it is an extremely
weak form of access control as the recipient is responsible for the
enforcement and is given access to the data even if they fail to meet
the criteria of the label.
An access control policy defines a set of criteria which is required
to be met 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). While S/MIME provides a standardized representation for
the security label, it does not provide for any method of obtaining
the necessary attributes for enforcement of the policy. Standards
now exist to that enable for the transport of subject attributes
[SAML-overview]. Adoption of these subject attribute protocols would
Freeman, et al. Expires February 4, 2012 [Page 4]
Internet-Draft Requirements for Message Access Control July 2011
allow a rich set of access control polices to be supported by S/MIME
in line with other applications.
ESS Security labels are 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 learn
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 by anyone who
is able to decrypt the message. I.e. if you only have SignedData
message, any Message Transport Agent (MTA) in the 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 users unable to decrypt the
message 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 is dependent on the configuration of the recipients email
client. Since the cryptographic access is granted before the access
checks, there is no cryptographic 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.
1.2. Encrypted E-Mail Using Web-based Credentials
There are many users on the Internet today who have some form of
authentication credential but the credentials 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 (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 at the expense of
adding a third party to the transaction.
1.3. Vocabulary
Cryptographic Lock Box is a per recipient data structure which holds
a content encryption key encrypted for the specific user.
Early Binding is the concept of creating the cryptographic lock box
Freeman, et al. Expires February 4, 2012 [Page 5]
Internet-Draft Requirements for Message Access Control July 2011
for a recipient at the time the message is sent. (Oppose to
Late Binding).
Late Binding is the concept of creating the cryptographic lock box
for a recipient when the recipient attempts to decrypt the
message. (Oppose to Early Binding)
Content Encryption Key (CEK) is a key used to encrypt protected end
user data.
Key Encryption Key (KEK) is a key used to encrypt a cryptographic
key, often a Content Encryption Key.
Authenticated denotes:-
The sender is able to establish to a known level of confidence
the identity of the recipient or
The recipient is able to establish to a known level of
confidence the identity of the sender
Confidential denotes that a message has been protected to a known
level of confidence so that the contents are not decipherable by
unauthorized users.
Integrity protected denotes that a recipient of a message can
determine to a known level of confidence that a message has not
been modified between the time that it was created and it was
received by the recipient.
Front End Attribute Exchange is when subject attributes are relayed
from the issuer to the relying party by the subject
Back End Attribute Exchange is when subject attributes are directly
send from the issuer to the relying party
1.4. 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.
Freeman, et al. Expires February 4, 2012 [Page 6]
Internet-Draft Requirements for Message Access Control July 2011
2. Background
The S/MIME standard [rfc5751] provides a method to send and receive
secure MIME messages. While CMS 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. This requires the sender to maintain a cache of
all potential recipient certificates (e.g. in a personal address
book) and/or have the ability to find an acceptable certificate for
the recipient from a repository at message creation. 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 recipient's
repository
o The recipient's repository may not be accessible to the sender
e.g. it's behind a firewall
o The sender may not implement the algorithms supported by the
recipient.
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 has the ability to provide some
relieve to the problem as the original sender does not need to know
the appropriate encryption information for all of the recipients on
the list. It can thus be thought of as a form of late-binding of
recipient information for originating sender. However it is still
early-binding encryption for the mail list agent; as it needs to
perform all of the gathering and processing of certificate
information for every recipient that the message will be send to. The
use of a mailing list also means that the originating sender has no
chance to perform any sender side filtering on who should receive an
email based on the recipients attributes as they do not know the full
list of the recipients.
Freeman, et al. Expires February 4, 2012 [Page 7]
Internet-Draft Requirements for Message Access Control July 2011
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 of the recipients since they don't have and frequently
should not have access to all the attributes about the recipients
because to do so may be a breach of the recipient's privacy. Indeed
to release the attributes to the sender may require that the sender's
attributes first be released to the recipient's attributes holder and
then recuse. It's a fundamental tenet of good security practice that
users must be in control of the release of data about themselves.
2.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 outer layer of a triple wrapped S/MIME message the label
is used for course grained optimization such as routing.
2.1.1. Problems With ESS Security Labels
ESS Security Labels have been found to have a number of limitations.
1. If the label is on the innermost content, access to the plain
text is provided to the recipient (in some form) independent of
the label evaluation as it will be processed for the purpose of
hash computation as part of signature validation. Depending on
how a triple wrapped message is processed by the recipient's CMS
code, the inner content may be processed for signature validation
even before the outer signature is validated. This would happen
for a stream based CMS processor which starts processing inner-
layers immediately rather than finishing processing of each layer
and caching the intermediate results.
2. Labels applied can be removed in transit. If a signed layer is
seen then it can be removed by any agent that processes the
message (such as a Message Transit Agent). If the label is
protected by an encryption layer then it can be removed by any
agent that has key access to the message (Encryption Mail List
Freeman, et al. Expires February 4, 2012 [Page 8]
Internet-Draft Requirements for Message Access Control July 2011
agents or Spam Filtering software would be two such examples).
3. Policies are identified by Object Identifiers. This makes for a
small tight encoding, but it does not provide any mechanism for
an email client to discover how to enforce 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.
Object identifiers also do not provide a good display name for a
user so that they could manually find and download a new policy.
4. The current ESS standard only allows for a single policy label in
a message, no standardized method of composing multiple policy
labels together has been defined. 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 need to be subject to multiple access control
polices. For instance, a message may contain information that is
both propriety 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.
5. They do not provide for any auditing of who has been granted
accessed the message. All policy evaluation is local to the
recipient's machine; no centralized logging of access to the
message can be performed
6. Enforcement of the policy occurs on the recipient's machine, this
means that compliance with the policy is dependent on the state
of the configuration of every receiving agent. This means that
the policy is enforce by whatever module is located on the user's
system. For cross cooperate systems, this means that the policy
provided by Company A must be installed on Company B machines, or
Company B must install a policy that Company A will accept as
being equivalent to their own policy enforcement module.
Additionally any time that a new version of the policy module is
rolled out; there will be a time lag before every recipient
machine will have the updated module. This makes policy
compliance practically impossible anything but a small closed
environment.
7. Access to the message cannot be granted or removed after the
message has been sent, but before the recipient attempts to read
it.
Freeman, et al. Expires February 4, 2012 [Page 9]
Internet-Draft Requirements for Message Access Control July 2011
2.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 it is 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 by the growth of identity theft, much of this bigger
data set data set is often publicly available 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 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
Freeman, et al. Expires February 4, 2012 [Page 10]
Internet-Draft Requirements for Message Access Control July 2011
The critical difference between SAML and pure authentication
protocols such as mutually authenticated TLS is that SAML is able to
exchange the rich and variable set of assertions which necessary for
authorizing transactions. X.509 certificate can exchange a limited
and fixed set of identity assertions such as an x.500 distinguished
name, email address, Kerberos principal name, etc. SAML is able to
do this as well as an extensible set of other assertions about the
subject such as: date of birth, business sign-off limits levels, etc.
SAML additionally defined a number of query/response style profiles
[SAML-QUERY] that allow for a relying party to specify the type of
attributes that are required to evaluate a policy.
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 certificates, 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.
2.3. Information Asset Protection
Information Asset Protection (IAP) is a concept developed by the
Transglobal 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
imposed by government regulators such as the US International Traffic
in Arms Regulations (ITAR) from the US Department of State. 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
Freeman, et al. Expires February 4, 2012 [Page 11]
Internet-Draft Requirements for Message Access Control July 2011
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).
2.4. Authentication Assurance Frameworks
A number of organizations have created taxonomies to define the
possible levels of identity assurance for electronic authentication.
The objective of the framework is to provide a simple abstraction the
details of any specific combination of identity proofing, credential
technology, authentication technology from the authorization policy.
These frameworks have been drafted by industry organizations [lib-
iaf][kan-iaf] and governments [sp800-63-1]. 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
a small number of levels of identity assurance, typically between 3
and 5. A simplified description of the levels is:
Level 1 Negligible confidence in the asserted identity
Level 2 Some confidence in the asserted identity
Level 3 Significant confidence in the asserted identity
Level 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.
Freeman, et al. Expires February 4, 2012 [Page 12]
Internet-Draft Requirements for Message Access Control July 2011
3. Use Case Scenarios
This section documents some use case scenarios the new protocol aims
to support.
3.1. Consumer to Consumer Secure Email
One of the issues that is stopping the use of secure email in
personal mail is the fact that consumers find certificates difficult
to obtain and then use. One of the possible use cases of PLASMA is
to try and deal with this. The details of the use case are
therefore: Alice wants to send an email message to Bob that is
encrypted so that eavesdroppers cannot read it. Bob however has not
ever obtained an X.509 certificate for this purpose. Alice needs to
ensure the following:
(a) Only Bob can read the email.
(b) Bob has the ability to verify the email is from Alice.
(c) Bob has the ability to verify the email message has not been
modified since Alice sent it.
The sequence of events could be as follows:
1. Alice composes the email to Bob.
2. Alice's email client allows here to classify the email. Alice
classifies the email using Personal Communication which is a
basic policy provided by her ISP.
3. Alice's email client knows the protections to apply to a Personal
communication; it knows to encrypt and sign the message.
4. 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.
5. Bob receives the email and sees that it is a secure message. Bob
can verify that the encrypted message has not been altered. Bob
attempts to open and decrypt the email. If Bob is on the same
ISP as Alice, then the same username/password as he uses to get
his email to obtain the needed keys. If Bob is on an ISP that
is federated with Alice's ISP then an infrastructure such as
OAUTH or ABFAB could be used to validate Bob allow the needed
keys to be released. If Bob's ISP is totally independent of
Alice's ISP, an email message could be sent to Bob so that Bob
can create an association with Alice's ISP's policy server.
Freeman, et al. Expires February 4, 2012 [Page 13]
Internet-Draft Requirements for Message Access Control July 2011
After that is done then Bob can try and open the message again,
this try supplying the newly created username/password to obtain
the keys.
3.2. Business to Consumer Secure Email
There are many examples of business to consumer secure email
scenarios where the email could potentially contain sensitive data.
This would include doctor, patient; bank, account holder; Medical
insurance, insured person. Two examples are presented here.
3.2.1 Bank Statement Email
In the first example, a bank (The Bank of Alice) has determined that
it will be using Email to distribute statements to its customers
(Bob). The information is confidential, so any channel of
communication she selects must protect Bob's privacy. Alice needs to
ensure the following:
(a) Only Bob (or additional owners of the account) can read the
email.
(b) Bob authenticates with a sufficient level of assurance. The
same authentication level used to do on-line banking would be
considered sufficient.
(c) Bob can verify the statement is from Alice (his bank).
(d) Bob can verify the statement has not been modified since Alice
sent it.
The sequence of events would be as follows:
1. As part of routine end of the month processing, Alice composes an
email to Bob. She includes the statement of balances and
activity either as an attachment or as the body of the message.
2. The statement mailer for Alice has been configured to use a
specific policy on the email.
3. The statement mailer for Alice knows the protections to apply
based on the policy; it knows to encrypt and integrity-protect
the message.
4. The protected email is able to flow security and seamlessly
through the existing email infrastructure to Bob. The data is
protected while in transit or at rest.
Freeman, et al. Expires February 4, 2012 [Page 14]
Internet-Draft Requirements for Message Access Control July 2011
5. Bob receives the email and sees that it is a secure message from
Alice. Bob can verify the message has not been altered as it is
signed by the statement producer. Bob uses his on-line banking
credentials to prove his identity to the PDP in order to obtain
the keys necessary to decrypt the message.
The same process could be used for any messages sent between the bank
and its customer. Thus messages dealing with loan applications and
changes in bank policies can be sent out in the same manner,
potentially using slightly different policies. In some of these
cases it might be in the bank's interests to record in an audit trail
if and when the keys were handed out on some emails. For a statement
Alice would not expect a reply to occur, however for other types of
messages it should be possible for Bob to reply under the same level
of protection. If Bob uses his on-line credentials when obtaining
the policy description blob sent with the message there is a degree
of assurance that the bank has similar to using web-based messaging
today that it was Bob who sent the message.
3.2.2 Doctor-Patient Communications
In the second example, let's say that Alice is a doctor and has
received test results for her patient Bob. This information is
confidential, so any channel of communication she selects must
protect Bob's privacy. Alice elects to use email to reach Bob
quickly with news of the results. In this respect it is similar to
the previous use case; however there are some additional
complications that might need to be dealt with as well. Depending on
who Bob is and where is currently is there are additional people that
may also need to be automatically informed of the same information,
or need to have the ability to access the contents of the message.
Examples of these would be Bob's spouse, the individual who is making
care decisions for Bob (i.e. Bob's parent), and the individual in
charge of dealing with Bob's day-to-day health care (i.e. a charge
nurse in a hospital or a visiting nurse). All of these people may
have the same need to know as Bob. There is also the possibility
that some parts of the message may need to be released to some
individuals but not to others. As an example, the mail message could
contain a prescription, that specific portion of the message may need
to be read by Bob's pharmacist. Alice needs to ensure the following:
(a) Only authorized individuals can read the email. However, the
definition of authorized will vary with the content of the
message and thus the policy applied. (General health issues
will certainly be treated differently than mental health issues,
even by a General Practitioner.)
(b) The message readers authenticate with a level 2 or above level
Freeman, et al. Expires February 4, 2012 [Page 15]
Internet-Draft Requirements for Message Access Control July 2011
of identity assurance.
(c) The Bob can verify the email is from Alice.
(d) The Bob can verify the email has not been modified after Alice
sent it.
The sequence of events would be as follows:
1. Alice composes the email to Bob. She includes some comments and
suggestions for Bob and attaches the test results.
2. Alice's email client allows her to classify the email. Alice
classifies the email as a Doctor-Patient communication. (a) As
a side effect of classifying the email message, the policy may
suggest or mandate additional individuals that the communication
should be addressed to.
3. Alice's email client knows the protections to apply to Doctor-
Patient communication; it knows to encrypt and integrity-protect
the message.
4. 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.(a)
5. Bob receives the email as sees it is a secure message from
Alice.(c) Bob can verify the message has not been
altered[Objective (d)]. Bob attempts to opens the email. Bob
provides a Level 2 password to retrieve the necessary decryption
keys from the policy server(b). After Bob has proved his
identity, he is able to read the email.
There are number of different places where the identity provider for
Bob could live. The first and possibly easiest is at Alice's office,
Bob already has a face-to-face relationship with Alice and the
password could be setup in her office. A second location could be
Bob's insurance provider. Bob has a relationship with his insurance
provider as does Alice, thus it can serve as an introducer. A third
location could be a federation of doctors in an area, potentially
with other health providers (such as hospitals and convalescent
centers), Bob has setup an identity with Alice, but if he gets
referred to Charlie by Alice for some procedures, Charlie would not
need to setup a new identity for Bob but instead could just refer to
Alice for the necessary identity proof. Many of these types of
situations could be dealt with by [ABFAB].
There are a number of other additional services that could be
Freeman, et al. Expires February 4, 2012 [Page 16]
Internet-Draft Requirements for Message Access Control July 2011
provided by the policy system. One example would be that if Bob does
not access his message within a given time period, the policy server
could notify Alice of this fact so that an alternate method of
communication can be attempted with the same information.
If Bob replies 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 contents when
sharing with others.
3.3. Business to Business Ad-Hoc Email
Early in the relationship between two companies, it is frequently
necessary to exchange sensitive information. This needs to occur
before the relationship has matured to the point that a formal
relationship is reflected through a legal agreement. Business owners
need the agility to interact with potential partners without having
to engage their respective IT staffs as a prerequisite of the
communication. As example, the IT staff might need to provide cross
certifications and exposure of certificate repositories.
As an example, 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 wants to send Dave some
sensitive information relating to the new business opportunity. When
Charlie sends the email to Dave with the sensitive content, he must
ensure the following objectives:
(a) Only Dave can read the email
(b) The Dave authenticates with a level 2 or above level of identity
assurance.
(c) The Dave can verify the email is from Charlie
(d) The Dave can verify the email has not been tampered with
(e) Charlie may also need to keep a record of the fact that Dave
accessed the message and when it was done.
The sequence of events would be as follows:
1. 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.
Freeman, et al. Expires February 4, 2012 [Page 17]
Internet-Draft Requirements for Message Access Control July 2011
2. Charlie's email client allows him to classify the email. He
classifies the email as an Ad-hoc pre-contractual communication.
3. Charlie's client knows the protections to apply to Ad-hoc pre-
contractual communication; it knows to encrypt and integrity-
protect the message and the level of assurance required for the
recipients identity.
4. The protected email is able to flow securely and seamlessly
through existing email infrastructure to the recipients (Dave in
this case). The data is protected while in transit or at rest.
5. Dave receives the email as sees it is a secure message from
Charlie. (Charlie requires level 2, Dave uses a password) Dave
is able to prove his identity to the level of assurance
requested by Charlie so is able to read the email. The
organization Dave work for has an identity service which he uses
to prove his identity for Charlie's email. Dave opens the email.
If Dave replies 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.
3.4. Business to Business Regulated Email
As business relationship mature they often result in a formal
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 government legal policies for
access control, authentication and integrity. The set of policies
applicable to an email is potentially 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 other's 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
Freeman, et al. Expires February 4, 2012 [Page 18]
Internet-Draft Requirements for Message Access Control July 2011
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.
4. The recipients can verify who the email is from to an acceptable
level of assurance as defined by the message policy
5. The recipients can verify the email has not been tampered with to
an acceptable level of assurance as defined by the message policy
6. 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 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 it is a secure message from Frank.
(Frank requires level 3, Grace uses her smart card) Grace is able to
prove her identity to the level requested by Frank and provides the
Freeman, et al. Expires February 4, 2012 [Page 19]
Internet-Draft Requirements for Message Access Control July 2011
requested attributes about herself in order to satisfy both the
Program X export control and the Company Foo IP protection policies.
Grace opens the email.
If Grace replies 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 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 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.
3.5. Email Pipeline Inspection (Security Boundary 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 content. They have a server which scans email from the
Internet. This works fine as long as the email is not encrypted,
however in that event the server will have a policy on how to deal
with encrypted mail. For some companies, encrypted mail will be
passed through and virus detection software on the recipient's system
will be relied on. In other circumstances, the decryption key used
by the recipient is shared with the gateway software so that it can
decrypt the message.
The ability to decrypt and check the content for malicious content is
still highly desirable even when a PLASMA encrypted email message is
encountered. The methods that this can be dealt with are as follows:
1. The scanning server can authenticate to the policy server as the
entity that is doing virus and malware scanning. The policy may
have specific attributes that allow for access to be granted to
systems in this case and the appropriate decryption keys will be
Freeman, et al. Expires February 4, 2012 [Page 20]
Internet-Draft Requirements for Message Access Control July 2011
released.
2. The policy server may be configured with information about the
various gateways and have certificates associated with them. In
this case the policy server can return a normal X.509 recipient
info structure (lockbox) to the sender of the message for
inclusion in the recipient info list. This allows normal
processing by the scanning software without the necessity to stop
and query the policy server for keying information.
3. The scanning server can either pass the encrypted mail without
scanning it or reject the mail. This decision would be based on
local policy.
3.6. 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.
3.6.1. Document Protection
This scenario is very similar to 3.3 and 3.4 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.
Freeman, et al. Expires February 4, 2012 [Page 21]
Internet-Draft Requirements for Message Access Control July 2011
4. Users can verify who the author was to an acceptable level of
assurance as defined by the document policy
5. Users can verify the document has not been tampered with to an
acceptable level of assurance as defined by the document policy
6. 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.
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 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 sees 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.
AUTHOR NOTE: Need XMPP scenario . Draft something and send to Leif
Freeman, et al. Expires February 4, 2012 [Page 22]
Internet-Draft Requirements for Message Access Control July 2011
and Peter for review.
Freeman, et al. Expires February 4, 2012 [Page 23]
Internet-Draft Requirements for Message Access Control July 2011
4. General Data Model
This work is modeled on a well established set of Actors for policy
enforcement [rfc3198] [XACML-core].
Policy Authoring Point (PAP): A service that creates policy rules
Policy Publication Point (PPP): The location where a PAP publishes
policy rules
Policy Decision Point (PDP): A service that is able to interpret the
policy rules published by a PAP to make decisions to allow or deny
requests
Policy Information Point (PIP): A service with issues assertions
about subjects, e.g. a SAML Security Token Service. This model
supports both front end and back end exchange of assertions.
Policy Enforcement Point (PEP): A set of code that queries a PDP and
ensures that the appropriate decision is enforced.
Freeman, et al. Expires February 4, 2012 [Page 24]
Internet-Draft Requirements for Message Access Control July 2011
-----------------
| |
| Policy |
| Authoring |
| Point |
| |
-----------------
|
Issue | Publish Issue
Attributes v Policy Attributes
| v |
----------------- | ----------------- | ----------------
| | | | | | | |
| Policy | | | Policy | | | Policy |
| Information |----->>| Publication |<<-----| Information |
| Point | | Point | | Point |
| | | | | |
----------------- ----------------- ----------------
| | |
| Issue | Read Issue |
| Attributes v Policy Attributes |
| v |
| ----------------- |
| | | |
| | Policy | |
| ------------>>| Decision |<<--------- |
| | | Point | | |
| | | | | |
| | ----------------- | |
| | Protect Consume | |
| | Content Content | |
| | Request Request | |
v | | v
v | | v
----------------- -----------------
| | | |
| Content | Distribute | Content |
| Creation | Content | Consumption |
| Policy | ---------------------------->>| Policy |
| Enforcement | | Enforcement |
| Point | | Point |
| | | |
----------------- -----------------
Figure 1 General Scheme for Publishing and Consuming Protected Content
The model is applicable to any data e.g. email, documents, databases
etc. Another objective is to not require the PEP to have access to
Freeman, et al. Expires February 4, 2012 [Page 25]
Internet-Draft Requirements for Message Access Control July 2011
the plain text content in order to be able to make decision requests
to the PDP. Policy process is complex so the PEP in this model just
uses policy pointers or policy labels to policy. The model allows the
content creation PEP to discover the set of policies a PDP would
allow the user to assert based on a role based assignment. The
Content consuming PEP dynamic may discover the PDP's who are
authoritative for the protected content in question.
When the Content Creation PEP bootstraps itself via the following
sequence of events:
(1) The content creation PEP is configured with the set PIP and PDP
it trusts.
(2) The content creation PEP summits a request to all the trusted
PDPs for what roles it has for the user. The use is
authenticated via attributes from the PIP. The attributes can be
exchanges via front or back end exchanges.
(3) The content creation receives a list of the roles the PDP can
configured for the user
(4) The PEP submits a request for the set of policy labels
authorized for each role. Additional attributes may be from the
PIP to authorize the release of the information for a role.
Now the PEP is bootstrapped with a list of roles and for each role a
list of polices associated with each role. Now the PEP is ready to
create content. When the user what to release protected content, they
use the following sequence of events
(i) The PEP encrypts the content to be protected
(ii) The PEP submits one or more CEK along with the set of requires
polices to be applied to the content to the PDP. The CEK can
be a raw key or a CEK key encrypted by a KEK if the user does
not want the PDP to have the ability to access the plain text
data. The PEP also submits a hash of the protected content.
(iii) The PDP returns encrypted metadata which contains the policy
list and the CEK. The metadata is signed by the PDP and
contain an integrity protected attributes to indicate the
network location(s) than can be used to submit decision
requests and the hash of the protected content.
(iv) The PEP attaches the PDP metadata to the protected content and
distributes the content.
4.1 Policy Types
Policies range from very simple to very complex. Polices have
dependencies not only on the technical implementation of the software
but on the range of attributes a PIP would issue to subjects. This is
likely constrained by the physical procedures a PIP would support to
Freeman, et al. Expires February 4, 2012 [Page 26]
Internet-Draft Requirements for Message Access Control July 2011
capture and verify the information about the subject. To manage this
range of requirements, this model uses type types of policy.
4.1.1 Basic Policy
Basic policy is intended to be universally usable by using a fixed
set of attributes. Basic policy is intended to be equivalent to
sending encrypted email with S/MIME today without the use of ESS
Security Labels. 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 that are
using public PIP which issue a limited set of attributes.
4.1.2 Advanced Policy
Advanced policy is intended to be used where one or more arbitrary
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. As such it is intended
to target the same set of situations where ESS Security Labels are
used with S/MIME today.
It is intended that policies will not have internal logic to combine
them; rather the infrastructure that is being provided will have a
set of logical operations that can be used for policy combination.
This allows for simpler definitions of policy as the logic of
combining policies can be done outside of the policy. This means
that one can combine policy A and policy B together with a logical
and or a logical or statement without the necessity of attempting to
define and have users use a policy C which is the combination of the
two policies.
5. Message Protection Requirements
5.1. General Requirements
Protected email MUST be where messages are confidential, integrity
protected AND provide data origination.
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 support the multiple levels of
identity assurance based on an identity assurance framework.(xref use
cases 1-3)
The specifics of every possible authorization algorithm to the IDP
cannot be know to the EPS, therefore the specifics of how the sender
Freeman, et al. Expires February 4, 2012 [Page 27]
Internet-Draft Requirements for Message Access Control July 2011
or recipient achieves the required level of identity assurance with
their Identity Provider MUST be abstracted from the email system e.g.
by the use of SAML [SAML-core] attributes.
Access to the plain text MUST only be provided after the recipient
has provided suitable valid attributes to satisfy the policy as
defined by the sender. (xref to ess labels)
Recipients MUST receive authenticated attributes of the identity of
the sender, the level of identity assurance of the sender and the
cryptographic fingerprint of the senders' message so the recipient
can confirm the messages has not been altered.
The decryption key exchange MUST support multiple levels of identity
assurance. The level of assurance requited MUST be selected by the
sender. need to disambiguate recipients auth vs. returning key to
recipient. Need matching text for encryption
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.
A time-to-live MUST be provided when access is granted to define when
the client needs submit a new access request.
The server being used to arbitrate message access control MUST have
no specific state for an individual message. It is completely
reasonable that the PDP being used by the sender of a message and the
PDP being used by the recipient of a message may be distinct and
share minimal information other than configuration (i.e. they would
need to know the encryption keys used by all PDPs).
The specifics of the access control policy MUST be abstracted from
the client i.e. the recipient's client MUST NOT make the access
control decision.
5.2. Email Requirements
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.
Freeman, et al. Expires February 4, 2012 [Page 28]
Internet-Draft Requirements for Message Access Control July 2011
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.2. Basic Policy Requirements
When using Basic Policy, the sending agent MUST define which basic
policy and the list of recipients.
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. need rewording to multiple basic polices
A sender using Basic policy MUST be able to send protected messages
without discovering any recipient's encryption key.
A message recipient MUST be able to obtain the required credentials
needed to read a message after a message has been created and sent.
5.3. Advanced Policy Requirements
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.
The system MUST support logical 'and' and logical 'or' as combining
operations. The system MAY support an 'except' operation (i.e. in
policy A but not in policy B).
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.
Freeman, et al. Expires February 4, 2012 [Page 29]
Internet-Draft Requirements for Message Access Control July 2011
6. IANA Considerations
This document describes the requirements for message access control.
As such no action by IANA is necessary for this document
Freeman, et al. Expires February 4, 2012 [Page 30]
Internet-Draft Requirements for Message Access Control July 2011
7. 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 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.
Freeman, et al. Expires February 4, 2012 [Page 31]
Internet-Draft Requirements for Message Access Control July 2011
Appendix A. References
A.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.
[rfc3198] Westerinen et. al., "Terminology for Policy Based
Management", November 2001.
[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", RFC 5751, January 2010
[SAML-core] OASIS, Assertions and Protocols for the Security
Assertion Markup Language (SAML) Version 2.0, March 2005
[sp800-63-1] NIST SP 800-63-1 "Electronic Authentication Guideline",
December 2008
A.2. Informative References
[ABFAB] Hewlett, J., S. Hartman, H. Tschofenig and E. Lear,
"Application Bridging for Federated Access Beyond Web
(ABFAB)", draft in progress.
[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-over] OASIS, Security Assertion Markup Language (SAML) Version
2.0 Technical Overview
[XACML-core] OASIS, eXtensible Access Control Markup Language (XACML)
Version 3.0 Core Specification
Freeman, et al. Expires February 4, 2012 [Page 32]
Internet-Draft Requirements for Message Access Control July 2011
Authors' Addresses
Trevor Freeman
Microsoft Corp.
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 February 4, 2012 [Page 33]