Network Work Group Trevor Freeman
Internet-Draft Microsoft Corp.
Intended status: Informational Jim Schaad
Expires: July 29, 2011 Soaring Hawk Consulting
Patrick Patterson
Carillon Information Security Inc
January 20, 2011
Requirements for Message Access Control
draft-freeman-message-access-control-req-00
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 July 24, 2011 [Page 1]
Internet-Draft Requirements for Message Access Control January 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 July 24, 2011 [Page 2]
Internet-Draft Requirements for Message Access Control January 2011
Freeman et al. Expires July 24, 2011 [Page 3]
Internet-Draft Requirements for Message Access Control January 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 . . . . . . . . . . . . . . . 10
4.3 Business to Business Regulated . . . . . . . . . . . . . . 11
4.4 Email Pipeline Inspection . . . . . . . . . . . . . . . . 12
5 Message Protection Requirements . . . . . . . . . . . . . . . . 12
5.1 General Requirements . . . . . . . . . . . . . . . . . . . 12
5.2 Basic Policy Requirements . . . . . . . . . . . . . . . . 13
5.3 Advanced Policy Requirements . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
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 July 24, 2011 [Page 4]
Internet-Draft Requirements for Message Access Control January 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 July 24, 2011 [Page 5]
Internet-Draft Requirements for Message Access Control January 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 July 24, 2011 [Page 6]
Internet-Draft Requirements for Message Access Control January 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 July 24, 2011 [Page 7]
Internet-Draft Requirements for Message Access Control January 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 July 24, 2011 [Page 8]
Internet-Draft Requirements for Message Access Control January 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 July 24, 2011 [Page 9]
Internet-Draft Requirements for Message Access Control January 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. A doctor has received test results their patient. The
information is confidential so any channel of communication they
selects must protect the patient's privacy. The doctor elects to use
email to reach their patient quickly with news of the results. They
must ensure that:
1. Only the patient can read the email
2. The patent authenticates with an acceptable level of assurance
3. The patient can verify the email is from their doctor
4. The patient can verify the email has not been tampered with
The doctor composes the email their patient. They include some
comments and suggestions for the patient and attach the test results.
The doctor's email client allows classifications to be bound to an
email. The doctor classifies the email as a Doctor-Patient
communication.
The email client knows the protections to apply to Doctor-Patient
communication; to encrypt and integrity-protect and the level of
assurance required for the recipients identity.
The email is able to flow securely and seamlessly through existing
email infrastructure to the patient. The data is protected while in
transit or at rest.
4.2 Business to Business Ad-Hoc
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
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.
A group of people have met to discuss the prospect of a potential new
business opportunity. Following the meeting the participants now want
to exchange some documents. When the mail is sent with the sensitive
content the sender must ensure:-
1. Only the business colleagues can read the email
2. The colleague authenticates with an acceptable level of assurance
Freeman et al. Expires July 24, 2011 [Page 10]
Internet-Draft Requirements for Message Access Control January 2011
3. The colleague can verify the email is from another colleague
4. The colleague can verify the email has not been tampered with
The sender composes the email their colleague. They include some
information relation to their assigned actions and attach the draft
contact.
The senders email client allows classifications to be bound to an
email. The sender classifies the email as an Ad-hoc pre-contractual
communication.
The email client knows the protections to apply to Ad-hoc pre-
contractual communication; to encrypt and integrity-protect and the
level of assurance required for the recipients identity.
The email is able to flow securely and seamlessly through existing
email infrastructure to the patient. The data is protected while in
transit or at rest.
4.3 Business to Business Regulated
As business relationship mature they often result in a formal
contractual agreement to work together. The agreement may define a
number of work areas and deliverables. These deliverable may be
regulated and require precise polices for access control,
authentication and integrity for the applicable data.
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 the program X. Company
Foo as set up some business rules for access to program X data to
ensure compliance with export control requirements. Company foo has
given pointers to the policies to company Bar.
An employee of foo has been assigned to program X. They want to send
some mail to colleagues in both Foo and Bar who are working on program
X. When the mail is sent with the sensitive content the employee must
ensure
1. Only the persons who meet the program X policy as defined by
company Foo can read the email
2. The recipients authenticates with an acceptable level of
assurance as defined by the company foo policy
3. The recipients can verify who the email is from
Freeman et al. Expires July 24, 2011 [Page 11]
Internet-Draft Requirements for Message Access Control January 2011
4. The recipients can verify the email has not been tampered with
5. They can also tell it is a program email and the contents can
only be shared with other program workers.
The sender composes the email and includes a set of recipients in both
Foo and Bar. They include some information relation to their assigned
actions for the program.
The senders email client allows classifications to be bound to an
email. The sender classifies the email as Program X and contains
export controlled information.
The email client knows the protections to apply to Program X email; to
encrypt and integrity-protect and the level of assurance required for
the recipients identity.
The email is able to flow securely and seamlessly through existing
email infrastructure to the patient. The data is protected while in
transit or at rest.
Only recipients who meet the Program X policy are able to read the
email.
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
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.
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.
Freeman et al. Expires July 24, 2011 [Page 12]
Internet-Draft Requirements for Message Access Control January 2011
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
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.
Freeman et al. Expires July 24, 2011 [Page 13]
Internet-Draft Requirements for Message Access Control January 2011
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.
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.
Freeman et al. Expires July 24, 2011 [Page 14]
Internet-Draft Requirements for Message Access Control January 2011
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
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
Freeman et al. Expires July 24, 2011 [Page 15]
Internet-Draft Requirements for Message Access Control January 2011
[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
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
Freeman et al. Expires July 24, 2011 [Page 16]
Internet-Draft Requirements for Message Access Control January 2011
Email: ietf@augustcellars.com
Patrick Patterson
Carillon Information Security Inc
Email: ppatterson@carillon.ca
Freeman et al. Expires July 24, 2011 [Page 17]