idnits 2.17.1 draft-ietf-ipseckey-rr-05.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 118 has weird spacing: '...ds with lower...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (June 30, 2003) is 7605 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 347, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 353, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 356, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 370, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 379, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2065 (ref. '4') (Obsoleted by RFC 2535) -- Obsolete informational reference (is this intentional?): RFC 1886 (ref. '5') (Obsoleted by RFC 3596) -- Obsolete informational reference (is this intentional?): RFC 2407 (ref. '7') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '8') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 3445 (ref. '11') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 2 errors (**), 0 flaws (~~), 11 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: December 29, 2003 June 30, 2003 6 A method for storing IPsec keying material in DNS. 7 draft-ietf-ipseckey-rr-05.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 December 29, 2003. 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 . . . . . . . . . . . . . . . . 5 53 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . 5 54 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . 5 55 2.6.1 Example: RSA public keys . . . . . . . . . . . . . . . . . . 6 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 [6]. 83 An IPSECKEY resource record SHOULD be used in combination with DNSSEC 84 unless some other means of authenticating the IPSECKEY resource 85 record is available. 87 It is expected that there will often be multiple IPSECKEY resource 88 records at the same name. This will be due to the presence of 89 multiple gateways and the need to rollover keys. 91 This resource record is class independent. 93 2. Storage formats 95 2.1 IPSECKEY RDATA format 97 The RDATA for an IPSECKEY RR consists of a precedence value, a public 98 key, algorithm type, and an optional gateway address. 100 0 1 2 3 101 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 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 103 | precedence | gateway type | algorithm | gateway | 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + 105 ~ gateway ~ 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | / 108 / public key / 109 / / 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 112 2.2 RDATA format - precedence 114 This is an 8-bit precedence for this record. This is interpreted in 115 the same way as the PREFERENCE field described in section 3.3.9 of 116 RFC1035 [2]. 118 Gateways listed in IPSECKEY records records with lower precedence 119 are to be attempted first. Where there is a tie in precedence, the 120 order should be non-deterministic. 122 2.3 RDATA format - algorithm type 124 RFC2535 established an IANA registry for DNS Security Algorithm 125 Numbers, and subsequent documents have specified algorithms and 126 associated KEY RR formats for use with DNSSEC. Rather than respecify 127 those formats, this document reuses that registry and the associated 128 KEY RR formats. 130 The algorithm type field identifies the public key's cryptographic 131 algorithm and determines the format of the public key field. 133 The public key field contains the algorithm-specific portion of the 134 KEY RR RDATA, omitting the first four octets of the KEY RR RDATA. 135 This is the same portion of the KEY RR that must be specified by 136 documents that define a DNSSEC algorithm. Those documents also 137 specify a message digest to be used for generation of SIG RRs; that 138 specification is not relevant to the IPSECKEY usage of the public key 139 format. 141 A value of 0 indicates that no key is present. 143 The following values defined by IANA are legal: 145 3 A DSA key is present, in the format defined in RFC2536 [9] 147 5 A RSA key is present, in the format defined in RFC3110 [10] 149 2.4 RDATA format - gateway type 151 The gateway type field indicates the format of the information that 152 is stored in the gateway field. 154 The following values are defined: 156 0 No gateway is present 158 1 A 4-byte IPv4 address is present 160 2 A 16-byte IPv6 address is present 162 3 A wire-encoded domain name is present. The wire-encoded format is 163 self-describing, so the length is implicit. The domain name MUST 164 NOT be compressed. 166 2.5 RDATA format - gateway 168 The gateway field indicates a gateway to which an IPsec tunnel may be 169 created in order to reach the entity named by this resource record. 171 There are three formats: 173 A 32-bit IPv4 address is present in the gateway field. The data 174 portion is an IPv4 address as described in section 3.4.1 of RFC1035 175 [2]. This is a 32-bit number in network byte order. 177 A 128-bit IPv6 address is present in the gateway field. The data 178 portion is an IPv6 address as described in section 2.2 of RFC1886 179 [5]. This is a 128-bit number in network byte order. 181 The gateway field is a normal wire-encoded domain name, as described 182 in section 3.3 of RFC1035 [2]. Compression MUST NOT be used. 184 2.6 RDATA format - public keys 186 There are two defined public key formats: RSA and DSA. No other 187 types are supported. 189 2.6.1 Example: RSA public keys 191 Per the DNS Security Algorithm registry, an algorithm type of 5 192 identifies an RSA public key, encoded as described in section 2 of 193 RFC3110. [The encoding of RSA/MD5 KEYs (type 1) specified in RFC2537 194 is the same as that defined in RFC3110. For simplicity and in 195 keeping with RSA/MD5 being NOT RECOMMENDED for DNSSEC, type 1 SHOULD 196 NOT be used in the IPSECKEY algorithm type.] 198 The earlier definition of RSA/MD5 (algorithm type 1) in RFC2065 199 limited the exponent and modulus to 2552 bits in length. RFC3110 200 extended that limit to 4096 bits for RSA/SHA1 keys (type 5). The 201 IPSECKEY RR imposes no length limit on type 5 public keys, other than 202 the 65535 octet limit imposed by the two-octet length encoding. This 203 length extension is applicable only to IPSECKEY and not to KEY RRs. 205 3. Presentation formats 207 3.1 Representation of IPSECKEY RRs 209 IPSECKEY RRs may appears 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 If no gateway is to be indicated, then the gateway type field MUST be 216 zero, and the gateway field MUST be "." 218 IN IPSECKEY ( precedence gateway-type algorithm 219 gateway base64-encoded-public-key ) 221 3.2 Examples 223 An example of a node 192.0.2.38 that will accept IPsec tunnels on its 224 own behalf. 226 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 5 227 192.0.2.38 228 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 230 An example of a node, 192.0.2.38 that has published its key only. 232 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 5 233 . 234 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 236 An example of a node, 192.0.2.38 that has delegated authority to the 237 node 192.0.2.3. 239 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 5 240 192.0.2.3 241 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 243 An example of a node, 192.0.1.38 that has delegated authority to the 244 node with the identity "mygateway.example.com". 246 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 5 247 mygateway.example.com. 248 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 250 An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has 251 delegated authority to the node 2001:0DB8:c000:0200:2::1 252 $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int. 253 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 5 254 2001:0DB8:0:8002::2000:1 255 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 257 4. Security Considerations 259 This entire memo pertains to the provision of public keying material 260 for use by key management protocols such as ISAKMP/IKE (RFC2407) [7]. 262 The IPSECKEY resource record contains information that SHOULD be 263 communicated to the end client in an integral fashion - i.e. free 264 from modification. The form of this channel is up to the consumer of 265 the data - there must be a trust relationship between the end 266 consumer of this resource record and the server. This relationship 267 may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to 268 another secure source, a secure local channel on the host, or some 269 combination of the above. 271 The keying material provided by the IPSECKEY resource record is not 272 sensitive to passive attacks. The keying material may be freely 273 disclosed to any party without any impact on the security properties 274 of the resulting IPsec session: IPsec and IKE provide for defense 275 against both active and passive attacks. 277 Any user of this resource record MUST carefully document their trust 278 model, and why the trust model of DNSSEC is appropriate, if that is 279 the secure channel used. 281 4.1 Active attacks against unsecured IPSECKEY resource records 283 This section deals with active attacks against the DNS. These 284 attacks require that DNS requests and responses be intercepted and 285 changed. DNSSEC is designed to defend against attacks of this kind. 287 The first kind of active attack is when the attacker replaces the 288 keying material with either a key under its control or with garbage. 290 If the attacker is not able to mount a subsequent man-in-the-middle 291 attack on the IKE negotiation after replacing the public key, then 292 this will result in a denial of service, as the authenticator used by 293 IKE would fail. 295 If the attacker is able to both to mount active attacks against DNS 296 and is also in a position to perform a man-in-the-middle attack on 297 IKE and IPsec negotiations, then the attacker will be in a position 298 to compromise the resulting IPsec channel. Note that an attacker 299 must be able to perform active DNS attacks on both sides of the IKE 300 negotiation in order for this to succeed. 302 The second kind of active attack is one in which the attacker 303 replaces the the gateway address to point to a node under the 304 attacker's control. The attacker can then either replace the public 305 key or remove it, thus providing an IPSECKEY record of its own to 306 match the gateway address. 308 This later form creates a simple man-in-the-middle since the attacker 309 can then create a second tunnel to the real destination. Note that, 310 as before, this requires that the attacker also mount an active 311 attack against the responder. 313 Note that the man-in-the-middle can not just forward cleartext 314 packets to the original destination. While the destination may be 315 willing to speak in the clear, replying to the original sender, the 316 sender will have already created a policy expecting ciphertext. 317 Thus, the attacker will need to intercept traffic from both sides. 318 In some cases, the attacker may be able to accomplish the full 319 intercept by use of Network Addresss/Port Translation (NAT/NAPT) 320 technology. 322 Note that the danger here only applies to cases where the gateway 323 field of the IPSECKEY RR indicates a different entity than the owner 324 name of the IPSECKEY RR. In cases where the end-to-end integrity of 325 the IPSECKEY RR is suspect, the end client MUST restrict its use of 326 the IPSECKEY RR to cases where the RR owner name matches the content 327 of the gateway field. 329 5. IANA Considerations 331 This document updates the IANA Registry for DNS Resource Record Types 332 by assigning type X to the IPSECKEY record. 334 The values for the algorithm type field in the IPSECKEY record are 335 inherited from the DNS Security Algorithm Numbers registry, and this 336 document makes no changes to that registry. 338 6. Acknowledgments 340 My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob 341 Austein, and Olafur Gurmundsson who reviewed this document carefully. 342 Additional thanks to Olafur Gurmundsson for a reference 343 implementation. 345 Normative references 347 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 348 13, RFC 1034, November 1987. 350 [2] Mockapetris, P., "Domain names - implementation and 351 specification", STD 13, RFC 1035, November 1987. 353 [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 354 9, RFC 2026, October 1996. 356 [4] Eastlake, D. and C. Kaufman, "Domain Name System Security 357 Extensions", RFC 2065, January 1997. 359 Non-normative references 361 [5] Thomson, S. and C. Huitema, "DNS Extensions to support IP 362 version 6", RFC 1886, December 1995. 364 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 365 Levels", BCP 14, RFC 2119, March 1997. 367 [7] Piper, D., "The Internet IP Security Domain of Interpretation 368 for ISAKMP", RFC 2407, November 1998. 370 [8] Eastlake, D., "Domain Name System Security Extensions", RFC 371 2535, March 1999. 373 [9] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 374 (DNS)", RFC 2536, March 1999. 376 [10] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 377 System (DNS)", RFC 3110, May 2001. 379 [11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 380 Record (RR)", RFC 3445, December 2002. 382 Author's Address 384 Michael C. Richardson 385 Sandelman Software Works 386 470 Dawson Avenue 387 Ottawa, ON K1Z 5V7 388 CA 390 EMail: mcr@sandelman.ottawa.on.ca 391 URI: http://www.sandelman.ottawa.on.ca/ 393 Full Copyright Statement 395 Copyright (C) The Internet Society (2003). All Rights Reserved. 397 This document and translations of it may be copied and furnished to 398 others, and derivative works that comment on or otherwise explain it 399 or assist in its implementation may be prepared, copied, published 400 and distributed, in whole or in part, without restriction of any 401 kind, provided that the above copyright notice and this paragraph are 402 included on all such copies and derivative works. However, this 403 document itself may not be modified in any way, such as by removing 404 the copyright notice or references to the Internet Society or other 405 Internet organizations, except as needed for the purpose of 406 developing Internet standards in which case the procedures for 407 copyrights defined in the Internet Standards process must be 408 followed, or as required to translate it into languages other than 409 English. 411 The limited permissions granted above are perpetual and will not be 412 revoked by the Internet Society or its successors or assigns. 414 This document and the information contained herein is provided on an 415 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 416 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 417 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 418 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 419 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 421 Acknowledgement 423 Funding for the RFC Editor function is currently provided by the 424 Internet Society.