idnits 2.17.1 draft-ietf-smime-x942-01.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 15 instances of too long lines in the document, the longest one being 11 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 116: '... pubInfo [2] OCTET STRING OPTIONAL,...' RFC 2119 keyword, line 161: '...lowing algorithm MAY be used to valida...' RFC 2119 keyword, line 215: '... m MUST be >=128, (consequently, q a...' RFC 2119 keyword, line 221: '... Agents SHOULD generate domain param...' RFC 2119 keyword, line 227: '... Parms which MAY be used by recipien...' (3 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 38, but not defined == Missing Reference: 'RFC2119' is mentioned on line 57, but not defined -- Looks like a reference, but probably isn't: '2' on line 116 == Missing Reference: 'DSS' is mentioned on line 209, but not defined == Missing Reference: 'X930' is mentioned on line 210, but not defined == Unused Reference: 'CMS' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'FIPS-81' is defined on line 271, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-smime-cms-05 -- 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. 'X942' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 E. Rescorla 2 INTERNET-DRAFT RTFM Inc. 3 October 1998 (Expires April 1999) 5 Diffie-Hellman Key Agreement Method 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, 11 and its working groups. Note that other groups may also distribute 12 working documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference 17 material or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 21 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 22 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 23 ftp.isi.edu (US West Coast). 25 Abstract 27 This document standardizes one particular Diffie-Hellman variant, 28 based on the ANSI X9.42 standard, developed by the ANSI X9F1 working 29 group. An algorithm for converting the shared secret into an arbi- 30 trary amount of keying material is provided. 32 TODO 34 Redo the examples to match the new algorithm for computing K. 36 1. Introduction 38 In [DH76] Diffie and Hellman describe a means for two parties to 39 agree upon a shared secret in such a way that the secret will be una- 40 vailable to eavesdroppers. This secret may then be converted into 41 cryptographic keying material for other (symmetric) algorithms. A 42 large number of minor variants of this process exist. This document 43 describes one such variant, based on the ANSI X9.42 specification. 45 1.1. Discussion of this Draft 47 This draft is being discussed on the "ietf-smime" mailing list. To 48 join the list, send a message to with 49 the single word "subscribe" in the body of the message. Also, there 50 is a Web site for the mailing list at . 53 1.2. Requirements Terminology 55 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 56 "MAY" that appear in this document are to be interpreted as described 57 in [RFC2119]. 59 2. Overview Of Method 61 Diffie-Hellman key agreement requires that both the sender and reci- 62 pient of a message have key pairs. By combining one's private key and 63 the other party's public key, both parties can compute the same 64 shared secret number. This number can then be converted into crypto- 65 graphic keying material. That keying material is typically used as a 66 key encryption key (KEK) to encrypt (wrap) a key (a message encryp- 67 tion key -- MEK) which is in turn used to encrypt the message data. 69 2.1. Key Agreement 71 The first stage of the key agreement process is to compute a shared 72 secret number ZZ (which will be constant for any pair of Diffie- 73 Hellman keys). ZZ is then converted into a shared symmetric key. Note 74 that the symmetric key will be different for each key agreement, due 75 to the introduction of public random components. 77 2.1.1. Generation of ZZ 79 X9.42 defines that the shared secret ZZ is generated as follows: 81 ZZ = g ^ (xb * xa) (mod p) 83 Note that the individual parties actually perform the computations: 85 ZZ = yb ^ xa (mod p) = ya ^ xb (mod p) 87 where ^ denotes exponentiation 88 ya is party a's public key; ya = g ^ xa (mod p) 89 yb is party b's public key; yb = g ^ xb (mod p) 90 xa is party a's private key 91 xb is party b's private key 92 p is a large prime 93 g is a generator for the integer group specified by p. 94 (See Section 2.2 for criteria for keys and parameters) 96 In CMS, the recipient's key is identified by the CMS 97 RecipientIdentifier, which points to the recipient's certificate. 98 The sender's key is identified using the OriginatorIdentifierOrKey 99 field, either by reference to the sender's certificate or by inline 100 inclusion of a key. 102 2.1.2. Generation of Keying Material 104 X9.42 provides an algorithm for generating an essentially arbitrary 105 amount of keying material from ZZ. Our algorithm is derived from that 106 algorithm by mandating some optional fields and omitting others. 108 KM = H ( ZZ || OtherInfo) 110 H is the message digest function SHA-1 [FIPS-180] ZZ is the shared 111 key computed in Section 2.1.1 OtherInfo is the DER encoding of the 112 following structure: 114 OtherInfo ::= SEQUENCE { 115 keyInfo KeySpecificInfo, 116 pubInfo [2] OCTET STRING OPTIONAL, 117 } 119 KeySpecificInfo ::= SEQUENCE { 120 algorithm OBJECT IDENTIFIER, 121 counter OCTET STRING SIZE (4..4) } 123 algorithm is the ASN.1 algorithm OID of the symmetric algorithm with which 124 this KEK will be used. 125 counter is a 32 bit number, represented in network byte order. 126 Its initial value is 1, i.e. the byte sequence 00 00 00 01 (hex) 127 pubInfo is a random string provided by the sender. In CMS, it is provided 128 as a parameter in the UserKeyingMaterial field (a 512 bit byte string). 130 Note that the only source of secret entropy in this computation is 131 ZZ, so the security of this data is limited to the size of ZZ, even 132 if more data than ZZ is generated. However, since pubInfo is dif- 133 ferent for each message, a different KEK will be generated for each 134 message. 136 2.1.3. KEK Computation 138 Each key encryption algorithm requires a specific size key (n). The 139 KEK is generated by mapping the left n-most bytes of KM onto the key. 140 Consequently, for a DES [FIPS-46-1] key, which requires 64 bits of 141 keying material, the algorithm is only run once, with a counter value 142 of 1. The first 64 bits of the output are parity adjusted and con- 143 verted into a DES key. For 3DES, which requires 192 bits of keying 144 material, the algorithm must be run twice, once with a counter value 145 of 1 (to generate K1', K2', and the first 32 bits of K3') and once 146 with a counter value of 2 (to generate the last 32 bits of K3). 147 K1',K2' and K3' are then parity adjusted to generate the 3 DES keys 148 K1,K2 and K3. 150 2.1.4. Keylengths for common algorithms 152 Some common key encryption algorithms have KEKs of the following 153 lengths. 155 DES-ECB 64 bits 156 3DES-EDE-ECB 192 bits 157 RC2 (all) 128 bits 159 2.1.5. Public Key Validation 161 The following algorithm MAY be used to validate received public keys. 163 1. Verify that y lies within the interval [2,p-1]. If it does not, 164 the key is invalid. 165 2. Compute y^q (mod p). If the result == 1, the key is valid. 166 Otherwise the key is invalid. 168 The primary purpose of public key validation is to prevent a small 169 subgroup attack [REFERENCE?] on the sender's key pair. If Ephemeral- 170 Static mode is used, this check is unnecessary. Note that this pro- 171 cedure may be subject to pending patents. 173 2.1.6. Example 175 ZZ is the 16 bytes 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 177 The key encryption algorithm is 3DES-EDE. 179 No pubInfo is used 181 Consequently, the input to the first invocation of SHA-1 is: 00 01 02 182 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f ; ZZ 30 13 183 30 11 184 06 09 2a 86 48 86 f7 0d 03 06 00 ; 3DES-EDE OID 185 04 04 00 00 00 01 ; Counter 187 And the output is the 20 bytes: a8 c6 4e 46 1a aa c2 36 45 c9 2e c6 188 0e 8a c1 96 8f fb 94 b3 189 The input to the second invocation of SHA-1 is: 00 01 02 03 04 05 06 190 07 08 09 0a 0b 0c 0d 0e 0f ; ZZ 30 13 191 30 11 192 06 09 2a 86 48 86 f7 0d 03 06 00 ; 3DES-EDE OID 193 04 04 00 00 00 01 ; Counter 195 And the output is the 20 bytes: 49 eb c8 09 27 77 19 c1 a3 0c cc 49 196 bd 0c 12 5e e0 f9 1a cc 198 Consequently, 199 K1=a8 c6 4e 46 1a aa c2 36 200 K2=45 c9 2e c6 0e 8a c1 96 201 K3=8f fb 94 b3 49 eb c8 09 203 Note: These keys are not parity adjusted 205 2.2. Key and Parameter Requirements 207 X9.42 requires that the group parameters be of the form p=jq + 1 208 where q is a large prime of length m and j>=2. An algorithm for gen- 209 erating primes of this form can be found in FIPS PUB 186-1[DSS] and 210 ANSI, X9.30-1 1996 [X930], as well as in [X942]. 212 X9.42 requires that the private key x be in the interval [2^(m-1) + 213 1, (q - 2)]. x should be randomly generated in this interval. y is 214 then computed by calculating g^x (mod p). To comply with this draft, 215 m MUST be >=128, (consequently, q and x MUST each be at least 128 216 bits long). When symmetric ciphers stronger than DES are to be used, 217 a larger m may be advisable. 219 2.2.1. Group Parameter Generation 221 Agents SHOULD generate domain parameters (g,p,q) using the algorithms 222 specified in Appendixes 2 and 3 of [FIPS-186]. 224 2.2.2. Group Parameter Validation 226 The ASN.1 for DH keys in [PKIX] includes elements j and validation- 227 Parms which MAY be used by recipients of a key to verify that the 228 group parameters were correctly generated. Two checks are possible: 230 1. Verify that p=qj + 1. This demonstrates that the parameters meet 231 the X9.42 parameter criteria. 232 2. Verify that when the p,q generation procedure of [FIPS-186] Appendix 2 233 is followed with seed 'seed', that p is found when 'counter' = pgenCounter. 234 This demonstrates that the parameters were randomly chosen and do not 235 have a special form. 237 Whether agents provide validation information in their certificates 238 is a local matter between the agents and their CA. 240 2.3. Ephemeral-Static Mode 242 In Ephemeral-Static mode, the recipient has a static (and certified) 243 key pair, but the sender generates a new key pair for each message 244 and sends it using the originatorKey production. If the sender's key 245 is freshly generated for each message, the shared secret ZZ will be 246 similarly different for each message and pubInfo MAY be omitted, 247 since it serves merely to decouple multiple KEKs generated by the 248 same set of pairwise keys. If, however, the same ephemeral sender key 249 is used for multiple messages (e.g. it is cached as a performance 250 optimization) then a separate pubInfo MUST be used for each message. 251 All implementations of this standard MUST implement Ephemeral-Static 252 mode. 254 Acknowledgements 256 The Key Agreement method described in this document is based on work 257 done by the ANSI X9F1 working group. The author wishes to extend his 258 thanks for their assistance. 260 The author also wishes to thank Paul Hoffman, Russ Housley, Brian 261 Korver, Mark Schertler, and Peter Yee for their expert advice and 262 review. 264 References 265 [CMS] Housley, R., "Cryptographic Message Syntax", draft-ietf-smime-cms-05.txt. 267 [FIPS-46-1] Federal Information Processing Standards Publication (FIPS PUB) 268 46-1, Data Encryption Standard, Reaffirmed 1988 January 22 269 (supersedes FIPS PUB 46, 1977 January 15). 271 [FIPS-81] Federal Information Processing Standards Publication (FIPS PUB) 272 81, DES Modes of Operation, 1980 December 2. 274 [FIPS-180] Federal Information Processing Standards Publication (FIPS PUB) 275 180-1, "Secure Hash Standard", 1995 April 17. 277 [FIPS-186] Federal Information Processing Standards Publication (FIPS PUB) 278 186, "Digital Signature Standard", 1994 May 19. 280 [PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public 281 Key Infrastructure Certificate and CRL Profile", RFC-XXXX. 283 [X942] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV Algorithms", 284 ANSI draft, 1998. 286 Security Considerations 288 All the security in this system is provided by the secrecy of the 289 private keying material. If either sender or recipient private keys 290 are disclosed, all messages sent or received using that key are 291 compromised. Similarly, loss of the private key results in an inabil- 292 ity to read messages sent using that key. 294 Author's Address 296 Eric Rescorla 297 RTFM Inc. 298 30 Newell Road, #16 299 East Palo Alto, CA 94303 300 Table of Contents 302 1. Introduction ................................................... 1 304 1.1. Discussion of this Draft ..................................... 1 306 1.2. Requirements Terminology ..................................... 2 308 2. Overview Of Method ............................................. 2 310 2.1. Key Agreement ................................................ 2 312 2.1.1. Generation of ZZ ........................................... 2 314 2.1.2. Generation of Keying Material .............................. 3 316 2.1.3. KEK Computation ............................................ 3 318 2.1.4. Keylengths for common algorithms ........................... 4 320 2.1.5. Public Key Validation ...................................... 4 322 2.1.6. Example .................................................... 4 324 2.2. Key and Parameter Requirements ............................... 5 326 2.2.1. Group Parameter Generation ................................. 5 328 2.2.2. Group Parameter Validation ................................. 5 330 2.3. Ephemeral-Static Mode ........................................ 6 332 2.3. Acknowledgements ............................................. 6 334 2.3. References ................................................... 6 336 Security Considerations ........................................... 7 338 Author's Address .................................................. 7