From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6278.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc6278.txt (limited to 'doc/rfc/rfc6278.txt') diff --git a/doc/rfc/rfc6278.txt b/doc/rfc/rfc6278.txt new file mode 100644 index 0000000..913c501 --- /dev/null +++ b/doc/rfc/rfc6278.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Herzog +Request for Comments: 6278 R. Khazan +Category: Informational MIT Lincoln Laboratory +ISSN: 2070-1721 June 2011 + + + Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in + Cryptographic Message Syntax + +Abstract + + This document describes how to use the 'static-static Elliptic Curve + Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie- + Hellman where both participants use static Diffie-Hellman values) + with the Cryptographic Message Syntax. In this form of key + agreement, the Diffie-Hellman values of both the sender and receiver + are long-term values contained in certificates. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6278. + + + + + + + + + + + + + + + + + + +Herzog & Khazan Informational [Page 1] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + +Copyright Notice + + Copyright (c) 2011 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. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Requirements Terminology ...................................5 + 2. EnvelopedData Using Static-Static 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 Static-Static ECDH ......................8 + 3.1. Fields of the KeyAgreeRecipientInfo ........................8 + 3.2. Actions of the Sending Agent ...............................8 + 3.3. Actions of the Receiving Agent .............................9 + 4. AuthEnvelopedData Using Static-Static 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 RFC 5753 ..........................................9 + 6. Requirements and Recommendations ...............................10 + 7. Security Considerations ........................................12 + 8. Acknowledgements ...............................................14 + 9. References .....................................................14 + 9.1. Normative References ......................................14 + 9.2. Informative References ....................................15 + +1. Introduction + + This document describes how to use the static-static Elliptic Curve + Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie- + Hellman [RFC6090] where both participants use static Diffie-Hellman + values) in the Cryptographic Message Syntax (CMS) [RFC5652]. The CMS + is a standard notation and representation for cryptographic messages. + The CMS uses ASN.1 notation [X.680] [X.681] [X.682] [X.683] to define + + + +Herzog & Khazan Informational [Page 2] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + + a number of structures that carry both cryptographically protected + information and key-management 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 content-encryption key (CEK); AuthenticatedData + uses an authentication key; AuthEnvelopedData uses a content- + authenticated-encryption key. The originator uses the symmetric key + to cryptographically protect the content. The symmetric key is then + 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 key-encryption key: the symmetric key is encrypted using a + previously distributed symmetric key, and + + o key agreement: the symmetric key is encrypted using a key- + encryption key (KEK) created using a key-agreement scheme and a + key-derivation function (KDF). + + One such key-agreement scheme is the Diffie-Hellman algorithm + [RFC2631], which uses group theory to produce a value known only to + 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: + + + + + +Herzog & Khazan Informational [Page 3] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + + 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 + elliptic curve group, which allows for shorter messages. + + o Over elliptic curve groups, the standard algorithm can be extended + to incorporate the 'cofactor' of the group. This method, called + 'cofactor Elliptic Curve Diffie-Hellman' [SP800-56A] can prevent + certain attacks possible in the elliptic curve group. + + o The participants can generate fresh new public/private values + (called ephemeral values) for each run of the algorithm, or they + can re-use long-term 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 'ephemeral-static' Diffie-Hellman, for example, + the sender uses an ephemeral public/private pair value while the + receiver uses a static pair. In 'static-static' Diffie-Hellman, + on the other hand, both participants use static pairs. (Receivers + cannot use ephemeral values in this setting, and so we ignore + ephemeral-ephemeral and static-ephemeral Diffie-Hellman in this + document.) + + Several of these variations are already described in existing CMS + standards; for example, [RFC3370] contains the conventions for using + ephemeral-static and static-static Diffie-Hellman over the 'basic' (Z + mod p) group. [RFC5753] contains the conventions for using + ephemeral-static Diffie-Hellman over elliptic curves (both standard + and cofactor methods). It does not, however, contain conventions for + using either method of static-static Elliptic Curve Diffie-Hellman, + preferring to discuss the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) + algorithm instead. + + In this document, we specify the conventions for using static-static + Elliptic Curve Diffie-Hellman (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 ephemeral-static Elliptic Curve Diffie- + Hellman, of course, but ephemeral-static Diffie-Hellman does not + provide source authentication. The CMS does allow the application of + digital signatures for source authentication, but this alternative is + available only to those participants with certified signature keys. + By specifying conventions for static-static Elliptic Curve Diffie- + Hellman in this document, we present a third alternative for source + authentication, available to those participants with certified + Elliptic Curve Diffie-Hellman keys. + + + + +Herzog & Khazan Informational [Page 4] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + + We note that like ephemeral-static ECDH, static-static ECDH creates a + secret key shared by the sender and receiver. Unlike ephemeral- + static ECDH, however, static-static ECDH uses a static key pair for + the sender. Each of the three CMS structures discussed in this + document (EnvelopedData, AuthenticatedData, and AuthEnvelopedData) + uses static-static ECDH to achieve different goals: + + o EnvelopedData uses static-static ECDH to provide data + confidentiality. It will not necessarily, however, provide data + authenticity. + + o AuthenticatedData uses static-static ECDH to provide data + authenticity. It will not provide data confidentiality. + + o AuthEnvelopedData uses static-static ECDH to provide both + confidentiality and data authenticity. + +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 Static-Static ECDH + + If an implementation uses static-static ECDH with the CMS + EnvelopedData, then the following techniques and formats MUST be + used. The fields of EnvelopedData are as in [RFC5652]; as static- + static ECDH is a key-agreement algorithm, the RecipientInfo 'kari' + choice is used. When using static-static 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 static-static ECDH with EnvelopedData, the fields of + KeyAgreeRecipientInfo [RFC5652] are as follows: + + o version MUST be 3. + + o originator identifies the static EC public key of the sender. It + MUST be either issuerAndSerialNumber or subjectKeyIdentifier, and + it MUST 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 + + + +Herzog & Khazan Informational [Page 5] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + + 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. The ukm, if present, is placed in the entityUInfo field + of the ECC-CMS-SharedInfo 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 content-encryption 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 static-static ECDH-generated + pairwise key-encryption key using the algorithm specified by the + KeyWrapAlgorithm. + +2.2. Actions of the Sending Agent + + When using static-static 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 recipient-certificate: + + o that both certificates (the recipient's certificate and its own) + contain public-key values with the same curve parameters, and + + o that both of these public-key values are marked as appropriate for + ECDH (that is, marked with algorithm identifiers id-ecPublicKey or + id-ecDH [RFC5480]). + + The sender then determines whether to use standard or cofactor + Diffie-Hellman. After doing so, the sender then determines which + hash algorithms to use for the key-derivation function. It then + chooses the keyEncryptionAlgorithm value that reflects these choices. + It then determines: + + + + +Herzog & Khazan Informational [Page 6] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + + o an integer "keydatalen", which is the KeyWrapAlgorithm symmetric + key size in bits, and + + o the value of ukm, if used. + + The sender then determines a bit string "SharedInfo", which is the + DER encoding of ECC-CMS-SharedInfo (see Section 7.2 of [RFC5753]). + The sending agent then performs either the Elliptic Curve Diffie- + Hellman operation of [RFC6090] (for standard Diffie-Hellman) or the + Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) + Primitive of [SP800-56A] (for cofactor Diffie-Hellman). 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 Diffie-Hellman 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 key-encryption key (KEK) to + wrap the CEK for that recipient, as specified in [RFC5652]. + +2.3. Actions of the Receiving Agent + + When using static-static ECDH with EnvelopedData, the receiving agent + retrieves keyEncryptionAlgorithm to determine the key-agreement + algorithm chosen by the sender, which will identify: + + o the domain parameters of the curve used, + + o whether standard or cofactor Diffie-Hellman was used, and + + o which hash function 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 + sender certificate: + + o that both certificates (the sender's certificate and its own) + contain public-key values with the same curve parameters, and + + o that both of these public-key values are marked as appropriate for + ECDH (that is, marked with algorithm identifiers id-ecPublicKey or + id-ecDH [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 ECC-CMS-SharedInfo (see + Section 7.2 of [RFC5753]). The receiving agent then performs either + the Elliptic Curve Diffie-Hellman operation of [RFC6090] (for + + + +Herzog & Khazan Informational [Page 7] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + + standard Diffie-Hellman) or the Elliptic Curve Cryptography Cofactor + Diffie-Hellman (ECC CDH) Primitive of [SP800-56A] (for cofactor + Diffie-Hellman). 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 Diffie-Hellman + 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 key-encryption key to unwrap the CEK. + +3. AuthenticatedData Using Static-Static ECDH + + This section describes how to use the static-static ECDH key- + agreement algorithm with AuthenticatedData. When using static-static + 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 -- id-hmacWITHSHA224, id-hmacWITHSHA256, + id-hmacWITHSHA384, or id-hmacWITHSHA512 -- and SHOULD NOT be + hmac-SHA1. (See Section 5.) + + o digestAlgorithm MUST contain the algorithm identifier of the hash + algorithm. This algorithm SHOULD be one of the following -- + id-sha224, id-sha256, id-sha384, or id-sha512 -- and SHOULD NOT be + id-sha1. (See Section 5.) + + As static-static 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 + KeyAgreeRecipientInfo fields of Section 2.1 of this document. The + authentication key is wrapped in the same manner as is described + there for the content-encryption key. + +3.2. Actions of the Sending Agent + + The sending agent uses the same actions as for EnvelopedData with + static-static ECDH, as specified in Section 2.2 of this document. + + + + + +Herzog & Khazan Informational [Page 8] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + +3.3. Actions of the Receiving Agent + + The receiving agent uses the same actions as for EnvelopedData with + static-static ECDH, as specified in Section 2.3 of this document. + +4. AuthEnvelopedData Using Static-Static ECDH + + When using static-static ECDH with AuthEnvelopedData, the fields of + AuthEnvelopedData are as in [RFC5083]. As static-static ECDH is a + key-agreement algorithm, the RecipientInfo kari choice is used. When + using static-static 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 + content-authenticated-encryption key is wrapped in the same manner as + is described there for the content-encryption key. + +4.2. Actions of the Sending Agent + + The sending agent uses the same actions as for EnvelopedData with + static-static 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 + static-static ECDH, as specified in Section 2.3 of this document. + +5. Comparison to RFC 5753 + + This document defines the use of static-static ECDH for + EnvelopedData, AuthenticatedData, and AuthEnvelopedData. [RFC5753] + defines ephemeral-static ECDH for EnvelopedData only. + + With regard to EnvelopedData, this document and [RFC5753] greatly + parallel each other. Both specify how to apply Elliptic Curve + Diffie-Hellman 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 includes 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: + + + +Herzog & Khazan Informational [Page 9] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + + o the keyEncryptionAlgorithm value indicates Elliptic Curve Diffie- + Hellman, and + + o the originator field contains an OriginatorPublicKey value. + + This document, on the other hand, provides an interpretation of a + KeyAgreeRecipientInfo structure where: + + o the keyEncryptionAlgorithm value indicates Elliptic Curve Diffie- + Hellman, and + + o the originator field contains either an 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 ephemeral-static Diffie-Hellman, and this + form of Diffie-Hellman does not (inherently) provide any form of data + authentication or data-origin authentication. This document, on the + other hand, requires that the sender use a certified public value. + Thus, this form of key agreement provides implicit key authentication + and, under some limited circumstances, data-origin 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 it allows previously defined algorithms + to be used under these new interpretations. Specifically: + + o The ECDH key-agreement algorithm identifiers from [RFC5753] define + only how Diffie-Hellman values are processed, and not where these + values are created. Therefore, they can be used for static-static + ECDH with no changes. + + o The key-wrap, MAC, and digest algorithms referenced in [RFC5753] + describe how the secret key is to be used but not created. + Therefore, they can be used with keys from static-static 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 Diffie-Hellman, and these implementations MAY also + support cofactor Elliptic Curve Diffie-Hellman. + + + +Herzog & Khazan Informational [Page 10] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + + In order to encourage interoperability, implementations SHOULD use + the elliptic curve domain parameters specified by [RFC5480]. + + Implementations that support standard static-static Elliptic Curve + Diffie-Hellman: + + o MUST support the dhSinglePass-stdDH-sha256kdf-scheme key- + agreement algorithm; + + o MAY support the dhSinglePass-stdDH-sha224kdf-scheme, + dhSinglePass-stdDH-sha384kdf-scheme, and + dhSinglePass-stdDH-sha512kdf-scheme key-agreement algorithms; and + + o SHOULD NOT support the dhSinglePass-stdDH-sha1kdf-scheme + algorithm. + + Other algorithms MAY also be supported. + + Implementations that support cofactor static-static Elliptic Curve + Diffie-Hellman: + + o MUST support the dhSinglePass-cofactorDH-sha256kdf-scheme key- + agreement algorithm; + + o MAY support the dhSinglePass-cofactorDH-sha224kdf-scheme, + dhSinglePass-cofactorDH-sha384kdf-scheme, and + dhSinglePass-cofactorDH-sha512kdf-scheme key-agreement algorithms; + and + + o SHOULD NOT support the dhSinglePass-cofactorDH-sha1kdf-scheme + algorithm. + + In addition, all implementations: + + o MUST support the id-aes128-wrap key-wrap algorithm and the + id-aes128-cbc content-encryption algorithm; + + o MAY support: + + * the id-aes192-wrap and id-aes256-wrap key-wrap algorithms; + + * the id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, id-aes128-GCM, + id-aes192-GCM, and id-aes256-GCM authenticated-encryption + algorithms; and + + * the id-aes192-cbc and id-aes256-cbc content-encryption + algorithms. + + + + +Herzog & Khazan Informational [Page 11] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + + o SHOULD NOT support the id-alg-CMS3DESwrap key-wrap algorithm or + the des-ede3-cbc content-encryption algorithms. + + (All algorithms above are 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 static-static Diffie-Hellman + (either standard or cofactor) without the use of some per-message + value in the ukm. As described in [RFC5753], the ukm value (if + present) will be embedded in an ECC-CMS-SharedInfo structure, and the + DER encoding of this structure will be used as the 'SharedInfo' input + to the key-derivation function of [X963]. The purpose of this input + is to add a message-unique value to the key-distribution function so + that two different sessions of static-static ECDH between a given + pair of agents result in independent keys. If the ukm value is not + used or is re-used, on the other hand, then the ECC-CMS-SharedInfo + structure (and 'SharedInfo' input) will likely not vary from message + to message. In this case, the two agents will re-use 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, yet-undiscovered attacks). + + It is for these reasons that Section 2.1 states that message senders + 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 the 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 + by the key-wrap algorithm identified in the keyEncryptionAlgorithm + field of the KeyAgreeRecipientInfo structure). However, other + methods (such as a counter) are possible. Also, applications that + cannot tolerate the inclusion of per-message information in the ukm + (due to bandwidth requirements, for example) SHOULD NOT use static- + static ECDH for a recipient without ascertaining that the recipient + knows the private value associated with their certified Diffie- + Hellman value. + + Static-static Diffie-Hellman, when used as described in this + document, does not necessarily provide data-origin authentication. + Consider, for example, the following sequence of events: + + + + + +Herzog & Khazan Informational [Page 12] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + + o Alice sends an AuthEnvelopedData message to both Bob and Mallory. + Furthermore, Alice uses a static-static DH method to transport the + content-authenticated-encryption 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 content-authenticated-encryption 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 content-authenticated-encryption + 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 static-static DH values, + 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 static-static Diffie-Hellman does not necessarily + provide data-origin authentication. (We note that this example does + not also contradict either confidentiality or data authentication: + Alice's message was not received by anyone not intended by Alice, and + Mallory's message was not modified before reaching Bob.) + + More generally, the data origin may not be authenticated unless: + + o it is a priori guaranteed that the message in question was sent to + exactly one recipient, or + + o data-origin 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 static-static ECDH per se, but is inherent in the way key- + agreement schemes are used in the AuthenticatedData and + AuthEnvelopedData structures of the CMS. + + When two parties are communicating using static-static ECDH as + described in this document, and either party's asymmetric keys have + been centrally generated, it is possible for that party's central + + + +Herzog & Khazan Informational [Page 13] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + + infrastructure to decrypt the communication (for application-layer + network monitoring or filtering, for example). By way of contrast: + were ephemeral-static ECDH to be used instead, such decryption by the + sender's infrastructure would not be possible (though it would remain + possible for the infrastructure of any recipient). + +8. Acknowledgements and Disclaimer + + This work is sponsored by the United States Air Force under Air Force + Contract FA8721-05-C-0002. Opinions, interpretations, conclusions + and recommendations are those of the authors and are not necessarily + endorsed by the United States Government. + + 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. + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, 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) + Authenticated-Enveloped-Data Content Type", RFC 5083, + November 2007. + + [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated + Encryption in the Cryptographic Message Syntax (CMS)", + RFC 5084, November 2007. + + [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)", STD 70, + RFC 5652, September 2009. + + + + +Herzog & Khazan Informational [Page 14] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + + [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. + + [SP800-56A] + Barker, E., Johnson, D., and M. Smid, "Recommendation for + Pair-Wise Key Establishment Schemes Using Discrete + Logarithm Cryptography (Revised)", NIST Special + Publication (SP) 800-56A, March 2007. + + [X963] "Public Key Cryptography for the Financial Services + Industry, Key Agreement and Key Transport Using Elliptic + Curve Cryptography", ANSI X9.63, 2001. + +9.2. Informative References + + [MenezesUstaoglu] + Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys in + Diffie-Hellman Key Agreement Protocols", International + Journal of Applied Cryptography, Vol. 2, No. 2, pp. 154- + 158, 2010. + + [RFC2631] Rescorla, E., "Diffie-Hellman 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] ITU-T, "Information Technology - Abstract Syntax Notation + One: Specification of Basic Notation", + Recommendation X.680, ISO/IEC 8824-1:2002, 2002. + + [X.681] ITU-T, "Information Technology - Abstract Syntax Notation + One: Information Object Specification", + Recommendation X.681, ISO/IEC 8824-2:2002, 2002. + + [X.682] ITU-T, "Information Technology - Abstract Syntax Notation + One: Constraint Specification", Recommendation X.682, ISO/ + IEC 8824-3:2002, 2002. + + [X.683] ITU-T, "Information Technology - Abstract Syntax Notation + One: Parameterization of ASN.1 Specifications", + Recommendation X.683, ISO/IEC 8824-4:2002, 2002. + + + + + +Herzog & Khazan Informational [Page 15] + +RFC 6278 Static-Static ECDH in CMS June 2011 + + +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 Informational [Page 16] + -- cgit v1.2.3