Use of StaticStatic Elliptic Curve DiffieHellman Key Agreement in Cryptographic Message Syntax
draftherzogstaticecdh06
The information below is for an old version of the document that is already published as an RFC.
Document  Type 
This is an older version of an InternetDraft that was ultimately published as RFC 6278.



Authors  Jonathan Herzog , Roger Khazan  
Last updated  20151014 (Latest revision 20110314)  
RFC stream  Internet Engineering Task Force (IETF)  
Formats  
Reviews  
Stream  WG state  (None)  
Document shepherd  (None)  
IESG  IESG state  RFC 6278 (Informational)  
Consensus boilerplate  Unknown  
Telechat date  (None)  
Responsible AD  Tim Polk  
IESG note  Jonathan Herzog (jherzog@ll.mit.edu) is the document Shepherd.  
Send notices to  (None) 
draftherzogstaticecdh06
Network Working Group J. Herzog InternetDraft R. Khazan Intended status: Informational MIT Lincoln Laboratory Expires: September 14, 2011 March 13, 2011 Use of staticstatic EllipticCurve DiffieHellman key agreement in Cryptographic Message Syntax draftherzogstaticecdh06 Abstract This document describes how to use 'staticstatic' Elliptic Curve DiffieHellman keyagreement (i.e., Elliptic Curve DiffieHellman where both participants use static DiffieHellman values) with the Cryptographic Message Syntax. In this form of keyagreement, the DiffieHellman values of both sender and receiver are longterm values contained in certificates. Disclaimer This work is sponsored by the United States Air Force under Air Force Contract FA872105C0002. Opinions, interpretations, conclusions and recommendations are those of the authors and are not necessarily endorsed by the United States Government. Status of this Memo This InternetDraft is submitted in full conformance with the provisions of BCP 78 and BCP 79. InternetDrafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as InternetDrafts. The list of current Internet Drafts is at http://datatracker.ietf.org/drafts/current/. InternetDrafts 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 InternetDrafts as reference material or to cite them other than as "work in progress." This InternetDraft will expire on September 14, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Herzog & Khazan Expires September 14, 2011 [Page 1] InternetDraft Staticstatic ECDH in CMS March 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/licenseinfo) 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 5 2. EnvelopedData using staticstatic ECDH . . . . . . . . . . . . 5 2.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 5 2.2. Actions of the sending agent . . . . . . . . . . . . . . . 6 2.3. Actions of the receiving agent . . . . . . . . . . . . . . 7 3. AuthenticatedData using staticstatic ECDH . . . . . . . . . . 8 3.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 8 3.2. Actions of the sending agent . . . . . . . . . . . . . . . 9 3.3. Actions of the receiving agent . . . . . . . . . . . . . . 9 4. AuthEnvelopedData using staticstatic ECDH . . . . . . . . . . 9 4.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 9 4.2. Actions of the sending agent . . . . . . . . . . . . . . . 9 4.3. Actions of the receiving agent . . . . . . . . . . . . . . 9 5. Comparison to [RFC5753] . . . . . . . . . . . . . . . . . . . 9 6. Requirements and Recommendations . . . . . . . . . . . . . . . 11 7. Security considerations . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Herzog & Khazan Expires September 14, 2011 [Page 2] InternetDraft Staticstatic ECDH in CMS March 2011 1. Introduction This document describes how to use the staticstatic EllipticCurve DiffieHellman key agreement scheme (i.e., Elliptic Curve Diffie Hellman [RFC6090] where both participants use static DiffieHellman values) in the Cryptographic Message Syntax (CMS) [RFC5652]. The CMS is a standard notation and representation for cryptographic messages. CMS uses ASN.1 notation [X.680] [X.681] [X.682] [X.683] to define a number of structures that carry both cryptographicallyprotected information and keymanagement information regarding the keys used. Of particular interest here are three structures: o EnvelopedData, which holds encrypted (but not necessarily authenticated) information [RFC5652], o AuthenticatedData, which holds authenticated (MACed) information [RFC5652], and o AuthEnvelopedData, which holds information protected by authenticated encryption: a cryptographic scheme that combines encryption and authentication [RFC5083]. All three of these types share the same basic structure. First, a fresh symmetric key is generated. This symmetric key has a different name that reflects its usage in each of the three structures. EnvelopedData uses a contentencryption key (CEK); AuthenticatedData uses an authentication key; AuthEnvelopedData uses a content authenticatedencryption key. The originator uses the symmetric key to cryptographically protect the content. The symmetric key is then used wrapped for each recipient; only the intended recipient has access to the private keying material necessary to unwrap the symmetric key. Once unwrapped, the recipient uses the symmetric key to decrypt the content, check the authenticity of the content, or both. The CMS supports several different approaches to symmetric key wrapping, including: o key transport: the symmetric key is encrypted using the public encryption key of some recipient, o keyencryption key: the symmetric key is encrypted using a previouslydistributed symmetric key, and o key agreement: the symmetric key is encrypted using a key encryption key (KEK) created using a keyagreement scheme and a keyderivation function (KDF). One such keyagreement scheme is the DiffieHellman algorithm [RFC2631] which uses grouptheory to produce a value known only to Herzog & Khazan Expires September 14, 2011 [Page 3] InternetDraft Staticstatic ECDH in CMS March 2011 its two participants. In this case, the participants are the originator and one of the recipients. Each participant produces a private value and a public value, and each participant can produce the shared secret value from their own private value and their counterpart's public value. There are some variations on the basic algorithm: o The basic algorithm typically uses the group 'Z mod p', meaning the set of integers modulo some prime p. One can also use an ellipticcurve group, which allows for shorter messages. o Over ellipticcurve groups, the standard algorithm can be extended to incorporate the 'cofactor' of the group. This method, called 'cofactor Elliptic Curve DiffieHellman' [SP80056A] can prevent certain attacks possible in the ellipticcurve group. o The participants can generate fresh new public/private values (called ephemeral values) for each run of the algorithm, or they can reuse longterm values (called static values). Ephemeral values add randomness to the resulting private value, while static values can be embedded in certificates. The two participants do not need to use the same kind of value: either participant can use either type. In 'ephemeralstatic' DiffieHellman, for example, the sender uses an ephemeral public/private pair value while the receiver uses a static pair. In 'staticstatic' DiffieHellman, on the other hand, both participants use static pairs. (Receivers cannot use ephemeral values in this setting, and so we ignore ephemeralephemeral and staticephemeral DiffieHellman in this document.) Several of these variations are already described in existing CMS standards. [RFC3370] contains the conventions for using for ephemeralstatic and staticstatic DiffieHellman over the 'basic' (Z mod p) group. [RFC5753] contains the conventions for using ephemeralstatic DiffieHellman over elliptic curves (both standard and cofactor methods). It does not, however, contain conventions for using either method of staticstatic EllipticCurve DiffieHellman, preferring to discuss the ECMQV algorithm instead. In this document, we specify the conventions for using staticstatic EllipticCurve DiffieHellman (ECDH) for both standard and cofactor methods. Our motivation stems from the fact that ECMQV has been removed from the National Security Agency's Suite B of cryptographic algorithms and will therefore be unavailable to some participants. These participants can use ephemeralstatic Elliptic Curve Diffie Hellman, of course, but ephemeralstatic DiffieHellman does not provide source authentication. CMS does allow the application of digital signatures for source authentication, but this alternative is Herzog & Khazan Expires September 14, 2011 [Page 4] InternetDraft Staticstatic ECDH in CMS March 2011 available only to those participants with certified signature keys. By specifying conventions for staticstatic Elliptic Curve Diffie Hellman in this document, we present a third alternative for source authentication, available to those participants with certified Elliptic Curve DiffieHellman keys. We note that like ephemeralstatic ECDH, staticstatic ECDH creates a secret key shared by sender and receiver. Unlike ephemeralstatic ECDH, however, staticstatic ECDH uses a static key pair for the sender. Each of the three CMS structures discussed in this document (EnvelopedData, AuthenticatedData, and AuthEnvelopedData) uses staticstatic ECDH to achieve different goals: o EnvelopedData uses staticstatic ECDH to provide data confidentiality. It will not necessarily, however, provide data authenticity. o AuthenticatedData uses staticstatic ECDH to provide data authenticity. It will not provide dataconfidentiality. o AuthEnvelopedData uses staticstatic ECDH to provide both of confidentiality and dataauthenticity. 1.1. Requirements Terminology 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]. 2. EnvelopedData using staticstatic ECDH If an implementation uses staticstatic ECDH with CMS EnvelopedData then the following techniques and formats MUST be used. The fields of EnvelopedData are as in [RFC5652]; as staticstatic ECDH is a key agreement algorithm, the RecipientInfo kari choice is used. When using staticstatic ECDH, the EnvelopedData originatorInfo field MAY include the certificate(s) for the EC public key(s) used in the formation of the pairwise key. 2.1. Fields of the KeyAgreeRecipientInfo When using staticstatic ECDH with EnvelopedData, the fields of KeyAgreeRecipientInfo [RFC5652] are: o version MUST be 3. Herzog & Khazan Expires September 14, 2011 [Page 5] InternetDraft Staticstatic ECDH in CMS March 2011 o originator identifies the static EC public key of the sender. It MUST be either issuerAndSerialNumber or subjectKeyIdentifier, and point to one of the sending agent's certificates. o ukm MAY be present or absent. However, message originators SHOULD include the ukm and SHOULD ensure that the value of ukm is unique to the message being sent. As specified in [RFC5652], implementations MUST support ukm message recipient processing, so interoperability is not a concern if the ukm is present or absent. The use of a fresh value for ukm will ensure that a different key is generated for each message between the same sender and receiver. ukm, if present, is placed in the entityUInfo field of the ECCCMSSharedInfo structure [RFC5753] and therefore used as an input to the key derivation function. o keyEncryptionAlgorithm MUST contain the object identifier of the key encryption algorithm, which in this case is a key agreement algorithm (see Section 5). The parameters field contains KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm identifier that indicates the symmetric encryption algorithm used to encrypt the contentencryption key (CEK) with the key encryption key (KEK) and any associated parameters (see Section 5). o recipientEncryptedKeys contains an identifier and an encrypted CEK for each recipient. The RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either the issuerAndSerialNumber identifying the recipient's certificate or the RecipientKeyIdentifier containing the subject key identifier from the recipient's certificate. In both cases, the recipient's certificate contains the recipient's static ECDH public key. RecipientEncryptedKey EncryptedKey MUST contain the content encryption key encrypted with the staticstatic ECDHgenerated pairwise keyencryption key using the algorithm specified by the KeyWrapAlgorithm. 2.2. Actions of the sending agent When using staticstatic ECDH with EnvelopedData, the sending agent first obtains the EC public key(s) and domain parameters contained in the recipient's certificate. It MUST confirm the following at least once per recipientcertificate: o That both certificates (the recipient's certificate and its own) contain publickey values with the same curve parameters, and o That both of these publickey values are marked as appropriate for ECDH (that is, marked with algorithmidentifiers idecPublicKey or Herzog & Khazan Expires September 14, 2011 [Page 6] InternetDraft Staticstatic ECDH in CMS March 2011 idecDH [RFC5480]). The sender then determines whether to use standard or cofactor DiffieHellman. After doing so, the sender then determines which hash algorithms to use for the keyderivation function. It then chooses keyEncryptionAlgorithm that reflects these choices. It then determines: o an integer "keydatalen", which is the KeyWrapAlgorithm symmetric keysize in bits, and o the value of ukm, if used. The sender then determines a bit string "SharedInfo", which is the DER encoding of ECCCMSSharedInfo (see Section 7.2 of [RFC5753]). The sending agent then performs either the Elliptic Curve Diffie Hellman operation of [RFC6090] (for standard DiffieHellman) or the Elliptic Curve Cryptography Cofactor DiffieHellman (ECC CDH) Primitive of [SP80056A] (for cofactor DiffieHellman). The sending agent then applies the simple hash function construct of [X963] (using the hash algorithm identified in the key agreement algorithm) to the results of the DiffieHellman operation and the SharedInfo string. (This construct is also described in Section 3.6.1 of [SEC1].) As a result the sending agent obtains a shared secret bit string "K", which is used as the pairwise keyencryption key (KEK) to wrap the CEK for that recipient, as specified in [RFC5652]. 2.3. Actions of the receiving agent When using staticstatic ECDH with EnvelopedData, the receiving agent retrieves keyEncryptionAlgorithm to determine the keyagreement algorithm chosen by the sender, which will identify: o the domainparameters of the curve used, o whether standard or cofactor DiffieHellman was used, and o which hashfunction was used for the KDF. The receiver then retrieves the sender's certificate identified in the rid field, and extracts the EC public key(s) and domain parameters contained therein. It MUST confirm the following at least once per sendercertificate: o That both certificates (the sender's certificate and its own) contain publickey values with the same curve parameters, and Herzog & Khazan Expires September 14, 2011 [Page 7] InternetDraft Staticstatic ECDH in CMS March 2011 o That both of these publickey values are marked as appropriate for ECDH (that is, marked with algorithmidentifiers idecPublicKey or idecDH [RFC5480]). The receiver then determines whether standard or cofactor Diffie Hellman was used. The receiver then determines a bit string "SharedInfo", which is the DER encoding of ECCCMSSharedInfo (see Section 7.2 of [RFC5753]). The receiving agent then performs either the Elliptic Curve Diffie Hellman operation of [RFC6090] (for standard DiffieHellman) or the Elliptic Curve Cryptography Cofactor DiffieHellman (ECC CDH) Primitive of [SP80056A] (for cofactor DiffieHellman). The receiving agent then applies the simple hash function construct of [X963] (using the hash algorithm identified in the key agreement algorithm) to the results of the DiffieHellman operation and the SharedInfo string. (This construct is also described in Section 3.6.1 of [SEC1].) As a result, the receiving agent obtains a shared secret bit string "K", which it uses as the pairwise keyencryption key to unwrap the CEK. 3. AuthenticatedData using staticstatic ECDH This section describes how to use the staticstatic ECDH key agreement algorithm with AuthenticatedData. When using staticstatic ECDH with AuthenticatedData, the fields of AuthenticatedData are as in [RFC5652], but with the following restrictions: o macAlgorithm MUST contain the algorithm identifier of the message authentication code (MAC) algorithm. This algorithm SHOULD be one of the following: idhmacWITHSHA224, idhmacWITHSHA256, id hmacWITHSHA384, or idhmacWITHSHA512, and SHOULD NOT be hmacSHA1. (See Section 5.) o digestAlgorithm MUST contain the algorithm identifier of the hash algorithm. This algorithm SHOULD be one of the following: id sha224, idsha256, idsha384, and idsha512, and SHOULD NOT be id sha1. (See Section 5.) As staticstatic ECDH is a key agreement algorithm, the RecipientInfo kari choice is used in the AuthenticatedData. When using static static ECDH, the AuthenticatedData originatorInfo field MAY include the certificate(s) for the EC public key(s) used in the formation of the pairwise key. 3.1. Fields of the KeyAgreeRecipientInfo The AuthenticatedData KeyAgreeRecipientInfo fields are used in the same manner as the fields for the corresponding EnvelopedData Herzog & Khazan Expires September 14, 2011 [Page 8] InternetDraft Staticstatic ECDH in CMS March 2011 KeyAgreeRecipientInfo fields of Section 2.1 of this document. The authentication key is wrapped in the same manner as is described there for the contentencryption key. 3.2. Actions of the sending agent The sending agent uses the same actions as for EnvelopedData with staticstatic ECDH, as specified in Section 2.2 of this document. 3.3. Actions of the receiving agent The receiving agent uses the same actions as for EnvelopedData with staticstatic ECDH, as specified in Section 2.3 of this document. 4. AuthEnvelopedData using staticstatic ECDH When using staticstatic ECDH with AuthEnvelopedData, the fields of AuthEnvelopedData are as in [RFC5083]. As staticstatic ECDH is a key agreement algorithm, the RecipientInfo kari choice is used. When using staticstatic ECDH, the AuthEnvelopedData originatorInfo field MAY include the certificate(s) for the EC public key used in the formation of the pairwise key. 4.1. Fields of the KeyAgreeRecipientInfo The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the same manner as the fields for the corresponding EnvelopedData KeyAgreeRecipientInfo fields of Section 2.1 of this document. The contentauthenticatedencryption key is wrapped in the same manner as is described there for the contentencryption key. 4.2. Actions of the sending agent The sending agent uses the same actions as for EnvelopedData with staticstatic ECDH, as specified in Section 2.2 of this document. 4.3. Actions of the receiving agent The receiving agent uses the same actions as for EnvelopedData with staticstatic ECDH, as specified in Section 2.3 of this document. 5. Comparison to [RFC5753] This document defines the use of staticstatic ECDH for EnvelopedData, AuthenticatedData, and AuthEnvelopedData. The standard [RFC5753] defines ephemeralstatic ECDH for EnvelopedData Herzog & Khazan Expires September 14, 2011 [Page 9] InternetDraft Staticstatic ECDH in CMS March 2011 only. With regard to EnvelopedData, this document and [RFC5753] greatly parallel each other. Both specify how to apply EllipticCurve DiffieHellman, and differ only on how the sender's public value is to be communicated to the recipient. In [RFC5753], the sender provides the public value explicitly by including an OriginatorPublicKey value in the originator field of KeyAgreeRecipientInfo. In this document, the sender include a reference to a (certified) public value by including either an IssuerAndSerialNumber or SubjectKeyIdentifier value in the same field. Put another way, [RFC5753] provides an interpretation of a KeyAgreeRecipientInfo structure where: o the keyEncryptionAlgorithm value indicates EllipticCurve Diffie Hellman, and o the originator field contains a OriginatorPublicKey value. This document, on the other hand, provides an interpretation of a KeyAgreeRecipientInfo structure where o the keyEncryptionAlgorithm value indicates EllipticCurve Diffie Hellman, and o the originator field contains either a IssuerAndSerialNumber value or a SubjectKeyIdentifier value. AuthenticatedData or AuthEnvelopedData messages, on the other hand, are not given any form of ECDH by [RFC5753]. This is appropriate: that document only defines ephemeralstatic DiffieHellman, and this form of DiffieHellman does not (inherently) provide any form of dataauthentication or dataorigin authentication. This document, on the other hand, requires that the sender use a certified public value. Thus, this form of keyagreement provides implicit key authentication and, under some limited circumstances, dataorigin authentication. (See Section 7.) This document does not define any new ASN.1 structures or algorithm identifiers. It provides new ways to interpret structures from [RFC5652] and [RFC5753], and allows previouslydefined algorithms to be used under these new interpretations. Specifically: o The ECDH keyagreement algorithmidentifiers from [RFC5753] define only how DiffieHellman values are processed, not where these values are created. Therefore, they can be used for staticstatic ECDH with no changes. Herzog & Khazan Expires September 14, 2011 [Page 10] InternetDraft Staticstatic ECDH in CMS March 2011 o The keywrap, MAC, and digest algorithms referenced in [RFC5753] describe how the secret key is to be used, not created. Therefore, they can be used with keys from staticstatic ECDH without modification. 6. Requirements and Recommendations It is RECOMMENDED that implementations of this specification support AuthenticatedData and EnvelopedData. Support for AuthEnvelopedData is OPTIONAL. Implementations that support this specification MUST support standard Elliptic Curve DiffieHellman, and these implementation MAY also support cofactor Elliptic Curve DiffieHellman. In order to encourage interoperability, implementations SHOULD use the elliptic curve domain parameters specified by [RFC5480]. Implementations that support standard staticstatic Elliptic Curve DiffieHellman: MUST support the dhSinglePassstdDHsha256kdfscheme key agreement algorithm; MAY support the dhSinglePassstdDHsha224kdfscheme, dhSinglePass stdDHsha384kdfscheme and dhSinglePassstdDHsha512kdfscheme key agreement algorithms; and SHOULD NOT support the dhSinglePassstdDHsha1kdfscheme Other algorithms MAY also be supported. Implementations that support cofactor staticstatic EllipticCurve DiffieHellman: MUST support the dhSinglePasscofactorDHsha256kdfscheme key agreement algorithm; MAY support the dhSinglePasscofactorDHsha224kdfscheme, dhSinglePasscofactorDHsha384kdfscheme, and dhSinglePass cofactorDHsha512kdfscheme key agreement algorithms; and, SHOULD NOT support the dhSinglePasscofactorDHsha1kdfscheme. In addition, all implementations: Herzog & Khazan Expires September 14, 2011 [Page 11] InternetDraft Staticstatic ECDH in CMS March 2011 MUST support the idaes128wrap key wrap algorithm and the id aes128cbc content encryption algorithm; MAY support: * The the idaes192wrap and idaes256wrap key wrap algorithms; * The idaes128CCM, idaes192CCM, idaes256CCM, idaes128GCM, idaes192GCM, idaes256GCM authenticatedencryption algorithms; and * idaes192cbc, and idaes256cbc content encryption algorithms. SHOULD NOT support the idalgCMS3DESwrap keywrap algorithm or the desede3cbc content encryption algorithms. (All algorithms above defined in [RFC3370], [RFC3565], [RFC5084], and [RFC5753].) Unless otherwise noted above, other algorithms MAY also be supported. 7. Security considerations All security considerations in Section 9 of [RFC5753] apply. Extreme care must be used when using staticstatic DiffieHellman (either standard or cofactor) without the use of some permessage value in ukm. As described in [RFC5753], the ukm value (if present) will be embedded in a ECCCMSSharedInfo structure and the DER encoding of this structure will be used as the 'SharedInfo' input to the keyderivation function of [X963]. The purpose of this input is to add a messageunique value to the keydistribution function so that two different sessions of staticstatic ECDH between a given pair of agents result in independent keys. If the ukm value is not used or is reused, on the other hand, then the ECCCMSSharedInfo structure (and 'SharedInfo' input) will likely not vary from message to message. In this case, the two agents will reuse the same keying material across multiple messages. This is considered to be bad cryptographic practice and may open the sender to attacks on Diffie Hellman (e.g., the 'small subgroup' attack [MenezesUstaoglu] or other, yetundiscovered attacks). It is for these reasons that Section 2.1 states that messagesenders SHOULD include the ukm and SHOULD ensure that the value of ukm is unique to the message being sent. One way to ensure the uniqueness of ukm is for the message sender to choose a 'sufficiently long' random string for each message (where, as a rule of thumb, a 'sufficiently long' string is one at least as long as the keys used Herzog & Khazan Expires September 14, 2011 [Page 12] InternetDraft Staticstatic ECDH in CMS March 2011 by the keywrap algorithm identified in the keyEncryptionAlgorithm field of the KeyAgreeRecipientInfo structure). However, other methods (such as a counter) are possible. Also, applications which cannot tolerate the inclusion of permessage information in ukm (due to bandwidth requirements, for example) SHOULD NOT use staticstatic ECDH for a recipient without ascertaining that the recipient knows the private value associated with their certified DiffieHellman value. Staticstatic DiffieHellman, when used as described in this document, does not necessarily provide dataorigin authentication. Consider, for example, the following sequence of events: o Alice sends an AuthEnvelopedData message to both Bob and Mallory. Furthermore, Alice uses a staticstatic DH method to transport the contentauthenticatedencryption key to Bob, and some arbitrary method to transport the same key to Mallory. o Mallory intercepts the message and prevents Bob from receiving it. o Mallory recovers the contentauthenticatedencryption key from the message received from Alice. Mallory then creates new plaintext of her choice, and encrypts it using the same authenticated encryption algorithm and the same contentauthenticatedencryption key used by Alice. o Mallory then replaces the EncryptedContentInfo and MessageAuthenticationCode fields of Alice's message with the values Mallory just generated. She may additionally remove her RecipientInfo value from Alice's message. o Mallory sends the modified message to Bob. o Bob receives the message, validates the staticstatic DH works and decrypts/authenticates the message. At this point, Bob has received and validated a message that appears to have been sent by Alice, but whose content was chosen by Mallory. Mallory may not even be an apparent receiver of the modified message. Thus, this use of staticstatic DiffieHellman does not necessarily provide dataorigin authentication. (We note that this example does not also contradict either confidentiality or dataauthentication: Alice's message was not received by anyone not intended by Alice, and Mallory's message was not modified before reaching Bob.) More generally, dataorigin may not be authenticated unless Herzog & Khazan Expires September 14, 2011 [Page 13] InternetDraft Staticstatic ECDH in CMS March 2011 o It is a priori guaranteed that the message in question was sent to exactly one recipient, or o Dataorigin authentication is provided by some other mechanism (such as digital signatures). However, we also note that this lack of authentication is not a product of staticstatic ECDH, per se, but is inherent in the way keyagreement schemes are used in the AuthenticatedData and AuthEnvelopedData structures of CMS. 8. IANA Considerations There are no IANA considerations. 9. Acknowledgements The authors would like to thank Jim Schaad, Russ Housley, Sean Turner, Brian Weis, Rene Struik, Brian Carpenter, David McGrew and Stephen Farrell for their helpful comments and suggestions. We would also like to thank Jim Schaad for describing to us the attack described in Section 7. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002. [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003. [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) AuthenticatedEnvelopedData Content Type", RFC 5083, November 2007. [RFC5084] Housley, R., "Using AESCCM and AESGCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, November 2007. Herzog & Khazan Expires September 14, 2011 [Page 14] InternetDraft Staticstatic ECDH in CMS March 2011 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009. [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 5652, September 2009. [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, January 2010. [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011. [SP80056A] Barker, E., Johnson, D., and M. Smid, "Recommendation for PairWise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST Special Publication (SP) 80056A, March 2007. [X963] "Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography", ANSI X9.63, 2001. 10.2. Informative References [MenezesUstaoglu] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys in DiffieHellman Key Agreement Protocols". International Journal of Applied Cryptography, Vol. 2, No. 2, pp. 154158, 2010. [RFC2631] Rescorla, E., "DiffieHellman Key Agreement Method", RFC 2631, June 1999. [SEC1] Standards for Efficient Cryptography Group (SECG), "SEC 1: Elliptic Curve Cryptography", Version 2.0, May 2009. [X.680] ITUT, "Information Technology  Abstract Syntax Notation One", Recommendation X.680, ISO/IEC 88241:2002, 2002. [X.681] ITUT, "Information Technology  Abstract Syntax Notation One: Information Object Specification", Recommendation X.681, ISO/IEC 88242:2002, 2002. [X.682] ITUT, "Information Technology  Abstract Syntax Notation One: Constraint Specification", Recommendation X.682, ISO/ Herzog & Khazan Expires September 14, 2011 [Page 15] InternetDraft Staticstatic ECDH in CMS March 2011 IEC 88243:2002, 2002. [X.683] ITUT, "Information Technology  Abstract Syntax Notation One: Parameterization of ASN.1 Specifications", Recommendation X.683, ISO/IEC 88244:2002, 2002. Authors' Addresses Jonathan C. Herzog MIT Lincoln Laboratory 244 Wood St. Lexington, MA 02144 USA Email: jherzog@ll.mit.edu Roger Khazan MIT Lincoln Laboratory 244 Wood St. Lexington, MA 02144 USA Email: rkh@ll.mit.edu Herzog & Khazan Expires September 14, 2011 [Page 16]