idnits 2.17.1 draft-ietf-ipseckey-rr-12.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.5 on line 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 549. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 565), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** Found boilerplate matching RFC 3979, Section 5, paragraph 3 (on line 549), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 464. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) 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: ---------------------------------------------------------------------------- == In addition to RFC 3979, Section 5, paragraph 3 boilerplate, a section with a similar start was also found: The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 103 has weird spacing: '... be the publi...' == Line 169 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 (January 18, 2005) is 7030 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: '3' is defined on line 481, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 484, 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: 10 errors (**), 0 flaws (~~), 8 warnings (==), 8 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: July 19, 2005 January 18, 2005 6 A Method for Storing IPsec Keying Material in DNS 7 draft-ietf-ipseckey-rr-12.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3667. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 19, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This document describes a new resource record for the Domain Name 40 System (DNS). This record may be used to store public keys for use in 41 IP security (IPsec) systems. The record also includes provisions for 42 indicating what system should be contacted when establishing an IPsec 43 tunnel with the entity in question. 45 This record replaces the functionality of the sub-type #1 of the KEY 46 Resource Record, which has been obsoleted by RFC3445. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2 Use of DNS address-to-name maps (IN-ADDR.ARPA and 53 IP6.ARPA) . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.3 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . 5 57 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . 5 58 2.3 RDATA format - gateway type . . . . . . . . . . . . . . . . 5 59 2.4 RDATA format - algorithm type . . . . . . . . . . . . . . . 6 60 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . 6 61 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . 6 62 3. Presentation formats . . . . . . . . . . . . . . . . . . . . 8 63 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . 8 64 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4. Security Considerations . . . . . . . . . . . . . . . . . . 10 66 4.1 Active attacks against unsecured IPSECKEY resource 67 records . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 4.1.1 Active attacks against IPSECKEY keying materials . . . . . . 10 69 4.1.2 Active attacks against IPSECKEY gateway material . . . . . . 11 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 71 6. Intellectual Property Claims . . . . . . . . . . . . . . . . 14 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 73 Normative references . . . . . . . . . . . . . . . . . . . . 16 74 Non-normative references . . . . . . . . . . . . . . . . . . 17 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . 17 76 Intellectual Property and Copyright Statements . . . . . . . 18 78 1. Introduction 80 Suppose we have a host which wishes to establish an IPsec tunnel with 81 some remote entity on the network. In many cases this end system 82 will only know a DNS name for the remote entity (whether that DNS 83 name be the name of the remote node, a DNS reverse tree name 84 corresponding to the IP address of the remote node, or perhaps a the 85 domain name portion of a "user@FQDN" name for a remote entity). In 86 these cases the host will need to obtain a public key in order to 87 authenticate the remote entity, and may also need some guidance about 88 whether it should contact the entity directly or use another node as 89 a gateway to the target entity. 91 The IPSECKEY RR provides a storage mechanism for such data as the 92 public key and the gateway information. 94 The type number for the IPSECKEY RR is TBD. 96 This record replaces the functionality of the sub-type #1 of the KEY 97 Resource Record, which has been obsoleted by RFC3445 [12]. 99 1.1 Overview 101 The IPSECKEY resource record (RR) is used to publish a public key 102 that is to be associated with a Domain Name System (DNS)[1] name for 103 use with the IPsec protocol suite. This can be the public key of a 104 host, network, or application (in the case of per-port keying). 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC2119 [7]. 110 1.2 Use of DNS address-to-name maps (IN-ADDR.ARPA and IP6.ARPA) 112 Often a security gateway will only have access to the IP address of 113 the node with which communication is desired, and will not know any 114 other name for the target node. Because of this, it will frequently 115 be the case that the best way of looking up IPSECKEY RRs will be by 116 using the IP address as an index into one of the reverse mapping 117 trees (IN-ADDR.ARPA for IPv4 or IP6.ARPA for IPv6). 119 The lookup is done in the usual fashion as for PTR records. The IP 120 address' octets (IPv4) or nibbles (IPv6) are reversed and looked up 121 with the appropriate suffix. Any CNAMEs or DNAMEs found MUST be 122 followed. 124 Note: even when the IPsec function is the end-host, often only the 125 application will know the forward name used. While the case where the 126 application knows the forward name is common, the user could easily 127 have typed in a literal IP address. This storage mechanism does not 128 preclude using the forward name when it is available, but does not 129 require it. 131 1.3 Usage Criteria 133 An IPSECKEY resource record SHOULD be used in combination with DNSSEC 134 [9] unless some other means of authenticating the IPSECKEY resource 135 record is available. 137 It is expected that there will often be multiple IPSECKEY resource 138 records at the same name. This will be due to the presence of 139 multiple gateways and the need to rollover keys. 141 This resource record is class independent. 143 2. Storage formats 145 2.1 IPSECKEY RDATA format 147 The RDATA for an IPSECKEY RR consists of a precedence value, a 148 gateway type, a public key, algorithm type, and an optional gateway 149 address. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | precedence | gateway type | algorithm | gateway | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + 156 ~ gateway ~ 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | / 159 / public key / 160 / / 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 163 2.2 RDATA format - precedence 165 This is an 8-bit precedence for this record. This is interpreted in 166 the same way as the PREFERENCE field described in section 3.3.9 of 167 RFC1035 [2]. 169 Gateways listed in IPSECKEY records with lower precedence are to be 170 attempted first. Where there is a tie in precedence, the order should 171 be non-deterministic. 173 2.3 RDATA format - gateway type 175 The gateway type field indicates the format of the information that 176 is stored in the gateway field. 178 The following values are defined: 180 0 No gateway is present 182 1 A 4-byte IPv4 address is present 184 2 A 16-byte IPv6 address is present 186 3 A wire-encoded domain name is present. The wire-encoded format is 187 self-describing, so the length is implicit. The domain name MUST 188 NOT be compressed. (see section 3.3 of RFC1035 [2]). 190 2.4 RDATA format - algorithm type 192 The algorithm type field identifies the public key's cryptographic 193 algorithm and determines the format of the public key field. 195 A value of 0 indicates that no key is present. 197 The following values are defined: 199 1 A DSA key is present, in the format defined in RFC2536 [10] 201 2 A RSA key is present, in the format defined in RFC3110 [11] 203 2.5 RDATA format - gateway 205 The gateway field indicates a gateway to which an IPsec tunnel may be 206 created in order to reach the entity named by this resource record. 208 There are three formats: 210 A 32-bit IPv4 address is present in the gateway field. The data 211 portion is an IPv4 address as described in section 3.4.1 of RFC1035 212 [2]. This is a 32-bit number in network byte order. 214 A 128-bit IPv6 address is present in the gateway field. The data 215 portion is an IPv6 address as described in section 2.2 of RFC3596 216 [13]. This is a 128-bit number in network byte order. 218 The gateway field is a normal wire-encoded domain name, as described 219 in section 3.3 of RFC1035 [2]. Compression MUST NOT be used. 221 2.6 RDATA format - public keys 223 Both of the public key types defined in this document (RSA and DSA) 224 inherit their public key formats from the corresponding KEY RR 225 formats. Specifically, the public key field contains the 226 algorithm-specific portion of the KEY RR RDATA, which is all of the 227 KEY RR DATA after the first four octets. This is the same portion of 228 the KEY RR that must be specified by documents that define a DNSSEC 229 algorithm. Those documents also specify a message digest to be used 230 for generation of SIG RRs; that specification is not relevant for 231 IPSECKEY RR. 233 Future algorithms, if they are to be used by both DNSSEC (in the KEY 234 RR) and IPSECKEY, are likely to use the same public key encodings in 235 both records. Unless otherwise specified, the IPSECKEY public key 236 field will contain the algorithm-specific portion of the KEY RR RDATA 237 for the corresponding algorithm. The algorithm must still be 238 designated for use by IPSECKEY, and an IPSECKEY algorithm type number 239 (which might be different than the DNSSEC algorithm number) must be 240 assigned to it. 242 The DSA key format is defined in RFC2536 [10] 244 The RSA key format is defined in RFC3110 [11], with the following 245 changes: 247 The earlier definition of RSA/MD5 in RFC2065 limited the exponent and 248 modulus to 2552 bits in length. RFC3110 extended that limit to 4096 249 bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on 250 RSA public keys, other than the 65535 octet limit imposed by the 251 two-octet length encoding. This length extension is applicable only 252 to IPSECKEY and not to KEY RRs. 254 3. Presentation formats 256 3.1 Representation of IPSECKEY RRs 258 IPSECKEY RRs may appear in a zone data master file. The precedence, 259 gateway type and algorithm and gateway fields are REQUIRED. The 260 base64 encoded public key block is OPTIONAL; if not present, then the 261 public key field of the resource record MUST be construed as being 262 zero octets in length. 264 The algorithm field is an unsigned integer. No mnemonics are defined. 266 If no gateway is to be indicated, then the gateway type field MUST be 267 zero, and the gateway field MUST be "." 269 The Public Key field is represented as a Base64 encoding of the 270 Public Key. Whitespace is allowed within the Base64 text. For a 271 definition of Base64 encoding, see RFC3548 [6] Section 5.2. 273 The general presentation for the record as as follows: 275 IN IPSECKEY ( precedence gateway-type algorithm 276 gateway base64-encoded-public-key ) 278 3.2 Examples 280 An example of a node 192.0.2.38 that will accept IPsec tunnels on its 281 own behalf. 283 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 284 192.0.2.38 285 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 287 An example of a node, 192.0.2.38 that has published its key only. 289 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 290 . 291 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 293 An example of a node, 192.0.2.38 that has delegated authority to the 294 node 192.0.2.3. 296 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 297 192.0.2.3 298 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 300 An example of a node, 192.0.1.38 that has delegated authority to the 301 node with the identity "mygateway.example.com". 303 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 304 mygateway.example.com. 305 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 307 An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has 308 delegated authority to the node 2001:0DB8:c000:0200:2::1 310 $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa. 311 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 312 2001:0DB8:0:8002::2000:1 313 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 315 4. Security Considerations 317 This entire memo pertains to the provision of public keying material 318 for use by key management protocols such as ISAKMP/IKE (RFC2407) [8]. 320 The IPSECKEY resource record contains information that SHOULD be 321 communicated to the end client in an integral fashion - i.e. free 322 from modification. The form of this channel is up to the consumer of 323 the data - there must be a trust relationship between the end 324 consumer of this resource record and the server. This relationship 325 may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to 326 another secure source, a secure local channel on the host, or some 327 combination of the above. 329 The keying material provided by the IPSECKEY resource record is not 330 sensitive to passive attacks. The keying material may be freely 331 disclosed to any party without any impact on the security properties 332 of the resulting IPsec session: IPsec and IKE provide for defense 333 against both active and passive attacks. 335 Any derivative specification that makes use of this resource record 336 MUST carefully document their trust model, and why the trust model of 337 DNSSEC is appropriate, if that is the secure channel used. 339 An active attack on the DNS that caused the wrong IP address to be 340 retrieved (via forged address), and therefore the wrong QNAME to be 341 queried would also result in a man-in-the-middle attack. This 342 situation exists independantly of whether or not the IPSECKEY RR is 343 used. 345 4.1 Active attacks against unsecured IPSECKEY resource records 347 This section deals with active attacks against the DNS. These attacks 348 require that DNS requests and responses be intercepted and changed. 349 DNSSEC is designed to defend against attacks of this kind. This 350 section deals with the situation where DNSSEC is not available. This 351 is not the recommended deployment scenario. 353 4.1.1 Active attacks against IPSECKEY keying materials 355 The first kind of active attack is when the attacker replaces the 356 keying material with either a key under its control or with garbage. 358 The gateway field is either untouched, or is null. The IKE 359 negotiation will therefore occur with the original end-system. For 360 this attack to be successful, the attacker must be able to perform a 361 man-in-the-middle attack on the IKE negotiation. This attack requires 362 that the attacker be able to intercept and modify packets on the 363 forwarding path for the IKE and data packets. 365 If the attacker is not able to perform this man-in-the-middle attack 366 on the IKE negotiation, then this will result in a denial of service, 367 as the IKE negotiation will fail. 369 If the attacker is able to both to mount active attacks against DNS 370 and is also in a position to perform a man-in-the-middle attack on 371 IKE and IPsec negotiations, then the attacker will be in a position 372 to compromise the resulting IPsec channel. Note that an attacker 373 must be able to perform active DNS attacks on both sides of the IKE 374 negotiation in order for this to succeed. 376 4.1.2 Active attacks against IPSECKEY gateway material 378 The second kind of active attack is one in which the attacker 379 replaces the the gateway address to point to a node under the 380 attacker's control. The attacker then either replaces the public key 381 or removes it. If they were to remove the public key, then they 382 could provide an accurate public key of their own in a second record. 384 This second form creates a simple man-in-the-middle since the 385 attacker can then create a second tunnel to the real destination. 386 Note that, as before, this requires that the attacker also mount an 387 active attack against the responder. 389 Note that the man-in-the-middle can not just forward cleartext 390 packets to the original destination. While the destination may be 391 willing to speak in the clear, replying to the original sender, the 392 sender will have already created a policy expecting ciphertext. Thus, 393 the attacker will need to intercept traffic in both directions. In 394 some cases, the attacker may be able to accomplish the full intercept 395 by use of Network Addresss/Port Translation (NAT/NAPT) technology. 397 This attack is easier than the first one because the attacker does 398 NOT need to be on the end-to-end forwarding path. The attacker need 399 only be able to modify DNS replies. This can be done by packet 400 modification, by various kinds of race attacks, or through methods 401 that pollute DNS caches. 403 In cases where the end-to-end integrity of the IPSECKEY RR is 404 suspect, the end client MUST restrict its use of the IPSECKEY RR to 405 cases where the RR owner name matches the content of the gateway 406 field. As the RR owner name is assumed when the gateway field is 407 null, a null gateway field is considered a match. 409 Thus, any records obtained under unverified conditions (e.g. no 410 DNSSEC, or trusted path to source) that have a non-null gateway field 411 MUST be ignored. 413 This restriction eliminates attacks against the gateway field, which 414 are considered much easier, as the attack does not need to be on the 415 forwarding path. 417 In the case of an IPSECKEY RR with a value of three in its gateway 418 type field, the gateway field contains a domain name. The subsequent 419 query required to translate that name into an IP address or IPSECKEY 420 RR will also be subject to man-in-the-middle attacks. If the 421 end-to-end integrity of this second query is suspect, then the 422 provisions above also apply. The IPSECKEY RR MUST be ignored whenever 423 the resulting gateway does not match the QNAME of the original 424 IPSECKEY RR query. 426 5. IANA Considerations 428 This document updates the IANA Registry for DNS Resource Record Types 429 by assigning type X to the IPSECKEY record. 431 This document creates two new IANA registries, both specific to the 432 IPSECKEY Resource Record: 434 This document creates an IANA registry for the algorithm type field. 436 Values 0, 1 and 2 are defined in Section 2.4. Algorithm numbers 3 437 through 255 can be assigned by IETF Consensus (see RFC2434 [5]). 439 This document creates an IANA registry for the gateway type field. 441 Values 0, 1, 2 and 3 are defined in Section 2.3. Gateway type numbers 442 4 through 255 can be assigned by Standards Action (see RFC2434 [5]). 444 6. Intellectual Property Claims 446 The IETF takes no position regarding the validity or scope of any 447 intellectual property or other rights that might be claimed to 448 pertain to the implementation or use of the technology described in 449 this document or the extent to which any license under such rights 450 might or might not be available; neither does it represent that it 451 has made any effort to identify any such rights. Information on the 452 IETF's procedures with respect to rights in standards-track and 453 standards-related documentation can be found in BCP-11. Copies of 454 claims of rights made available for publication and any assurances of 455 licenses to be made available, or the result of an attempt made to 456 obtain a general license or permission for the use of such 457 proprietary rights by implementors or users of this specification can 458 be obtained from the IETF Secretariat. 460 The IETF invites any interested party to bring to its attention any 461 copyrights, patents or patent applications, or other proprietary 462 rights which may cover technology that may be required to practice 463 this standard. Please address the information to the IETF Executive 464 Director. 466 7. Acknowledgments 468 My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob 469 Austein, and Olafur Gurmundsson who reviewed this document carefully. 470 Additional thanks to Olafur Gurmundsson for a reference 471 implementation. 473 Normative references 475 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 476 13, RFC 1034, November 1987. 478 [2] Mockapetris, P., "Domain names - implementation and 479 specification", STD 13, RFC 1035, November 1987. 481 [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 482 9, RFC 2026, October 1996. 484 [4] Eastlake, D. and C. Kaufman, "Domain Name System Security 485 Extensions", RFC 2065, January 1997. 487 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 488 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 490 [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 491 RFC 3548, July 2003. 493 Non-normative references 495 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 496 Levels", BCP 14, RFC 2119, March 1997. 498 [8] Piper, D., "The Internet IP Security Domain of Interpretation 499 for ISAKMP", RFC 2407, November 1998. 501 [9] Eastlake, D., "Domain Name System Security Extensions", RFC 502 2535, March 1999. 504 [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 505 (DNS)", RFC 2536, March 1999. 507 [11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 508 System (DNS)", RFC 3110, May 2001. 510 [12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 511 Record (RR)", RFC 3445, December 2002. 513 [13] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS 514 Extensions to Support IP Version 6", RFC 3596, October 2003. 516 Author's Address 518 Michael C. Richardson 519 Sandelman Software Works 520 470 Dawson Avenue 521 Ottawa, ON K1Z 5V7 522 CA 524 EMail: mcr@sandelman.ottawa.on.ca 525 URI: http://www.sandelman.ottawa.on.ca/ 527 Intellectual Property Statement 529 The IETF takes no position regarding the validity or scope of any 530 Intellectual Property Rights or other rights that might be claimed to 531 pertain to the implementation or use of the technology described in 532 this document or the extent to which any license under such rights 533 might or might not be available; nor does it represent that it has 534 made any independent effort to identify any such rights. Information 535 on the IETF's procedures with respect to rights in IETF Documents can 536 be found in BCP 78 and BCP 79. 538 Copies of IPR disclosures made to the IETF Secretariat and any 539 assurances of licenses to be made available, or the result of an 540 attempt made to obtain a general license or permission for the use of 541 such proprietary rights by implementers or users of this 542 specification can be obtained from the IETF on-line IPR repository at 543 http://www.ietf.org/ipr. 545 The IETF invites any interested party to bring to its attention any 546 copyrights, patents or patent applications, or other proprietary 547 rights that may cover technology that may be required to implement 548 this standard. Please address the information to the IETF at 549 ietf-ipr@ietf.org. 551 Disclaimer of Validity 553 This document and the information contained herein are provided on an 554 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 555 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 556 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 557 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 558 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 559 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 561 Copyright Statement 563 Copyright (C) The Internet Society (2005). This document is subject 564 to the rights, licenses and restrictions contained in BCP 78, and 565 except as set forth therein, the authors retain all their rights. 567 Acknowledgment 569 Funding for the RFC Editor function is currently provided by the 570 Internet Society.