idnits 2.17.1 draft-ietf-ipseckey-rr-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 90 has weird spacing: '... be the publi...' == Line 135 has weird spacing: '...ds with lower...' -- 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 (December 15, 2003) is 7438 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) == Unused Reference: '1' is defined on line 404, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 410, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 413, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 430, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 439, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2065 (ref. '4') (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2434 (ref. '5') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3548 (ref. '6') (Obsoleted by RFC 4648) -- Obsolete informational reference (is this intentional?): RFC 2407 (ref. '8') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '9') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3445 (ref. '12') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPSECKEY WG M. Richardson 2 Internet-Draft SSW 3 Expires: June 14, 2004 December 15, 2003 5 A Method for Storing IPsec Keying Material in DNS 6 draft-ietf-ipseckey-rr-08.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on June 14, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document describes a new resource record for DNS. This record 38 may be used to store public keys for use in IPsec systems. The 39 record also includes provisions for indicating what IP address (v4 or 40 v6) should be contacted when establishing an IPsec tunnel with the 41 entity in question. 43 This record replaces the functionality of the sub-type #1 of the KEY 44 Resource Record, which has been obsoleted by RFC3445. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.2 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 4 53 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 4 54 2.3 RDATA format - gateway type . . . . . . . . . . . . . . . . . 4 55 2.4 RDATA format - algorithm type . . . . . . . . . . . . . . . . 5 56 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 5 57 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . . 5 58 3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 7 59 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 7 60 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 62 4.1 Active attacks against unsecured IPSECKEY resource records . . 9 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 6. Intellectual Property Claims . . . . . . . . . . . . . . . . . 12 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 66 Normative references . . . . . . . . . . . . . . . . . . . . . 14 67 Non-normative references . . . . . . . . . . . . . . . . . . . 15 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 69 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 71 1. Introduction 73 It postulated that there is an end system desiring to establish an 74 IPsec tunnel with some remote entity on the network. This system, 75 having only a DNS name of some kind (forward, reverse or even 76 user@FQDN) needs a public key to authenticate the remote entity. It 77 also desires some guidance about whether to contact the entity 78 directly, or whether to contact another entity, as the gateway to 79 that desired entity. 81 The IPSECKEY RR provides a storage mechanism for such items as the 82 public key, and the gateway information. 84 The type number for the IPSECKEY RR is TBD. 86 1.1 Overview 88 The IPSECKEY resource record (RR) is used to publish a public key 89 that is to be associated with a Domain Name System (DNS) name for use 90 with the IPsec protocol suite. This can be the public key of a 91 host, network, or application (in the case of per-port keying). 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC2119 [7]. 97 1.2 Usage Criteria 99 An IPSECKEY resource record SHOULD be used in combination with DNSSEC 100 unless some other means of authenticating the IPSECKEY resource 101 record is available. 103 It is expected that there will often be multiple IPSECKEY resource 104 records at the same name. This will be due to the presence of 105 multiple gateways and the need to rollover keys. 107 This resource record is class independent. 109 2. Storage formats 111 2.1 IPSECKEY RDATA format 113 The RDATA for an IPSECKEY RR consists of a precedence value, a 114 gateway type, a public key, algorithm type, and an optional gateway 115 address. 117 0 1 2 3 118 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 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | precedence | gateway type | algorithm | gateway | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + 122 ~ gateway ~ 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | / 125 / public key / 126 / / 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 129 2.2 RDATA format - precedence 131 This is an 8-bit precedence for this record. This is interpreted in 132 the same way as the PREFERENCE field described in section 3.3.9 of 133 RFC1035 [2]. 135 Gateways listed in IPSECKEY records with lower precedence are to be 136 attempted first. Where there is a tie in precedence, the order 137 should be non-deterministic. 139 2.3 RDATA format - gateway type 141 The gateway type field indicates the format of the information that 142 is stored in the gateway field. 144 The following values are defined: 146 0 No gateway is present 148 1 A 4-byte IPv4 address is present 150 2 A 16-byte IPv6 address is present 152 3 A wire-encoded domain name is present. The wire-encoded format is 153 self-describing, so the length is implicit. The domain name MUST 154 NOT be compressed. (see section 3.3 of RFC1035 [2]). 156 2.4 RDATA format - algorithm type 158 The algorithm type field identifies the public key's cryptographic 159 algorithm and determines the format of the public key field. 161 A value of 0 indicates that no key is present. 163 The following values are defined: 165 1 A DSA key is present, in the format defined in RFC2536 [10] 167 2 A RSA key is present, in the format defined in RFC3110 [11] 169 2.5 RDATA format - gateway 171 The gateway field indicates a gateway to which an IPsec tunnel may be 172 created in order to reach the entity named by this resource record. 174 There are three formats: 176 A 32-bit IPv4 address is present in the gateway field. The data 177 portion is an IPv4 address as described in section 3.4.1 of RFC1035 178 [2]. This is a 32-bit number in network byte order. 180 A 128-bit IPv6 address is present in the gateway field. The data 181 portion is an IPv6 address as described in section 2.2 of RFC3596 182 [13]. This is a 128-bit number in network byte order. 184 The gateway field is a normal wire-encoded domain name, as described 185 in section 3.3 of RFC1035 [2]. Compression MUST NOT be used. 187 2.6 RDATA format - public keys 189 Both of the public key types defined in this document (RSA and DSA) 190 inherit their public key formats from the corresponding KEY RR 191 formats. Specifically, the public key field contains the algorithm- 192 specific portion of the KEY RR RDATA, which is all of the KEY RR DATA 193 after the first four octets. This is the same portion of the KEY RR 194 that must be specified by documents that define a DNSSEC algorithm. 195 Those documents also specify a message digest to be used for 196 generation of SIG RRs; that specification is not relevant for 197 IPSECKEY RR. 199 Future algorithms, if they are to be used by both DNSSEC (in the KEY 200 RR) and IPSECKEY, are likely to use the same public key encodings in 201 both records. Unless otherwise specified, the IPSECKEY public key 202 field will contain the algorithm-specific portion of the KEY RR RDATA 203 for the corresponding algorithm. The algorithm must still be 204 designated for use by IPSECKEY, and an IPSECKEY algorithm type number 205 (which might be different than the DNSSEC algorithm number) must be 206 assigned to it. 208 The DSA key format is defined in RFC2536 [10] 210 The RSA key format is defined in RFC3110 [11], with the following 211 changes: 213 The earlier definition of RSA/MD5 in RFC2065 limited the exponent and 214 modulus to 2552 bits in length. RFC3110 extended that limit to 4096 215 bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on 216 RSA public keys, other than the 65535 octet limit imposed by the two- 217 octet length encoding. This length extension is applicable only to 218 IPSECKEY and not to KEY RRs. 220 3. Presentation formats 222 3.1 Representation of IPSECKEY RRs 224 IPSECKEY RRs may appear in a zone data master file. The precedence, 225 gateway type and algorithm and gateway fields are REQUIRED. The 226 base64 encoded public key block is OPTIONAL; if not present, then the 227 public key field of the resource record MUST be construed as being 228 zero octets in length. 230 The algorithm field is an unsigned integer. No mnemonics are 231 defined. 233 If no gateway is to be indicated, then the gateway type field MUST be 234 zero, and the gateway field MUST be "." 236 The Public Key field is represented as a Base64 encoding of the 237 Public Key. Whitespace is allowed within the Base64 text. For a 238 definition of Base64 encoding, see RFC3548 [6] Section 5.2. 240 The general presentation for the record as as follows: 242 IN IPSECKEY ( precedence gateway-type algorithm 243 gateway base64-encoded-public-key ) 245 3.2 Examples 247 An example of a node 192.0.2.38 that will accept IPsec tunnels on its 248 own behalf. 250 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 251 192.0.2.38 252 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 254 An example of a node, 192.0.2.38 that has published its key only. 256 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 257 . 258 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 260 An example of a node, 192.0.2.38 that has delegated authority to the 261 node 192.0.2.3. 263 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 264 192.0.2.3 265 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 267 An example of a node, 192.0.1.38 that has delegated authority to the 268 node with the identity "mygateway.example.com". 270 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 271 mygateway.example.com. 272 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 274 An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has 275 delegated authority to the node 2001:0DB8:c000:0200:2::1 277 $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa. 278 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 279 2001:0DB8:0:8002::2000:1 280 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 282 4. Security Considerations 284 This entire memo pertains to the provision of public keying material 285 for use by key management protocols such as ISAKMP/IKE (RFC2407) [8]. 287 The IPSECKEY resource record contains information that SHOULD be 288 communicated to the end client in an integral fashion - i.e. free 289 from modification. The form of this channel is up to the consumer of 290 the data - there must be a trust relationship between the end 291 consumer of this resource record and the server. This relationship 292 may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to 293 another secure source, a secure local channel on the host, or some 294 combination of the above. 296 The keying material provided by the IPSECKEY resource record is not 297 sensitive to passive attacks. The keying material may be freely 298 disclosed to any party without any impact on the security properties 299 of the resulting IPsec session: IPsec and IKE provide for defense 300 against both active and passive attacks. 302 Any derivative standard that makes use of this resource record MUST 303 carefully document their trust model, and why the trust model of 304 DNSSEC is appropriate, if that is the secure channel used. 306 4.1 Active attacks against unsecured IPSECKEY resource records 308 This section deals with active attacks against the DNS. These 309 attacks require that DNS requests and responses be intercepted and 310 changed. DNSSEC is designed to defend against attacks of this kind. 312 The first kind of active attack is when the attacker replaces the 313 keying material with either a key under its control or with garbage. 315 If the attacker is not able to mount a subsequent man-in-the-middle 316 attack on the IKE negotiation after replacing the public key, then 317 this will result in a denial of service, as the authenticator used by 318 IKE would fail. 320 If the attacker is able to both to mount active attacks against DNS 321 and is also in a position to perform a man-in-the-middle attack on 322 IKE and IPsec negotiations, then the attacker will be in a position 323 to compromise the resulting IPsec channel. Note that an attacker 324 must be able to perform active DNS attacks on both sides of the IKE 325 negotiation in order for this to succeed. 327 The second kind of active attack is one in which the attacker 328 replaces the the gateway address to point to a node under the 329 attacker's control. The attacker can then either replace the public 330 key or remove it, thus providing an IPSECKEY record of its own to 331 match the gateway address. 333 This later form creates a simple man-in-the-middle since the attacker 334 can then create a second tunnel to the real destination. Note that, 335 as before, this requires that the attacker also mount an active 336 attack against the responder. 338 Note that the man-in-the-middle can not just forward cleartext 339 packets to the original destination. While the destination may be 340 willing to speak in the clear, replying to the original sender, the 341 sender will have already created a policy expecting ciphertext. 342 Thus, the attacker will need to intercept traffic from both sides. 343 In some cases, the attacker may be able to accomplish the full 344 intercept by use of Network Addresss/Port Translation (NAT/NAPT) 345 technology. 347 Note that the danger here only applies to cases where the gateway 348 field of the IPSECKEY RR indicates a different entity than the owner 349 name of the IPSECKEY RR. In cases where the end-to-end integrity of 350 the IPSECKEY RR is suspect, the end client MUST restrict its use of 351 the IPSECKEY RR to cases where the RR owner name matches the content 352 of the gateway field. 354 5. IANA Considerations 356 This document updates the IANA Registry for DNS Resource Record Types 357 by assigning type X to the IPSECKEY record. 359 This document creates two new IANA registries, both specific to the 360 IPSECKEY Resource Record: 362 This document creates an IANA registry for the algorithm type field. 364 Values 0, 1 and 2 are defined in Section 2.4. Algorithm numbers 3 365 through 255 can be assigned by IETF Consensus (see RFC2434 [5]). 367 This document creates an IANA registry for the gateway type field. 369 Values 0, 1, 2 and 3 are defined in Section 2.3. Gateway type 370 numbers 4 through 255 can be assigned by Standards Action (see 371 RFC2434 [5]). 373 6. Intellectual Property Claims 375 The IETF takes no position regarding the validity or scope of any 376 intellectual property or other rights that might be claimed to 377 pertain to the implementation or use of the technology described in 378 this document or the extent to which any license under such rights 379 might or might not be available; neither does it represent that it 380 has made any effort to identify any such rights. Information on the 381 IETF's procedures with respect to rights in standards-track and 382 standards-related documentation can be found in BCP-11. Copies of 383 claims of rights made available for publication and any assurances of 384 licenses to be made available, or the result of an attempt made to 385 obtain a general license or permission for the use of such 386 proprietary rights by implementors or users of this specification can 387 be obtained from the IETF Secretariat. 389 The IETF invites any interested party to bring to its attention any 390 copyrights, patents or patent applications, or other proprietary 391 rights which may cover technology that may be required to practice 392 this standard. Please address the information to the IETF Executive 393 Director. 395 7. Acknowledgments 397 My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob 398 Austein, and Olafur Gurmundsson who reviewed this document carefully. 399 Additional thanks to Olafur Gurmundsson for a reference 400 implementation. 402 Normative references 404 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 405 13, RFC 1034, November 1987. 407 [2] Mockapetris, P., "Domain names - implementation and 408 specification", STD 13, RFC 1035, November 1987. 410 [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 411 9, RFC 2026, October 1996. 413 [4] Eastlake, D. and C. Kaufman, "Domain Name System Security 414 Extensions", RFC 2065, January 1997. 416 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 417 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 419 [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 420 RFC 3548, July 2003. 422 Non-normative references 424 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 425 Levels", BCP 14, RFC 2119, March 1997. 427 [8] Piper, D., "The Internet IP Security Domain of Interpretation 428 for ISAKMP", RFC 2407, November 1998. 430 [9] Eastlake, D., "Domain Name System Security Extensions", RFC 431 2535, March 1999. 433 [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 434 (DNS)", RFC 2536, March 1999. 436 [11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 437 System (DNS)", RFC 3110, May 2001. 439 [12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 440 Record (RR)", RFC 3445, December 2002. 442 [13] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS 443 Extensions to Support IP Version 6", RFC 3596, October 2003. 445 Author's Address 447 Michael C. Richardson 448 Sandelman Software Works 449 470 Dawson Avenue 450 Ottawa, ON K1Z 5V7 451 CA 453 EMail: mcr@sandelman.ottawa.on.ca 454 URI: http://www.sandelman.ottawa.on.ca/ 456 Full Copyright Statement 458 Copyright (C) The Internet Society (2003). All Rights Reserved. 460 This document and translations of it may be copied and furnished to 461 others, and derivative works that comment on or otherwise explain it 462 or assist in its implementation may be prepared, copied, published 463 and distributed, in whole or in part, without restriction of any 464 kind, provided that the above copyright notice and this paragraph are 465 included on all such copies and derivative works. However, this 466 document itself may not be modified in any way, such as by removing 467 the copyright notice or references to the Internet Society or other 468 Internet organizations, except as needed for the purpose of 469 developing Internet standards in which case the procedures for 470 copyrights defined in the Internet Standards process must be 471 followed, or as required to translate it into languages other than 472 English. 474 The limited permissions granted above are perpetual and will not be 475 revoked by the Internet Society or its successors or assigns. 477 This document and the information contained herein is provided on an 478 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 479 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 480 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 481 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 482 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 484 Acknowledgement 486 Funding for the RFC Editor function is currently provided by the 487 Internet Society.