idnits 2.17.1 draft-ietf-smime-x942-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** 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 122: '... pubInfo [2] OCTET STRING OPTIONAL,...' RFC 2119 keyword, line 141: '... in Static-Static mode, but MAY appear...' RFC 2119 keyword, line 167: '...lowing algorithm MAY be used to valida...' RFC 2119 keyword, line 256: '...p). To comply with this draft, m MUST...' RFC 2119 keyword, line 257: '...quently, q and x MUST each be at least...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DH76' is mentioned on line 40, but not defined == Missing Reference: 'RFC2119' is mentioned on line 59, but not defined -- Looks like a reference, but probably isn't: '2' on line 122 == Missing Reference: 'DSS' is mentioned on line 251, but not defined == Missing Reference: 'X930' is mentioned on line 252, but not defined == Unused Reference: 'CMS' is defined on line 307, but no explicit reference was found in the text == Unused Reference: 'FIPS-46-1' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'FIPS-81' is defined on line 313, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-smime-cms-07 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-81' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-186' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX' -- Possible downref: Non-RFC (?) normative reference: ref. 'LAW98' -- Possible downref: Non-RFC (?) normative reference: ref. 'X942' Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 E. Rescorla 3 INTERNET-DRAFT RTFM Inc. 4 November 1998 (Expires May 1999) 6 Diffie-Hellman Key Agreement Method 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 This document standardizes one particular Diffie-Hellman variant, 29 based on the ANSI X9.42 standard, developed by the ANSI X9F1 working 30 group. Diffie-Hellam is a key agreement algorithm used by two parties 31 to agree on a shared secret. An algorithm for converting the shared 32 secret into an arbitrary amount of keying material is provided. The 33 resulting keying material is used as a symmetric encryption key. The 34 D-H variant described requires the recipient to have a certificate, 35 but the originator may have a static key pair (with the public key 36 placed in a certificate) or an ephemeral key pair. 38 1. Introduction 40 In [DH76] Diffie and Hellman describe a means for two parties to 41 agree upon a shared secret in such a way that the secret will be una- 42 vailable to eavesdroppers. This secret may then be converted into 43 cryptographic keying material for other (symmetric) algorithms. A 44 large number of minor variants of this process exist. This document 45 describes one such variant, based on the ANSI X9.42 specification. 47 1.1. Discussion of this Draft 49 This draft is being discussed on the "ietf-smime" mailing list. To 50 join the list, send a message to with 51 the single word "subscribe" in the body of the message. Also, there 52 is a Web site for the mailing list at . 55 1.2. Requirements Terminology 57 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 58 "MAY" that appear in this document are to be interpreted as described 59 in [RFC2119]. 61 2. Overview Of Method 63 Diffie-Hellman key agreement requires that both the sender and reci- 64 pient of a message have key pairs. By combining one's private key and 65 the other party's public key, both parties can compute the same 66 shared secret number. This number can then be converted into crypto- 67 graphic keying material. That keying material is typically used as a 68 key encryption key (KEK) to encrypt (wrap) a content encryption key 69 (CEK) which is in turn used to encrypt the message data. 71 2.1. Key Agreement 73 The first stage of the key agreement process is to compute a shared 74 secret number, called ZZ. When the same originator and recipient 75 public/private key pairs are used, the same ZZ value will result. 76 The ZZ value is then converted into a shared symmetric cryptographic 77 key. When the originator employs a static private/public key pair, 78 the introduction of public random values are used to ensure that the 79 resulting symmetric key will be different for each key agreement. 81 2.1.1. Generation of ZZ 83 X9.42 defines that the shared secret ZZ is generated as follows: 85 ZZ = g ^ (xb * xa) (mod p) 87 Note that the individual parties actually perform the computations: 89 ZZ = yb ^ xa (mod p) = ya ^ xb (mod p) 91 where ^ denotes exponentiation 92 ya is party a's public key; ya = g ^ xa (mod p) 93 yb is party b's public key; yb = g ^ xb (mod p) 94 xa is party a's private key 95 xb is party b's private key 96 p is a large prime 97 g is a generator for the integer group specified by p. 98 j a large integer such that 99 q is a large prime and p=qj + 1 100 (See Section 2.2 for criteria for keys and parameters) 102 In CMS, the recipient's key is identified by the CMS RecipientIden- 103 tifier, which points to the recipient's certificate. The sender's 104 key is identified using the OriginatorIdentifierOrKey field, either 105 by reference to the sender's certificate or by inline inclusion of a 106 key. 108 2.1.2. Generation of Keying Material 110 X9.42 provides an algorithm for generating an essentially arbitrary 111 amount of keying material from ZZ. Our algorithm is derived from that 112 algorithm by mandating some optional fields and omitting others. 114 KM = H ( ZZ || OtherInfo) 116 H is the message digest function SHA-1 [FIPS-180] 117 ZZ is the shared key computed in Section 2.1.1 118 OtherInfo is the DER encoding of the following structure: 120 OtherInfo ::= SEQUENCE { 121 keyInfo KeySpecificInfo, 122 pubInfo [2] OCTET STRING OPTIONAL, 123 } 125 KeySpecificInfo ::= SEQUENCE { 126 algorithm OBJECT IDENTIFIER, 127 counter OCTET STRING SIZE (4..4) } 129 algorithm is the ASN.1 algorithm OID of the symmetric algorithm with which 130 this KEK will be used. 131 counter is a 32 bit number, represented in network byte order. 132 Its initial value is 1, i.e. the byte sequence 00 00 00 01 (hex) 133 pubInfo is a random string provided by the sender. In CMS, it is provided 134 as a parameter in the UserKeyingMaterial field (a 512 bit value represented 135 as an OCTET STRING). 137 Note that the only source of secret entropy in this computation is 138 ZZ, so the security of this data is limited to the size of ZZ, even 139 if more data than ZZ is generated. However, if pubInfo is different 140 for each message, a different KEK will be generated for each message. 141 Note that pubInfo is required in Static-Static mode, but MAY appear 142 in Ephemeral-Static mode. 144 2.1.3. KEK Computation 146 Each key encryption algorithm requires a specific size key (n). The 147 KEK is generated by mapping the left n-most bytes of KM onto the key. 148 For 3DES, which requires 192 bits of keying material, the algorithm 149 must be run twice, once with a counter value of 1 (to generate K1', 150 K2', and the first 32 bits of K3') and once with a counter value of 2 151 (to generate the last 32 bits of K3). K1',K2' and K3' are then parity 152 adjusted to generate the 3 DES keys K1,K2 and K3. For RC2, which 153 requires 128 bits of keying material, the algorithm is run once, with 154 a counter value of 1, and the left-most 128 bits are directly con- 155 verted to an RC2 key. 157 2.1.4. Keylengths for common algorithms 159 Some common key encryption algorithms have KEKs of the following 160 lengths. 162 3DES-EDE-ECB 192 bits 163 RC2 (all) 128 bits 165 2.1.5. Public Key Validation 167 The following algorithm MAY be used to validate received public keys. 169 1. Verify that y lies within the interval [2,p-1]. If it does not, 170 the key is invalid. 171 2. Compute y^q (mod p). If the result == 1, the key is valid. 172 Otherwise the key is invalid. 174 The primary purpose of public key validation is to prevent a small 175 subgroup attack [LAW98] on the sender's key pair. If Ephemeral-Static 176 mode is used, this check may not be necessary. 178 Note that this procedure may be subject to pending patents. 180 2.1.6. Example 1 182 ZZ is the 16 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 184 The key encryption algorithm is 3DES-EDE. 186 No pubInfo is used 188 Consequently, the input to the first invocation of SHA-1 is: 190 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ; ZZ 191 30 13 192 30 11 193 06 09 2a 86 48 86 f7 0d 03 06 00 ; 3DES-EDE OID 194 04 04 00 00 00 01 ; Counter 196 And the output is the 20 bytes: 198 a8 c6 4e 46 1a aa c2 36 45 c9 2e c6 0e 8a c1 96 8f fb 94 b3 200 The input to the second invocation of SHA-1 is: 202 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ; ZZ 203 30 13 204 30 11 205 06 09 2a 86 48 86 f7 0d 03 06 00 ; 3DES-EDE OID 206 04 04 00 00 00 01 ; Counter 208 And the output is the 20 bytes: 210 49 eb c8 09 27 77 19 c1 a3 0c cc 49 bd 0c 12 5e e0 f9 1a cc 212 Consequently, 213 K1'=a8 c6 4e 46 1a aa c2 36 214 K2'=45 c9 2e c6 0e 8a c1 96 215 K3'=8f fb 94 b3 49 eb c8 09 217 Note: These keys are not parity adjusted 219 2.1.7. Example 2 221 ZZ is the 16 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 223 The key encryption algorithm is RC2 225 No pubInfo is used 227 Consequently, the input to the first invocation of SHA-1 is: 229 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ; ZZ 230 30 56 231 30 10 232 06 08 2a 86 48 86 f7 0d 03 02 ; RC2 OID 233 04 04 00 00 00 02 ; Counter 234 a2 42 04 40 235 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef ; PubInfo 236 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 237 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 238 01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd ef 240 And the output is the 20 bytes: 242 f3 91 81 0b 33 34 3e c5 48 e5 a5 49 51 83 c0 0a 99 7e b4 1e 244 Consequently, 245 K=f3 91 81 0b 33 34 3e c5 48 e5 a5 49 51 83 c0 0a 247 2.2. Key and Parameter Requirements 249 X9.42 requires that the group parameters be of the form p=jq + 1 250 where q is a large prime of length m and j>=2. An algorithm for gen- 251 erating primes of this form can be found in FIPS PUB 186-1[DSS] and 252 ANSI, X9.30-1 1996 [X930], as well as in [X942]. 254 X9.42 requires that the private key x be in the interval [2, (q - 255 2)]. x should be randomly generated in this interval. y is then com- 256 puted by calculating g^x (mod p). To comply with this draft, m MUST 257 be >=128, (consequently, q and x MUST each be at least 128 bits 258 long). When symmetric ciphers stronger than DES are to be used, a 259 larger m may be advisable. 261 2.2.1. Group Parameter Generation 263 Agents SHOULD generate domain parameters (g,p,q) using the algorithms 264 specified in Appendixes 2 and 3 of [FIPS-186]. 266 2.2.2. Group Parameter Validation 268 The ASN.1 for DH keys in [PKIX] includes elements j and validation- 269 Parms which MAY be used by recipients of a key to verify that the 270 group parameters were correctly generated. Two checks are possible: 272 1. Verify that p=qj + 1. This demonstrates that the parameters meet 273 the X9.42 parameter criteria. 274 2. Verify that when the p,q generation procedure of [FIPS-186] 275 Appendix 2 is followed with seed 'seed', that p is found when 276 This demonstrates that the parameters were randomly chosen and 277 do not have a special form. 279 Whether agents provide validation information in their certificates 280 is a local matter between the agents and their CA. 282 2.3. Ephemeral-Static Mode 284 In Ephemeral-Static mode, the recipient has a static (and certified) 285 key pair, but the sender generates a new key pair for each message 286 and sends it using the originatorKey production. If the sender's key 287 is freshly generated for each message, the shared secret ZZ will be 288 similarly different for each message and pubInfo MAY be omitted, 289 since it serves merely to decouple multiple KEKs generated by the 290 same set of pairwise keys. If, however, the same ephemeral sender key 291 is used for multiple messages (e.g. it is cached as a performance 292 optimization) then a separate pubInfo MUST be used for each message. 293 All implementations of this standard MUST implement Ephemeral-Static 294 mode. 296 Acknowledgements 298 The Key Agreement method described in this document is based on work 299 done by the ANSI X9F1 working group. The author wishes to extend his 300 thanks for their assistance. 302 The author also wishes to thank Paul Hoffman, Stephen Henson, Russ 303 Housley, Brian Korver, Mark Schertler, and Peter Yee for their expert 304 advice and review. 306 References 307 [CMS] Housley, R., "Cryptographic Message Syntax", draft-ietf-smime-cms-07.txt. 309 [FIPS-46-1] Federal Information Processing Standards Publication (FIPS PUB) 310 46-1, Data Encryption Standard, Reaffirmed 1988 January 22 311 (supersedes FIPS PUB 46, 1977 January 15). 313 [FIPS-81] Federal Information Processing Standards Publication (FIPS PUB) 314 81, DES Modes of Operation, 1980 December 2. 316 [FIPS-180] Federal Information Processing Standards Publication (FIPS PUB) 317 180-1, "Secure Hash Standard", 1995 April 17. 319 [FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) 320 186, "Digital Signature Standard", 1994 May 19. 322 [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public 323 Key Infrastructure Certificate and CRL Profile", RFC-XXXX. 325 [LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, 326 "An efficient protocol for authenticated key agreement", 327 Technical report CORR 98-05, University of Waterloo, 1998. 329 [X942] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV Algorithms", 330 ANSI draft, 1998. 332 Security Considerations 334 All the security in this system is provided by the secrecy of the 335 private keying material. If either sender or recipient private keys 336 are disclosed, all messages sent or received using that key are 337 compromised. Similarly, loss of the private key results in an inabil- 338 ity to read messages sent using that key. 340 Static Diffie-Hellman keys are vulnerable to a small subgroup attack 341 [LAW98]. In practice, this issue arises for both sides in Static- 342 Static mode and for the receiver during Ephemeral-Static mode. In 343 Static-Static mode, both originator and recipient SHOULD either per- 344 form the validation step described in S 2.1.5 or verify that the CA 345 has properly verified the validity of the key. In Ephemeral-Static 346 mode, the recipient SHOULD perform the check described in 2.1.5. If 347 the sender cannot determine success or failure of decryption, the 348 recipient MAY choose to omit this check. 350 Author's Address 352 Eric Rescorla 353 RTFM Inc. 354 30 Newell Road, #16 355 East Palo Alto, CA 94303 356 Table of Contents 358 1. Introduction ................................................... 1 360 1.1. Discussion of this Draft ..................................... 2 362 1.2. Requirements Terminology ..................................... 2 364 2. Overview Of Method ............................................. 2 366 2.1. Key Agreement ................................................ 2 368 2.1.1. Generation of ZZ ........................................... 2 370 2.1.2. Generation of Keying Material .............................. 3 372 2.1.3. KEK Computation ............................................ 4 374 2.1.4. Keylengths for common algorithms ........................... 4 376 2.1.5. Public Key Validation ...................................... 4 378 2.1.6. Example 1 .................................................. 4 380 2.1.7. Example 2 .................................................. 5 382 2.2. Key and Parameter Requirements ............................... 6 384 2.2.1. Group Parameter Generation ................................. 6 386 2.2.2. Group Parameter Validation ................................. 6 388 2.3. Ephemeral-Static Mode ........................................ 7 390 2.3. Acknowledgements ............................................. 7 392 2.3. References ................................................... 7 394 Security Considerations ........................................... 8 396 Author's Address .................................................. 8