idnits 2.17.1 draft-ietf-ipseckey-rr-11.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 556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 546. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 562), 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 546), which is fine, but *also* found old RFC 2026, Section 10.4B text on line 461. ** 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 100 has weird spacing: '... be the publi...' == Line 166 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 (July 17, 2004) is 7195 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 472, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 478, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 481, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 498, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 507, 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 (~~), 11 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: January 15, 2005 July 17, 2004 6 A Method for Storing IPsec Keying Material in DNS 7 draft-ietf-ipseckey-rr-11.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 January 15, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). 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 1.1 Overview 98 The IPSECKEY resource record (RR) is used to publish a public key 99 that is to be associated with a Domain Name System (DNS) name for use 100 with the IPsec protocol suite. This can be the public key of a 101 host, network, or application (in the case of per-port keying). 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC2119 [7]. 107 1.2 Use of DNS address-to-name maps (IN-ADDR.ARPA and IP6.ARPA) 109 Often a security gateway will only have access to the IP address of 110 the node with which communication is desired, and will not know any 111 other name for the target node. Because of this, it will frequently 112 be the case that the best way of looking up IPSECKEY RRs will be by 113 using the IP address as an index into one of the reverse mapping 114 trees (IN-ADDR.ARPA for IPv4 or IP6.ARPA for IPv6). 116 The lookup is done in the usual fashion as for PTR records. The IP 117 address' octets (IPv4) or nibbles (IPv6) are reversed and looked up 118 with the appropriate suffix. Any CNAMEs or DNAMEs found MUST be 119 followed. 121 Note: even when the IPsec function is the end-host, often only the 122 application will know the forward name used. While the case where the 123 application knows the forward name is common, the user could easily 124 have typed in a literal IP address. This storage mechanism does not 125 preclude using the forward name when it is available, but does not 126 require it. 128 1.3 Usage Criteria 130 An IPSECKEY resource record SHOULD be used in combination with DNSSEC 131 unless some other means of authenticating the IPSECKEY resource 132 record is available. 134 It is expected that there will often be multiple IPSECKEY resource 135 records at the same name. This will be due to the presence of 136 multiple gateways and the need to rollover keys. 138 This resource record is class independent. 140 2. Storage formats 142 2.1 IPSECKEY RDATA format 144 The RDATA for an IPSECKEY RR consists of a precedence value, a 145 gateway type, a public key, algorithm type, and an optional gateway 146 address. 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | precedence | gateway type | algorithm | gateway | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + 153 ~ gateway ~ 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | / 156 / public key / 157 / / 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 160 2.2 RDATA format - precedence 162 This is an 8-bit precedence for this record. This is interpreted in 163 the same way as the PREFERENCE field described in section 3.3.9 of 164 RFC1035 [2]. 166 Gateways listed in IPSECKEY records with lower precedence are to be 167 attempted first. Where there is a tie in precedence, the order should 168 be non-deterministic. 170 2.3 RDATA format - gateway type 172 The gateway type field indicates the format of the information that 173 is stored in the gateway field. 175 The following values are defined: 177 0 No gateway is present 179 1 A 4-byte IPv4 address is present 181 2 A 16-byte IPv6 address is present 183 3 A wire-encoded domain name is present. The wire-encoded format is 184 self-describing, so the length is implicit. The domain name MUST 185 NOT be compressed. (see section 3.3 of RFC1035 [2]). 187 2.4 RDATA format - algorithm type 189 The algorithm type field identifies the public key's cryptographic 190 algorithm and determines the format of the public key field. 192 A value of 0 indicates that no key is present. 194 The following values are defined: 196 1 A DSA key is present, in the format defined in RFC2536 [10] 198 2 A RSA key is present, in the format defined in RFC3110 [11] 200 2.5 RDATA format - gateway 202 The gateway field indicates a gateway to which an IPsec tunnel may be 203 created in order to reach the entity named by this resource record. 205 There are three formats: 207 A 32-bit IPv4 address is present in the gateway field. The data 208 portion is an IPv4 address as described in section 3.4.1 of RFC1035 209 [2]. This is a 32-bit number in network byte order. 211 A 128-bit IPv6 address is present in the gateway field. The data 212 portion is an IPv6 address as described in section 2.2 of RFC3596 213 [13]. This is a 128-bit number in network byte order. 215 The gateway field is a normal wire-encoded domain name, as described 216 in section 3.3 of RFC1035 [2]. Compression MUST NOT be used. 218 2.6 RDATA format - public keys 220 Both of the public key types defined in this document (RSA and DSA) 221 inherit their public key formats from the corresponding KEY RR 222 formats. Specifically, the public key field contains the 223 algorithm-specific portion of the KEY RR RDATA, which is all of the 224 KEY RR DATA after the first four octets. This is the same portion of 225 the KEY RR that must be specified by documents that define a DNSSEC 226 algorithm. Those documents also specify a message digest to be used 227 for generation of SIG RRs; that specification is not relevant for 228 IPSECKEY RR. 230 Future algorithms, if they are to be used by both DNSSEC (in the KEY 231 RR) and IPSECKEY, are likely to use the same public key encodings in 232 both records. Unless otherwise specified, the IPSECKEY public key 233 field will contain the algorithm-specific portion of the KEY RR RDATA 234 for the corresponding algorithm. The algorithm must still be 235 designated for use by IPSECKEY, and an IPSECKEY algorithm type number 236 (which might be different than the DNSSEC algorithm number) must be 237 assigned to it. 239 The DSA key format is defined in RFC2536 [10] 241 The RSA key format is defined in RFC3110 [11], with the following 242 changes: 244 The earlier definition of RSA/MD5 in RFC2065 limited the exponent and 245 modulus to 2552 bits in length. RFC3110 extended that limit to 4096 246 bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on 247 RSA public keys, other than the 65535 octet limit imposed by the 248 two-octet length encoding. This length extension is applicable only 249 to IPSECKEY and not to KEY RRs. 251 3. Presentation formats 253 3.1 Representation of IPSECKEY RRs 255 IPSECKEY RRs may appear in a zone data master file. The precedence, 256 gateway type and algorithm and gateway fields are REQUIRED. The 257 base64 encoded public key block is OPTIONAL; if not present, then the 258 public key field of the resource record MUST be construed as being 259 zero octets in length. 261 The algorithm field is an unsigned integer. No mnemonics are defined. 263 If no gateway is to be indicated, then the gateway type field MUST be 264 zero, and the gateway field MUST be "." 266 The Public Key field is represented as a Base64 encoding of the 267 Public Key. Whitespace is allowed within the Base64 text. For a 268 definition of Base64 encoding, see RFC3548 [6] Section 5.2. 270 The general presentation for the record as as follows: 272 IN IPSECKEY ( precedence gateway-type algorithm 273 gateway base64-encoded-public-key ) 275 3.2 Examples 277 An example of a node 192.0.2.38 that will accept IPsec tunnels on its 278 own behalf. 280 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 281 192.0.2.38 282 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 284 An example of a node, 192.0.2.38 that has published its key only. 286 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 287 . 288 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 290 An example of a node, 192.0.2.38 that has delegated authority to the 291 node 192.0.2.3. 293 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 294 192.0.2.3 295 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 297 An example of a node, 192.0.1.38 that has delegated authority to the 298 node with the identity "mygateway.example.com". 300 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 301 mygateway.example.com. 302 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 304 An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has 305 delegated authority to the node 2001:0DB8:c000:0200:2::1 307 $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa. 308 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 309 2001:0DB8:0:8002::2000:1 310 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 312 4. Security Considerations 314 This entire memo pertains to the provision of public keying material 315 for use by key management protocols such as ISAKMP/IKE (RFC2407) [8]. 317 The IPSECKEY resource record contains information that SHOULD be 318 communicated to the end client in an integral fashion - i.e. free 319 from modification. The form of this channel is up to the consumer of 320 the data - there must be a trust relationship between the end 321 consumer of this resource record and the server. This relationship 322 may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to 323 another secure source, a secure local channel on the host, or some 324 combination of the above. 326 The keying material provided by the IPSECKEY resource record is not 327 sensitive to passive attacks. The keying material may be freely 328 disclosed to any party without any impact on the security properties 329 of the resulting IPsec session: IPsec and IKE provide for defense 330 against both active and passive attacks. 332 Any derivative specification that makes use of this resource record 333 MUST carefully document their trust model, and why the trust model of 334 DNSSEC is appropriate, if that is the secure channel used. 336 An active attack on the DNS that caused the wrong IP address to be 337 retrieved (via forged address), and therefore the wrong QNAME to be 338 queried would also result in a man-in-the-middle attack. This 339 situation exists independantly of whether or not the IPSECKEY RR is 340 used. 342 4.1 Active attacks against unsecured IPSECKEY resource records 344 This section deals with active attacks against the DNS. These attacks 345 require that DNS requests and responses be intercepted and changed. 346 DNSSEC is designed to defend against attacks of this kind. This 347 section deals with the situation where DNSSEC is not available. This 348 is not the recommended deployment scenario. 350 4.1.1 Active attacks against IPSECKEY keying materials 352 The first kind of active attack is when the attacker replaces the 353 keying material with either a key under its control or with garbage. 355 The gateway field is either untouched, or is null. The IKE 356 negotiation will therefore occur with the original end-system. For 357 this attack to be successful, the attacker must be able to perform a 358 man-in-the-middle attack on the IKE negotiation. This attack requires 359 that the attacker be able to intercept and modify packets on the 360 forwarding path for the IKE and data packets. 362 If the attacker is not able to perform this man-in-the-middle attack 363 on the IKE negotiation, then this will result in a denial of service, 364 as the IKE negotiation will fail. 366 If the attacker is able to both to mount active attacks against DNS 367 and is also in a position to perform a man-in-the-middle attack on 368 IKE and IPsec negotiations, then the attacker will be in a position 369 to compromise the resulting IPsec channel. Note that an attacker 370 must be able to perform active DNS attacks on both sides of the IKE 371 negotiation in order for this to succeed. 373 4.1.2 Active attacks against IPSECKEY gateway material 375 The second kind of active attack is one in which the attacker 376 replaces the the gateway address to point to a node under the 377 attacker's control. The attacker then either replaces the public key 378 or removes it. If they were to remove the public key, then they 379 could provide an accurate public key of their own in a second record. 381 This second form creates a simple man-in-the-middle since the 382 attacker can then create a second tunnel to the real destination. 383 Note that, as before, this requires that the attacker also mount an 384 active attack against the responder. 386 Note that the man-in-the-middle can not just forward cleartext 387 packets to the original destination. While the destination may be 388 willing to speak in the clear, replying to the original sender, the 389 sender will have already created a policy expecting ciphertext. Thus, 390 the attacker will need to intercept traffic in both directions. In 391 some cases, the attacker may be able to accomplish the full intercept 392 by use of Network Addresss/Port Translation (NAT/NAPT) technology. 394 This attack is easier than the first one because the attacker does 395 NOT need to be on the end-to-end forwarding path. The attacker need 396 only be able to modify DNS replies. This can be done by packet 397 modification, by various kinds of race attacks, or through methods 398 that pollute DNS caches. 400 In cases where the end-to-end integrity of the IPSECKEY RR is 401 suspect, the end client MUST restrict its use of the IPSECKEY RR to 402 cases where the RR owner name matches the content of the gateway 403 field. As the RR owner name is assumed when the gateway field is 404 null, a null gateway field is considered a match. 406 Thus, any records obtained under unverified conditions (e.g. no 407 DNSSEC, or trusted path to source) that have a non-null gateway field 408 MUST be ignored. 410 This restriction eliminates attacks against the gateway field, which 411 are considered much easier, as the attack does not need to be on the 412 forwarding path. 414 In the case of an IPSECKEY RR with a value of three in its gateway 415 type field, the gateway field contains a domain name. The subsequent 416 query required to translate that name into an IP address or IPSECKEY 417 RR will also be subject to man-in-the-middle attacks. If the 418 end-to-end integrity of this second query is suspect, then the 419 provisions above also apply. The IPSECKEY RR MUST be ignored whenever 420 the resulting gateway does not match the QNAME of the original 421 IPSECKEY RR query. 423 5. IANA Considerations 425 This document updates the IANA Registry for DNS Resource Record Types 426 by assigning type X to the IPSECKEY record. 428 This document creates two new IANA registries, both specific to the 429 IPSECKEY Resource Record: 431 This document creates an IANA registry for the algorithm type field. 433 Values 0, 1 and 2 are defined in Section 2.4. Algorithm numbers 3 434 through 255 can be assigned by IETF Consensus (see RFC2434 [5]). 436 This document creates an IANA registry for the gateway type field. 438 Values 0, 1, 2 and 3 are defined in Section 2.3. Gateway type numbers 439 4 through 255 can be assigned by Standards Action (see RFC2434 [5]). 441 6. Intellectual Property Claims 443 The IETF takes no position regarding the validity or scope of any 444 intellectual property or other rights that might be claimed to 445 pertain to the implementation or use of the technology described in 446 this document or the extent to which any license under such rights 447 might or might not be available; neither does it represent that it 448 has made any effort to identify any such rights. Information on the 449 IETF's procedures with respect to rights in standards-track and 450 standards-related documentation can be found in BCP-11. Copies of 451 claims of rights made available for publication and any assurances of 452 licenses to be made available, or the result of an attempt made to 453 obtain a general license or permission for the use of such 454 proprietary rights by implementors or users of this specification can 455 be obtained from the IETF Secretariat. 457 The IETF invites any interested party to bring to its attention any 458 copyrights, patents or patent applications, or other proprietary 459 rights which may cover technology that may be required to practice 460 this standard. Please address the information to the IETF Executive 461 Director. 463 7. Acknowledgments 465 My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob 466 Austein, and Olafur Gurmundsson who reviewed this document carefully. 467 Additional thanks to Olafur Gurmundsson for a reference 468 implementation. 470 Normative references 472 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 473 13, RFC 1034, November 1987. 475 [2] Mockapetris, P., "Domain names - implementation and 476 specification", STD 13, RFC 1035, November 1987. 478 [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 479 9, RFC 2026, October 1996. 481 [4] Eastlake, D. and C. Kaufman, "Domain Name System Security 482 Extensions", RFC 2065, January 1997. 484 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 485 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 487 [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 488 RFC 3548, July 2003. 490 Non-normative references 492 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 493 Levels", BCP 14, RFC 2119, March 1997. 495 [8] Piper, D., "The Internet IP Security Domain of Interpretation 496 for ISAKMP", RFC 2407, November 1998. 498 [9] Eastlake, D., "Domain Name System Security Extensions", RFC 499 2535, March 1999. 501 [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 502 (DNS)", RFC 2536, March 1999. 504 [11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 505 System (DNS)", RFC 3110, May 2001. 507 [12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 508 Record (RR)", RFC 3445, December 2002. 510 [13] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS 511 Extensions to Support IP Version 6", RFC 3596, October 2003. 513 Author's Address 515 Michael C. Richardson 516 Sandelman Software Works 517 470 Dawson Avenue 518 Ottawa, ON K1Z 5V7 519 CA 521 EMail: mcr@sandelman.ottawa.on.ca 522 URI: http://www.sandelman.ottawa.on.ca/ 524 Intellectual Property Statement 526 The IETF takes no position regarding the validity or scope of any 527 Intellectual Property Rights or other rights that might be claimed to 528 pertain to the implementation or use of the technology described in 529 this document or the extent to which any license under such rights 530 might or might not be available; nor does it represent that it has 531 made any independent effort to identify any such rights. Information 532 on the IETF's procedures with respect to rights in IETF Documents can 533 be found in BCP 78 and BCP 79. 535 Copies of IPR disclosures made to the IETF Secretariat and any 536 assurances of licenses to be made available, or the result of an 537 attempt made to obtain a general license or permission for the use of 538 such proprietary rights by implementers or users of this 539 specification can be obtained from the IETF on-line IPR repository at 540 http://www.ietf.org/ipr. 542 The IETF invites any interested party to bring to its attention any 543 copyrights, patents or patent applications, or other proprietary 544 rights that may cover technology that may be required to implement 545 this standard. Please address the information to the IETF at 546 ietf-ipr@ietf.org. 548 Disclaimer of Validity 550 This document and the information contained herein are provided on an 551 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 552 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 553 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 554 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 555 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 556 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 558 Copyright Statement 560 Copyright (C) The Internet Society (2004). This document is subject 561 to the rights, licenses and restrictions contained in BCP 78, and 562 except as set forth therein, the authors retain all their rights. 564 Acknowledgment 566 Funding for the RFC Editor function is currently provided by the 567 Internet Society.