idnits 2.17.1 draft-ietf-dnsext-rfc2539bis-dhk-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 226. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 242. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 248. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2539, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- The document date (October 2006) is 6374 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 3755 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Diffie-Hellman Information in the DNS 2 OBSOLETES: RFC 2539 Donald E. Eastlake 3rd 3 Motorola Laboratories 4 Expires: April 2007 October 2006 6 Storage of Diffie-Hellman Keying Information in the DNS 7 ------- -- -------------- ------ ----------- -- --- --- 8 10 Status of This Document 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Distribution of this document is unlimited. Comments should be sent 18 to the DNS extensions working group mailing list 19 . 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 The standard method for encoding Diffie-Hellman keys in the Domain 40 Name System is specified. 42 Acknowledgements 44 Part of the format for Diffie-Hellman keys and the description 45 thereof was taken from a work in progress by Ashar Aziz, Tom Markson, 46 and Hemma Prafullchandra. In addition, the following persons 47 provided useful comments that were incorporated into the predecessor 48 of this document: Ran Atkinson, Thomas Narten. 50 Table of Contents 52 Status of This Document....................................1 53 Abstract...................................................1 55 Acknowledgements...........................................2 56 Table of Contents..........................................2 58 1. Introduction............................................3 59 1.1 About This Document....................................3 60 1.2 About Diffie-Hellman...................................3 61 2. Encoding Diffie-Hellman Keying Information..............4 62 3. Performance Considerations..............................5 63 4. IANA Considerations.....................................5 64 5. Security Considerations.................................5 65 Copyright, Disclaimer, and Additional IPR Provisions.......5 67 Normative References.......................................7 68 Informative References.....................................7 70 Appendix A: Well known prime/generator pairs...............9 71 A.1. Well-Known Group 1: A 768 bit prime..................9 72 A.2. Well-Known Group 2: A 1024 bit prime.................9 73 A.3. Well-Known Group 3: A 1536 bit prime................10 74 A.4 Well known Groups 4 through 8.........................10 75 Appendix B: Changes from RFC 2539.........................10 77 Author's Address..........................................12 78 Expiration and File Name..................................12 80 1. Introduction 82 The Domain Name System (DNS) is the global hierarchical replicated 83 distributed database system for Internet addressing, mail proxy, and 84 other information [RFC1034], [RFC1035]. The DNS has been extended to 85 include digital signatures and cryptographic keys as described in 86 [RFC4033], [RFC4034, [RFC4035] and there is additional work which 87 would use keying information in the DNS such as TKEY [RFC2930] and 88 GSS-TSIG [RFC3645]. This document does not change the wire format of 89 KEY RR's but extends the use of Diffie-Hellman DNS keys to cover the 90 DNSKEY RR. 92 1.1 About This Document 94 This document describes how to store Diffie-Hellman keys in the DNS. 95 Familiarity with the Diffie-Hellman key exchange algorithm is assumed 96 [Schneier], [RFC2631]. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 1.2 About Diffie-Hellman 104 Diffie-Hellman requires two parties to interact to derive keying 105 information which can then be used for authentication. Thus Diffie- 106 Hellman is inherently a key agreement algorithm. As a result, no 107 format is defined for Diffie-Hellman "signature information". For 108 example, assume that two parties have local secrets "i" and "j". 109 Assume they each respectively calculate X and Y as follows: 111 X = g**i ( mod p ) 113 Y = g**j ( mod p ) 115 They exchange these quantities and then each calculates a Z as 116 follows: 118 Zi = Y**i ( mod p ) 120 Zj = X**j ( mod p ) 122 Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared 123 secret between the two parties that an adversary who does not know i 124 or j will not be able to learn from the exchanged messages (unless 125 the adversary can derive i or j by performing a discrete logarithm 126 mod p which is hard for strong p and g). 128 The private key for each party is their secret i (or j). The public 129 key is the pair p and g, which is the same for both parties, and 130 their individual X (or Y). 132 For further information about Diffie-Hellman and precautions to take 133 in deciding on a p and g, see [RFC2631]. 135 2. Encoding Diffie-Hellman Keying Information 137 When Diffie-Hellman keys appear within the RDATA portion of a RR, 138 they are encoded as shown below. 140 The period of key validity is not included in this data but is 141 indicated separately, for example by an RR such as RRSIG which signs 142 and authenticates the RR containing the keying information. 144 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 145 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | prime length (or flag) | prime (p) (or special) / 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 / prime (p) (variable length) | generator length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | generator (g) (variable length) | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | public value length | public value (variable length)/ 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 / public value (g^i mod p) (variable length) | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Prime length is the length of the Diffie-Hellman prime (p) in bytes 159 if it is 16 or greater. Prime contains the binary representation of 160 the Diffie-Hellman prime with most significant byte first (i.e., in 161 network order). If "prime length" field is 1 or 2, then the "prime" 162 field is actually an unsigned index into a table of 65,536 163 prime/generator pairs and the generator length SHOULD be zero. See 164 Appendix A for defined table entries and Section 4 for information on 165 allocating additional table entries. The meaning of a zero or 3 166 through 15 value for "prime length" is reserved. 168 Generator length is the length of the generator (g) in bytes. 169 Generator is the binary representation of generator with most 170 significant byte first. PublicValueLen is the Length of the Public 171 Value (g**i (mod p)) in bytes. PublicValue is the binary 172 representation of the DH public value with most significant byte 173 first. 175 3. Performance Considerations 177 Current DNS implementations are optimized for small transfers, 178 typically less than 512 bytes including DNS overhead. Larger 179 transfers will perform correctly and extensions have been 180 standardized [RFC2671] to make larger transfers more efficient. But 181 it is still advisable at this time to make reasonable efforts to 182 minimize the size of RR sets containing keying information consistent 183 with adequate security. 185 4. IANA Considerations 187 Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires 188 an IETF consensus as defined in [RFC2434]. 190 Well known prime/generator pairs number 0x0000 through 0x07FF can 191 only be assigned by an IETF Standards Action. [RFC2539], the Proposed 192 Standard predecessor of this document, assigned 0x0001 through 193 0x0002. This document additionally assigns 0x0003 through 0x0008. 194 Pairs number 0s0800 through 0xBFFF can be assigned based on 195 Specification Required as specified in [RFC2434]. Pairs number 0xC000 196 through 0xFFFF are available for private use and are not centrally 197 coordinated. Use of such private pairs outside of a closed 198 environment may result in conflicts and/or security failures. 200 5. Security Considerations 202 Keying information retrieved from the DNS should not be trusted 203 unless (1) it has been securely obtained from a secure resolver or 204 independently verified by the user and (2) this secure resolver and 205 secure obtainment or independent verification conform to security 206 policies acceptable to the user. As with all cryptographic 207 algorithms, evaluating the necessary strength of the key is important 208 and dependent on security policy. 210 In addition, the usual Diffie-Hellman key strength considerations 211 apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p 212 SHOULD be "large", etc. See [RFC2631], [Schneier]. 214 Copyright, Disclaimer, and Additional IPR Provisions 216 Copyright (C) The Internet Society 2006. This document is subject to 217 the rights, licenses and restrictions contained in BCP 78, and except 218 as set forth therein, the authors retain all their rights. 220 This document and the information contained herein are provided on an 221 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 222 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 223 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 224 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 225 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 226 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 228 The IETF takes no position regarding the validity or scope of any 229 Intellectual Property Rights or other rights that might be claimed to 230 pertain to the implementation or use of the technology described in 231 this document or the extent to which any license under such rights 232 might or might not be available; nor does it represent that it has 233 made any independent effort to identify any such rights. Information 234 on the procedures with respect to rights in RFC documents can be 235 found in BCP 78 and BCP 79. 237 Copies of IPR disclosures made to the IETF Secretariat and any 238 assurances of licenses to be made available, or the result of an 239 attempt made to obtain a general license or permission for the use of 240 such proprietary rights by implementers or users of this 241 specification can be obtained from the IETF on-line IPR repository at 242 http://www.ietf.org/ipr. 244 The IETF invites any interested party to bring to its attention any 245 copyrights, patents or patent applications, or other proprietary 246 rights that may cover technology that may be required to implement 247 this standard. Please address the information to the IETF at ietf- 248 ipr@ietf.org. 250 Normative References 252 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, March 1997. 255 [RFC2434] - "Guidelines for Writing an IANA Considerations Section in 256 RFCs", T. Narten, H. Alvestrand, October 1998. 258 [RFC2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June 259 1999. 261 [RFC3526] - Kivinen, T., and M. Kojo, "More Modular Exponential 262 (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", May 263 2003. 265 [RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 266 Rose, "Resource Records for the DNS Security Extensions", RFC 4034, 267 March 2005. 269 Informative References 271 [RFC1034] - "Domain names - concepts and facilities", P. Mockapetris, 272 November 1987. 274 [RFC1035] - "Domain names - implementation and specification", P. 275 Mockapetris, November 1987. 277 [RFC2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY 278 RR)", September 2000. 280 [RFC2539] - "Storage of Diffie-Hellman Keys in the Domain Name System 281 (DNS)", D. Eastlake, March 1999, obsoleted by this RFC. 283 [RFC2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August 284 1999. 286 [RFC3645] - Kwan, S., et al "Generic Security Service Algorithm for 287 Secret Key Transaction Authentication for DNS (GSS-TSIG)", October 288 2000. 290 [RFC3755] - Weiler, S., "Legacy Resolver Compatibility for Delegation 291 Signer (DS)", May 2004. 293 [RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 294 Rose, "DNS Security Introduction and Requirements", RFC 4033, March 295 2005. 297 [RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 299 Rose, "Protocol Modifications for the DNS Security Extensions", RFC 300 4035, March 2005. 302 [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, 303 Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley 304 and Sons. 306 Appendix A: Well known prime/generator pairs 308 These numbers are copied from the IPSEC effort where the derivation 309 of these values is more fully explained and additional information is 310 available. Richard Schroeppel performed all the mathematical and 311 computational work for this appendix. 313 A.1. Well-Known Group 1: A 768 bit prime 315 The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its 316 decimal value is 317 155251809230070893513091813125848175563133404943451431320235 318 119490296623994910210725866945387659164244291000768028886422 319 915080371891804634263272761303128298374438082089019628850917 320 0691316593175367469551763119843371637221007210577919 322 Prime modulus: Length (32 bit words): 24, Data (hex): 323 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 324 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 325 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 326 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF 328 Generator: Length (32 bit words): 1, Data (hex): 2 330 A.2. Well-Known Group 2: A 1024 bit prime 332 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. 333 Its decimal value is 334 179769313486231590770839156793787453197860296048756011706444 335 423684197180216158519368947833795864925541502180565485980503 336 646440548199239100050792877003355816639229553136239076508735 337 759914822574862575007425302077447712589550957937778424442426 338 617334727629299387668709205606050270810842907692932019128194 339 467627007 341 Prime modulus: Length (32 bit words): 32, Data (hex): 342 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 343 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 344 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 345 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 346 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 347 FFFFFFFF FFFFFFFF 349 Generator: Length (32 bit words): 1, Data (hex): 2 351 A.3. Well-Known Group 3: A 1536 bit prime 353 The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }. 354 Its decimal value is 355 241031242692103258855207602219756607485695054850245994265411 356 694195810883168261222889009385826134161467322714147790401219 357 650364895705058263194273070680500922306273474534107340669624 358 601458936165977404102716924945320037872943417032584377865919 359 814376319377685986952408894019557734611984354530154704374720 360 774996976375008430892633929555996888245787241299381012913029 361 459299994792636526405928464720973038494721168143446471443848 362 8520940127459844288859336526896320919633919 364 Prime modulus Length (32 bit words): 48, Data (hex): 365 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 366 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 367 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 368 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 369 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D 370 C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F 371 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D 372 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF 374 Generator: Length (32 bit words): 1, Data (hex): 2 376 A.4 Well known Groups 4 through 8 378 The additional Diffie-Hellman Groups specified in [RFC3526] are also 379 adopted and assigned well known group numbers as follows: 381 Group Number Size 382 4 2048-bit 383 5 3072-bit 384 6 4096-bit 385 7 6144-bit 386 8 8192-bit 388 Appendix B: Changes from RFC 2539 390 When [RFC2539] was published, keys in the DNS appeared only in KEY 391 resource records. As described in [RFC3755], due to a revision in DNS 392 data origin authentication security, the recommended RR was changed 393 to DNSKEY which is described in [RFC4034]; however KEY continues to 394 be used in connection with TKEY [RFC2930]. 396 Thus the primary change from [RFC2539] in this document is to 397 eliminate the tie to the KEY RRs. In addition, more well known 398 Diffie-Hellman Groups are listed and assigned identification numbers 399 and many references have been updated. 401 Author's Address 403 Donald E. Eastlake 3rd 404 Motorola Laboratories 405 111 Locke Drive 406 Marlborough, MA 01752 USA 408 Telephone: +1-508-786-7554 409 EMail: Donald.Eastlake@motorola.com 411 Expiration and File Name 413 This draft expires in April 2007. 415 Its file name is draft-ietf-dnsext-rfc2539bis-dhk-08.txt.