As per Relevance of the word reference, we have this rfc below:
Network Working Group S.
Request for Comments: 3185 Baltimore
Category: Standards Track S.
October 2001
Reuse of CMS Content Encryption
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document describes a way to include a key identifier in a
(Cryptographic Message Syntax) enveloped data structure, so that
content encryption key can be re-used for further enveloped
packets
Table Of
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
Authors' Addresses................................................ 6
Appendix A: ASN.1 Module.......................................... 7
Full Copyright Statement.......................................... 10
Farrell & Turner Standards Track [Page 1]
RFC 3185 Reuse of CMS Content Encryption Keys October 2001
1.
CMS [CMS] specifies EnvelopedData. EnvelopedData supports
encryption using either symmetric or asymmetric key
techniques. Since asymmetric key establishment is
expensive, it is desirable in some environments to re-use a
content-encryption key established using asymmetric mechanisms
encryption operations in subsequent messages
The basic idea here is to reuse the content-encryption key (CEK)
a message (say MSG1) to derive the key-encryption key (KEK) for
later message, (MSG2), by including a reference value for the CEK
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.
This specification is intended to be used to provide more
selective field confidentiality between communicating peers,
particular in the cases where
- The originator is a client that wishes to send a number of
to a server (the recipient) in a single transaction, where
referenced CEK is used for the separate encryption of each field
- The originator and recipient are servers that communicate
frequently and use this specification purely for efficiency
This specification is not intended to be applicable in all cases.
is suited for use where
- Its use is further scoped: that is, this specification doesn'
define a protocol but merely a trick that can be used in a
context and additional specification will be needed for each
case. In particular, in order to use this specification, it
REQUIRED to define the originators' and recipients' behavior
a referenced CEK has been "lost".
- This specification is not suitable for general group
management
Farrell & Turner Standards Track [Page 2]
RFC 3185 Reuse of CMS Content Encryption Keys October 2001
- The underlying cryptographic API is suitable: it is very
that any cryptographic API that completely "hides" the bits
cryptographic keys from the CMS layer will prevent reuse of
referenced CEK (since they won't have a primitive that
MSG1.CEK to be transformed to MSG2.KEK).
- The algorithms for content and key encryption have compatible
values and strengths, that is, if MSG1.
is a 40bit cipher and MSG2.keyEncryptionAlgorithm requires 168
bits of keying material, then this specification SHOULD NOT
used
There are other ways that could be envisaged to establish
required symmetric keying material, e.g., by leveraging a
keying scheme or by defining a content type that contains a
value. Although this scheme is much simpler than generic group
management, if an implementation already supports group
management then this scheme doesn't add value. This scheme is
suitable for inclusion in CMS libraries (though the addition of
state might be a problem for some implementations), which can
some advantages over application layer schemes (e.g., where
content includes MSG2.KEK).
3. How to do
In order to reference the content-encryption key (CEK) used in
EnvelopedData, a key identifier can be included in
unprotectedAttrs field of MSG1. This key can then be used to
the key-encryption key (KEK) for other instances of EnvelopedData
for other purposes. If the CEK from MSG1 is to be used to derive
KEK for MSG2 then MSG1 MUST contain an unprotectedAttrs Attribute
type id-aa-CEKReference with a single value using the
syntax
MSG2.KEK is to be derived by reversing the bytes of MSG1.CEK.
byte reversal is to avoid an attack where the attacker has a
plaintext and the related ciphertext (encrypted with MSG1.CEK)
(otherwise) could be directly used as a MSG2.KEK
The application MUST ensure that the relevant algorithms
compatible. That is, a CEKReference attribute alone can only be
where the content-encryption algorithm from MSG1 employs the
type of symmetric key as the key-encryption algorithm from MSG2.
Farrell & Turner Standards Track [Page 3]
RFC 3185 Reuse of CMS Content Encryption Keys October 2001
Notes
1) There is nothing to prevent inclusion of a CEKReference
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
RecipientInfo: ktri, kari or kekri. Implementors MUST NOT
that CEKReference can only occur where ktri or kari is used
id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
CEKReference ::= OCTET
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
has an INTEGER syntax (the value MUST be >=1 and maximally 2^31),
indicates to the recipient the maximum number of messages (
MSG1) that will use the referenced CEK. This Attribute MUST only
sent when a CEKReference attribute is also included
The recipient SHOULD maintain the CEKReference information (
the key identifier and the CEK value) while less than
messages have been successfully received. Recipients SHOULD
the CEKReference information after some locally configured period
When this attribute is not present, originators and recipients
behave as if a value of one had been sent
id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
CEKMaxDecrypts ::=
If CEKMaxDecrypts is missing, or has the value one, then each
will be re-used once as the KEK for the next message. This
that MSG[n].KEK is the byte-reversal of MSG[n-1].CEK;
MSG[n+1].KEK will be the byte-reversal of MSG[n].CEK. Note
MSG[n-1].CEK has no impact whatsoever to MSG[n+1], so long as
are generated randomly (and not e.g., derived from KEKs somehow).
4. Using different CEK and KEK
Where MSG1.content-encryption algorithm and MSG2.key-
algorithm are the same then the MSG2.KEK is the byte-reverse
MSG1.CEK. However, in general, these algorithms MAY differ, e.g.,
requiring different key lengths. This section specifies a
way to derive MSG2.KEK for such cases
Farrell & Turner Standards Track [Page 4]
RFC 3185 Reuse of CMS Content Encryption Keys October 2001
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
purposes of this specification, all we care about is that
algorithms use the same format and size of keying material (see
security considerations) and that they do not differ significantly
terms of the resulting cryptographic "strength." In that sense
two algorithms in the example above are the "same."
Implementations MAY include this functionality
The basic approach is to use the PBKDF2 key derivation
defined in PKCS#5 [RFC2898], but using MSG1.CEK as input instead of
password. The output of the PBKDF2 function is MSG2.KEK. To
end, a new attribute type is defined which allows passing of
required parameters
id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 }
KEKDerivationAlgorithm ::= SEQUENCE {
kekAlg AlgorithmIdentifier
pbkdf2Param PBKDF2-
}
kekAlg is the algorithm identifier (and associated parameters,
any), for the MSG2 key encryption algorithm. Note that it is
necessary to protect this field since modification of keyAlg
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
present
- The prf field MUST use the default algorithm specified
[RFC2898] which is algid-hmacWithSHA1 (and so the prf field
be omitted).
5.
This specification only applies to messages where the
attribute is present. All attributes specified here SHOULD
ignored unless they are present in a message containing a valid,
or recognized, existing value of CEKReference. The
attribute is to be treated by the recipient as a hint, but MUST
honored by the originator
Farrell & Turner Standards Track [Page 5]
RFC 3185 Reuse of CMS Content Encryption Keys October 2001
The optional to implement KEKDerivationAlgorithm attribute MUST
be present when MSG1.content-encryption algorithm differs
MSG2.key-encryption algorithm, in which case it MUST be present
Implementations that recognize this attribute, but do not support
functionality SHOULD ignore the attribute
Ignoring attributes as discussed above, will lead to
failures. CMS implementations SHOULD be able to signal
particular reason for this failure to the calling application
6. Security
Encryption does not provide authentication, for example, if
encryptedContent is essentially random then recipients MUST
assume that "knowing" a CEKReference value proves anything -
could have created the EnvelopedData. This is relevant both
security (the recovered plaintext should not be entirely random)
for avoiding denial of service (the recipient MUST NOT assume
using the right CEKReference means that message originator
genuine).
Similarly, using the correct CEKReference does not mean that
message has not been replayed or inserted, and recipients MUST
assume that replay has been avoided
The maxDecrypts field presents a potential denial-of-service
if a very large value is included by an originator in an attempt
get a recipient to consume memory by storing the referenced CEKs
a long period or if the originator never sends the indicated
of ciphertexts. Recipients SHOULD therefore drop referenced
where the maxDecrypts value is too large (according to
configuration) or the referenced CEK has been held for too long
period
Suppose MSG1 is sent to a set S1 of users. In the case where MSG2
sent to only a subset of users in S1, all users from S1 will still
able to decrypt MSG2 (since MSG2.KEK is computed only from MSG1.CEK).
Implementers should be aware that in such cases, all members of
original set of recipients (S1) can access the plaintext of MSG2
subsequent messages
The reason for the byte reversal is as follows: without the
reversal, an attacker knowing some of MSG1.plaintext (a prefix in
field for instance) can use the corresponding ciphertext block as
next encrypted CEK, i.e., as MSG2.KEKRecipientInfo.encryptedKey.
the attacker knows the next CEK. This attacks something this note
not claiming to protect (origin authentication), but is
avoided using the byte reversal. Byte-reversal was chosen over bit
Farrell & Turner Standards Track [Page 6]
RFC 3185 Reuse of CMS Content Encryption Keys October 2001
reversal since bit-reversal would cause parity bits from MSG1.CEK
be used as keying bits for MSG2.KEK for DES-based algorithms.
that byte reversal would similarly affect parity if parity
spanned more than one octet, however no well-known algorithms
in this way
Implementations should be very careful with this scheme if MSG[n].
is used to derive MSG[n].CEK, e.g., if MSG[n].CEK were the byte
reversal of MSG[n].KEK, then this scheme could result in a fixed
being unexpectedly used
7.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
1999.
[CMS-MSG] Ramsdell, B. "S/MIME Version 3 Message Specification",
2633, June 1999.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based
Specification Version 2.0", RFC 2898, September 2000.
[RFC2026] Bradner, S., "The Internet Standards Process --
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors'
Stephen Farrell
Baltimore Technologies
39 Parkgate Street
Dublin 8
Phone: +353-1-881-6000
EMail: stephen.farrell@baltimore.
Sean
IECA, Inc
9010 Edgepark
Vienna, VA 22182
Phone: +1.703.628.3180
EMail: turners@ieca.
Farrell & Turner Standards Track [Page 7]
RFC 3185 Reuse of CMS Content Encryption Keys October 2001
Appendix A: ASN.1
{ 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
-- used for re-using the content encryption key from
-- message in further messages
DEFINITIONS IMPLICIT TAGS ::=
-- EXPORTS ALL --
AlgorithmIdentifier
AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 } ;
-- [RFC2898] uses 1993 ASN.1 to define PBKDF2-params.
-- this specification only uses 1988 ASN.1, the definition
-- repeated here for completeness
-- The DEFAULT prf field value, MUST be used for
--
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,
-- results in the same encoding as produced by the
-- below. See [RFC2898] for that definition
PBKDF2-params ::= SEQUENCE {
salt CHOICE {
specified OCTET STRING, -- MUST BE
otherSource AlgorithmIdentifier -- DO NOT USE THIS
},
iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX)
}
-- id-aa is the arc with all new authenticated
-- unauthenticated attributes produced the by S/
-- Working Group. It is also defined in [CMS-MSG
Farrell & Turner Standards Track [Page 8]
RFC 3185 Reuse of CMS Content Encryption Keys October 2001
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
-- for subsequent
id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 }
CEKReference ::= OCTET
-- This attribute contains a "hint" to the
-- indicating how many times the originator will
-- the re-used
id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
CEKMaxDecrypts ::=
-- This attribute specifies the key derivation
-- to be used when the default byte reversal operation
-- be used
id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 }
KEKDerivationAlgorithm ::= SEQUENCE {
kekAlg AlgorithmIdentifier
pbkdf2Param PBKDF2-params }
Farrell & Turner Standards Track [Page 9]
RFC 3185 Reuse of CMS Content Encryption Keys October 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Farrell & Turner Standards Track [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
