idnits 2.17.1 draft-herzog-static-ecdh-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 217: '...ques and formats MUST be used. The fi...' RFC 2119 keyword, line 220: '...EnvelopedData originatorInfo field MAY...' RFC 2119 keyword, line 229: '... o version MUST be 3....' RFC 2119 keyword, line 232: '... MUST be either issuerAndSerialNu...' RFC 2119 keyword, line 235: '... o ukm MAY be present or absent. H...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [MUST], but that reference does not seem to mention RFC 2119 either. -- The document date (December 7, 2010) is 4888 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Herzog 3 Internet-Draft R. Khazan 4 Intended status: Informational MIT Lincoln Laboratory 5 Expires: June 10, 2011 December 7, 2010 7 Use of static-static Elliptic-Curve Diffie-Hellman key agreement in 8 Cryptographic Message Syntax 9 draft-herzog-static-ecdh-02 11 Abstract 13 This document describes how to use 'static-static' Elliptic Curve 14 Diffie-Hellman key-agreement with the Cryptographic Message Syntax. 15 In this form of key-agreement, the Diffie-Hellman values of both 16 sender and receiver are long-term values contained in certificates. 18 Disclaimer 20 This work is sponsored by the United States Air Force under Air Force 21 Contract FA8721-05-C-0002. Opinions, interpretations, conclusions 22 and recommendations are those of the authors and are not necessarily 23 endorsed by the United States Government. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on June 10, 2011. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 5 66 2. EnvelopedData using static-static ECDH . . . . . . . . . . . . 5 67 2.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 5 68 2.2. Actions of the sending agent . . . . . . . . . . . . . . . 6 69 2.3. Actions of the receiving agent . . . . . . . . . . . . . . 7 70 3. AuthenticatedData using static-static ECDH . . . . . . . . . . 8 71 3.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 8 72 3.2. Actions of the sending agent . . . . . . . . . . . . . . . 8 73 3.3. Actions of the receiving agent . . . . . . . . . . . . . . 8 74 4. AuthEnvelopedData using static-static ECDH . . . . . . . . . . 8 75 4.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 9 76 4.2. Actions of the sending agent . . . . . . . . . . . . . . . 9 77 4.3. Actions of the receiving agent . . . . . . . . . . . . . . 9 78 5. Comparison to [CMS-ECC] . . . . . . . . . . . . . . . . . . . 9 79 6. Requirements and Recommendations . . . . . . . . . . . . . . . 10 80 7. Security considerations . . . . . . . . . . . . . . . . . . . 11 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 This document describes how to use the static-static Elliptic-Curve 91 Diffie-Hellman key agreement scheme [SEC1] in the Cryptographic 92 Message Syntax (CMS) [CMS]. The CMS is a standard notation and 93 representation for cryptographic messages. CMS uses ASN.1 notation 94 [X.680] [X.681] [X.682] [X.683] to define a number of structures that 95 carry both cryptographically-protected information and key-management 96 information regarding the keys used. Of particular interest here are 97 three structures: 99 o EnvelopedData, which holds encrypted (but not necessarily 100 authenticated) information [CMS], 102 o AuthenticatedData, which holds authenticated (MACed) information 103 [CMS], and 105 o AuthEnvelopedData, which holds information protected by 106 authenticated encryption: a cryptographic scheme that combines 107 encryption and authentication [CMS-AUTHENV]. 109 All three of these types share the same basic structure. First, a 110 fresh symmetric key is generated. This symmetric key has a different 111 name that reflects its usage in each of the three structures. 112 EnvelopedData uses a content-encryption key (CEK); AuthenticatedData 113 uses an authentication key; AuthEnvelopedData uses a content- 114 authenticated-encryption key. The originator uses the symmetric key 115 to cryptographically protect the content. The symmetric key is then 116 used wrapped for each recipient; only the intended recipient has 117 access to the private keying material necessary to unwrap the 118 symmetric key. Once unwrapped, the recipient uses the symmetric key 119 to decrypt the content, check the integrity of the content, or both. 120 The CMS supports several different approaches to symmetric key 121 wrapping, including: 123 o key transport: the symmetric key is encrypted using the public 124 encryption key of some recipient, 126 o key-encryption key: the symmetric key is encrypted using a 127 previously-distributed symmetric key, and 129 o key agreement: the symmetric key is encrypted using a key- 130 encryption key (KEK) created using a key-agreement scheme and a 131 key-derivation function (KDF). 133 One such key-agreement scheme is the Diffie-Hellman algorithm [DH] 134 which uses group-theory to produce a value known only to its two 135 participants. In this case, the participants are the originator and 136 one of the recipients. Each participant produces a private value and 137 a public value, and each participant can produce the shared secret 138 value from their own private value and their counterpart's public 139 value. There are some variations on the basic algorithm: 141 o The basic algorithm typically uses the group 'Z mod p', meaning 142 the set of integers modulo some prime p. One can also use an 143 elliptic-curve group, which allows for shorter messages. 145 o Over elliptic-curve groups, the standard algorithm can be extended 146 to incorporate the 'cofactor' of the group (see [SEC1] for more 147 details). This method, called 'cofactor Elliptic Curve Diffie- 148 Hellman', can prevent certain attacks possible in the elliptic- 149 curve group. 151 o The participants can generate fresh new public/private values 152 (called ephemeral values) for each run of the algorithm, or they 153 can re-use long-term values (called static values). Ephemeral 154 values add randomness to the resulting private value, while static 155 values can be embedded in certificates. The two participants do 156 not need to use the same kind of value: either participant can use 157 either type. In 'ephemeral-static' Diffie-Hellman, for example, 158 the sender uses an ephemeral public/private pair value while the 159 receiver uses a static pair. In 'static-static' Diffie-Hellman, 160 on the other hand, both participants use static pairs. (Receivers 161 cannot use ephemeral values in this setting, and so we ignore 162 ephemeral-ephemeral and static-ephemeral Diffie-Hellman in this 163 document.) 165 Several of these variations are already described in existing CMS 166 standards. [CMS-ALG] contains the conventions for using for 167 ephemeral-static and static-static Diffie-Hellman over the 'basic' (Z 168 mod p) group. [CMS-ECC] contains the conventions for using 169 ephemeral-static Diffie-Hellman over elliptic curves (both standard 170 and cofactor methods). It does not, however, contain conventions for 171 using either method of static-static Elliptic-Curve Diffie-Hellman, 172 preferring to discuss the ECMQV algorithm instead. 174 In this document, we specify the conventions for using static-static 175 Elliptic-Curve Diffie-Hellman (ECDH) for both standard and cofactor 176 methods. Our motivations are three-fold: 178 1. Intellectual-property concerns have hindered market adoptation of 179 the ECMQV algorithm, 181 2. ECMQV has been removed from the National Security Agency's Suite 182 B of cryptographic algorithms, and 184 3. ECMQV requires the sender to create a fresh random value for each 185 recipient. While the incorporation of per-session randomness is 186 good cryptographic practice, ECMQV fixes the size of this 187 randomness: that of one elliptic-curve point. For low-bandwidth 188 networks, it may be necessary to use smaller amounts of per- 189 recipient randomness. 191 We note that like ephemeral-static ECDH, static-static ECDH creates a 192 secret key shared by sender and receiver. Unlike ephemeral-static 193 ECDH, however, static-static ECDH uses a static key pair for the 194 sender. Each of the three CMS structures discussed in this document 195 (EnvelopedData, AuthenticatedData, and AuthEnvelopedData) uses 196 static-static ECDH to achieve different goals: 198 o EnvelopedData uses static-static ECDH to provide data 199 confidentiality. It will not necessarily, however, provide data 200 integrity. 202 o AuthenticatedData uses static-static ECDH to provide data- 203 integrity. It will not provide data-confidentiality. 205 o AuthEnvelopedData uses static-static ECDH to provide both of 206 confidentiality and data-integrity. 208 1.1. Requirements Terminology 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in [MUST]. 214 2. EnvelopedData using static-static ECDH 216 If an implementation uses static-static ECDH with CMS EnvelopedData 217 then the following techniques and formats MUST be used. The fields 218 of EnvelopedData are as in [CMS]; as static-static ECDH is a key 219 agreement algorithm, the RecipientInfo kari choice is used. When 220 using static-static ECDH, the EnvelopedData originatorInfo field MAY 221 include the certificate(s) for the EC public key(s) used in the 222 formation of the pairwise key. 224 2.1. Fields of the KeyAgreeRecipientInfo 226 When using static-static ECDH with EnvelopedData, the fields of 227 KeyAgreeRecipientInfo [CMS] are: 229 o version MUST be 3. 231 o originator identifies the static EC public key of the sender. It 232 MUST be either issuerAndSerialNumber or subjectKeyIdentifier, and 233 point to one of the sending agent's certificates. 235 o ukm MAY be present or absent. However, message originators SHOULD 236 include the ukm. As specified in [CMS], implementations MUST 237 support ukm message recipient processing, so interoperability is 238 not a concern if the ukm is present or absent. The use of a fresh 239 value for ukm will ensure that a different key is generated for 240 each message between the same sender and receiver. ukm, if 241 present, is placed in the entityUInfo field of the ECC-CMS- 242 SharedInfo structure [CMS-ECC] and therefore used as an input to 243 the key derivation function. 245 o keyEncryptionAlgorithm MUST contain the object identifier of the 246 key encryption algorithm, which in this case is a key agreement 247 algorithm (see Section 5). The parameters field contains 248 KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm 249 identifier that indicates the symmetric encryption algorithm used 250 to encrypt the content-encryption key (CEK) with the key- 251 encryption key (KEK) and any associated parameters (see 252 Section 5). 254 o recipientEncryptedKeys contains an identifier and an encrypted CEK 255 for each recipient. The RecipientEncryptedKey 256 KeyAgreeRecipientIdentifier MUST contain either the 257 issuerAndSerialNumber identifying the recipient's certificate or 258 the RecipientKeyIdentifier containing the subject key identifier 259 from the recipient's certificate. In both cases, the recipient's 260 certificate contains the recipient's static ECDH public key. 261 RecipientEncryptedKey EncryptedKey MUST contain the content- 262 encryption key encrypted with the static-static ECDH-generated 263 pairwise key-encryption key using the algorithm specified by the 264 KeyWrapAlgorithm. 266 2.2. Actions of the sending agent 268 When using static-static ECDH with EnvelopedData, the sending agent 269 first obtains the recipient's EC public key and domain parameters 270 (e.g. from the recipient's certificate). It confirms that both 271 certificates contain public-key values with the same curve 272 parameters, and that both of these public-key values are marked as 273 appropriate for ECDH (that is, marked with algorithm-identifiers id- 274 ecPublicKey or id-ecDH [PKI-ECC]). The sender then determines: 276 o whether to use standard or cofactor Diffie-Hellman, and 277 o which hash algorithms to use for the key-derivation function. 279 The sender then chooses keyEncryptionAlgorithm that reflects these 280 choices. It then determines: 282 o an integer "keydatalen", which is the KeyWrapAlgorithm symmetric 283 key-size in bits, and 285 o the value of ukm, if used. 287 The sender then determines a bit string "SharedInfo", which is the 288 DER encoding of ECC-CMS-SharedInfo (see Section 7.2 of [CMS-ECC]). 289 The sending agent then performs the key agreement operation of the 290 Elliptic Curve Diffie-Hellman Scheme specified in [SEC1] and the KDF 291 defined in Section 3.6.1 of [SEC1] with the hash algorithm identified 292 in the key agreement algorithm. As a result the sending agent 293 obtains a shared secret bit string "K", which is used as the pairwise 294 key-encryption key (KEK) to wrap the CEK for that recipient, as 295 specified in [CMS]. 297 2.3. Actions of the receiving agent 299 When using static-static ECDH with EnvelopedData, the receiving agent 300 retrieves keyEncryptionAlgorithm to determine the key-agreement 301 algorithm chosen by the sender, which will identify: 303 o the domain-parameters of the curve used, 305 o whether standard or cofactor Diffie-Hellman was used, and 307 o which hash-function was used for the KDF. 309 The receiver then retrieves the static EC public key identified in 310 the rid field. It confirms that both certificates contain public-key 311 values associated with the curve identified by the 312 keyEncryptionAlgorithm, and that both of these public-key values are 313 marked as appropriate for ECDH (that is, marked with algorithm- 314 identifiers id-ecPublicKey or id-ecDH [PKI-ECC]). The receiver then 315 determines a bit string "SharedInfo", which is the DER encoding of 316 ECC-CMS-SharedInfo (see Section 7.2 of [CMS-ECC]) and performs the 317 key agreement operation of the Elliptic Curve Diffie-Hellman Scheme 318 specified in [SEC1]; in either case, use the KDF defined in Section 319 3.6.1 of [SEC1]. As a result, the receiving agent obtains a shared 320 secret bit string "K", which it uses as the pairwise key-encryption 321 key to unwrap the CEK. 323 3. AuthenticatedData using static-static ECDH 325 This section describes how to use the static-static ECDH key 326 agreement algorithm with AuthenticatedData. When using static-static 327 ECDH with AuthenticatedData, the fields of AuthenticatedData are as 328 in [CMS], but with the following restrictions: 330 o macAlgorithm MUST contain the algorithm identifier of the message 331 authentication code (MAC) algorithm which MUST be one of the 332 following: hmac-SHA1, id-hmacWITHSHA224, id- hmacWITHSHA256, id- 333 hmacWITHSHA384, or id-hmacWITHSHA512. (See Section 5.) 335 o digestAlgorithm MUST contain the algorithm identifier of the hash 336 algorithm which MUST be one of the following: id-sha1, id-sha224, 337 id-sha256, id-sha384, and id-sha512. (See Section 5.) 339 As static-static ECDH is a key agreement algorithm, the RecipientInfo 340 kari choice is used in the AuthenticatedData. When using static- 341 static ECDH, the AuthenticatedData originatorInfo field MAY include 342 the certificate(s) for the EC public key(s) used in the formation of 343 the pairwise key. 345 3.1. Fields of the KeyAgreeRecipientInfo 347 The AuthenticatedData KeyAgreeRecipientInfo fields are used in the 348 same manner as the fields for the corresponding EnvelopedData 349 KeyAgreeRecipientInfo fields of Section 2.1 of this document. The 350 authentication key is wrapped in the same manner as is described 351 there for the content-encryption key. 353 3.2. Actions of the sending agent 355 The sending agent uses the same actions as for EnvelopedData with 356 static-static ECDH, as specified in Section 2.2 of this document. 358 3.3. Actions of the receiving agent 360 The receiving agent uses the same actions as for EnvelopedData with 361 static-static ECDH, as specified in Section 2.3 of this document. 363 4. AuthEnvelopedData using static-static ECDH 365 When using static-static ECDH with AuthEnvelopedData, the fields of 366 AuthEnvelopedData are as in [CMS-AUTHENV]. As static-static ECDH is 367 a key agreement algorithm, the RecipientInfo kari choice is used. 368 When using static-static ECDH, the AuthEnvelopedData originatorInfo 369 field MAY include the certificate(s) for the EC public key used in 370 the formation of the pairwise key. 372 4.1. Fields of the KeyAgreeRecipientInfo 374 The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the 375 same manner as the fields for the corresponding EnvelopedData 376 KeyAgreeRecipientInfo fields of Section 2.1 of this document. The 377 content-authenticated-encryption key is wrapped in the same manner as 378 is described there for the content-encryption key. 380 4.2. Actions of the sending agent 382 The sending agent uses the same actions as for EnvelopedData with 383 static-static ECDH, as specified in Section 2.2 of this document. 385 4.3. Actions of the receiving agent 387 The receiving agent uses the same actions as for EnvelopedData with 388 static-static ECDH, as specified in Section 2.3 of this document. 390 5. Comparison to [CMS-ECC] 392 This document defines the use of static-static ECDH for 393 EnvelopedData, AuthenticatedData, and AuthEnvelopedData. The 394 standard [CMS-ECC] defines ephemeral-static ECDH for EnvelopedData 395 only. 397 With regard to EnvelopedData, this document and [CMS-ECC] greatly 398 parallel each other. Both specify how to apply Elliptic-Curve 399 Diffie-Hellman, and differ only on how the sender's public value is 400 to be communicated to the recipient. In [CMS-ECC], the sender 401 provides the public value explicitly by including an 402 OriginatorPublicKey value in the originator field of 403 KeyAgreeRecipientInfo. In this document, the sender include a 404 reference to a (certified) public value by including either an 405 IssuerAndSerialNumber or SubjectKeyIdentifier value in the same 406 field. Put another way, [CMS-ECC] provides an interpretation of a 407 KeyAgreeRecipientInfo structure where: 409 o the keyEncryptionAlgorithm value indicates Elliptic-Curve Diffie- 410 Hellman, and 412 o the originator field contains a OriginatorPublicKey value. 414 This document, on the other hand, provides an interpretation of a 415 KeyAgreeRecipientInfo structure where 416 o the keyEncryptionAlgorithm value indicates Elliptic-Curve Diffie- 417 Hellman, and 419 o the originator field contains either a IssuerAndSerialNumber value 420 or a SubjectKeyIdentifier value. 422 AuthenticatedData or AuthEnvelopedData messages, on the other hand, 423 are not given any form of ECDH by [CMS-ECC]. This is appropriate: 424 that document only defines ephemeral-static Diffie-Hellman, and this 425 form of Diffie-Hellman does not (inherently) provide any form of 426 data-authentication or data-origin authentication. This document, on 427 the other hand, requires that the sender use a certified public 428 value. Thus, this form of key-agreement provides implicit key 429 authentication and, under some limited circumstances, data-origin 430 authentication. (See Section 7.) 432 This document does not define any new ASN.1 structures or algorithm 433 identifiers. It provides new ways to interpret structures from [CMS] 434 and [CMS-ECC], and allows previously-defined algorithms to be used 435 under these new interpretations. Specifically: 437 o The ECDH key-agreement algorithm-identifiers from [CMS-ECC] define 438 only how Diffie-Hellman values are processed, not where these 439 values are created. Therefore, they can be used for static-static 440 ECDH with no changes. 442 o The key-wrap, MAC, and digest algorithms referenced in [CMS-ECC] 443 describe how the secret key is to be used, not created. 444 Therefore, they can be used with keys from static-static ECDH 445 without modification. 447 6. Requirements and Recommendations 449 It is RECOMMENDED that implementations of this specification support 450 AuthenticatedData and EnvelopedData. Support for AuthEnvelopedData 451 is OPTIONAL. 453 Implementations that support this specification MUST support standard 454 Elliptic Curve Diffie-Hellman, and these implementation MAY also 455 support cofactor Elliptic Curve Diffie-Hellman. 457 In order to encourage interoperability, implementations SHOULD use 458 the elliptic curve domain parameters specified by [PKI-ECC]. 460 Implementations that support standard static-static Elliptic Curve 461 Diffie-Hellman: 463 MUST support the dhSinglePass-stdDH-sha256kdf-scheme key agreement 464 algorithm, the id-aes128-wrap key wrap algorithm, and the id- 465 aes128-cbc content encryption algorithm; and, 467 MAY support the dhSinglePass-stdDH-sha1kdf-scheme, dhSinglePass- 468 stdDH-sha224kdf-scheme, dhSinglePass-stdDH-sha384kdf-scheme and 469 dhSinglePass-stdDH-sha512kdf-scheme key agreement algorithms, the 470 id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap 471 algorithms and the des-ede3-cbc, id-aes192-cbc, and id-aes256-cbc 472 content encryption algorithms; other algorithms MAY also be 473 supported. 475 Implementations that support cofactor static-static Elliptic-Curve 476 Diffie-Hellman: 478 MUST support the dhSinglePass-cofactorDH-sha256kdf-scheme key 479 agreement algorithm, the id-aes128-wrap key wrap algorithm, and 480 the id-aes128-cbc content encryption algorithm; and, 482 MAY support the dhSinglePass-cofactorDH-sha1kdf-scheme, 483 dhSinglePass-cofactorDH-sha224kdf-scheme, dhSinglePass- 484 cofactorDH-sha384kdf-scheme, and dhSinglePass-cofactorDH- 485 sha512kdf-scheme key agreement, the id-alg-CMS3DESwrap, id- 486 aes192-wrap, and id-aes256-wrap key wrap algorithms and the des- 487 ede3-cbc, id-aes192-cbc, and id-aes256-cbc content encryption 488 algorithms; other algorithms MAY also be supported. 490 7. Security considerations 492 All security considerations in Section 9 of [CMS-ECC] apply. 494 Extreme care must be used when using static-static Diffie-Hellman 495 (either standard or cofactor) without the use of some per-message 496 value in ukm. If no message-specific information is used (such as a 497 counter value, or a fresh random string) then the resulting secret 498 key could be used in more than one message. Under some 499 circumstances, this will open the sender to the 'small subgroup' 500 attack [MenezesUstaoglu] or other, yet-undiscovered attacks on re- 501 used Diffie-Hellman keys. Applications that cannot tolerate the 502 inclusion of per-message information in ukm (due to bandwidth 503 requirements, for example) SHOULD NOT use static-static ECDH for a 504 recipient without ascertaining that the recipient knows the private 505 value associated with their certified Diffie-Hellman value. Static- 506 static Diffie-Hellman, when used as described in this document, does 507 not necessarily provide data-origin authentication. Consder, for 508 example, the following sequence of events: 510 o Alice sends an AuthEnvelopedData message to both Bob and Mallory. 511 Furthermore, Alice uses a static-static DH method to transport the 512 content-authenticated-encryption key to Bob, and some arbitrary 513 method to transport the same key to Mallory. 515 o Mallory intercepts the message and prevents Bob from receiving it. 517 o Mallory recovers the content-authenticated-encryption key from the 518 message received from Alice. Mallory then creates new plaintext 519 of her choice, and encrypts it using the same authenticated- 520 encryption algorithm and the same content-authenticated-encryption 521 key used by Alice. 523 o Mallory then replaces the EncryptedContentInfo and 524 MessageAuthenticationCode fields of Alice's message with the 525 values Mallory just generated. She may additionally remove her 526 RecipientInfo value from Alice's message. 528 o Mallory sends the modified message to Bob. 530 o Bob receives the message, validates the static-static DH works and 531 decrypts/authenticates the message. 533 At this point, Bob has received and validated a message that appears 534 to have been sent by Alice, but whose content was chosen by Mallory. 535 Mallory may not even be an apparent reciever of the modified message. 536 Thus, this use of static-static Diffie-Hellman does not necessarily 537 provide data-origin authentication. (We note that this example does 538 not also contradict either confidentiality or data-authentication: 539 Alice's message was not received by anyone not intended by Alice, and 540 Mallory's message was not modified before reaching Bob.) More 541 generally, data-origin may not be authenticated unless 543 o It is a priori guaranteed that the message in question was sent to 544 exactly one recipient, or 546 o Data-origin authentication is provided by some other mechanism 547 (such as digital signatures). 549 8. IANA Considerations 551 There are no IANA considerations. 553 9. Acknowledgements 555 The authors would like to thank Jim Schaad, Russ Housley, and Sean 556 Turner for their helpful comments and suggestions. We would also 557 like to thank Jim Schaad for describing to us the attack described in 558 Section 7. 560 10. References 562 10.1. Normative References 564 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", Request 565 For Comments 5652, September 2009. 567 [CMS-AUTHENV] 568 Housley, R., "Cryptographic Message Syntax (CMS) 569 Authenticated-Enveloped-Data Content Type", Request For 570 Comments 5083, November 2007. 572 [CMS-ECC] Turner, S. and D. Brown, "Use of Elliptic Curve 573 Cryptography (ECC) Algorithms in Cryptographic Message 574 Syntax (CMS)", Request For Comments 5753, January 2010. 576 [MUST] Bradner, S., "Key words for use in RFCs to Indicate 577 Requirement Levels", Request 2119, March 1997. 579 [PKI-ECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 580 "Elliptic Curve Cryptography Subject Public Key 581 Information", Request For Comments 5480, March 2009. 583 [SEC1] Brown, D., "Standards for Efficient Cryptography 1 (SEC 584 1)", Standards for Efficient Cryptography 1, May 2009. 586 10.2. Informative References 588 [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) 589 Algorithms", Request For Comments 3370, August 2002. 591 [DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", 592 Request For Comments 2631, June 1999. 594 [MenezesUstaoglu] 595 Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys in 596 Diffie-Hellman Key Agreement Protocols". 598 International Journal of Applied Cryptography, to appear. 600 [X.680] ITU-T, "Information Technology - Abstract Syntax Notation 601 One", Recommendation X.680, ISO/IEC 8824-1:2002, 2002. 603 [X.681] ITU-T, "Information Technology - Abstract Syntax Notation 604 One: Information Object Specifcation", 605 Recommendation X.681, ISO/IEC 8824-2:2002, 2002. 607 [X.682] ITU-T, "Information Technology - Abstract Syntax Notation 608 One: Constraint Specification", Recommendation X.682, ISO/ 609 IEC 8824-3:2002, 2002. 611 [X.683] ITU-T, "Information Technology - Abstract Syntax Notation 612 One: Parameterization of ASN.1 Specifications", 613 Recommendation X.683, ISO/IEC 8824-4:2002, 2002. 615 Authors' Addresses 617 Jonathan C. Herzog 618 MIT Lincoln Laboratory 619 244 Wood St. 620 Lexington, MA 02144 621 USA 623 Email: jherzog@ll.mit.edu 625 Roger Khazan 626 MIT Lincoln Laboratory 627 244 Wood St. 628 Lexington, MA 02144 629 USA 631 Email: rkh@ll.mit.edu