doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

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]
+