idnits 2.17.1 draft-ietf-ipseckey-rr-07.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 76 has weird spacing: '... be the publi...' == Line 120 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 (September 4, 2003) is 7530 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 363, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 374, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 377, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 394, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 403, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1521 (ref. '3') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 2065 (ref. '5') (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2434 (ref. '6') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 1886 (ref. '7') (Obsoleted by RFC 3596) -- Obsolete informational reference (is this intentional?): RFC 2407 (ref. '9') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '10') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3445 (ref. '13') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 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: March 4, 2004 September 4, 2003 6 A method for storing IPsec keying material in DNS. 7 draft-ietf-ipseckey-rr-07.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 March 4, 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 1.2 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 4 50 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 4 51 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 4 52 2.3 RDATA format - algorithm type . . . . . . . . . . . . . . . . 4 53 2.4 RDATA format - gateway type . . . . . . . . . . . . . . . . . 4 54 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 5 55 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . . 5 56 3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 7 57 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 7 58 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 60 4.1 Active attacks against unsecured IPSECKEY resource records . . 9 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 63 Normative references . . . . . . . . . . . . . . . . . . . . . 13 64 Non-normative references . . . . . . . . . . . . . . . . . . . 14 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 66 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 68 1. Introduction 70 The type number for the IPSECKEY RR is TBD. 72 1.1 Overview 74 The IPSECKEY resource record (RR) is used to publish a public key 75 that is to be associated with a Domain Name System (DNS) name for use 76 with the IPsec protocol suite. This can be the public key of a 77 host, network, or application (in the case of per-port keying). 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC2119 [8]. 83 1.2 Usage Criteria 85 An IPSECKEY resource record SHOULD be used in combination with DNSSEC 86 unless some other means of authenticating the IPSECKEY resource 87 record is available. 89 It is expected that there will often be multiple IPSECKEY resource 90 records at the same name. This will be due to the presence of 91 multiple gateways and the need to rollover keys. 93 This resource record is class independent. 95 2. Storage formats 97 2.1 IPSECKEY RDATA format 99 The RDATA for an IPSECKEY RR consists of a precedence value, a public 100 key, algorithm type, and an optional gateway address. 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 | precedence | gateway type | algorithm | gateway | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + 107 ~ gateway ~ 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | / 110 / public key / 111 / / 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 114 2.2 RDATA format - precedence 116 This is an 8-bit precedence for this record. This is interpreted in 117 the same way as the PREFERENCE field described in section 3.3.9 of 118 RFC1035 [2]. 120 Gateways listed in IPSECKEY records with lower precedence are to be 121 attempted first. Where there is a tie in precedence, the order 122 should be non-deterministic. 124 2.3 RDATA format - algorithm type 126 The algorithm type field identifies the public key's cryptographic 127 algorithm and determines the format of the public key field. 129 A value of 0 indicates that no key is present. 131 The following values are defined: 133 1 A DSA key is present, in the format defined in RFC2536 [11] 135 2 A RSA key is present, in the format defined in RFC3110 [12] 137 2.4 RDATA format - gateway type 139 The gateway type field indicates the format of the information that 140 is stored in the gateway field. 142 The following values are defined: 144 0 No gateway is present 146 1 A 4-byte IPv4 address is present 148 2 A 16-byte IPv6 address is present 150 3 A wire-encoded domain name is present. The wire-encoded format is 151 self-describing, so the length is implicit. The domain name MUST 152 NOT be compressed. 154 2.5 RDATA format - gateway 156 The gateway field indicates a gateway to which an IPsec tunnel may be 157 created in order to reach the entity named by this resource record. 159 There are three formats: 161 A 32-bit IPv4 address is present in the gateway field. The data 162 portion is an IPv4 address as described in section 3.4.1 of RFC1035 163 [2]. This is a 32-bit number in network byte order. 165 A 128-bit IPv6 address is present in the gateway field. The data 166 portion is an IPv6 address as described in section 2.2 of RFC1886 167 [7]. This is a 128-bit number in network byte order. 169 The gateway field is a normal wire-encoded domain name, as described 170 in section 3.3 of RFC1035 [2]. Compression MUST NOT be used. 172 2.6 RDATA format - public keys 174 Both of the public key types defined in this document (RSA and DSA) 175 inherit their public key formats from the corresponding KEY RR 176 formats. Specifically, the public key field contains the algorithm- 177 specific portion of the KEY RR RDATA, which is all of the KEY RR DATA 178 after the first four octets. This is the same portion of the KEY RR 179 that must be specified by documents that define a DNSSEC algorithm. 180 Those documents also specify a message digest to be used for 181 generation of SIG RRs; that specification is not relevant for 182 IPSECKEY RR. 184 Future algorithms, if they are to be used by both DNSSEC (in the KEY 185 RR) and IPSECKEY, are likely to use the same public key encodings in 186 both records. Unless otherwise specified, the IPSECKEY public key 187 field will contain the algorithm-specific portion of the KEY RR RDATA 188 for the corresponding algorithm. The algorithm must still be 189 designated for use by IPSECKEY, and an IPSECKEY algorithm type number 190 (which might be different than the DNSSEC algorithm number) must be 191 assigned to it. 193 The DSA key format is defined in RFC2536 [11] 195 The RSA key format is defined in RFC3110 [12], with the following 196 changes: 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 Public Key field is represented as a Base64 encoding of the 222 Public Key. Whitespace is allowed within the Base64 text. For a 223 definition of Base64 encoding, see RFC1521 [3] Section 5.2. 225 The general presentation for the record as as follows: 227 IN IPSECKEY ( precedence gateway-type algorithm 228 gateway base64-encoded-public-key ) 230 3.2 Examples 232 An example of a node 192.0.2.38 that will accept IPsec tunnels on its 233 own behalf. 235 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 236 192.0.2.38 237 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 239 An example of a node, 192.0.2.38 that has published its key only. 241 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 242 . 243 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 245 An example of a node, 192.0.2.38 that has delegated authority to the 246 node 192.0.2.3. 248 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 249 192.0.2.3 250 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 252 An example of a node, 192.0.1.38 that has delegated authority to the 253 node with the identity "mygateway.example.com". 255 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 256 mygateway.example.com. 257 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 259 An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has 260 delegated authority to the node 2001:0DB8:c000:0200:2::1 262 $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int. 263 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 264 2001:0DB8:0:8002::2000:1 265 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 267 4. Security Considerations 269 This entire memo pertains to the provision of public keying material 270 for use by key management protocols such as ISAKMP/IKE (RFC2407) [9]. 272 The IPSECKEY resource record contains information that SHOULD be 273 communicated to the end client in an integral fashion - i.e. free 274 from modification. The form of this channel is up to the consumer of 275 the data - there must be a trust relationship between the end 276 consumer of this resource record and the server. This relationship 277 may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to 278 another secure source, a secure local channel on the host, or some 279 combination of the above. 281 The keying material provided by the IPSECKEY resource record is not 282 sensitive to passive attacks. The keying material may be freely 283 disclosed to any party without any impact on the security properties 284 of the resulting IPsec session: IPsec and IKE provide for defense 285 against both active and passive attacks. 287 Any user of this resource record MUST carefully document their trust 288 model, and why the trust model of DNSSEC is appropriate, if that is 289 the secure channel used. 291 4.1 Active attacks against unsecured IPSECKEY resource records 293 This section deals with active attacks against the DNS. These 294 attacks require that DNS requests and responses be intercepted and 295 changed. DNSSEC is designed to defend against attacks of this kind. 297 The first kind of active attack is when the attacker replaces the 298 keying material with either a key under its control or with garbage. 300 If the attacker is not able to mount a subsequent man-in-the-middle 301 attack on the IKE negotiation after replacing the public key, then 302 this will result in a denial of service, as the authenticator used by 303 IKE would fail. 305 If the attacker is able to both to mount active attacks against DNS 306 and is also in a position to perform a man-in-the-middle attack on 307 IKE and IPsec negotiations, then the attacker will be in a position 308 to compromise the resulting IPsec channel. Note that an attacker 309 must be able to perform active DNS attacks on both sides of the IKE 310 negotiation in order for this to succeed. 312 The second kind of active attack is one in which the attacker 313 replaces the the gateway address to point to a node under the 314 attacker's control. The attacker can then either replace the public 315 key or remove it, thus providing an IPSECKEY record of its own to 316 match the gateway address. 318 This later form creates a simple man-in-the-middle since the attacker 319 can then create a second tunnel to the real destination. Note that, 320 as before, this requires that the attacker also mount an active 321 attack against the responder. 323 Note that the man-in-the-middle can not just forward cleartext 324 packets to the original destination. While the destination may be 325 willing to speak in the clear, replying to the original sender, the 326 sender will have already created a policy expecting ciphertext. 327 Thus, the attacker will need to intercept traffic from both sides. 328 In some cases, the attacker may be able to accomplish the full 329 intercept by use of Network Addresss/Port Translation (NAT/NAPT) 330 technology. 332 Note that the danger here only applies to cases where the gateway 333 field of the IPSECKEY RR indicates a different entity than the owner 334 name of the IPSECKEY RR. In cases where the end-to-end integrity of 335 the IPSECKEY RR is suspect, the end client MUST restrict its use of 336 the IPSECKEY RR to cases where the RR owner name matches the content 337 of the gateway field. 339 5. IANA Considerations 341 This document updates the IANA Registry for DNS Resource Record Types 342 by assigning type X to the IPSECKEY record. 344 This document creates an IANA registry for the algorithm type field. 346 Values 0, 1 and 2 are defined in Section 2.3. Algorithm numbers 3 347 through 255 can be assigned by IETF Consensus (see RFC2434 [6]). 349 This document creates an IANA registry for the gateway type field. 351 Values 0, 1, 2 and 3 are defined in Section 2.4. Algorithm numbers 4 352 through 255 can be assigned by Standards Action (see RFC2434 [6]). 354 6. Acknowledgments 356 My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob 357 Austein, and Olafur Gurmundsson who reviewed this document carefully. 358 Additional thanks to Olafur Gurmundsson for a reference 359 implementation. 361 Normative references 363 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 364 13, RFC 1034, November 1987. 366 [2] Mockapetris, P., "Domain names - implementation and 367 specification", STD 13, RFC 1035, November 1987. 369 [3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail 370 Extensions) Part One: Mechanisms for Specifying and Describing 371 the Format of Internet Message Bodies", RFC 1521, September 372 1993. 374 [4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 375 9, RFC 2026, October 1996. 377 [5] Eastlake, D. and C. Kaufman, "Domain Name System Security 378 Extensions", RFC 2065, January 1997. 380 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 381 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 383 Non-normative references 385 [7] Thomson, S. and C. Huitema, "DNS Extensions to support IP 386 version 6", RFC 1886, December 1995. 388 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 389 Levels", BCP 14, RFC 2119, March 1997. 391 [9] Piper, D., "The Internet IP Security Domain of Interpretation 392 for ISAKMP", RFC 2407, November 1998. 394 [10] Eastlake, D., "Domain Name System Security Extensions", RFC 395 2535, March 1999. 397 [11] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 398 (DNS)", RFC 2536, March 1999. 400 [12] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 401 System (DNS)", RFC 3110, May 2001. 403 [13] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 404 Record (RR)", RFC 3445, December 2002. 406 Author's Address 408 Michael C. Richardson 409 Sandelman Software Works 410 470 Dawson Avenue 411 Ottawa, ON K1Z 5V7 412 CA 414 EMail: mcr@sandelman.ottawa.on.ca 415 URI: http://www.sandelman.ottawa.on.ca/ 417 Full Copyright Statement 419 Copyright (C) The Internet Society (2003). All Rights Reserved. 421 This document and translations of it may be copied and furnished to 422 others, and derivative works that comment on or otherwise explain it 423 or assist in its implementation may be prepared, copied, published 424 and distributed, in whole or in part, without restriction of any 425 kind, provided that the above copyright notice and this paragraph are 426 included on all such copies and derivative works. However, this 427 document itself may not be modified in any way, such as by removing 428 the copyright notice or references to the Internet Society or other 429 Internet organizations, except as needed for the purpose of 430 developing Internet standards in which case the procedures for 431 copyrights defined in the Internet Standards process must be 432 followed, or as required to translate it into languages other than 433 English. 435 The limited permissions granted above are perpetual and will not be 436 revoked by the Internet Society or its successors or assigns. 438 This document and the information contained herein is provided on an 439 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 440 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 441 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 442 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 443 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 445 Acknowledgement 447 Funding for the RFC Editor function is currently provided by the 448 Internet Society.