idnits 2.17.1 draft-ietf-ipseckey-rr-06.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 75 has weird spacing: '... be the publi...' == Line 117 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 (August 16, 2003) is 7558 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 359, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 365, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 368, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 385, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 394, 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 informational reference (is this intentional?): RFC 1886 (ref. '6') (Obsoleted by RFC 3596) -- 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: 3 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECKEY WG M. Richardson 3 Internet-Draft SSW 4 Expires: February 14, 2004 August 16, 2003 6 A method for storing IPsec keying material in DNS. 7 draft-ietf-ipseckey-rr-06.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on February 14, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes a new resource record for DNS. This record 39 may be used to store public keys for use in IPsec systems. 41 This record replaces the functionality of the sub-type #1 of the KEY 42 Resource Record, which has been obsoleted by RFC3445. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 4 49 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 4 50 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 4 51 2.3 RDATA format - algorithm type . . . . . . . . . . . . . . . . 4 52 2.4 RDATA format - gateway type . . . . . . . . . . . . . . . . . 4 53 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 5 54 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . . 5 55 3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 7 56 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 7 57 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 4.1 Active attacks against unsecured IPSECKEY resource records . . 9 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 62 Normative references . . . . . . . . . . . . . . . . . . . . . 13 63 Non-normative references . . . . . . . . . . . . . . . . . . . 14 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 65 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 67 1. Introduction 69 The type number for the IPSECKEY RR is TBD. 71 1.1 Overview 73 The IPSECKEY resource record (RR) is used to publish a public key 74 that is to be associated with a Domain Name System (DNS) name for use 75 with the IPsec protocol suite. This can be the public key of a 76 host, network, or application (in the case of per-port keying). 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in RFC2119 [7]. 82 An IPSECKEY resource record SHOULD be used in combination with DNSSEC 83 unless some other means of authenticating the IPSECKEY resource 84 record is available. 86 It is expected that there will often be multiple IPSECKEY resource 87 records at the same name. This will be due to the presence of 88 multiple gateways and the need to rollover keys. 90 This resource record is class independent. 92 2. Storage formats 94 2.1 IPSECKEY RDATA format 96 The RDATA for an IPSECKEY RR consists of a precedence value, a public 97 key, algorithm type, and an optional gateway address. 99 0 1 2 3 100 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 101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 102 | precedence | gateway type | algorithm | gateway | 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + 104 ~ gateway ~ 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | / 107 / public key / 108 / / 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 111 2.2 RDATA format - precedence 113 This is an 8-bit precedence for this record. This is interpreted in 114 the same way as the PREFERENCE field described in section 3.3.9 of 115 RFC1035 [2]. 117 Gateways listed in IPSECKEY records records with lower precedence 118 are to be attempted first. Where there is a tie in precedence, the 119 order should be non-deterministic. 121 2.3 RDATA format - algorithm type 123 The algorithm type field identifies the public key's cryptographic 124 algorithm and determines the format of the public key field. 126 A value of 0 indicates that no key is present. 128 The following values are defined: 130 1 A DSA key is present, in the format defined in RFC2536 [10] 132 2 A RSA key is present, in the format defined in RFC3110 [11] 134 2.4 RDATA format - gateway type 136 The gateway type field indicates the format of the information that 137 is stored in the gateway field. 139 The following values are defined: 141 0 No gateway is present 143 1 A 4-byte IPv4 address is present 145 2 A 16-byte IPv6 address is present 147 3 A wire-encoded domain name is present. The wire-encoded format is 148 self-describing, so the length is implicit. The domain name MUST 149 NOT be compressed. 151 2.5 RDATA format - gateway 153 The gateway field indicates a gateway to which an IPsec tunnel may be 154 created in order to reach the entity named by this resource record. 156 There are three formats: 158 A 32-bit IPv4 address is present in the gateway field. The data 159 portion is an IPv4 address as described in section 3.4.1 of RFC1035 160 [2]. This is a 32-bit number in network byte order. 162 A 128-bit IPv6 address is present in the gateway field. The data 163 portion is an IPv6 address as described in section 2.2 of RFC1886 164 [6]. This is a 128-bit number in network byte order. 166 The gateway field is a normal wire-encoded domain name, as described 167 in section 3.3 of RFC1035 [2]. Compression MUST NOT be used. 169 2.6 RDATA format - public keys 171 Both of the public key types defined in this document (RSA and DSA) 172 inherit their public key formats from the corresponding KEY RR 173 formats. Specifically, the public key field contains the algorithm- 174 specific portion of the KEY RR RDATA, which is all of the KEY RR DATA 175 after the first four octets. This is the same portion of the KEY RR 176 that must be specified by documents that define a DNSSEC algorithm. 177 Those documents also specify a message digest to be used for 178 generation of SIG RRs; that specification is not relevant for 179 IPSECKEY RR. 181 Future algorithms, if they are to be used by both DNSSEC (in the KEY 182 RR) and IPSECKEY, are likely to use the same public key encodings in 183 both records. Unless otherwise specified, the IPSECKEY public key 184 field will contain the algorithm-specific portion of the KEY RR RDATA 185 for the corresponding algorithm. The algorithm must still be 186 designated for use by IPSECKEY, and an IPSECKEY algorithm type number 187 (which might be different than the DNSSEC algorithm number) must be 188 assigned to it. 190 The DSA key format is defined in RFC2536 [10] 192 The RSA key format is defined in RFC3110 [11], with the following 193 changes: 195 The encoding of RSA/MD5 KEYs (type 1) specified in RFC2537 is the 196 same as that defined in RFC3110. 198 The earlier definition of RSA/MD5 in RFC2065 limited the exponent and 199 modulus to 2552 bits in length. RFC3110 extended that limit to 4096 200 bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on 201 RSA public keys, other than the 65535 octet limit imposed by the two- 202 octet length encoding. This length extension is applicable only to 203 IPSECKEY and not to KEY RRs. 205 3. Presentation formats 207 3.1 Representation of IPSECKEY RRs 209 IPSECKEY RRs may appear in a zone data master file. The precedence, 210 gateway type and algorithm and gateway fields are REQUIRED. The 211 base64 encoded public key block is OPTIONAL; if not present, then the 212 public key field of the resource record MUST be construed as being 213 zero octets in length. 215 The algorithm field is an unsigned integer. No mnemonics are 216 defined. 218 If no gateway is to be indicated, then the gateway type field MUST be 219 zero, and the gateway field MUST be "." 221 The general presentation for the record as as follows: 223 IN IPSECKEY ( precedence gateway-type algorithm 224 gateway base64-encoded-public-key ) 226 3.2 Examples 228 An example of a node 192.0.2.38 that will accept IPsec tunnels on its 229 own behalf. 231 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 232 192.0.2.38 233 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 235 An example of a node, 192.0.2.38 that has published its key only. 237 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 238 . 239 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 241 An example of a node, 192.0.2.38 that has delegated authority to the 242 node 192.0.2.3. 244 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 245 192.0.2.3 246 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 248 An example of a node, 192.0.1.38 that has delegated authority to the 249 node with the identity "mygateway.example.com". 251 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 252 mygateway.example.com. 253 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 255 An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has 256 delegated authority to the node 2001:0DB8:c000:0200:2::1 258 $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int. 259 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 260 2001:0DB8:0:8002::2000:1 261 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 263 4. Security Considerations 265 This entire memo pertains to the provision of public keying material 266 for use by key management protocols such as ISAKMP/IKE (RFC2407) [8]. 268 The IPSECKEY resource record contains information that SHOULD be 269 communicated to the end client in an integral fashion - i.e. free 270 from modification. The form of this channel is up to the consumer of 271 the data - there must be a trust relationship between the end 272 consumer of this resource record and the server. This relationship 273 may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to 274 another secure source, a secure local channel on the host, or some 275 combination of the above. 277 The keying material provided by the IPSECKEY resource record is not 278 sensitive to passive attacks. The keying material may be freely 279 disclosed to any party without any impact on the security properties 280 of the resulting IPsec session: IPsec and IKE provide for defense 281 against both active and passive attacks. 283 Any user of this resource record MUST carefully document their trust 284 model, and why the trust model of DNSSEC is appropriate, if that is 285 the secure channel used. 287 4.1 Active attacks against unsecured IPSECKEY resource records 289 This section deals with active attacks against the DNS. These 290 attacks require that DNS requests and responses be intercepted and 291 changed. DNSSEC is designed to defend against attacks of this kind. 293 The first kind of active attack is when the attacker replaces the 294 keying material with either a key under its control or with garbage. 296 If the attacker is not able to mount a subsequent man-in-the-middle 297 attack on the IKE negotiation after replacing the public key, then 298 this will result in a denial of service, as the authenticator used by 299 IKE would fail. 301 If the attacker is able to both to mount active attacks against DNS 302 and is also in a position to perform a man-in-the-middle attack on 303 IKE and IPsec negotiations, then the attacker will be in a position 304 to compromise the resulting IPsec channel. Note that an attacker 305 must be able to perform active DNS attacks on both sides of the IKE 306 negotiation in order for this to succeed. 308 The second kind of active attack is one in which the attacker 309 replaces the the gateway address to point to a node under the 310 attacker's control. The attacker can then either replace the public 311 key or remove it, thus providing an IPSECKEY record of its own to 312 match the gateway address. 314 This later form creates a simple man-in-the-middle since the attacker 315 can then create a second tunnel to the real destination. Note that, 316 as before, this requires that the attacker also mount an active 317 attack against the responder. 319 Note that the man-in-the-middle can not just forward cleartext 320 packets to the original destination. While the destination may be 321 willing to speak in the clear, replying to the original sender, the 322 sender will have already created a policy expecting ciphertext. 323 Thus, the attacker will need to intercept traffic from both sides. 324 In some cases, the attacker may be able to accomplish the full 325 intercept by use of Network Addresss/Port Translation (NAT/NAPT) 326 technology. 328 Note that the danger here only applies to cases where the gateway 329 field of the IPSECKEY RR indicates a different entity than the owner 330 name of the IPSECKEY RR. In cases where the end-to-end integrity of 331 the IPSECKEY RR is suspect, the end client MUST restrict its use of 332 the IPSECKEY RR to cases where the RR owner name matches the content 333 of the gateway field. 335 5. IANA Considerations 337 This document updates the IANA Registry for DNS Resource Record Types 338 by assigning type X to the IPSECKEY record. 340 This document creates an IANA registry for the algorithm type field. 342 Values 0, 1 and 2 are defined in Section 2.3. Algorithm numbers 3 343 through 255 can be assigned by IETF Consensus (see RFC2434 [5]). 345 This document creates an IANA registry for the gateway type field. 347 Values 0, 1, 2 and 3 are defined in Section 2.4. Algorithm numbers 4 348 through 255 can be assigned by Standards Action (see RFC2434 [5]). 350 6. Acknowledgments 352 My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob 353 Austein, and Olafur Gurmundsson who reviewed this document carefully. 354 Additional thanks to Olafur Gurmundsson for a reference 355 implementation. 357 Normative references 359 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 360 13, RFC 1034, November 1987. 362 [2] Mockapetris, P., "Domain names - implementation and 363 specification", STD 13, RFC 1035, November 1987. 365 [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 366 9, RFC 2026, October 1996. 368 [4] Eastlake, D. and C. Kaufman, "Domain Name System Security 369 Extensions", RFC 2065, January 1997. 371 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 372 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 374 Non-normative references 376 [6] Thomson, S. and C. Huitema, "DNS Extensions to support IP 377 version 6", RFC 1886, December 1995. 379 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 380 Levels", BCP 14, RFC 2119, March 1997. 382 [8] Piper, D., "The Internet IP Security Domain of Interpretation 383 for ISAKMP", RFC 2407, November 1998. 385 [9] Eastlake, D., "Domain Name System Security Extensions", RFC 386 2535, March 1999. 388 [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 389 (DNS)", RFC 2536, March 1999. 391 [11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 392 System (DNS)", RFC 3110, May 2001. 394 [12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 395 Record (RR)", RFC 3445, December 2002. 397 Author's Address 399 Michael C. Richardson 400 Sandelman Software Works 401 470 Dawson Avenue 402 Ottawa, ON K1Z 5V7 403 CA 405 EMail: mcr@sandelman.ottawa.on.ca 406 URI: http://www.sandelman.ottawa.on.ca/ 408 Full Copyright Statement 410 Copyright (C) The Internet Society (2003). All Rights Reserved. 412 This document and translations of it may be copied and furnished to 413 others, and derivative works that comment on or otherwise explain it 414 or assist in its implementation may be prepared, copied, published 415 and distributed, in whole or in part, without restriction of any 416 kind, provided that the above copyright notice and this paragraph are 417 included on all such copies and derivative works. However, this 418 document itself may not be modified in any way, such as by removing 419 the copyright notice or references to the Internet Society or other 420 Internet organizations, except as needed for the purpose of 421 developing Internet standards in which case the procedures for 422 copyrights defined in the Internet Standards process must be 423 followed, or as required to translate it into languages other than 424 English. 426 The limited permissions granted above are perpetual and will not be 427 revoked by the Internet Society or its successors or assigns. 429 This document and the information contained herein is provided on an 430 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 431 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 432 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 433 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 434 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 436 Acknowledgement 438 Funding for the RFC Editor function is currently provided by the 439 Internet Society.