idnits 2.17.1 draft-herzog-static-ecdh-05.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 (February 23, 2011) is 4811 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: August 27, 2011 February 23, 2011 7 Use of static-static Elliptic-Curve Diffie-Hellman key agreement in 8 Cryptographic Message Syntax 9 draft-herzog-static-ecdh-05 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 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). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on August 27, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Terminology . . . . . . . . . . . . . . . . . 5 61 2. EnvelopedData using static-static ECDH . . . . . . . . . . . . 5 62 2.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 5 63 2.2. Actions of the sending agent . . . . . . . . . . . . . . . 6 64 2.3. Actions of the receiving agent . . . . . . . . . . . . . . 7 65 3. AuthenticatedData using static-static ECDH . . . . . . . . . . 8 66 3.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 8 67 3.2. Actions of the sending agent . . . . . . . . . . . . . . . 8 68 3.3. Actions of the receiving agent . . . . . . . . . . . . . . 8 69 4. AuthEnvelopedData using static-static ECDH . . . . . . . . . . 8 70 4.1. Fields of the KeyAgreeRecipientInfo . . . . . . . . . . . 9 71 4.2. Actions of the sending agent . . . . . . . . . . . . . . . 9 72 4.3. Actions of the receiving agent . . . . . . . . . . . . . . 9 73 5. Comparison to [CMS-ECC] . . . . . . . . . . . . . . . . . . . 9 74 6. Requirements and Recommendations . . . . . . . . . . . . . . . 10 75 7. Security considerations . . . . . . . . . . . . . . . . . . . 11 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 This document describes how to use the static-static Elliptic-Curve 86 Diffie-Hellman key agreement scheme [SEC1] in the Cryptographic 87 Message Syntax (CMS) [CMS]. The CMS is a standard notation and 88 representation for cryptographic messages. CMS uses ASN.1 notation 89 [X.680] [X.681] [X.682] [X.683] to define a number of structures that 90 carry both cryptographically-protected information and key-management 91 information regarding the keys used. Of particular interest here are 92 three structures: 94 o EnvelopedData, which holds encrypted (but not necessarily 95 authenticated) information [CMS], 97 o AuthenticatedData, which holds authenticated (MACed) information 98 [CMS], and 100 o AuthEnvelopedData, which holds information protected by 101 authenticated encryption: a cryptographic scheme that combines 102 encryption and authentication [CMS-AUTHENV]. 104 All three of these types share the same basic structure. First, a 105 fresh symmetric key is generated. This symmetric key has a different 106 name that reflects its usage in each of the three structures. 107 EnvelopedData uses a content-encryption key (CEK); AuthenticatedData 108 uses an authentication key; AuthEnvelopedData uses a content- 109 authenticated-encryption key. The originator uses the symmetric key 110 to cryptographically protect the content. The symmetric key is then 111 used wrapped for each recipient; only the intended recipient has 112 access to the private keying material necessary to unwrap the 113 symmetric key. Once unwrapped, the recipient uses the symmetric key 114 to decrypt the content, check the integrity of the content, or both. 115 The CMS supports several different approaches to symmetric key 116 wrapping, including: 118 o key transport: the symmetric key is encrypted using the public 119 encryption key of some recipient, 121 o key-encryption key: the symmetric key is encrypted using a 122 previously-distributed symmetric key, and 124 o key agreement: the symmetric key is encrypted using a key- 125 encryption key (KEK) created using a key-agreement scheme and a 126 key-derivation function (KDF). 128 One such key-agreement scheme is the Diffie-Hellman algorithm [DH] 129 which uses group-theory to produce a value known only to its two 130 participants. In this case, the participants are the originator and 131 one of the recipients. Each participant produces a private value and 132 a public value, and each participant can produce the shared secret 133 value from their own private value and their counterpart's public 134 value. There are some variations on the basic algorithm: 136 o The basic algorithm typically uses the group 'Z mod p', meaning 137 the set of integers modulo some prime p. One can also use an 138 elliptic-curve group, which allows for shorter messages. 140 o Over elliptic-curve groups, the standard algorithm can be extended 141 to incorporate the 'cofactor' of the group (see [SEC1] for more 142 details). This method, called 'cofactor Elliptic Curve Diffie- 143 Hellman', can prevent certain attacks possible in the elliptic- 144 curve group. 146 o The participants can generate fresh new public/private values 147 (called ephemeral values) for each run of the algorithm, or they 148 can re-use long-term values (called static values). Ephemeral 149 values add randomness to the resulting private value, while static 150 values can be embedded in certificates. The two participants do 151 not need to use the same kind of value: either participant can use 152 either type. In 'ephemeral-static' Diffie-Hellman, for example, 153 the sender uses an ephemeral public/private pair value while the 154 receiver uses a static pair. In 'static-static' Diffie-Hellman, 155 on the other hand, both participants use static pairs. (Receivers 156 cannot use ephemeral values in this setting, and so we ignore 157 ephemeral-ephemeral and static-ephemeral Diffie-Hellman in this 158 document.) 160 Several of these variations are already described in existing CMS 161 standards. [CMS-ALG] contains the conventions for using for 162 ephemeral-static and static-static Diffie-Hellman over the 'basic' (Z 163 mod p) group. [CMS-ECC] contains the conventions for using 164 ephemeral-static Diffie-Hellman over elliptic curves (both standard 165 and cofactor methods). It does not, however, contain conventions for 166 using either method of static-static Elliptic-Curve Diffie-Hellman, 167 preferring to discuss the ECMQV algorithm instead. 169 In this document, we specify the conventions for using static-static 170 Elliptic-Curve Diffie-Hellman (ECDH) for both standard and cofactor 171 methods. Our motivations are three-fold: 173 1. Intellectual-property concerns have hindered market adoptation of 174 the ECMQV algorithm, 176 2. ECMQV has been removed from the National Security Agency's Suite 177 B of cryptographic algorithms, and 179 3. ECMQV requires the sender to create a fresh random value for each 180 recipient. While the incorporation of per-session randomness is 181 good cryptographic practice, ECMQV fixes the size of this 182 randomness: that of one elliptic-curve point. For low-bandwidth 183 networks, it may be necessary to use smaller amounts of per- 184 recipient randomness. 186 We note that like ephemeral-static ECDH, static-static ECDH creates a 187 secret key shared by sender and receiver. Unlike ephemeral-static 188 ECDH, however, static-static ECDH uses a static key pair for the 189 sender. Each of the three CMS structures discussed in this document 190 (EnvelopedData, AuthenticatedData, and AuthEnvelopedData) uses 191 static-static ECDH to achieve different goals: 193 o EnvelopedData uses static-static ECDH to provide data 194 confidentiality. It will not necessarily, however, provide data 195 integrity. 197 o AuthenticatedData uses static-static ECDH to provide data- 198 integrity. It will not provide data-confidentiality. 200 o AuthEnvelopedData uses static-static ECDH to provide both of 201 confidentiality and data-integrity. 203 1.1. Requirements Terminology 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in [MUST]. 209 2. EnvelopedData using static-static ECDH 211 If an implementation uses static-static ECDH with CMS EnvelopedData 212 then the following techniques and formats MUST be used. The fields 213 of EnvelopedData are as in [CMS]; as static-static ECDH is a key 214 agreement algorithm, the RecipientInfo kari choice is used. When 215 using static-static ECDH, the EnvelopedData originatorInfo field MAY 216 include the certificate(s) for the EC public key(s) used in the 217 formation of the pairwise key. 219 2.1. Fields of the KeyAgreeRecipientInfo 221 When using static-static ECDH with EnvelopedData, the fields of 222 KeyAgreeRecipientInfo [CMS] are: 224 o version MUST be 3. 226 o originator identifies the static EC public key of the sender. It 227 MUST be either issuerAndSerialNumber or subjectKeyIdentifier, and 228 point to one of the sending agent's certificates. 230 o ukm MAY be present or absent. However, message originators SHOULD 231 include the ukm. As specified in [CMS], implementations MUST 232 support ukm message recipient processing, so interoperability is 233 not a concern if the ukm is present or absent. The use of a fresh 234 value for ukm will ensure that a different key is generated for 235 each message between the same sender and receiver. ukm, if 236 present, is placed in the entityUInfo field of the ECC-CMS- 237 SharedInfo structure [CMS-ECC] and therefore used as an input to 238 the key derivation function. 240 o keyEncryptionAlgorithm MUST contain the object identifier of the 241 key encryption algorithm, which in this case is a key agreement 242 algorithm (see Section 5). The parameters field contains 243 KeyWrapAlgorithm. The KeyWrapAlgorithm is the algorithm 244 identifier that indicates the symmetric encryption algorithm used 245 to encrypt the content-encryption key (CEK) with the key- 246 encryption key (KEK) and any associated parameters (see 247 Section 5). 249 o recipientEncryptedKeys contains an identifier and an encrypted CEK 250 for each recipient. The RecipientEncryptedKey 251 KeyAgreeRecipientIdentifier MUST contain either the 252 issuerAndSerialNumber identifying the recipient's certificate or 253 the RecipientKeyIdentifier containing the subject key identifier 254 from the recipient's certificate. In both cases, the recipient's 255 certificate contains the recipient's static ECDH public key. 256 RecipientEncryptedKey EncryptedKey MUST contain the content- 257 encryption key encrypted with the static-static ECDH-generated 258 pairwise key-encryption key using the algorithm specified by the 259 KeyWrapAlgorithm. 261 2.2. Actions of the sending agent 263 When using static-static ECDH with EnvelopedData, the sending agent 264 first obtains the recipient's EC public key and domain parameters 265 (e.g. from the recipient's certificate). It confirms that both 266 certificates contain public-key values with the same curve 267 parameters, and that both of these public-key values are marked as 268 appropriate for ECDH (that is, marked with algorithm-identifiers id- 269 ecPublicKey or id-ecDH [PKI-ECC]). The sender then determines: 271 o whether to use standard or cofactor Diffie-Hellman, and 272 o which hash algorithms to use for the key-derivation function. 274 The sender then chooses keyEncryptionAlgorithm that reflects these 275 choices. It then determines: 277 o an integer "keydatalen", which is the KeyWrapAlgorithm symmetric 278 key-size in bits, and 280 o the value of ukm, if used. 282 The sender then determines a bit string "SharedInfo", which is the 283 DER encoding of ECC-CMS-SharedInfo (see Section 7.2 of [CMS-ECC]). 284 The sending agent then performs the key agreement operation of the 285 Elliptic Curve Diffie-Hellman Scheme specified in [SEC1] and the KDF 286 defined in Section 3.6.1 of [SEC1] with the hash algorithm identified 287 in the key agreement algorithm. As a result the sending agent 288 obtains a shared secret bit string "K", which is used as the pairwise 289 key-encryption key (KEK) to wrap the CEK for that recipient, as 290 specified in [CMS]. 292 2.3. Actions of the receiving agent 294 When using static-static ECDH with EnvelopedData, the receiving agent 295 retrieves keyEncryptionAlgorithm to determine the key-agreement 296 algorithm chosen by the sender, which will identify: 298 o the domain-parameters of the curve used, 300 o whether standard or cofactor Diffie-Hellman was used, and 302 o which hash-function was used for the KDF. 304 The receiver then retrieves the static EC public key identified in 305 the rid field. It confirms that both certificates contain public-key 306 values associated with the curve identified by the 307 keyEncryptionAlgorithm, and that both of these public-key values are 308 marked as appropriate for ECDH (that is, marked with algorithm- 309 identifiers id-ecPublicKey or id-ecDH [PKI-ECC]). The receiver then 310 determines a bit string "SharedInfo", which is the DER encoding of 311 ECC-CMS-SharedInfo (see Section 7.2 of [CMS-ECC]) and performs the 312 key agreement operation of the Elliptic Curve Diffie-Hellman Scheme 313 specified in [SEC1]; in either case, use the KDF defined in Section 314 3.6.1 of [SEC1]. As a result, the receiving agent obtains a shared 315 secret bit string "K", which it uses as the pairwise key-encryption 316 key to unwrap the CEK. 318 3. AuthenticatedData using static-static ECDH 320 This section describes how to use the static-static ECDH key 321 agreement algorithm with AuthenticatedData. When using static-static 322 ECDH with AuthenticatedData, the fields of AuthenticatedData are as 323 in [CMS], but with the following restrictions: 325 o macAlgorithm MUST contain the algorithm identifier of the message 326 authentication code (MAC) algorithm which MUST be one of the 327 following: hmac-SHA1, id-hmacWITHSHA224, id- hmacWITHSHA256, id- 328 hmacWITHSHA384, or id-hmacWITHSHA512. (See Section 5.) 330 o digestAlgorithm MUST contain the algorithm identifier of the hash 331 algorithm which MUST be one of the following: id-sha1, id-sha224, 332 id-sha256, id-sha384, and id-sha512. (See Section 5.) 334 As static-static ECDH is a key agreement algorithm, the RecipientInfo 335 kari choice is used in the AuthenticatedData. When using static- 336 static ECDH, the AuthenticatedData originatorInfo field MAY include 337 the certificate(s) for the EC public key(s) used in the formation of 338 the pairwise key. 340 3.1. Fields of the KeyAgreeRecipientInfo 342 The AuthenticatedData KeyAgreeRecipientInfo fields are used in the 343 same manner as the fields for the corresponding EnvelopedData 344 KeyAgreeRecipientInfo fields of Section 2.1 of this document. The 345 authentication key is wrapped in the same manner as is described 346 there for the content-encryption key. 348 3.2. Actions of the sending agent 350 The sending agent uses the same actions as for EnvelopedData with 351 static-static ECDH, as specified in Section 2.2 of this document. 353 3.3. Actions of the receiving agent 355 The receiving agent uses the same actions as for EnvelopedData with 356 static-static ECDH, as specified in Section 2.3 of this document. 358 4. AuthEnvelopedData using static-static ECDH 360 When using static-static ECDH with AuthEnvelopedData, the fields of 361 AuthEnvelopedData are as in [CMS-AUTHENV]. As static-static ECDH is 362 a key agreement algorithm, the RecipientInfo kari choice is used. 363 When using static-static ECDH, the AuthEnvelopedData originatorInfo 364 field MAY include the certificate(s) for the EC public key used in 365 the formation of the pairwise key. 367 4.1. Fields of the KeyAgreeRecipientInfo 369 The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the 370 same manner as the fields for the corresponding EnvelopedData 371 KeyAgreeRecipientInfo fields of Section 2.1 of this document. The 372 content-authenticated-encryption key is wrapped in the same manner as 373 is described there for the content-encryption key. 375 4.2. Actions of the sending agent 377 The sending agent uses the same actions as for EnvelopedData with 378 static-static ECDH, as specified in Section 2.2 of this document. 380 4.3. Actions of the receiving agent 382 The receiving agent uses the same actions as for EnvelopedData with 383 static-static ECDH, as specified in Section 2.3 of this document. 385 5. Comparison to [CMS-ECC] 387 This document defines the use of static-static ECDH for 388 EnvelopedData, AuthenticatedData, and AuthEnvelopedData. The 389 standard [CMS-ECC] defines ephemeral-static ECDH for EnvelopedData 390 only. 392 With regard to EnvelopedData, this document and [CMS-ECC] greatly 393 parallel each other. Both specify how to apply Elliptic-Curve 394 Diffie-Hellman, and differ only on how the sender's public value is 395 to be communicated to the recipient. In [CMS-ECC], the sender 396 provides the public value explicitly by including an 397 OriginatorPublicKey value in the originator field of 398 KeyAgreeRecipientInfo. In this document, the sender include a 399 reference to a (certified) public value by including either an 400 IssuerAndSerialNumber or SubjectKeyIdentifier value in the same 401 field. Put another way, [CMS-ECC] provides an interpretation of a 402 KeyAgreeRecipientInfo structure where: 404 o the keyEncryptionAlgorithm value indicates Elliptic-Curve Diffie- 405 Hellman, and 407 o the originator field contains a OriginatorPublicKey value. 409 This document, on the other hand, provides an interpretation of a 410 KeyAgreeRecipientInfo structure where 411 o the keyEncryptionAlgorithm value indicates Elliptic-Curve Diffie- 412 Hellman, and 414 o the originator field contains either a IssuerAndSerialNumber value 415 or a SubjectKeyIdentifier value. 417 AuthenticatedData or AuthEnvelopedData messages, on the other hand, 418 are not given any form of ECDH by [CMS-ECC]. This is appropriate: 419 that document only defines ephemeral-static Diffie-Hellman, and this 420 form of Diffie-Hellman does not (inherently) provide any form of 421 data-authentication or data-origin authentication. This document, on 422 the other hand, requires that the sender use a certified public 423 value. Thus, this form of key-agreement provides implicit key 424 authentication and, under some limited circumstances, data-origin 425 authentication. (See Section 7.) 427 This document does not define any new ASN.1 structures or algorithm 428 identifiers. It provides new ways to interpret structures from [CMS] 429 and [CMS-ECC], and allows previously-defined algorithms to be used 430 under these new interpretations. Specifically: 432 o The ECDH key-agreement algorithm-identifiers from [CMS-ECC] define 433 only how Diffie-Hellman values are processed, not where these 434 values are created. Therefore, they can be used for static-static 435 ECDH with no changes. 437 o The key-wrap, MAC, and digest algorithms referenced in [CMS-ECC] 438 describe how the secret key is to be used, not created. 439 Therefore, they can be used with keys from static-static ECDH 440 without modification. 442 6. Requirements and Recommendations 444 It is RECOMMENDED that implementations of this specification support 445 AuthenticatedData and EnvelopedData. Support for AuthEnvelopedData 446 is OPTIONAL. 448 Implementations that support this specification MUST support standard 449 Elliptic Curve Diffie-Hellman, and these implementation MAY also 450 support cofactor Elliptic Curve Diffie-Hellman. 452 In order to encourage interoperability, implementations SHOULD use 453 the elliptic curve domain parameters specified by [PKI-ECC]. 455 Implementations that support standard static-static Elliptic Curve 456 Diffie-Hellman: 458 MUST support the dhSinglePass-stdDH-sha256kdf-scheme key agreement 459 algorithm, the id-aes128-wrap key wrap algorithm, and the id- 460 aes128-cbc content encryption algorithm; and, 462 MAY support the dhSinglePass-stdDH-sha1kdf-scheme, dhSinglePass- 463 stdDH-sha224kdf-scheme, dhSinglePass-stdDH-sha384kdf-scheme and 464 dhSinglePass-stdDH-sha512kdf-scheme key agreement algorithms, the 465 id-alg-CMS3DESwrap, id-aes192-wrap, and id-aes256-wrap key wrap 466 algorithms and the des-ede3-cbc, id-aes192-cbc, and id-aes256-cbc 467 content encryption algorithms; other algorithms MAY also be 468 supported. 470 Implementations that support cofactor static-static Elliptic-Curve 471 Diffie-Hellman: 473 MUST support the dhSinglePass-cofactorDH-sha256kdf-scheme key 474 agreement algorithm, the id-aes128-wrap key wrap algorithm, and 475 the id-aes128-cbc content encryption algorithm; and, 477 MAY support the dhSinglePass-cofactorDH-sha1kdf-scheme, 478 dhSinglePass-cofactorDH-sha224kdf-scheme, dhSinglePass- 479 cofactorDH-sha384kdf-scheme, and dhSinglePass-cofactorDH- 480 sha512kdf-scheme key agreement, the id-alg-CMS3DESwrap, id- 481 aes192-wrap, and id-aes256-wrap key wrap algorithms and the des- 482 ede3-cbc, id-aes192-cbc, and id-aes256-cbc content encryption 483 algorithms; other algorithms MAY also be supported. 485 7. Security considerations 487 All security considerations in Section 9 of [CMS-ECC] apply. 489 Extreme care must be used when using static-static Diffie-Hellman 490 (either standard or cofactor) without the use of some per-message 491 value in ukm. If no message-specific information is used (such as a 492 counter value, or a fresh random string) then the resulting secret 493 key could be used in more than one message. Under some 494 circumstances, this will open the sender to the 'small subgroup' 495 attack [MenezesUstaoglu] or other, yet-undiscovered attacks on re- 496 used Diffie-Hellman keys. Applications that cannot tolerate the 497 inclusion of per-message information in ukm (due to bandwidth 498 requirements, for example) SHOULD NOT use static-static ECDH for a 499 recipient without ascertaining that the recipient knows the private 500 value associated with their certified Diffie-Hellman value. Static- 501 static Diffie-Hellman, when used as described in this document, does 502 not necessarily provide data-origin authentication. Consder, for 503 example, the following sequence of events: 505 o Alice sends an AuthEnvelopedData message to both Bob and Mallory. 506 Furthermore, Alice uses a static-static DH method to transport the 507 content-authenticated-encryption key to Bob, and some arbitrary 508 method to transport the same key to Mallory. 510 o Mallory intercepts the message and prevents Bob from receiving it. 512 o Mallory recovers the content-authenticated-encryption key from the 513 message received from Alice. Mallory then creates new plaintext 514 of her choice, and encrypts it using the same authenticated- 515 encryption algorithm and the same content-authenticated-encryption 516 key used by Alice. 518 o Mallory then replaces the EncryptedContentInfo and 519 MessageAuthenticationCode fields of Alice's message with the 520 values Mallory just generated. She may additionally remove her 521 RecipientInfo value from Alice's message. 523 o Mallory sends the modified message to Bob. 525 o Bob receives the message, validates the static-static DH works and 526 decrypts/authenticates the message. 528 At this point, Bob has received and validated a message that appears 529 to have been sent by Alice, but whose content was chosen by Mallory. 530 Mallory may not even be an apparent reciever of the modified message. 531 Thus, this use of static-static Diffie-Hellman does not necessarily 532 provide data-origin authentication. (We note that this example does 533 not also contradict either confidentiality or data-authentication: 534 Alice's message was not received by anyone not intended by Alice, and 535 Mallory's message was not modified before reaching Bob.) More 536 generally, data-origin may not be authenticated unless 538 o It is a priori guaranteed that the message in question was sent to 539 exactly one recipient, or 541 o Data-origin authentication is provided by some other mechanism 542 (such as digital signatures). 544 8. IANA Considerations 546 There are no IANA considerations. 548 9. Acknowledgements 550 The authors would like to thank Jim Schaad, Russ Housley, and Sean 551 Turner for their helpful comments and suggestions. We would also 552 like to thank Jim Schaad for describing to us the attack described in 553 Section 7. 555 10. References 557 10.1. Normative References 559 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 560 RFC 5652, September 2009. 562 [CMS-AUTHENV] 563 Housley, R., "Cryptographic Message Syntax (CMS) 564 Authenticated-Enveloped-Data Content Type", RFC 5083, 565 November 2007. 567 [CMS-ECC] Turner, S. and D. Brown, "Use of Elliptic Curve 568 Cryptography (ECC) Algorithms in Cryptographic Message 569 Syntax (CMS)", RFC 5753, January 2010. 571 [MUST] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", RFC 2119, March 1997. 574 [PKI-ECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 575 "Elliptic Curve Cryptography Subject Public Key 576 Information", RFC 5480, March 2009. 578 [SEC1] Standards for Efficient Cryptography Group (SECG), "SEC 1: 579 Elliptic Curve Cryptography", Version 2.0, May 2009. 581 10.2. Informative References 583 [CMS-ALG] Housley, R., "Cryptographic Message Syntax (CMS) 584 Algorithms", RFC 3370, August 2002. 586 [DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", 587 RFC 2631, June 1999. 589 [MenezesUstaoglu] 590 Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys in 591 Diffie-Hellman Key Agreement Protocols". 593 International Journal of Applied Cryptography, to appear. 595 [X.680] ITU-T, "Information Technology - Abstract Syntax Notation 596 One", Recommendation X.680, ISO/IEC 8824-1:2002, 2002. 598 [X.681] ITU-T, "Information Technology - Abstract Syntax Notation 599 One: Information Object Specifcation", 600 Recommendation X.681, ISO/IEC 8824-2:2002, 2002. 602 [X.682] ITU-T, "Information Technology - Abstract Syntax Notation 603 One: Constraint Specification", Recommendation X.682, ISO/ 604 IEC 8824-3:2002, 2002. 606 [X.683] ITU-T, "Information Technology - Abstract Syntax Notation 607 One: Parameterization of ASN.1 Specifications", 608 Recommendation X.683, ISO/IEC 8824-4:2002, 2002. 610 Authors' Addresses 612 Jonathan C. Herzog 613 MIT Lincoln Laboratory 614 244 Wood St. 615 Lexington, MA 02144 616 USA 618 Email: jherzog@ll.mit.edu 620 Roger Khazan 621 MIT Lincoln Laboratory 622 244 Wood St. 623 Lexington, MA 02144 624 USA 626 Email: rkh@ll.mit.edu