[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 rfc3185                                        
INTERNET-DRAFT                                              S. Farrell
Expires in six months                           Baltimore Technologies
                                                             S. Turner
                                                                  IECA
                                                         February 2001

                   Reuse of CMS Content Encryption Keys
                      <draft-ietf-smime-rcek-01.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. Security Considerations......................................5
   6. References...................................................5
   Author's Addresses..............................................5
   Full Copyright Statement........................................6
   Appendix A: ASN.1 Module........................................6
   Appendix B: Revision History....................................7




Farrell & Turner                                              [Page 1]


INTERNET-DRAFT                                           February 2001


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 message 1) to derive the key encryption key
   (KEK) for a later message, (message 2), 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 system 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".

   - Key encryption is "unidirectional": that is, the referenced CEK is
     only used by the originator for encryption and the recipient for
     decryption, recipients must not expect originators to be able to
     decrypt using (anything derived from) the referenced CEK. This
     means that the referenced CEK MUST NOT be considered to be a
     shared secret between many parties (i.e. this specification is not
     sufficient for group keying schemes). This also means that
     originators may have discarded the referenced CEK by the time the
     recipient receives the first message containing the reference.


Farrell & Turner                                              [Page 2]


INTERNET-DRAFT                                           February 2001


     Recipients MUST NOT use the referenced CEK when replying to the
     originator.

   - 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.

   In particular, this specification is not intended to be a general
   specification for group key management.


3. How to do it

   In order to reference the content-encryption key (CEK) used in an
   EnvelopedData (call this MSG1) 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 (say MSG2) 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-cek-reference with a single
   value using the CEKReference syntax.

   MSG2.KEK is to be derived by reversing the bits of MSG1.CEK. The bit
   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 in 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-rcek-attrs ::= OBJECT IDENTIFIER { TBD }
   id-cek-reference ::= OBJECT IDENTIFIER { id-rcek-attrs 1}
   CEKReference ::= OCTET STRING


Farrell & Turner                                              [Page 3]


INTERNET-DRAFT                                           February 2001



   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 indicates to the
   recipient the maximum number of messages (including this one) 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.

   id-cek-maxDecrypts ::= OBJECT IDENTIFIER { id-rcek-attrs 2}
   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 bit-reversal 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.

   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-kek-derivation-algorithm ::= OBJECT IDENTIFIER { id-rcek-attrs 3}
   KEKDerivationAlgorithm ::= SEQUENCE {
         kekAlg          AlgorithmIdentifier,
         pbkdf2Param     PBKDF2-params
   }

   keyAlg 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 MSG.KEK is only used by the
   originator.

   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.


Farrell & Turner                                              [Page 4]


INTERNET-DRAFT                                           February 2001


  -   The prf field MUST use the DEFAULT algorithm specified in
       [RFC2898] which is algid-hmacWithSHA1.



5. 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.


6. References

  [CMS]       Housley, R., "Cryptographic Message Syntax", RFC 2630.
  [RFC2898]   Kaliski, B., "PKCS #5: Password-Based Cryptography
              Specification Version 2.0", RFC 2898,   February 2001.
  [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.

Farrell & Turner                                              [Page 5]


INTERNET-DRAFT                                           February 2001


   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(TBD) }

      DEFINITIONS EXPLICIT --<<IMPLICIT??>>-- TAGS ::=

      BEGIN

      -- EXPORTS ALL --

      IMPORTS

        PBKDF2-Params FROM
           PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)

Farrell & Turner                                              [Page 6]


INTERNET-DRAFT                                           February 2001


                  pkcs-5(5) } ;

        id-rcek-attrs ::= OBJECT IDENTIFIER { TBD }

        id-cek-reference ::= OBJECT IDENTIFIER { id-rcek-attrs 1}
        CEKReference ::= OCTET STRING

        id-cek-maxDecrypts ::= OBJECT IDENTIFIER { id-rcek-attrs 2}
        CEKMaxDecrypts ::= INTEGER

        id-kek-derivation-algorithm ::= OBJECT IDENTIFIER
                                          { id-rcek-attrs 3}
        KEKDerivationAlgorithm ::= SEQUENCE {
             kekAlg          AlgorithmIdentifier,
             pbkdf2Param     PBKDF2-params }


      END


Appendix B: Revision History

   Changes from -00 to -01:

   - Removed error flag attribute, since this is the responsibility of
     a consuming protocol
   - Change the key derivation from home-grown to use pkcs#5 scheme
   - Added compilable ASN.1 module


























Farrell & Turner                                              [Page 7]