<pre>Internet Engineering Task Force (IETF)                         J. Herzog
Request for Comments: 6278                                     R. Khazan
Category: Informational                           MIT Lincoln Laboratory
ISSN: 2070-1721                                                June 2011


  <span class="h1">Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in</span>
                      <span class="h1">Cryptographic Message Syntax</span>

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 <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6278">http://www.rfc-editor.org/info/rfc6278</a>.


















<span class="grey">Herzog &amp; Khazan               Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents

   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
      <a href="#section-1.1">1.1</a>. Requirements Terminology ...................................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. EnvelopedData Using Static-Static ECDH ..........................<a href="#page-5">5</a>
      <a href="#section-2.1">2.1</a>. Fields of the KeyAgreeRecipientInfo ........................<a href="#page-5">5</a>
      <a href="#section-2.2">2.2</a>. Actions of the Sending Agent ...............................<a href="#page-6">6</a>
      <a href="#section-2.3">2.3</a>. Actions of the Receiving Agent .............................<a href="#page-7">7</a>
   <a href="#section-3">3</a>. AuthenticatedData Using Static-Static ECDH ......................<a href="#page-8">8</a>
      <a href="#section-3.1">3.1</a>. Fields of the KeyAgreeRecipientInfo ........................<a href="#page-8">8</a>
      <a href="#section-3.2">3.2</a>. Actions of the Sending Agent ...............................<a href="#page-8">8</a>
      <a href="#section-3.3">3.3</a>. Actions of the Receiving Agent .............................<a href="#page-9">9</a>
   <a href="#section-4">4</a>. AuthEnvelopedData Using Static-Static ECDH ......................<a href="#page-9">9</a>
      <a href="#section-4.1">4.1</a>. Fields of the KeyAgreeRecipientInfo ........................<a href="#page-9">9</a>
      <a href="#section-4.2">4.2</a>. Actions of the Sending Agent ...............................<a href="#page-9">9</a>
      <a href="#section-4.3">4.3</a>. Actions of the Receiving Agent .............................<a href="#page-9">9</a>
   <a href="#section-5">5</a>. Comparison to <a href="./rfc5753">RFC 5753</a> ..........................................<a href="#page-9">9</a>
   <a href="#section-6">6</a>. Requirements and Recommendations ...............................<a href="#page-10">10</a>
   <a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-12">12</a>
   <a href="#section-8">8</a>. Acknowledgements ...............................................<a href="#page-14">14</a>
   <a href="#section-9">9</a>. References .....................................................<a href="#page-14">14</a>
      <a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-14">14</a>
      <a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-15">15</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   This document describes how to use the static-static Elliptic Curve
   Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie-
   Hellman [<a href="./rfc6090" title="&quot;Fundamental Elliptic Curve Cryptography Algorithms&quot;">RFC6090</a>] where both participants use static Diffie-Hellman
   values) in the Cryptographic Message Syntax (CMS) [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>].  The CMS
   is a standard notation and representation for cryptographic messages.
   The CMS uses ASN.1 notation [<a href="#ref-X.680" title="&quot;Information Technology - Abstract Syntax Notation One: Specification of Basic Notation&quot;">X.680</a>] [<a href="#ref-X.681" title="&quot;Information Technology - Abstract Syntax Notation One: Information Object Specification&quot;">X.681</a>] [<a href="#ref-X.682" title="&quot;Information Technology - Abstract Syntax Notation One: Constraint Specification&quot;">X.682</a>] [<a href="#ref-X.683" title="&quot;Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications&quot;">X.683</a>] to define



<span class="grey">Herzog &amp; Khazan               Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


   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 [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>],

   o  AuthenticatedData, which holds authenticated (MACed) information
      [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>], and

   o  AuthEnvelopedData, which holds information protected by
      authenticated encryption: a cryptographic scheme that combines
      encryption and authentication [<a href="./rfc5083" title="&quot;Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type&quot;">RFC5083</a>].

   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
   [<a href="./rfc2631" title="&quot;Diffie-Hellman Key Agreement Method&quot;">RFC2631</a>], 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:





