| Network Working Group | J. Schaad |
| Internet-Draft | Soaring Hawk Consulting |
| Intended status: Standards Track | March 09, 2012 |
| Expires: September 08, 2012 |
Plasma Service CMS Processing
draft-schaad-plasma-cms-00
Secure Mime (S/MIME) defined a method of placing security labels on a Cryptographic Message Syntax (CMS) object. These labels are placed as part of the data signed and validated by the parties. This means that the message content is visible to the recipient prior to the label enforcement. In [EPS-WS-TRUST] a new model has been presented where a third party is used as the enforcement point of the label. This document provides the details needed to implement the new Plasma model in the CMS infrastructure.
Additional benefits of using the Plasma module include moving responsibility of building lock boxes to the server and determining, based on policy, who should be a message recipient.
The document describes and details how the encryption process is performed, defines a new lock box attribute to hold the information needed to valid the label and to obtain the keys needed to decrypt the message. The document does not cover the protocol between the client and the Plasma policy enforcement server.
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/.
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 September 08, 2012.
Copyright (c) 2012 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.
In the traditional S/MIME (Secure MIME) e-mail system, the sender of a message is responsible for determining the list of recipients for a message, obtaining a valid public or group key for each recipient, applying a security label to a message, and sending the message. The recipient of a message is responsible for the enforcement of any security labels on a message. While this system works in theory, in practice it has some difficulties that have lead to problems in getting S/MIME mail widely deployed. This document is part of an effort to provide an alternative method of allocating the responsibilities above to different entities in an attempt to make the process work better.
In an Email Policy Service (PLASMA) deployment of S/MIME, the sender of the message is still responsible for determining the list of recipients for the message and determining the security label to be applied to the message, however the responsibility of obtaining valid keys for each recipient can be off-loaded to the Plasma server component. The recipient is no longer responsible for enforcement of the policy as this is off-loaded to the Plasma server component. Doing this allows for the following changes in behavior of the system:
This document is laid out as follows:
Some of the terms used in this document include:
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 [RFC2119].
To be supplied from the problem statement document.
To be supplied from the problem statement document.
(1)(2)(6)
(3)(5) +----------+ (7)
+------------|Sending |-------------+
| |Agent | |
(4) | +----------+ |
+----------+ +---------+
|Email | |Mail |
|Policy | |Transfer |
|Service | |Agent |
+----------+ +---------+
(4) | +----------+ |
| |Receiving | |
+------------|Agent |-------------+
(3)(5) +----------+ (1)
(2)(6)
List the boxes above and give some info about them.
The general steps that need to be taken by the sender of an EPS message are listed below. The steps refer to the numbers in the upper halve of Figure 1. Talk about the expansion in section x.x
The general steps that need to be taken by a Receiving Agent for an EPS messaging system. The steps refer to the bottom half of Figure 1. An expansion of this is covered in Section 5.
This documents defines a new Other Key Attribute to be used in the KEK Recipient Info structure. There are two distinct ways that the problem of defining a new recipient info structure for Plasma could be approached. The first would be to define a new recipient info structure to be placed in the Other Recipient Info structure. The second option is to create a new key attribute to be placed in the KEK Recipient Info structure.
The use of a new recipient info structure would have been the easiest to document and implement, if most major CMS implementations had kept up with the latest versions. However it is known that several implementations stopped with RFC 2630 [RFC2630] and it was not until RFC 3369 [RFC3369] that the other recipient info choice was introduced along with the language stating that implementations need to gracefully handle unimplemented alternatives in the choice. This means that if a new recipient info structure was defined and adopted, the mail message would fail decoding for many recipients, even for those recipients that had a key transfer or key agreement recipient info structure. For this reason it was decided that the second option would be chosen.
The use of the KEKRecipeintInfo type may seem to be a stretch at first, it was defined for those situations where a symmetric key had already been distributed and either a specific key or a specific transformation on the key was to be applied in order to decrypt the KEK value. However, in the most generic situation, Plasma will distribute a symmetric key back to the client so the difference between the original usage and how Plasma uses it is when the symmetric key is distributed to the recipient. Additionally, it is easy for client implementations to make the determination of a Plasma recipient info by looking at the OID for the other key attribute structure.
The attribute is created only by a Plasma server and not by the client software. A protocol such as the one in RFC TBD1 [EPS-WS-TRUST] is used for clients to obtain the attribute from a Plasma server.
For the convenience of the reader we include the KEKRecipientInfo structure pieces here (copied from [CMS-ASN]:
KEKRecipientInfo ::= SEQUENCE {
version CMSVersion, -- always set to 4
kekid KEKIdentifier,
keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
encryptedKey EncryptedKey }
KEKIdentifier ::= SEQUENCE {
keyIdentifier OCTET STRING,
date GeneralizedTime OPTIONAL,
other OtherKeyAttribute OPTIONAL }
OtherKeyAttribute ::= SEQUENCE {
keyAttrId KEY-ATTRIBUTE.
&id({SupportedKeyAttributes}),
keyAttr KEY-ATTRIBUTE.
&Type({SupportedKeyAttributes}{@keyAttrId})}
When you look at the KEKRecipientInfo structure you fill out the fields as follows:
The EPS Other Key Attribute functions as the lock box for the KEK used in encrypting the CEK. In addition to the KEK, the lock box also contains the information that is needed by the Email Policy Server to know the policy(s) applied to the encrypted data and possible parameters for the policy and for the client to validate that the lock box applies to the encrypted content.
The relevant section from the ASN.1 module which contains the content is:
--
-- New Other Key Attribute value for Plasma
-- This structure holds the encrypted KEK value for the server
-- and other signed attributes used by the client for checking
-- the structure applies in this case
--
keyatt-eps-kek KEY-ATTRIBUTE ::= {
SignedData IDENTIFIED BY id-keyatt-eps-token
}
id-keyatt-eps-token OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD2 }
We define a new KEY-ATTRIBUTE called keyatt-eps-kek. This attribute is identified by the id-keyatt-eps-token. The data structure that is associated with this key attribute is the CMS SignedData structure. The CMS SignedData structure is used directly without a CMS ContentInfo structure wrapping it.
The SignedData structure fields are filled as follows (some less significant fields are omitted):
When creating the recipient info structures for the EnvelopedData structure, there will normally only need to be a single entry in the sequence as the only entity that needs to decrypt the EPS Lockbox is the Email Policy Service. In the event that the service is distributed over multiple servers then multiple lock boxes may need to be created. One of the implications of the fact that the originator of the message is the only recipient is that, although the signing key needs to be contained in a certificate, there is no corresponding requirement that the encryption key needs to be in a certificate. Instead of using a certificate, a subject key identifier that is meaningful only to the Email Policy Service can be used.
The inner content type for an EPS Other Key Attribute is an EPS Lockbox. This content is contained in an encrypted CMS object which is encrypted by and for the Plasma server itself, as such the contents and structure is known just to the Plasma server.
The relevant section from the ASN.1 module which defines this content is:
--
-- EPS Content Type
--
ct-eps-LockBox CONTENT-TYPE ::= {
TYPE EPS-LockBox
IDENTIFIED BY id-ct-eps-LockBox
}
id-ct-eps-LockBox OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) TBD1}
EPS-LockBox ::= SEQUENCE {
label OneLabel,
keyList KeyList,
attrList AttributeList OPTIONAL
}
KeyList ::= SEQUENCE {
namedRecipients [0] SEQUENCE SIZE (1..MAX) OF
NamedRecipient OPTIONAL,
defaultRecipients [1] SEQUENCE SIZE (1..MAX) OF
OneKek OPTIONAL
}
(WITH COMPONENTS {
...,
namedRecipients PRESENT
} |
WITH COMPONENTS {
...,
defaultRecipients PRESENT
})
NamedRecipient ::= SEQUENCE {
recipient IA5String, -- name of the recipient
kekValue SEQUENCE {
kekIdentifier OCTET STRING,
keyValue RecipientInfo
}
}
OneKek ::= SEQUENCE {
kekIdentifier OCTET STRING,
kekValue OCTET STRING
}
OneLabel ::= CHOICE {
andLabels [1] SEQUENCE SIZE (2..MAX) OF OneLabel,
orLabels [2] SEQUENCE SIZE (2..MAX) OF OneLabel,
exclude [3] SEQUENCE SIZE (2) OF OneLabel,
uriLeaf [4] SEQUENCE {
policyId UTF8String,
names SEQUENCE SIZE (1..MAX) OF
IA5String OPTIONAL
},
oidLeaf [5] ESSSecurityLabel,
...
}
AttributeList ::= SEQUENCE SIZE (1..MAX) OF
SingleAttribute{{EPSAttributes}}
EPSAttributes ATTRIBUTE ::= { ... }
In the above ASN.1, the following items are defined:
The ASN.1 type OneLabel has been explicitly defined to allow for later extensibility. When a new element is added, it will be added with at the end of the choice with a different tag value. ASN.1 decoders need to following the current recommendations on dealing with extensibility. This means that when the decoder finds a new choice in this structure that is not part of the current syntax, the element should be treated as an unknown blob and returned to the caller as an unrecognized blob. This allows for the calling code to make the decision on how the unknown element is treated.
However the extensibility is not handled the same in all cases. Each of the four different cases is outlined below.
The set of policies that can be used by the sender in applying a label is usually given as a list of policies, however under some circumstances the sender may be handed structured policies either for application or for checking that some policies can be used together. If structured policies are provided to the sender, it will not matter to the sender that they cannot evaluate the policy unless the details are to be shown to the sending user. Following the current ASN.1 rules which allow for the decoding and then re-encoding of a type which contains unknown nodes allows the sending agent the most flexibility.
The protocol used to give the policy information to the sending client may not use the ASN.1 structure provided here or configuration purposes but would generally be expected to provide for a different data format.
In the sending agent to Email Policy Service protocol (defined external to this document) the ASN.1 type OneLabel may or may not be used directly. If it is used, then the Email Policy Server is expected to reject the label if it contains elements which it does not understand. The general expectation is that the Email Policy Service that the sender is communicating with is going to be the same one as is later enforcing the policy. It makes no sense for this server to accept a policy that it would later be unable to enforce. The protocol should make provisions for the return of this as an explicit error code. Having the ASN.1 decoded allows for the communication of the exact tag that is causing the problem. Under most policies, the evaluation of sender policy would be expected to be different than laid out in the next session. As a general rule, the sender should be permitted to assert all of the leaf policies for the purpose of sending.
The Email Policy Service which recipient communicates way is normally the same server as the sender communicated with. However the server can be a different server, or the server may have been downgraded in the mean time. In this case the policy evaluation need to be conservative. There are two different ways of doing this evaluation. The first option is to say that if an unknown node is found, then the policy evaluation results in "Deny" for all cases. The second option is to try and evaluation the policy, but to do so in a conservative manner. In this section we use the same terms as XACML [XACML] uses in section 7.2.1. If the second option is chosen then the following rules are used:
If the final node results in "Permit", then access is granted. If the final result is either "Deny" or "Not Applicable" then access is denied. If the final result is "Indeterminate", then access is denied, however if the protocol permits, then the result can be "Not Applicable" and the attributes needed to do the policy evaluation can be requested and policy evaluation may be re-attempted.
Any future element that is added to the choice needs to define a similar rule to the set of rules above.
Recipient user agents may want to display the policy to the user. This policy may be communicated from the Email Policy Service to the recipient using the OneLabel ASN.1 structure or using a different type. The label has been successfully (or unsuccessfully) validated so access has been granted (or denied) to the message. At this point we are only talking about a user interface issue. The recipient user agent should make some type of provision for indicating that an operation was placed in that location of the tree, but the agent is not aware of what the operation is.
It is required that the name of the Email Policy Server be securely communicated to the message recipient. For this purpose a URL is used as this can communicate both a server name as well as additional parameters that can be used to identify a specific service on the server.
The relevant section from the ASN.1 module for this attribute is:
--
-- Define the Signed Attribute to carry the
-- Email Policy Server URL
--
-- This attribute is added to the SignedAttributSet set of
-- attributes in [CMS-ASN]
--
aa-eps-url ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-aa-eps-url
}
id-aa-eps-url OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD3}
From this we can see the following:
The attribute structure defined for signed attributes allows for multiple values to be carried in a single attribute. For this attribute there MUST be at least one value. If there is more than one value, each value MUST be a unique. Multiple values are allowed as there can be multiple Plasma servers that can be used to evaluate the policy. The order of URLs does not indicate any order of priority, any of the values may be used.
This attribute is only included in a SignedData object by an Email Policy Server. There are no processing rules for the sender of a message. The processing rules for a recipient can be found in Section 5.
For privacy reasons, it is highly desirable that the recipient of a message can validate that the Plasma lock box embedded in a message is associated with encrypted data it is attached to. For this reason, in addition to the requirement that a recipient validate the signature of the Plasma server over the lock box, a new attribute is defined which contains the hash of the encrypted content.
--
-- Define the Signed Attribute to carry the
-- hash of encrypted data
--
-- This attribute is added to the SignedAttributeSet set of
-- attributes in [CMS-ASN]
--
aa-eps-hash ATTRIBUTE ::= {
TYPE HashValue IDENTIFIED BY id-aa-eps-hash
}
id-aa-eps-hash OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD4}
HashValue ::= SEQUENCE {
hashAlgorithm DigestAlgorithmIdentifier,
hashValue OCTET STRING
}
The above ASN.1 fragment defines the following items:
The hash is computed over the encrypted content, without including any of the ASN.1 wrapping around the content. Thus this value does not cover the content type identifier, the encryption algorithm and parameters or any authenticated attributes for AEAD algorithms.
This is the set of processing steps that a sender needs to do (the order of the steps is not normative):
In this section we expand on the list of actions that are Section 2.3. When looking at the validation steps that are given here, the results need to be the same but the order that the steps are taken can be different. As an example, it can make sense to do the policy check in step X before doing the signature validation as this would not require any network access.
This is the set of processing that the recipient needs to do:
In some circumstances a message recipient may be permitted to read a message sent under a certan policy, but it not permitted to send a message for that policy. In the event that a complex policy is used the recipient may be permitted to read under one policy, but not have any rights under a second policy. In both of these case a recipient of a message would be unable to either reply or forward a message using the same policy as they received it under. For this reason, the protocol used to communicate with the Plasma server will frequently return a single purpose policy that permits a recipient to reply to a message using the same policy as the original message.
The SMIMECapabilities attribute was defined by S/MIME in [SMIME-MSG] so that the abilities of a client can be advertised to the recipients of an S/MIME message. This information can be advertised either directly in an S/MIME message sent from a client to a recipient, or more indirectly by publishing the information in an LDAP directory [RFC4262].
A new S/MIME capability is defined by this document so that a client can advertise to others that it understands how to deal with Plasma recipient information. The ASN.1 for this attribute is:
--
-- Create an S/MIME capability for advertising that
-- a client can understand the PLASMA recipient info
-- structure information
--
cap-Plasma-RecipientInfo SMIME-CAPS ::= {
IDENTIFIED BY id-cap-plasma-recipientInfo
}
id-cap-plasma-recipientInfo OBJECT IDENTIFIER ::= {
id-cap TBD5
}
We define a new SMIME-CAPS object called cap-Plasma-RecipentInfo. This attribute is identified by the the OID id-cap-plasma-recipientInfo and has no data structure associated with it. When encoded as an S/MIME capability the parameters MUST to be absent and not NULL.
KEK manditory to implement algorithms - MUST AES-128 KEK Wrap. SHOULD AES-256 KEK wrap.
Key Transport - MUST RSA v 1.5
Key Agreement - MUST EC-DH for group ...
Content Encryption - MUST AES-128.
Man in the middle attack on the protocol from the sending agent to the email policy server.
Man in the middle attack on the protocol from the receiving agent to the email policy server.
All of the object identifiers defined by this document are done so under the existing S/MIME Object Identifier arc. No actions by IANA are required for this document.
| [CMS-ASN] | Hoffman, P. and J. Schaad, "New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME", RFC 5911, June 2010. |
| [CMS-AED] | Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007. |
| [EPS-WS-TRUST] | Schaad, J, "Using WS Trust as an EPS protocol", Internet-Draft draft-TBD, December 2010. |
| [ESS-BASE] | Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [SMIME-MSG] | Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. |
| [Plasma] | Freeman, T., Schaad, J. and P. Patterson, "Requirements for Message Access Control", Work in progress draft-freeman-message-access-control, October 2011. |
| [RFC3369] | Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, August 2002. |
| [RFC2630] | Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. |
| [RFC4262] | Santesson, S., "X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities", RFC 4262, December 2005. |
| [eps-token] | Schaad, J., "Email Policy Service Trust Processing", Work in progress draft-schaad-plasma-service, March 2012. |
| [XACML] | Rissanen, E, "eXtensible Access Control Markup Language (XACML) Version 3.0", OASIS Standard xacml-201008, August 2010. |
PolicySMime -- TBD Get a module number --
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
-- Cryptographic Message Syntax (CMS) [RFC5652]
CONTENT-TYPE, RecipientInfo, KEY-ATTRIBUTE, SignedData,
DigestAlgorithmIdentifier
FROM CryptographicMessageSyntax-2010
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
-- Common PKIX structures [RFC5912]
SMIME-CAPS
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58)}
ATTRIBUTE, SingleAttribute{}
FROM PKIX-CommonTypes-2009
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) }
ESSSecurityLabel
FROM ExtendedSecurityServices-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-ess-2006-02(42) }
id-cap
FROM SecureMimeMessage
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-msg-v3dot1-02(39) }
;
--
-- EPS Content Type
--
ct-eps-LockBox CONTENT-TYPE ::= {
TYPE EPS-LockBox
IDENTIFIED BY id-ct-eps-LockBox
}
id-ct-eps-LockBox OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs7(7) TBD1}
EPS-LockBox ::= SEQUENCE {
label OneLabel,
keyList KeyList,
attrList AttributeList OPTIONAL
}
KeyList ::= SEQUENCE {
namedRecipients [0] SEQUENCE SIZE (1..MAX) OF
NamedRecipient OPTIONAL,
defaultRecipients [1] SEQUENCE SIZE (1..MAX) OF
OneKek OPTIONAL
}
(WITH COMPONENTS {
...,
namedRecipients PRESENT
} |
WITH COMPONENTS {
...,
defaultRecipients PRESENT
})
NamedRecipient ::= SEQUENCE {
recipient IA5String, -- name of the recipient
kekValue SEQUENCE {
kekIdentifier OCTET STRING,
keyValue RecipientInfo
}
}
OneKek ::= SEQUENCE {
kekIdentifier OCTET STRING,
kekValue OCTET STRING
}
OneLabel ::= CHOICE {
andLabels [1] SEQUENCE SIZE (2..MAX) OF OneLabel,
orLabels [2] SEQUENCE SIZE (2..MAX) OF OneLabel,
exclude [3] SEQUENCE SIZE (2) OF OneLabel,
uriLeaf [4] SEQUENCE {
policyId UTF8String,
names SEQUENCE SIZE (1..MAX) OF
IA5String OPTIONAL
},
oidLeaf [5] ESSSecurityLabel,
...
}
AttributeList ::= SEQUENCE SIZE (1..MAX) OF
SingleAttribute{{EPSAttributes}}
EPSAttributes ATTRIBUTE ::= { ... }
--
-- New Other Key Attribute value for Plasma
-- This structure holds the encrypted KEK value for the server
-- and other signed attributes used by the client for checking
-- the structure applies in this case
--
keyatt-eps-kek KEY-ATTRIBUTE ::= {
SignedData IDENTIFIED BY id-keyatt-eps-token
}
id-keyatt-eps-token OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD2 }
--
-- Define the Signed Attribute to carry the
-- Email Policy Server URL
--
-- This attribute is added to the SignedAttributSet set of
-- attributes in [CMS-ASN]
--
aa-eps-url ATTRIBUTE ::= {
TYPE UTF8String IDENTIFIED BY id-aa-eps-url
}
id-aa-eps-url OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD3}
--
-- Define the Signed Attribute to carry the
-- hash of encrypted data
--
-- This attribute is added to the SignedAttributeSet set of
-- attributes in [CMS-ASN]
--
aa-eps-hash ATTRIBUTE ::= {
TYPE HashValue IDENTIFIED BY id-aa-eps-hash
}
id-aa-eps-hash OBJECT IDENTIFIER ::= {iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) TBD4}
HashValue ::= SEQUENCE {
hashAlgorithm DigestAlgorithmIdentifier,
hashValue OCTET STRING
}
--
-- Create an S/MIME capability for advertising that
-- a client can understand the PLASMA recipient info
-- structure information
--
cap-Plasma-RecipientInfo SMIME-CAPS ::= {
IDENTIFIED BY id-cap-plasma-recipientInfo
}
id-cap-plasma-recipientInfo OBJECT IDENTIFIER ::= {
id-cap TBD5
}
END