< draft-ietf-smime-rcek-03.txt		draft-ietf-smime-rcek-04.txt >
			A new Request for Comments is now available in online RFC libraries.
	INTERNET-DRAFT S. Farrell		RFC 3185
	Expires in six months Baltimore Technologies
	S. Turner
	IECA
	May 2001
	Reuse of CMS Content Encryption Keys
	<draft-ietf-smime-rcek-03.txt>
	Status of this Memo
	This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of [RFC2026].
	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/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	Abstract
	This note describes a way to include a key identifier in a CMS
	enveloped data structure, so that the content encryption key can be
	re-used for further enveloped data packets.
	Table Of Contents
	Status of this Memo.............................................1
	Abstract........................................................1
	Table Of Contents...............................................1
	1. Introduction.................................................2
	2. Applicability................................................2
	3. How to do it.................................................3
	4. Using different CEK and KEK algorithms.......................4
	5. Conformance..................................................5
	6. Security Considerations......................................5
	7. References...................................................6
	Author's Addresses..............................................6
	Full Copyright Statement........................................6
	Appendix A: ASN.1 Module........................................7
	Appendix B: Revision History....................................9
	1. Introduction
	CMS [CMS] specifies EnvelopedData. EnvelopedData supports data
	encryption using either symmetric or asymmetric key management
	techniques. Since asymmetric key establishment is relatively
	expensive, it is desirable in some environments to re-use a shared
	content-encryption key established using asymmetric mechanisms for
	encryption operations in subsequent messages.
	The basic idea here is to reuse the content encryption key (CEK)
	from a message (say MSG1) to derive the key encryption key (KEK) for
	a later message, (MSG2), by including a reference value for the CEK
	in message 1, and that same value as the KEKIdentifier for message
	2. The CEK from message 1 is called the "referenced CEK".
	The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
	in this document are to be interpreted as described in [RFC2119].
	2. Applicability
	This specification is intended to be used to provide more efficient
	selective field confidentiality between communicating peers, in
	particular in the cases where:
	- The originator is a client that wishes to send a number of fields
	to a server (the recipient) in a single transaction, where the
	referenced CEK is used for the separate encryption of each field.
	- The originator and recipient are servers that communicate very
	frequently and use this specification purely for efficiency.
	This specification is not intended to be applicable in all cases. It
	is suited for use where:
	- Its use is further scoped: that is, this specification doesn't
	define a protocol but merely a trick that can be used in a larger
	context and additional specification will be needed for each such
	case. In particular, in order to use this specification, it is
	REQUIRED to define the originators' and recipients' behavior where
	a referenced CEK has been "lost".
	- This specification is not suitable for general group key
	management.
	- The underlying cryptographic API is suitable: it is very likely
	that any cryptographic API that completely "hides" the bits of
	cryptographic keys from the CMS layer will prevent reuse of a
	referenced CEK (since they won't have a primitive that allows
	MSG1.CEK to be transformed to MSG2.KEK).
	- The algorithms for content and key encryption have compatible key
	values and strengths, that is, if MSG1.contentEncryptionAlgorithm
	is a 40bit cipher and MSG2.keyEncryptionAlgorithm requires 168
	bits of keying material, then this specification SHOULD NOT be
	used.
	There are other ways that could be envisaged to establish the
	required symmetric keying material, e.g. by leveraging a group
	keying scheme or by defining a content type that contains a KEK
	value. Although this scheme is much simpler than generic group key
	management, if an implementation already supports group key
	management then this scheme doesn't add value. This scheme is also
	suitable for inclusion in CMS libraries (though the addition of new
	state might be a problem for some implementations), which can offer
	some advantages over application layer schemes (e.g. where the
	content includes MSG2.KEK).
	3. How to do it
	In order to reference the content-encryption key (CEK) used in an
	EnvelopedData, a key identifier can be included in the
	unprotectedAttrs field of MSG1. This key can then be used to derive
	the key-encryption key (KEK) for other instances of EnvelopedData or
	for other purposes. If the CEK from MSG1 is to be used to derive the
	KEK for MSG2 then MSG1 MUST contain an unprotectedAttrs Attribute of
	type id-aa-CEKReference with a single value using the CEKReference
	syntax.
	MSG2.KEK is to be derived by reversing the bytes of MSG1.CEK. The
	byte reversal is to avoid an attack where the attacker has a known
	plaintext and the related ciphertext (encrypted with MSG1.CEK) that
	(otherwise) could be directly used as a MSG2.KEK.
	The application MUST ensure that the relevant algorithms are
	compatible. That is, a CEKReference attribute alone can only be used
	where the content-encryption algorithm from MSG1 employs the same
	type of symmetric key as the key-encryption algorithm from MSG2.
	Notes:
	1) There is nothing to prevent inclusion of a CEKReference attribute
	in MSG2 as well as in MSG1. That is, an originator could "roll"
	the referenced CEK with every message.
	2) The CEKReference attribute can occur with any of the choices for
	RecipientInfo: ktri, kari or kekri. Implementors MUST NOT assume
	that CEKReference can only occur where ktri or kari is used.
	id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
	CEKReference ::= OCTET STRING
	id-aa is an object identifier defined in [CMS-MSG].
	In order to allow the originator of MSG1 to indicate the "lifetime"
	of the CEK, the originator MAY include a CEKMaxDecrypts attribute,
	also in the unprotectedAttrs field of EnvelopedData. This attribute
	has an INTEGER syntax (the value MUST be >=1 and maximally 2^31),
	and indicates to the recipient the maximum number of messages
	(excluding MSG1) that will use the referenced CEK. This Attribute
	MUST only be sent when a CEKReference attribute is also included.
	The recipient SHOULD maintain the CEKReference information
	(minimally the key identifier and the CEK value) while less than
	maxDecrypt messages have been successfully received. Recipients
	SHOULD delete the CEKReference information after some locally
	configured period.
	When this attribute is not present, originators and recipients
	SHOULD behave as if a value of one had been sent.
	id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
	CEKMaxDecrypts ::= INTEGER
	4. Using different CEK and KEK algorithms
	Where MSG1.content-encryption algorithm and MSG2.key-encryption
	algorithm are the same then the MSG2.KEK is the byte-reverse of
	MSG1.CEK. However, in general, these algorithms MAY differ, e.g.
	requiring different key lengths. This section specifies a generic
	way to derive MSG2.KEK for such cases.
	Note: In some sense, the CEK and KEK algorithms are never the
	"same", e.g. id-alg-CMS3DESwrap and des-ede3-cbc differ. However,
	for the purposes of this specification, all we care about is that
	the algorithms use the same format and size of keying material (see
	also security considerations) and that they do not differ
	significantly in terms of the resulting cryptographic "strength". In
	that sense the two algorithms in the example above are the "same."
	Implementations MAY include this functionality.
	The basic approach is to use the PBKDF2 key derivation function
	defined in PKCS#5 [RFC2898], but using MSG1.CEK as input instead of
	a password. The output of the PBKDF2 function is MSG2.KEK. To this
	end, a new attribute type is defined which allows passing of the
	required parameters.
	id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 }
	KEKDerivationAlgorithm ::= SEQUENCE {
	kekAlg AlgorithmIdentifier,
	pbkdf2Param PBKDF2-params
	}
	kekAlg is the algorithm identifier (and associated parameters, if
	any), for the MSG2 key encryption algorithm. Note that it is not
	necessary to protect this field since modification of keyAlg only
	represents a denial-of-service attack.
	The PBKDF2 algorithm parameters are to be handled as follows:
	- The salt MUST use the "specified" element of the CHOICE.
	- The message originator selects the iterationCount.
	- The value of keyLength is determined by the kekAlg and MUST be
	present.
	- The prf field MUST use the default algorithm specified in
	[RFC2898] which is algid-hmacWithSHA1 (and so the prf field MUST
	be omitted).
	5. Conformance
	This specification only applies to messages where the CEKReference
	attribute is present. All attributes specified here SHOULD be
	ignored unless they are present in a message containing a valid, new
	or recognized, existing value of CEKReference. The CEKMaxDecrypts
	attribute is to be treated by the recipient as a hint, but MUST be
	honored by the originator.
	The optional to implement KEKDerivationAlgorithm attribute MUST only
	be present when MSG1.content-encryption-algorithm differs from
	MSG2.key-encryption-algorithm, in which case it MUST be present.
	Implementations that recognize this attribute, but do not support
	the functionality SHOULD ignore the attribute.
	Ignoring attributes as discussed above, will lead to decryption
	failures. CMS implementations SHOULD be able to signal the
	particular reason for this failure to the calling application.
	6. Security Considerations
	Encryption does not provide authentication, for example, if the
	encryptedContent is essentially random then recipients MUST NOT
	assume that "knowing" a CEKReference value proves anything - anyone
	could have created the EnvelopedData. This is relevant both for
	security (the recovered plaintext should not be entirely random) and
	for avoiding denial of service (the recipient MUST NOT assume that
	using the right CEKReference means that message originator is
	genuine).
	Similarly, using the correct CEKReference does not mean that a
	message has not been replayed or inserted, and recipients MUST NOT
	assume that replay has been avoided.
	The maxDecrypts field presents a potential denial-of-service attack
	if a very large value is included by an originator in an attempt to
	get a recipient to consume memory by storing the referenced CEKs for
	a long period or if the originator never sends the indicated number
	of ciphertexts. Recipients SHOULD therefore drop referenced CEKs
	where the maxDecrypts value is too large (according to local
	configuration) or the referenced CEK has been held for too long a
	period.
	Suppose MSG1 is sent to a set S1 of users. In the case where MSG2 is
	sent to only a subset of users in S1, all users from S1 will still
	be able to decrypt MSG2 (since MSG2.KEK is computed only from
	MSG1.CEK). Implementers should be aware that in such cases, all
	members of the original set of recipients (S1) can access the
	plaintext of MSG2 and subsequent messages.
	The reason for the byte reversal is as follows: without the byte
	reversal, an attacker knowing some of MSG1.plaintext (a prefix in a
	field for instance) can use the corresponding ciphertext block as
	the next encrypted CEK, i.e. as MSG2.KEKRecipientInfo.encryptedKey.
	Now the attacker knows the next CEK. This attacks something this
	note is not claiming to protect (origin authentication), but is
	easily avoided using the byte reversal. Byte-reversal was chosen
	over bit-reversal since bit-reversal would cause parity bits from
	MSG1.CEK to be used as keying bits for MSG2.KEK for DES-based
	algorithms. Note that byte reversal would similarly affect parity if
	parity checks spanned more than one octet, however no well-known
	algorithms operate in this way.
	7. References
	[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630.
	[CMS-MSG] Ramsdell, B. "S/MIME Version 3 Message Specification",
	RFC 2633.
	[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
	Specification Version 2.0", RFC 2898, September 2000.
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	3", RFC 2026, BCP 9, October 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119.
	Author's Addresses
	Stephen Farrell,
	Baltimore Technologies,
	39 Parkgate Street,
	Dublin 8
	IRELAND
	tel: +353-1-881-6000
	email: stephen.farrell@baltimore.ie
	Sean Turner
	IECA, Inc.
	9010 Edgepark Road
	Vienna, VA 22182
	USA
	tel: +1.703.628.3180
	email: turners@ieca.com
	Full Copyright Statement
	Copyright (C) The Internet Society (date). All Rights Reserved.
	This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. In addition,
	the ASN.1 module presented in Appendix B may be used in whole or in
	part without inclusion of the copyright notice. However, this
	document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process shall be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assigns. This
	document and the information contained herein is provided on an "AS
	IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
	FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
	NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
	WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Appendix A: ASN.1 Module
	SMIMERcek
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
	smime(16) modules(0) rcek(13) }
	-- This module contains the definitions of the attributes
	-- used for re-using the content encryption key from a
	-- message in further messages.
	DEFINITIONS IMPLICIT TAGS ::=
	BEGIN
	-- EXPORTS ALL --
	IMPORTS
	AlgorithmIdentifier FROM
	AuthenticationFramework { joint-iso-itu-t ds(5)
	module(1) authenticationFramework(7) 3 } ;
	-- [RFC2898] uses 1993 ASN.1 to define PBKDF2-params. Since
	-- this specification only uses 1988 ASN.1, the definition is
	-- repeated here for completeness.
	-- The DEFAULT prf field value, MUST be used for this
	-- specification
	digestAlgorithm OBJECT IDENTIFIER ::=
	{ iso(1) member-body(2) us(840) rsadsi(113549) 2}
	id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7}
	-- [RFC2898] defines PBKDF2-params using 1993 ASN.1, which
	-- results in the same encoding as produced by the definition
	-- below. See [RFC2898] for that definition.
	PBKDF2-params ::= SEQUENCE {
	salt CHOICE {
	specified OCTET STRING, -- MUST BE USED
	otherSource AlgorithmIdentifier -- DO NOT USE THIS FIELD
	},
	iterationCount INTEGER (1..MAX),
	keyLength INTEGER (1..MAX) OPTIONAL
	}
	-- id-aa is the arc with all new authenticated and
	-- unauthenticated attributes produced the by S/MIME
	-- Working Group. It is also defined in [CMS-MSG]
	id-aa OBJECT IDENTIFIER ::=
	{iso(1) member-body(2) usa(840) rsadsi(113549)
	pkcs(1) pkcs-9(9) smime(16) attributes(2)}
	-- This attribute contains what will be the key identifier		Title: Reuse of CMS Content Encryption Keys
	-- for subsequent messages		Author(s): S. Farrell, S. Turner
	id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }		Status: Standards Track
	CEKReference ::= OCTET STRING		Date: October 2001
			Mailbox: stephen.farrell@baltimore.ie, turners@ieca.com
			Pages: 10
			Characters: 20404
			SeeAlso/Updates/Obsoletes: None
	-- This attribute contains a "hint" to the recipient		I-D Tag: draft-ietf-smime-rcek-04.txt
	-- indicating how many times the originator will use
	-- the re-used CEK
	id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
	CEKMaxDecrypts ::= INTEGER
	-- This attribute specifies the key derivation function		URL: ftp://ftp.rfc-editor.org/in-notes/rfc3185.txt
	-- to be used when the default byte reversal operation cannot
	-- be used.
	id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 }
	KEKDerivationAlgorithm ::= SEQUENCE {
	kekAlg AlgorithmIdentifier,
	pbkdf2Param PBKDF2-params }
	END		This document describes a way to include a key identifier in a CMS
			(Cryptographic Message Syntax) enveloped data structure, so that the
			content encryption key can be re-used for further enveloped data
			packets.
	Appendix B: Revision History		This document is a product of the S/MIME Mail Security Working Group
			of the IETF.
	Note to RFC editor: Please delete this section.		This is now a Proposed Standard Protocol.
	Changes from -00 to -01:		This document specifies an Internet standards track protocol for
			the Internet community, and requests discussion and suggestions
			for improvements. Please refer to the current edition of the
			"Internet Official Protocol Standards" (STD 1) for the
			standardization state and status of this protocol. Distribution
			of this memo is unlimited.
	- Removed error flag attribute, since this is the responsibility of		This announcement is sent to the IETF list and the RFC-DIST list.
	a consuming protocol		Requests to be added to or deleted from the IETF distribution list
	- Change the key derivation from home-grown to use pkcs#5 scheme		should be sent to IETF-REQUEST@IETF.ORG. Requests to be
	- Added compilable ASN.1 module		added to or deleted from the RFC-DIST distribution list should
			be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
	Changes from -01 to -02:		Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
			an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
			help: ways_to_get_rfcs. For example:
	- Changed default KDF from bit to byte reversal to avoid parity-bit		To: rfc-info@RFC-EDITOR.ORG
	problems		Subject: getting rfcs
	- Added allocated OIDs for module and attributes
	- Added more justification text to section 2
	- Added conformance text (new section 5)
	- Added security consideration about subset of recipients
	- Added security consideration describing reason for byte reversal
	- Changed from unidirectional since Diameter may need bi-directional
	- Copied kdf params stuff from rfc2898 since it uses '93 ASN.1
	- Changed so that max decrypts=1, implies that one more message can
	re-use the CEK (used to be silly where a value of 1 meant no more)
	Changes from -02 to -03		help: ways_to_get_rfcs
	- Removed extra comma from ASN.1 module		Requests for special distribution should be addressed to either the
	- Reworded section 4, para 6		author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
			specifically noted otherwise on the RFC itself, all RFCs are for
			unlimited distribution.echo
			Submissions for Requests for Comments should be sent to
			RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
			Authors, for further information.
End of changes. 14 change blocks.
	431 lines changed or deleted		36 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/