<span class="grey">Herzog &amp; Khazan               Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


   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' [<a href="#ref-SP800-56A">SP800-56A</a>] 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, [<a href="./rfc3370" title="&quot;Cryptographic Message Syntax (CMS) Algorithms&quot;">RFC3370</a>] contains the conventions for using
   ephemeral-static and static-static Diffie-Hellman over the 'basic' (Z
   mod p) group.  [<a href="./rfc5753" title="&quot;Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)&quot;">RFC5753</a>] 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.




<span class="grey">Herzog &amp; Khazan               Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


   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.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Requirements Terminology</span>

   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 [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  EnvelopedData Using Static-Static ECDH</span>

   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 [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>]; 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.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Fields of the KeyAgreeRecipientInfo</span>

   When using static-static ECDH with EnvelopedData, the fields of
   KeyAgreeRecipientInfo [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>] 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 [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>],
      implementations MUST support ukm message recipient processing, so



<span class="grey">Herzog &amp; Khazan               Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


      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 [<a href="./rfc5753" title="&quot;Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)&quot;">RFC5753</a>] 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 <a href="#section-5">Section 5</a>).  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
      <a href="#section-5">Section 5</a>).

   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.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Actions of the Sending Agent</span>

   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 [<a href="./rfc5480" title="&quot;Elliptic Curve Cryptography Subject Public Key Information&quot;">RFC5480</a>]).

   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:




<span class="grey">Herzog &amp; Khazan               Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


   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 <a href="./rfc5753#section-7.2">Section&nbsp;7.2 of [RFC5753]</a>).
   The sending agent then performs either the Elliptic Curve Diffie-
   Hellman operation of [<a href="./rfc6090" title="&quot;Fundamental Elliptic Curve Cryptography Algorithms&quot;">RFC6090</a>] (for standard Diffie-Hellman) or the
   Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH)
   Primitive of [<a href="#ref-SP800-56A">SP800-56A</a>] (for cofactor Diffie-Hellman).  The sending
   agent then applies the simple hash-function construct of [<a href="#ref-X963" title="&quot;Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography&quot;">X963</a>]
   (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
   [<a href="#ref-SEC1" title="&quot;SEC 1: Elliptic Curve Cryptography&quot;">SEC1</a>].)  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 [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>].

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Actions of the Receiving Agent</span>

   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 [<a href="./rfc5480" title="&quot;Elliptic Curve Cryptography Subject Public Key Information&quot;">RFC5480</a>]).

   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
   <a href="./rfc5753#section-7.2">Section&nbsp;7.2 of [RFC5753]</a>).  The receiving agent then performs either
   the Elliptic Curve Diffie-Hellman operation of [<a href="./rfc6090" title="&quot;Fundamental Elliptic Curve Cryptography Algorithms&quot;">RFC6090</a>] (for



<span class="grey">Herzog &amp; Khazan               Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


   standard Diffie-Hellman) or the Elliptic Curve Cryptography Cofactor
   Diffie-Hellman (ECC CDH) Primitive of [<a href="#ref-SP800-56A">SP800-56A</a>] (for cofactor
   Diffie-Hellman).  The receiving agent then applies the simple hash-
   function construct of [<a href="#ref-X963" title="&quot;Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography&quot;">X963</a>] (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 [<a href="#ref-SEC1" title="&quot;SEC 1: Elliptic Curve Cryptography&quot;">SEC1</a>].)  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.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  AuthenticatedData Using Static-Static ECDH</span>

   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 [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>], 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 <a href="#section-5">Section 5</a>.)

   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 <a href="#section-5">Section 5</a>.)

   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.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Fields of the KeyAgreeRecipientInfo</span>

   The AuthenticatedData KeyAgreeRecipientInfo fields are used in the
   same manner as the fields for the corresponding EnvelopedData
   KeyAgreeRecipientInfo fields of <a href="#section-2.1">Section 2.1</a> of this document.  The
   authentication key is wrapped in the same manner as is described
   there for the content-encryption key.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Actions of the Sending Agent</span>

   The sending agent uses the same actions as for EnvelopedData with
   static-static ECDH, as specified in <a href="#section-2.2">Section 2.2</a> of this document.





