idnits 2.17.1 draft-ietf-smime-x942-00.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-26) 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 9 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 105: '... Senders SHOULD verify the receiver'...' RFC 2119 keyword, line 106: '...ting shared secrets. This check MAY be...' RFC 2119 keyword, line 108: '...rly, recipient's SHOULD verify the sen...' RFC 2119 keyword, line 125: '... pubInfo [2] OCTET STRING OPTIONAL,...' RFC 2119 keyword, line 191: '... m MUST be >=128, (consequently, q a...' 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 41, but not defined == Missing Reference: 'RFC2119' is mentioned on line 60, but not defined -- Looks like a reference, but probably isn't: '2' on line 125 == Missing Reference: 'DSS' is mentioned on line 185, but not defined == Missing Reference: 'X930' is mentioned on line 186, but not defined == Unused Reference: 'CMS' is defined on line 211, but no explicit reference was found in the text == Unused Reference: 'FIPS-81' is defined on line 217, 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. 'X942' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 E. Rescorla 3 INTERNET-DRAFT Terisa Systems, Inc. 4 June 1998 (Expires December 1998) 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. An algorithm for converting the shared secret into an arbi- 31 trary amount of keying material is provided. In addition, a standard 32 group that meets the X9.42 requirements is provided. 34 TODO 36 Redo the examples to match the new algorithm for computing K. Actu- 37 ally generate the group. 39 1. Introduction 41 In [DH76] Diffie and Hellman describe a means for two parties to 42 agree upon a shared secret in such a way that the secret will be una- 43 vailable to eavesdroppers. This secret may then be converted into 44 cryptographic keying material for other (symmetric) algorithms. A 45 large number of minor variants of this process exist. This document 46 describes one such variant, based on the ANSI X9.42 specification. 48 1.1. Discussion of this Draft 50 This draft is being discussed on the "ietf-smime" mailing list. To 51 join the list, send a message to with 52 the single word "subscribe" in the body of the message. Also, there 53 is a Web site for the mailing list at . 56 1.2. Requirements Terminology 58 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 59 "MAY" that appear in this document are to be interpreted as described 60 in [RFC2119]. 62 2. Overview Of Method 64 Diffie-Hellman key agreement requires that both the sender and reci- 65 pient of a message have key pairs. By combining one's private key and 66 the other party's public key, both parties can compute the same 67 shared secret number. This number can then be converted into crypto- 68 graphic keying material. That keying material is typically used as a 69 key encryption key (KEK) to encrypt (wrap) a key (a message encryp- 70 tion key -- MEK) which is in turn used to encrypt the message data. 72 2.1. Key Agreement 74 The first stage of the key agreement process is to compute a shared 75 secret number ZZ (which will be constant for any pair of Diffie- 76 Hellman keys). ZZ is then converted into a shared symmetric key. Note 77 that the symmetric key will be different for each key agreement, due 78 to the introduction of public random components. 80 2.1.1. Generation of ZZ 82 X9.42 defines that the shared secret ZZ is generated as follows: 84 ZZ = g ^ (xb * xa) (mod p) 86 Note that the individual parties actually perform the computations: 88 ZZ = yb ^ xa (mod p) = ya ^ xb (mod p) 90 where ^ denotes exponentiation 91 ya is party a's public key; ya = g ^ xa (mod p) 92 yb is party b's public key; yb = g ^ xb (mod p) 93 xa is party a's private key 94 xb is party b's private key 95 p is a large prime 96 g is a generator for the integer group specified by p. 97 (See Section 2.2 for criteria for keys and parameters) 99 In CMS, the recipient's key is identified by the CMS RecipientIden- 100 tifier, which points to the recipient's certificate. The sender's 101 key is identified using the OriginatorIdentifier field, either by 102 reference to the sender's certificate or by inline inclusion of a 103 key. 105 Senders SHOULD verify the receiver's public key using the procedure 106 of Section 2.1.5 before generating shared secrets. This check MAY be 107 omitted if the CA which certified the key performs this check. Simi- 108 larly, recipient's SHOULD verify the sender's public key before 109 decrypting messages. 111 2.1.2. Generation of Keying Material 113 X9.42 provides an algorithm for generating an essentially arbitrary 114 amount of keying material from ZZ. Our algorithm is derived from that 115 algorithm by mandating some optional fields and omitting others. 117 KM = H ( ZZ || OtherInfo) 119 H is the message digest function SHA-1 [FIPS-180] ZZ is the shared 120 key computed in Section 2.1.1 OtherInfo is the DER encoding of the 121 following structure: 123 OtherInfo ::= SEQUENCE { 124 keyInfo KeySpecificInfo, 125 pubInfo [2] OCTET STRING OPTIONAL, 126 } 128 KeySpecificInfo ::= SEQUENCE { 129 algorithm OBJECT IDENTIFIER, 130 counter OCTET STRING SIZE (4..4) } 132 algorithm is the ASN.1 algorithm OID of the symmetric algorithm with which 133 this KEK will be used. 134 counter is a 32 bit number, represented in network byte order. 135 Its initial value is 1, i.e. the byte sequence 00 00 00 01 (hex) 136 pubInfo is a random string provided by the sender. In CMS, it is provided 137 as a parameter in the UserKeyingMaterial field (a 512 bit byte string). 139 Note that the only source of secret entropy in this computation is 140 ZZ, so the security of this data is limited to the size of ZZ, even 141 if more data than ZZ is generated. However, since pubInfo is dif- 142 ferent for each message, a different KEK will be generated for each 143 message. 145 2.1.3. KEK Computation 147 Each key encryption algorithm requires a specific size key (n). The 148 KEK is generated by mapping the left n-most bytes of KM onto the key. 149 Consequently, for a DES [FIPS-46-1] key, which requires 64 bits of 150 keying material, the algorithm is only run once, with a counter value 151 of 1. The first 64 bits of the output are parity adjusted and con- 152 verted into a DES key. For 3DES, which requires 192 bits of keying 153 material, the algorithm must be run twice, once with a counter value 154 of 1 (to generate K1', K2', and the first 32 bits of K3') and once 155 with a counter value of 2 (to generate the last 32 bits of K3). 156 K1',K2' and K3' are then parity adjusted to generate the 3 DES keys 157 K1,K2 and K3. 159 2.1.4. Keylengths for common algorithms 161 Some common key encryption algorithms have KEKs of the following 162 lengths. 164 DES-ECB 64 bits 165 3DES-EDE-ECB 192 bits 166 RC2 (all) 256 bits 168 2.1.5. Public Key Validation 170 The following algorithm may be used to validate received public keys. 172 1. Verify that y lies within the interval [2,p-1]. If it does not, 173 the key is invalid. 174 2. Compute y^q (mod p). If the result == 1, the key is valid. 175 Otherwise the key is invalid. 177 2.1.6. Example 179 TBD 181 2.2. Key and Parameter Requirements 183 X9.42 requires that the group parameters be of the form p=jq + 1 184 where q is a large prime of length m and j>=2. An algorithm for gen- 185 erating primes of this form can be found in FIPS PUB 186-1[DSS] and 186 ANSI, X9.30-1 1996 [X930], as well as in [X942]. 188 X9.42 requires that the private key x be in the interval [2^(m-1) + 189 1, (q - 2)]. x should be randomly generated in this interval. y is 190 then computed by calculating g^x (mod p). To comply with this draft, 191 m MUST be >=128, (consequently, q and x MUST each be at least 128 192 bits long). When symmetric ciphers stronger than DES are to be used, 193 a larger m may be advisable. 195 2.2.1. Common Group 197 This standard specifies a common IETF DH group that satisfies the 198 above parameters. Standards incorporating this key exchange method 199 may choose to require support of this group. TBD 201 Acknowledgements 203 The Key Agreement method described in this document is based on work 204 done by the ANSI X9F1 working group. The author wishes to extend his 205 thanks for their assistance. 207 The author also wishes to thank Russ Housley, Brian Korver, Mark 208 Schertler, and Peter Yee for their expert advice and review. 210 References 211 [CMS] Housley, R., "Cryptographic Message Syntax", draft-ietf-smime-cms-05.txt. 213 [FIPS-46-1] Federal Information Processing Standards Publication (FIPS PUB) 214 46-1, Data Encryption Standard, Reaffirmed 1988 January 22 215 (supersedes FIPS PUB 46, 1977 January 15). 217 [FIPS-81] Federal Information Processing Standards Publication (FIPS PUB) 218 81, DES Modes of Operation, 1980 December 2. 220 [FIPS-180] Federal Information Processing Standards Publication (FIPS PUB) 221 180-1, "Secure Hash Standard", 1995 April 17. 223 [X942] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV Algorithms", 224 ANSI draft, 1998. 226 Security Considerations 228 All the security in this system is provided by the secrecy of the 229 private keying material. If either sender or recipient private keys 230 are disclosed, all messages sent or received using that key are 231 compromised. Similarly, loss of the private key results in an inabil- 232 ity to read messages sent using that key. 234 Author's Address 235 Eric Rescorla 236 Terisa Systems, Inc. 237 4984 El Camino Real 238 Los Altos, CA 94022 239 Phone: (650) 919-1753 240 Table of Contents 242 1. Introduction ................................................... 1 244 1.1. Discussion of this Draft ..................................... 2 246 1.2. Requirements Terminology ..................................... 2 248 2. Overview Of Method ............................................. 2 250 2.1. Key Agreement ................................................ 2 252 2.1.1. Generation of ZZ ........................................... 2 254 2.1.2. Generation of Keying Material .............................. 3 256 2.1.3. KEK Computation ............................................ 4 258 2.1.4. Keylengths for common algorithms ........................... 4 260 2.1.5. Public Key Validation ...................................... 4 262 2.1.6. Example .................................................... 4 264 2.2. Key and Parameter Requirements ............................... 4 266 2.2.1. Common Group ............................................... 5 268 2.2.1. Acknowledgements ........................................... 5 270 2.2.1. References ................................................. 5 272 Security Considerations ........................................... 5 274 Author's Address .................................................. 5