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