<span class="grey">Herzog &amp; Khazan               Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Actions of the Receiving Agent</span>

   The receiving agent uses the same actions as for EnvelopedData with
   static-static ECDH, as specified in <a href="#section-2.3">Section 2.3</a> of this document.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  AuthEnvelopedData Using Static-Static ECDH</span>

   When using static-static ECDH with AuthEnvelopedData, the fields of
   AuthEnvelopedData are as in [<a href="./rfc5083" title="&quot;Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type&quot;">RFC5083</a>].  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.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Fields of the KeyAgreeRecipientInfo</span>

   The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the
   same manner as the fields for the corresponding EnvelopedData
   KeyAgreeRecipientInfo fields of <a href="#section-2.1">Section 2.1</a> of this document.  The
   content-authenticated-encryption key is wrapped in the same manner as
   is described there for the content-encryption key.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Actions of the Sending Agent</span>

   The sending agent uses the same actions as for EnvelopedData with
   static-static ECDH, as specified in <a href="#section-2.2">Section 2.2</a> of this document.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Actions of the Receiving Agent</span>

   The receiving agent uses the same actions as for EnvelopedData with
   static-static ECDH, as specified in <a href="#section-2.3">Section 2.3</a> of this document.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Comparison to <a href="./rfc5753">RFC 5753</a></span>

   This document defines the use of static-static ECDH for
   EnvelopedData, AuthenticatedData, and AuthEnvelopedData.  [<a href="./rfc5753" title="&quot;Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)&quot;">RFC5753</a>]
   defines ephemeral-static ECDH for EnvelopedData only.

   With regard to EnvelopedData, this document and [<a href="./rfc5753" title="&quot;Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)&quot;">RFC5753</a>] 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 [<a href="./rfc5753" title="&quot;Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)&quot;">RFC5753</a>], 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, [<a href="./rfc5753" title="&quot;Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)&quot;">RFC5753</a>] provides an
   interpretation of a KeyAgreeRecipientInfo structure where:



<span class="grey">Herzog &amp; Khazan               Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


   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 [<a href="./rfc5753" title="&quot;Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)&quot;">RFC5753</a>].  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 <a href="#section-7">Section 7</a>.)

   This document does not define any new ASN.1 structures or algorithm
   identifiers.  It provides new ways to interpret structures from
   [<a href="./rfc5652" title="&quot;Cryptographic Message Syntax (CMS)&quot;">RFC5652</a>] and [<a href="./rfc5753" title="&quot;Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)&quot;">RFC5753</a>], and it allows previously defined algorithms
   to be used under these new interpretations.  Specifically:

   o  The ECDH key-agreement algorithm identifiers from [<a href="./rfc5753" title="&quot;Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)&quot;">RFC5753</a>] 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 [<a href="./rfc5753" title="&quot;Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)&quot;">RFC5753</a>]
      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.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Requirements and Recommendations</span>

   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.



<span class="grey">Herzog &amp; Khazan               Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


   In order to encourage interoperability, implementations SHOULD use
   the elliptic curve domain parameters specified by [<a href="./rfc5480" title="&quot;Elliptic Curve Cryptography Subject Public Key Information&quot;">RFC5480</a>].

   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.




<span class="grey">Herzog &amp; Khazan               Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


   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 [<a href="./rfc3370" title="&quot;Cryptographic Message Syntax (CMS) Algorithms&quot;">RFC3370</a>], [<a href="./rfc3565" title="&quot;Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)&quot;">RFC3565</a>], [<a href="./rfc5084" title="&quot;Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)&quot;">RFC5084</a>],
   and [<a href="./rfc5753" title="&quot;Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)&quot;">RFC5753</a>].)  Unless otherwise noted above, other algorithms MAY
   also be supported.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   All security considerations in <a href="./rfc5753#section-9">Section&nbsp;9 of [RFC5753]</a> 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 [<a href="./rfc5753" title="&quot;Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)&quot;">RFC5753</a>], 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 [<a href="#ref-X963" title="&quot;Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography&quot;">X963</a>].  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 [<a href="#ref-MenezesUstaoglu">MenezesUstaoglu</a>] or
   other, yet-undiscovered attacks).

   It is for these reasons that <a href="#section-2.1">Section 2.1</a> 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:





