idnits 2.17.1 draft-herzog-static-ecdh-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2011) is 4786 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 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: September 14, 2011 March 13, 2011 7 Use of static-static Elliptic-Curve Diffie-Hellman key agreement in 8 Cryptographic Message Syntax 9 draft-herzog-static-ecdh-06 11 Abstract 13 This document describes how to use 'static-static' Elliptic Curve 14 Diffie-Hellman key-agreement (i.e., Elliptic Curve Diffie-Hellman 15 where both participants use static Diffie-Hellman values) with the 16 Cryptographic Message Syntax. In this form of key-agreement, the 17 Diffie-Hellman values of both sender and receiver are long-term 18 values contained in certificates. 20 Disclaimer 22 This work is sponsored by the United States Air Force under Air Force 23 Contract FA8721-05-C-0002. Opinions, interpretations, conclusions 24 and recommendations are those of the authors and are not necessarily 25 endorsed by the United States Government. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 14, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 5 63 2. EnvelopedData using static-static ECDH . . . . . . . . . . . . 5 64 2.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 5 65 2.2. Actions of the sending agent . . . . . . . . . . . . . . . 6 66 2.3. Actions of the receiving agent . . . . . . . . . . . . . . 7 67 3. AuthenticatedData using static-static ECDH . . . . . . . . . . 8 68 3.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 8 69 3.2. Actions of the sending agent . . . . . . . . . . . . . . . 9 70 3.3. Actions of the receiving agent . . . . . . . . . . . . . . 9 71 4. AuthEnvelopedData using static-static ECDH . . . . . . . . . . 9 72 4.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 9 73 4.2. Actions of the sending agent . . . . . . . . . . . . . . . 9 74 4.3. Actions of the receiving agent . . . . . . . . . . . . . . 9 75 5. Comparison to [RFC5753] . . . . . . . . . . . . . . . . . . . 9 76 6. Requirements and Recommendations . . . . . . . . . . . . . . . 11 77 7. Security considerations . . . . . . . . . . . . . . . . . . . 12 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 85 1. Introduction 87 This document describes how to use the static-static Elliptic-Curve 88 Diffie-Hellman key agreement scheme (i.e., Elliptic Curve Diffie- 89 Hellman [RFC6090] where both participants use static Diffie-Hellman 90 values) in the Cryptographic Message Syntax (CMS) [RFC5652]. The CMS 91 is a standard notation and representation for cryptographic messages. 92 CMS uses ASN.1 notation [X.680] [X.681] [X.682] [X.683] to define a 93 number of structures that carry both cryptographically-protected 94 information and key-management information regarding the keys used. 95 Of particular interest here are three structures: 97 o EnvelopedData, which holds encrypted (but not necessarily 98 authenticated) information [RFC5652], 100 o AuthenticatedData, which holds authenticated (MACed) information 101 [RFC5652], and 103 o AuthEnvelopedData, which holds information protected by 104 authenticated encryption: a cryptographic scheme that combines 105 encryption and authentication [RFC5083]. 107 All three of these types share the same basic structure. First, a 108 fresh symmetric key is generated. This symmetric key has a different 109 name that reflects its usage in each of the three structures. 110 EnvelopedData uses a content-encryption key (CEK); AuthenticatedData 111 uses an authentication key; AuthEnvelopedData uses a content- 112 authenticated-encryption key. The originator uses the symmetric key 113 to cryptographically protect the content. The symmetric key is then 114 used wrapped for each recipient; only the intended recipient has 115 access to the private keying material necessary to unwrap the 116 symmetric key. Once unwrapped, the recipient uses the symmetric key 117 to decrypt the content, check the authenticity of the content, or 118 both. The CMS supports several different approaches to symmetric key 119 wrapping, including: 121 o key transport: the symmetric key is encrypted using the public 122 encryption key of some recipient, 124 o key-encryption key: the symmetric key is encrypted using a 125 previously-distributed symmetric key, and 127 o key agreement: the symmetric key is encrypted using a key- 128 encryption key (KEK) created using a key-agreement scheme and a 129 key-derivation function (KDF). 131 One such key-agreement scheme is the Diffie-Hellman algorithm 132 [RFC2631] which uses group-theory to produce a value known only to 133 its two participants. In this case, the participants are the 134 originator and one of the recipients. Each participant produces a 135 private value and a public value, and each participant can produce 136 the shared secret value from their own private value and their 137 counterpart's public value. There are some variations on the basic 138 algorithm: 140 o The basic algorithm typically uses the group 'Z mod p', meaning 141 the set of integers modulo some prime p. One can also use an 142 elliptic-curve group, which allows for shorter messages. 144 o Over elliptic-curve groups, the standard algorithm can be extended 145 to incorporate the 'cofactor' of the group. This method, called 146 'cofactor Elliptic Curve Diffie-Hellman' [SP800-56A] can prevent 147 certain attacks possible in the elliptic-curve group. 149 o The participants can generate fresh new public/private values 150 (called ephemeral values) for each run of the algorithm, or they 151 can re-use long-term values (called static values). Ephemeral 152 values add randomness to the resulting private value, while static 153 values can be embedded in certificates. The two participants do 154 not need to use the same kind of value: either participant can use 155 either type. In 'ephemeral-static' Diffie-Hellman, for example, 156 the sender uses an ephemeral public/private pair value while the 157 receiver uses a static pair. In 'static-static' Diffie-Hellman, 158 on the other hand, both participants use static pairs. (Receivers 159 cannot use ephemeral values in this setting, and so we ignore 160 ephemeral-ephemeral and static-ephemeral Diffie-Hellman in this 161 document.) 163 Several of these variations are already described in existing CMS 164 standards. [RFC3370] contains the conventions for using for 165 ephemeral-static and static-static Diffie-Hellman over the 'basic' (Z 166 mod p) group. [RFC5753] contains the conventions for using 167 ephemeral-static Diffie-Hellman over elliptic curves (both standard 168 and cofactor methods). It does not, however, contain conventions for 169 using either method of static-static Elliptic-Curve Diffie-Hellman, 170 preferring to discuss the ECMQV algorithm instead. 172 In this document, we specify the conventions for using static-static 173 Elliptic-Curve Diffie-Hellman (ECDH) for both standard and cofactor 174 methods. Our motivation stems from the fact that ECMQV has been 175 removed from the National Security Agency's Suite B of cryptographic 176 algorithms and will therefore be unavailable to some participants. 177 These participants can use ephemeral-static Elliptic Curve Diffie- 178 Hellman, of course, but ephemeral-static Diffie-Hellman does not 179 provide source authentication. CMS does allow the application of 180 digital signatures for source authentication, but this alternative is 181 available only to those participants with certified signature keys. 182 By specifying conventions for static-static Elliptic Curve Diffie- 183 Hellman in this document, we present a third alternative for source- 184 authentication, available to those participants with certified 185 Elliptic Curve Diffie-Hellman keys. 187 We note that like ephemeral-static ECDH, static-static ECDH creates a 188 secret key shared by sender and receiver. Unlike ephemeral-static 189 ECDH, however, static-static ECDH uses a static key pair for the 190 sender. Each of the three CMS structures discussed in this document 191 (EnvelopedData, AuthenticatedData, and AuthEnvelopedData) uses 192 static-static ECDH to achieve different goals: 194 o EnvelopedData uses static-static ECDH to provide data 195 confidentiality. It will not necessarily, however, provide data 196 authenticity. 198 o AuthenticatedData uses static-static ECDH to provide data- 199 authenticity. It will not provide data-confidentiality. 201 o AuthEnvelopedData uses static-static ECDH to provide both of 202 confidentiality and data-authenticity. 204 1.1. Requirements Terminology 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in [RFC2119]. 210 2. EnvelopedData using static-static ECDH 212 If an implementation uses static-static ECDH with CMS EnvelopedData 213 then the following techniques and formats MUST be used. The fields 214 of EnvelopedData are as in [RFC5652]; as static-static ECDH is a key 215 agreement algorithm, the RecipientInfo kari choice is used. When 216 using static-static ECDH, the EnvelopedData originatorInfo field MAY 217 include the certificate(s) for the EC public key(s) used in the 218 formation of the pairwise key. 220 2.1. Fields of the KeyAgreeRecipientInfo 222 When using static-static ECDH with EnvelopedData, the fields of 223 KeyAgreeRecipientInfo [RFC5652] are: 225 o version MUST be 3. 227 o originator identifies the static EC public key of the sender. It 228 MUST be either issuerAndSerialNumber or subjectKeyIdentifier, and 229 point to one of the sending agent's certificates. 231 o ukm MAY be present or absent. However, message originators SHOULD 232 include the ukm and SHOULD ensure that the value of ukm is unique 233 to the message being sent. As specified in [RFC5652], 234 implementations MUST support ukm message recipient processing, so 235 interoperability is not a concern if the ukm is present or absent. 236 The use of a fresh value for ukm will ensure that a different key 237 is generated for each message between the same sender and 238 receiver. ukm, if present, is placed in the entityUInfo field of 239 the ECC-CMS-SharedInfo structure [RFC5753] and therefore used as 240 an input to the key derivation function. 242 o keyEncryptionAlgorithm MUST contain the object identifier of the 243 key encryption algorithm, which in this case is a key agreement 244 algorithm (see Section 5). The parameters field contains 245 KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm 246 identifier that indicates the symmetric encryption algorithm used 247 to encrypt the content-encryption key (CEK) with the key- 248 encryption key (KEK) and any associated parameters (see 249 Section 5). 251 o recipientEncryptedKeys contains an identifier and an encrypted CEK 252 for each recipient. The RecipientEncryptedKey 253 KeyAgreeRecipientIdentifier MUST contain either the 254 issuerAndSerialNumber identifying the recipient's certificate or 255 the RecipientKeyIdentifier containing the subject key identifier 256 from the recipient's certificate. In both cases, the recipient's 257 certificate contains the recipient's static ECDH public key. 258 RecipientEncryptedKey EncryptedKey MUST contain the content- 259 encryption key encrypted with the static-static ECDH-generated 260 pairwise key-encryption key using the algorithm specified by the 261 KeyWrapAlgorithm. 263 2.2. Actions of the sending agent 265 When using static-static ECDH with EnvelopedData, the sending agent 266 first obtains the EC public key(s) and domain parameters contained in 267 the recipient's certificate. It MUST confirm the following at least 268 once per recipient-certificate: 270 o That both certificates (the recipient's certificate and its own) 271 contain public-key values with the same curve parameters, and 273 o That both of these public-key values are marked as appropriate for 274 ECDH (that is, marked with algorithm-identifiers id-ecPublicKey or 275 id-ecDH [RFC5480]). 277 The sender then determines whether to use standard or cofactor 278 Diffie-Hellman. After doing so, the sender then determines which 279 hash algorithms to use for the key-derivation function. It then 280 chooses keyEncryptionAlgorithm that reflects these choices. It then 281 determines: 283 o an integer "keydatalen", which is the KeyWrapAlgorithm symmetric 284 key-size in bits, and 286 o the value of ukm, if used. 288 The sender then determines a bit string "SharedInfo", which is the 289 DER encoding of ECC-CMS-SharedInfo (see Section 7.2 of [RFC5753]). 290 The sending agent then performs either the Elliptic Curve Diffie 291 Hellman operation of [RFC6090] (for standard Diffie-Hellman) or the 292 Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) 293 Primitive of [SP800-56A] (for cofactor Diffie-Hellman). The sending 294 agent then applies the simple hash function construct of [X963] 295 (using the hash algorithm identified in the key agreement algorithm) 296 to the results of the Diffie-Hellman operation and the SharedInfo 297 string. (This construct is also described in Section 3.6.1 of 298 [SEC1].) As a result the sending agent obtains a shared secret bit 299 string "K", which is used as the pairwise key-encryption key (KEK) to 300 wrap the CEK for that recipient, as specified in [RFC5652]. 302 2.3. Actions of the receiving agent 304 When using static-static ECDH with EnvelopedData, the receiving agent 305 retrieves keyEncryptionAlgorithm to determine the key-agreement 306 algorithm chosen by the sender, which will identify: 308 o the domain-parameters of the curve used, 310 o whether standard or cofactor Diffie-Hellman was used, and 312 o which hash-function was used for the KDF. 314 The receiver then retrieves the sender's certificate identified in 315 the rid field, and extracts the EC public key(s) and domain 316 parameters contained therein. It MUST confirm the following at least 317 once per sender-certificate: 319 o That both certificates (the sender's certificate and its own) 320 contain public-key values with the same curve parameters, and 322 o That both of these public-key values are marked as appropriate for 323 ECDH (that is, marked with algorithm-identifiers id-ecPublicKey or 324 id-ecDH [RFC5480]). 326 The receiver then determines whether standard or cofactor Diffie- 327 Hellman was used. The receiver then determines a bit string 328 "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see 329 Section 7.2 of [RFC5753]). The receiving agent then performs either 330 the Elliptic Curve Diffie Hellman operation of [RFC6090] (for 331 standard Diffie-Hellman) or the Elliptic Curve Cryptography Cofactor 332 Diffie-Hellman (ECC CDH) Primitive of [SP800-56A] (for cofactor 333 Diffie-Hellman). The receiving agent then applies the simple hash 334 function construct of [X963] (using the hash algorithm identified in 335 the key agreement algorithm) to the results of the Diffie-Hellman 336 operation and the SharedInfo string. (This construct is also 337 described in Section 3.6.1 of [SEC1].) As a result, the receiving 338 agent obtains a shared secret bit string "K", which it uses as the 339 pairwise key-encryption key to unwrap the CEK. 341 3. AuthenticatedData using static-static ECDH 343 This section describes how to use the static-static ECDH key 344 agreement algorithm with AuthenticatedData. When using static-static 345 ECDH with AuthenticatedData, the fields of AuthenticatedData are as 346 in [RFC5652], but with the following restrictions: 348 o macAlgorithm MUST contain the algorithm identifier of the message 349 authentication code (MAC) algorithm. This algorithm SHOULD be one 350 of the following: id-hmacWITHSHA224, id-hmacWITHSHA256, id- 351 hmacWITHSHA384, or id-hmacWITHSHA512, and SHOULD NOT be hmac-SHA1. 352 (See Section 5.) 354 o digestAlgorithm MUST contain the algorithm identifier of the hash 355 algorithm. This algorithm SHOULD be one of the following: id- 356 sha224, id-sha256, id-sha384, and id-sha512, and SHOULD NOT be id- 357 sha1. (See Section 5.) 359 As static-static ECDH is a key agreement algorithm, the RecipientInfo 360 kari choice is used in the AuthenticatedData. When using static- 361 static ECDH, the AuthenticatedData originatorInfo field MAY include 362 the certificate(s) for the EC public key(s) used in the formation of 363 the pairwise key. 365 3.1. Fields of the KeyAgreeRecipientInfo 367 The AuthenticatedData KeyAgreeRecipientInfo fields are used in the 368 same manner as the fields for the corresponding EnvelopedData 369 KeyAgreeRecipientInfo fields of Section 2.1 of this document. The 370 authentication key is wrapped in the same manner as is described 371 there for the content-encryption key. 373 3.2. Actions of the sending agent 375 The sending agent uses the same actions as for EnvelopedData with 376 static-static ECDH, as specified in Section 2.2 of this document. 378 3.3. Actions of the receiving agent 380 The receiving agent uses the same actions as for EnvelopedData with 381 static-static ECDH, as specified in Section 2.3 of this document. 383 4. AuthEnvelopedData using static-static ECDH 385 When using static-static ECDH with AuthEnvelopedData, the fields of 386 AuthEnvelopedData are as in [RFC5083]. As static-static ECDH is a 387 key agreement algorithm, the RecipientInfo kari choice is used. When 388 using static-static ECDH, the AuthEnvelopedData originatorInfo field 389 MAY include the certificate(s) for the EC public key used in the 390 formation of the pairwise key. 392 4.1. Fields of the KeyAgreeRecipientInfo 394 The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the 395 same manner as the fields for the corresponding EnvelopedData 396 KeyAgreeRecipientInfo fields of Section 2.1 of this document. The 397 content-authenticated-encryption key is wrapped in the same manner as 398 is described there for the content-encryption key. 400 4.2. Actions of the sending agent 402 The sending agent uses the same actions as for EnvelopedData with 403 static-static ECDH, as specified in Section 2.2 of this document. 405 4.3. Actions of the receiving agent 407 The receiving agent uses the same actions as for EnvelopedData with 408 static-static ECDH, as specified in Section 2.3 of this document. 410 5. Comparison to [RFC5753] 412 This document defines the use of static-static ECDH for 413 EnvelopedData, AuthenticatedData, and AuthEnvelopedData. The 414 standard [RFC5753] defines ephemeral-static ECDH for EnvelopedData 415 only. 417 With regard to EnvelopedData, this document and [RFC5753] greatly 418 parallel each other. Both specify how to apply Elliptic-Curve 419 Diffie-Hellman, and differ only on how the sender's public value is 420 to be communicated to the recipient. In [RFC5753], the sender 421 provides the public value explicitly by including an 422 OriginatorPublicKey value in the originator field of 423 KeyAgreeRecipientInfo. In this document, the sender include a 424 reference to a (certified) public value by including either an 425 IssuerAndSerialNumber or SubjectKeyIdentifier value in the same 426 field. Put another way, [RFC5753] provides an interpretation of a 427 KeyAgreeRecipientInfo structure where: 429 o the keyEncryptionAlgorithm value indicates Elliptic-Curve Diffie- 430 Hellman, and 432 o the originator field contains a OriginatorPublicKey value. 434 This document, on the other hand, provides an interpretation of a 435 KeyAgreeRecipientInfo structure where 437 o the keyEncryptionAlgorithm value indicates Elliptic-Curve Diffie- 438 Hellman, and 440 o the originator field contains either a IssuerAndSerialNumber value 441 or a SubjectKeyIdentifier value. 443 AuthenticatedData or AuthEnvelopedData messages, on the other hand, 444 are not given any form of ECDH by [RFC5753]. This is appropriate: 445 that document only defines ephemeral-static Diffie-Hellman, and this 446 form of Diffie-Hellman does not (inherently) provide any form of 447 data-authentication or data-origin authentication. This document, on 448 the other hand, requires that the sender use a certified public 449 value. Thus, this form of key-agreement provides implicit key 450 authentication and, under some limited circumstances, data-origin 451 authentication. (See Section 7.) 453 This document does not define any new ASN.1 structures or algorithm 454 identifiers. It provides new ways to interpret structures from 455 [RFC5652] and [RFC5753], and allows previously-defined algorithms to 456 be used under these new interpretations. Specifically: 458 o The ECDH key-agreement algorithm-identifiers from [RFC5753] define 459 only how Diffie-Hellman values are processed, not where these 460 values are created. Therefore, they can be used for static-static 461 ECDH with no changes. 463 o The key-wrap, MAC, and digest algorithms referenced in [RFC5753] 464 describe how the secret key is to be used, not created. 465 Therefore, they can be used with keys from static-static ECDH 466 without modification. 468 6. Requirements and Recommendations 470 It is RECOMMENDED that implementations of this specification support 471 AuthenticatedData and EnvelopedData. Support for AuthEnvelopedData 472 is OPTIONAL. 474 Implementations that support this specification MUST support standard 475 Elliptic Curve Diffie-Hellman, and these implementation MAY also 476 support cofactor Elliptic Curve Diffie-Hellman. 478 In order to encourage interoperability, implementations SHOULD use 479 the elliptic curve domain parameters specified by [RFC5480]. 481 Implementations that support standard static-static Elliptic Curve 482 Diffie-Hellman: 484 MUST support the dhSinglePass-stdDH-sha256kdf-scheme key agreement 485 algorithm; 487 MAY support the dhSinglePass-stdDH-sha224kdf-scheme, dhSinglePass- 488 stdDH-sha384kdf-scheme and dhSinglePass-stdDH-sha512kdf-scheme key 489 agreement algorithms; and 491 SHOULD NOT support the dhSinglePass-stdDH-sha1kdf-scheme 493 Other algorithms MAY also be supported. 495 Implementations that support cofactor static-static Elliptic-Curve 496 Diffie-Hellman: 498 MUST support the dhSinglePass-cofactorDH-sha256kdf-scheme key 499 agreement algorithm; 501 MAY support the dhSinglePass-cofactorDH-sha224kdf-scheme, 502 dhSinglePass-cofactorDH-sha384kdf-scheme, and dhSinglePass- 503 cofactorDH-sha512kdf-scheme key agreement algorithms; and, 505 SHOULD NOT support the dhSinglePass-cofactorDH-sha1kdf-scheme. 507 In addition, all implementations: 509 MUST support the id-aes128-wrap key wrap algorithm and the id- 510 aes128-cbc content encryption algorithm; 512 MAY support: 514 * The the id-aes192-wrap and id-aes256-wrap key wrap algorithms; 516 * The id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, id-aes128-GCM, 517 id-aes192-GCM, id-aes256-GCM authenticated-encryption 518 algorithms; and 520 * id-aes192-cbc, and id-aes256-cbc content encryption algorithms. 522 SHOULD NOT support the id-alg-CMS3DESwrap key-wrap algorithm or 523 the des-ede3-cbc content encryption algorithms. 525 (All algorithms above defined in [RFC3370], [RFC3565], [RFC5084], and 526 [RFC5753].) Unless otherwise noted above, other algorithms MAY also 527 be supported. 529 7. Security considerations 531 All security considerations in Section 9 of [RFC5753] apply. 533 Extreme care must be used when using static-static Diffie-Hellman 534 (either standard or cofactor) without the use of some per-message 535 value in ukm. As described in [RFC5753], the ukm value (if present) 536 will be embedded in a ECC-CMS-SharedInfo structure and the DER- 537 encoding of this structure will be used as the 'SharedInfo' input to 538 the key-derivation function of [X963]. The purpose of this input is 539 to add a message-unique value to the key-distribution function so 540 that two different sessions of static-static ECDH between a given 541 pair of agents result in independent keys. If the ukm value is not 542 used or is re-used, on the other hand, then the ECC-CMS-SharedInfo 543 structure (and 'SharedInfo' input) will likely not vary from message 544 to message. In this case, the two agents will re-use the same keying 545 material across multiple messages. This is considered to be bad 546 cryptographic practice and may open the sender to attacks on Diffie- 547 Hellman (e.g., the 'small subgroup' attack [MenezesUstaoglu] or 548 other, yet-undiscovered attacks). 550 It is for these reasons that Section 2.1 states that message-senders 551 SHOULD include the ukm and SHOULD ensure that the value of ukm is 552 unique to the message being sent. One way to ensure the uniqueness 553 of ukm is for the message sender to choose a 'sufficiently long' 554 random string for each message (where, as a rule of thumb, a 555 'sufficiently long' string is one at least as long as the keys used 556 by the key-wrap algorithm identified in the keyEncryptionAlgorithm 557 field of the KeyAgreeRecipientInfo structure). However, other 558 methods (such as a counter) are possible. Also, applications which 559 cannot tolerate the inclusion of per-message information in ukm (due 560 to bandwidth requirements, for example) SHOULD NOT use static-static 561 ECDH for a recipient without ascertaining that the recipient knows 562 the private value associated with their certified Diffie-Hellman 563 value. 565 Static-static Diffie-Hellman, when used as described in this 566 document, does not necessarily provide data-origin authentication. 567 Consider, for example, the following sequence of events: 569 o Alice sends an AuthEnvelopedData message to both Bob and Mallory. 570 Furthermore, Alice uses a static-static DH method to transport the 571 content-authenticated-encryption key to Bob, and some arbitrary 572 method to transport the same key to Mallory. 574 o Mallory intercepts the message and prevents Bob from receiving it. 576 o Mallory recovers the content-authenticated-encryption key from the 577 message received from Alice. Mallory then creates new plaintext 578 of her choice, and encrypts it using the same authenticated- 579 encryption algorithm and the same content-authenticated-encryption 580 key used by Alice. 582 o Mallory then replaces the EncryptedContentInfo and 583 MessageAuthenticationCode fields of Alice's message with the 584 values Mallory just generated. She may additionally remove her 585 RecipientInfo value from Alice's message. 587 o Mallory sends the modified message to Bob. 589 o Bob receives the message, validates the static-static DH works and 590 decrypts/authenticates the message. 592 At this point, Bob has received and validated a message that appears 593 to have been sent by Alice, but whose content was chosen by Mallory. 594 Mallory may not even be an apparent receiver of the modified message. 595 Thus, this use of static-static Diffie-Hellman does not necessarily 596 provide data-origin authentication. (We note that this example does 597 not also contradict either confidentiality or data-authentication: 598 Alice's message was not received by anyone not intended by Alice, and 599 Mallory's message was not modified before reaching Bob.) 601 More generally, data-origin may not be authenticated unless 602 o It is a priori guaranteed that the message in question was sent to 603 exactly one recipient, or 605 o Data-origin authentication is provided by some other mechanism 606 (such as digital signatures). 608 However, we also note that this lack of authentication is not a 609 product of static-static ECDH, per se, but is inherent in the way 610 key-agreement schemes are used in the AuthenticatedData and 611 AuthEnvelopedData structures of CMS. 613 8. IANA Considerations 615 There are no IANA considerations. 617 9. Acknowledgements 619 The authors would like to thank Jim Schaad, Russ Housley, Sean 620 Turner, Brian Weis, Rene Struik, Brian Carpenter, David McGrew and 621 Stephen Farrell for their helpful comments and suggestions. We would 622 also like to thank Jim Schaad for describing to us the attack 623 described in Section 7. 625 10. References 627 10.1. Normative References 629 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", RFC 2119, March 1997. 632 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 633 Algorithms", RFC 3370, August 2002. 635 [RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) 636 Encryption Algorithm in Cryptographic Message Syntax 637 (CMS)", RFC 3565, July 2003. 639 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 640 Authenticated-Enveloped-Data Content Type", RFC 5083, 641 November 2007. 643 [RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated 644 Encryption in the Cryptographic Message Syntax (CMS)", 645 RFC 5084, November 2007. 647 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 648 "Elliptic Curve Cryptography Subject Public Key 649 Information", RFC 5480, March 2009. 651 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 652 RFC 5652, September 2009. 654 [RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve 655 Cryptography (ECC) Algorithms in Cryptographic Message 656 Syntax (CMS)", RFC 5753, January 2010. 658 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 659 Curve Cryptography Algorithms", RFC 6090, February 2011. 661 [SP800-56A] 662 Barker, E., Johnson, D., and M. Smid, "Recommendation for 663 Pair-Wise Key Establishment Schemes Using Discrete 664 Logarithm Cryptography (Revised)", NIST Special 665 Publication (SP) 800-56A, March 2007. 667 [X963] "Public Key Cryptography for the Financial Services 668 Industry, Key Agreement and Key Transport Using Elliptic 669 Curve Cryptography", ANSI X9.63, 2001. 671 10.2. Informative References 673 [MenezesUstaoglu] 674 Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys in 675 Diffie-Hellman Key Agreement Protocols". 677 International Journal of Applied Cryptography, Vol. 2, No. 678 2, pp. 154-158, 2010. 680 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 681 RFC 2631, June 1999. 683 [SEC1] Standards for Efficient Cryptography Group (SECG), "SEC 1: 684 Elliptic Curve Cryptography", Version 2.0, May 2009. 686 [X.680] ITU-T, "Information Technology - Abstract Syntax Notation 687 One", Recommendation X.680, ISO/IEC 8824-1:2002, 2002. 689 [X.681] ITU-T, "Information Technology - Abstract Syntax Notation 690 One: Information Object Specification", 691 Recommendation X.681, ISO/IEC 8824-2:2002, 2002. 693 [X.682] ITU-T, "Information Technology - Abstract Syntax Notation 694 One: Constraint Specification", Recommendation X.682, ISO/ 695 IEC 8824-3:2002, 2002. 697 [X.683] ITU-T, "Information Technology - Abstract Syntax Notation 698 One: Parameterization of ASN.1 Specifications", 699 Recommendation X.683, ISO/IEC 8824-4:2002, 2002. 701 Authors' Addresses 703 Jonathan C. Herzog 704 MIT Lincoln Laboratory 705 244 Wood St. 706 Lexington, MA 02144 707 USA 709 Email: jherzog@ll.mit.edu 711 Roger Khazan 712 MIT Lincoln Laboratory 713 244 Wood St. 714 Lexington, MA 02144 715 USA 717 Email: rkh@ll.mit.edu