<span class="grey">Herzog &amp; Khazan               Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


   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



<span class="grey">Herzog &amp; Khazan               Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


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

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Acknowledgements and Disclaimer</span>

   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 <a href="#section-7">Section 7</a>.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  References</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Normative References</span>

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC3370">RFC3370</a>]  Housley, R., "Cryptographic Message Syntax (CMS)
              Algorithms", <a href="./rfc3370">RFC 3370</a>, August 2002.

   [<a id="ref-RFC3565">RFC3565</a>]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
              Encryption Algorithm in Cryptographic Message Syntax
              (CMS)", <a href="./rfc3565">RFC 3565</a>, July 2003.

   [<a id="ref-RFC5083">RFC5083</a>]  Housley, R., "Cryptographic Message Syntax (CMS)
              Authenticated-Enveloped-Data Content Type", <a href="./rfc5083">RFC 5083</a>,
              November 2007.

   [<a id="ref-RFC5084">RFC5084</a>]  Housley, R., "Using AES-CCM and AES-GCM Authenticated
              Encryption in the Cryptographic Message Syntax (CMS)",
              <a href="./rfc5084">RFC 5084</a>, November 2007.

   [<a id="ref-RFC5480">RFC5480</a>]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", <a href="./rfc5480">RFC 5480</a>, March 2009.

   [<a id="ref-RFC5652">RFC5652</a>]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              <a href="./rfc5652">RFC 5652</a>, September 2009.




<span class="grey">Herzog &amp; Khazan               Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


   [<a id="ref-RFC5753">RFC5753</a>]  Turner, S. and D. Brown, "Use of Elliptic Curve
              Cryptography (ECC) Algorithms in Cryptographic Message
              Syntax (CMS)", <a href="./rfc5753">RFC 5753</a>, January 2010.

   [<a id="ref-RFC6090">RFC6090</a>]  McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
              Curve Cryptography Algorithms", <a href="./rfc6090">RFC 6090</a>, February 2011.

   [<a id="ref-SP800-56A">SP800-56A</a>]
              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.

   [<a id="ref-X963">X963</a>]     "Public Key Cryptography for the Financial Services
              Industry, Key Agreement and Key Transport Using Elliptic
              Curve Cryptography", ANSI X9.63, 2001.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Informative References</span>

   [<a id="ref-MenezesUstaoglu">MenezesUstaoglu</a>]
              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.

   [<a id="ref-RFC2631">RFC2631</a>]  Rescorla, E., "Diffie-Hellman Key Agreement Method",
              <a href="./rfc2631">RFC 2631</a>, June 1999.

   [<a id="ref-SEC1">SEC1</a>]     Standards for Efficient Cryptography Group (SECG), "SEC 1:
              Elliptic Curve Cryptography", Version 2.0, May 2009.

   [<a id="ref-X.680">X.680</a>]    ITU-T, "Information Technology - Abstract Syntax Notation
              One: Specification of Basic Notation",
              Recommendation X.680, ISO/IEC 8824-1:2002, 2002.

   [<a id="ref-X.681">X.681</a>]    ITU-T, "Information Technology - Abstract Syntax Notation
              One: Information Object Specification",
              Recommendation X.681, ISO/IEC 8824-2:2002, 2002.

   [<a id="ref-X.682">X.682</a>]    ITU-T, "Information Technology - Abstract Syntax Notation
              One: Constraint Specification", Recommendation X.682, ISO/
              IEC 8824-3:2002, 2002.

   [<a id="ref-X.683">X.683</a>]    ITU-T, "Information Technology - Abstract Syntax Notation
              One: Parameterization of ASN.1 Specifications",
              Recommendation X.683, ISO/IEC 8824-4:2002, 2002.





<span class="grey">Herzog &amp; Khazan               Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6278">RFC 6278</a>                Static-Static ECDH in CMS              June 2011</span>


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 &amp; Khazan               Informational                    [Page 16]
</pre>