idnits 2.17.1 draft-ietf-ipseckey-rr-09.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 95 has weird spacing: '... be the publi...' == Line 164 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 (February 2004) is 7374 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 463, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 469, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 472, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 491, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 500, 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: 4 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: August 1, 2004 February 2004 6 A Method for Storing IPsec Keying Material in DNS 7 | draft-ietf-ipseckey-rr-09.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 August 1, 2004. 32 Copyright Notice 34 | Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 | This document describes a new resource record for Domain Name System 39 | (DNS). This record may be used to store public keys for use in IP 40 | security (IPsec) systems. The record also includes provisions for 41 | indicating what system should be contacted when establishing an IPsec 42 | tunnel with the entity in question. 44 This record replaces the functionality of the sub-type #1 of the KEY 45 Resource Record, which has been obsoleted by RFC3445. 47 |Internet-Draft Storing IPsec keying material in DNS February 2004 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 | 1.2 Use of reverse (in-addr.arpa) map . . . . . . . . . . . . . . 3 54 | 1.3 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . . 3 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 records . . 10 67 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 | 6. Intellectual Property Claims . . . . . . . . . . . . . . . . . 13 69 | 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 70 | Normative references . . . . . . . . . . . . . . . . . . . . . 15 71 | Non-normative references . . . . . . . . . . . . . . . . . . . 16 72 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 73 | Full Copyright Statement . . . . . . . . . . . . . . . . . . . 17 74 |Internet-Draft Storing IPsec keying material in DNS February 2004 76 1. Introduction 78 It postulated that there is an end system desiring to establish an 79 IPsec tunnel with some remote entity on the network. This system, 80 having only a DNS name of some kind (forward, reverse or even 81 user@FQDN) needs a public key to authenticate the remote entity. It 82 also desires some guidance about whether to contact the entity 83 directly, or whether to contact another entity, as the gateway to 84 that desired entity. 86 The IPSECKEY RR provides a storage mechanism for such items as the 87 public key, and the gateway information. 89 The type number for the IPSECKEY RR is TBD. 91 1.1 Overview 93 The IPSECKEY resource record (RR) is used to publish a public key 94 that is to be associated with a Domain Name System (DNS) name for use 95 with the IPsec protocol suite. This can be the public key of a 96 host, network, or application (in the case of per-port keying). 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC2119 [7]. 102 |1.2 Use of reverse (in-addr.arpa) map 104 | Often a security gateway will only have access to the IP address to 105 | which communication is desired. It will not know the forward name. 106 | As such, it will frequently be the case that the IP address will be 107 | used an index into the reverse map. 109 | The lookup is done in the usual fashion as for PTR records. The IP 110 | address' octets (IPv4) or nibbles (IPv6) are reversed and looked up 111 | under the .arpa. zone. Any CNAMEs or DNAMEs found SHOULD be 112 | followed. 114 | Note: even when the IPsec function is the end-host, often only the 115 | application will know the forward name used. While the case where 116 | the application knows the forward name is common, the user could 117 | easily have typed in a literal IP address. This storage mechanism 118 | does not preclude using the forward name when it is available, but 119 | does not require it. 121 |1.3 Usage Criteria 123 An IPSECKEY resource record SHOULD be used in combination with DNSSEC 125 |Internet-Draft Storing IPsec keying material in DNS February 2004 127 unless some other means of authenticating the IPSECKEY resource 128 record is available. 130 It is expected that there will often be multiple IPSECKEY resource 131 records at the same name. This will be due to the presence of 132 multiple gateways and the need to rollover keys. 134 This resource record is class independent. 136 |Internet-Draft Storing IPsec keying material in DNS February 2004 138 2. Storage formats 140 2.1 IPSECKEY RDATA format 142 The RDATA for an IPSECKEY RR consists of a precedence value, a 143 gateway type, a public key, algorithm type, and an optional gateway 144 address. 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | precedence | gateway type | algorithm | gateway | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + 151 ~ gateway ~ 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | / 154 / public key / 155 / / 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 158 2.2 RDATA format - precedence 160 This is an 8-bit precedence for this record. This is interpreted in 161 the same way as the PREFERENCE field described in section 3.3.9 of 162 RFC1035 [2]. 164 Gateways listed in IPSECKEY records with lower precedence are to be 165 attempted first. Where there is a tie in precedence, the order 166 should be non-deterministic. 168 2.3 RDATA format - gateway type 170 The gateway type field indicates the format of the information that 171 is stored in the gateway field. 173 The following values are defined: 175 0 No gateway is present 177 1 A 4-byte IPv4 address is present 179 2 A 16-byte IPv6 address is present 181 3 A wire-encoded domain name is present. The wire-encoded format is 182 self-describing, so the length is implicit. The domain name MUST 183 NOT be compressed. (see section 3.3 of RFC1035 [2]). 185 |Internet-Draft Storing IPsec keying material in DNS February 2004 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 algorithm- 223 specific portion of the KEY RR RDATA, which is all of the KEY RR DATA 224 after the first four octets. This is the same portion of the KEY RR 225 that must be specified by documents that define a DNSSEC algorithm. 226 Those documents also specify a message digest to be used for 227 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 235 |Internet-Draft Storing IPsec keying material in DNS February 2004 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 two- 251 octet length encoding. This length extension is applicable only to 252 IPSECKEY and not to KEY RRs. 254 |Internet-Draft Storing IPsec keying material in DNS February 2004 256 3. Presentation formats 258 3.1 Representation of IPSECKEY RRs 260 IPSECKEY RRs may appear in a zone data master file. The precedence, 261 gateway type and algorithm and gateway fields are REQUIRED. The 262 base64 encoded public key block is OPTIONAL; if not present, then the 263 public key field of the resource record MUST be construed as being 264 zero octets in length. 266 The algorithm field is an unsigned integer. No mnemonics are 267 defined. 269 If no gateway is to be indicated, then the gateway type field MUST be 270 zero, and the gateway field MUST be "." 272 The Public Key field is represented as a Base64 encoding of the 273 Public Key. Whitespace is allowed within the Base64 text. For a 274 definition of Base64 encoding, see RFC3548 [6] Section 5.2. 276 The general presentation for the record as as follows: 278 IN IPSECKEY ( precedence gateway-type algorithm 279 gateway base64-encoded-public-key ) 281 3.2 Examples 283 An example of a node 192.0.2.38 that will accept IPsec tunnels on its 284 own behalf. 286 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 287 192.0.2.38 288 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 290 An example of a node, 192.0.2.38 that has published its key only. 292 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 293 . 294 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 296 An example of a node, 192.0.2.38 that has delegated authority to the 297 node 192.0.2.3. 299 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 300 192.0.2.3 301 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 303 |Internet-Draft Storing IPsec keying material in DNS February 2004 305 An example of a node, 192.0.1.38 that has delegated authority to the 306 node with the identity "mygateway.example.com". 308 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 309 mygateway.example.com. 310 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 312 An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has 313 delegated authority to the node 2001:0DB8:c000:0200:2::1 315 $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa. 316 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 317 2001:0DB8:0:8002::2000:1 318 AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) 320 |Internet-Draft Storing IPsec keying material in DNS February 2004 322 4. Security Considerations 324 This entire memo pertains to the provision of public keying material 325 for use by key management protocols such as ISAKMP/IKE (RFC2407) [8]. 327 The IPSECKEY resource record contains information that SHOULD be 328 communicated to the end client in an integral fashion - i.e. free 329 from modification. The form of this channel is up to the consumer of 330 the data - there must be a trust relationship between the end 331 consumer of this resource record and the server. This relationship 332 may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to 333 another secure source, a secure local channel on the host, or some 334 combination of the above. 336 The keying material provided by the IPSECKEY resource record is not 337 sensitive to passive attacks. The keying material may be freely 338 disclosed to any party without any impact on the security properties 339 of the resulting IPsec session: IPsec and IKE provide for defense 340 against both active and passive attacks. 342 Any derivative standard that makes use of this resource record MUST 343 carefully document their trust model, and why the trust model of 344 DNSSEC is appropriate, if that is the secure channel used. 346 4.1 Active attacks against unsecured IPSECKEY resource records 348 This section deals with active attacks against the DNS. These 349 attacks require that DNS requests and responses be intercepted and 350 changed. DNSSEC is designed to defend against attacks of this kind. 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 If the attacker is not able to mount a subsequent man-in-the-middle 356 attack on the IKE negotiation after replacing the public key, then 357 this will result in a denial of service, as the authenticator used by 358 IKE would fail. 360 If the attacker is able to both to mount active attacks against DNS 361 and is also in a position to perform a man-in-the-middle attack on 362 IKE and IPsec negotiations, then the attacker will be in a position 363 to compromise the resulting IPsec channel. Note that an attacker 364 must be able to perform active DNS attacks on both sides of the IKE 365 negotiation in order for this to succeed. 367 The second kind of active attack is one in which the attacker 368 replaces the the gateway address to point to a node under the 369 attacker's control. The attacker can then either replace the public 371 |Internet-Draft Storing IPsec keying material in DNS February 2004 373 key or remove it, thus providing an IPSECKEY record of its own to 374 match the gateway address. 376 This later form creates a simple man-in-the-middle since the attacker 377 can then create a second tunnel to the real destination. Note that, 378 as before, this requires that the attacker also mount an active 379 attack against the responder. 381 Note that the man-in-the-middle can not just forward cleartext 382 packets to the original destination. While the destination may be 383 willing to speak in the clear, replying to the original sender, the 384 sender will have already created a policy expecting ciphertext. 385 Thus, the attacker will need to intercept traffic from both sides. 386 In some cases, the attacker may be able to accomplish the full 387 intercept by use of Network Addresss/Port Translation (NAT/NAPT) 388 technology. 390 | Note that risk of a man-in-the-middle attack mediated by the IPSECKEY 391 | RR only applies to cases where the gateway field of the IPSECKEY RR 392 | indicates a different entity than the owner name of the IPSECKEY RR. 394 | An active attack on the DNS that caused the wrong IP address to be 395 | retrieved (via forged A RR), and therefore the wrong QNAME to be 396 | queried would also result in a man-in-the-middle attack. This 397 | situation exists independantly of whether or not the IPSECKEY RR is 398 | used. 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. 405 |Internet-Draft Storing IPsec keying material in DNS February 2004 407 5. IANA Considerations 409 This document updates the IANA Registry for DNS Resource Record Types 410 by assigning type X to the IPSECKEY record. 412 This document creates two new IANA registries, both specific to the 413 IPSECKEY Resource Record: 415 This document creates an IANA registry for the algorithm type field. 417 Values 0, 1 and 2 are defined in Section 2.4. Algorithm numbers 3 418 through 255 can be assigned by IETF Consensus (see RFC2434 [5]). 420 This document creates an IANA registry for the gateway type field. 422 Values 0, 1, 2 and 3 are defined in Section 2.3. Gateway type 423 numbers 4 through 255 can be assigned by Standards Action (see 424 RFC2434 [5]). 426 |Internet-Draft Storing IPsec keying material in DNS February 2004 428 6. Intellectual Property Claims 430 The IETF takes no position regarding the validity or scope of any 431 intellectual property or other rights that might be claimed to 432 pertain to the implementation or use of the technology described in 433 this document or the extent to which any license under such rights 434 might or might not be available; neither does it represent that it 435 has made any effort to identify any such rights. Information on the 436 IETF's procedures with respect to rights in standards-track and 437 standards-related documentation can be found in BCP-11. Copies of 438 claims of rights made available for publication and any assurances of 439 licenses to be made available, or the result of an attempt made to 440 obtain a general license or permission for the use of such 441 proprietary rights by implementors or users of this specification can 442 be obtained from the IETF Secretariat. 444 The IETF invites any interested party to bring to its attention any 445 copyrights, patents or patent applications, or other proprietary 446 rights which may cover technology that may be required to practice 447 this standard. Please address the information to the IETF Executive 448 Director. 450 |Internet-Draft Storing IPsec keying material in DNS February 2004 452 7. Acknowledgments 454 My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob 455 Austein, and Olafur Gurmundsson who reviewed this document carefully. 456 Additional thanks to Olafur Gurmundsson for a reference 457 implementation. 459 |Internet-Draft Storing IPsec keying material in DNS February 2004 461 Normative references 463 [1] Mockapetris, P., "Domain names - concepts and facilities", STD 464 13, RFC 1034, November 1987. 466 [2] Mockapetris, P., "Domain names - implementation and 467 specification", STD 13, RFC 1035, November 1987. 469 [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 470 9, RFC 2026, October 1996. 472 [4] Eastlake, D. and C. Kaufman, "Domain Name System Security 473 Extensions", RFC 2065, January 1997. 475 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 476 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 478 [6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 479 RFC 3548, July 2003. 481 |Internet-Draft Storing IPsec keying material in DNS February 2004 483 Non-normative references 485 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 486 Levels", BCP 14, RFC 2119, March 1997. 488 [8] Piper, D., "The Internet IP Security Domain of Interpretation 489 for ISAKMP", RFC 2407, November 1998. 491 [9] Eastlake, D., "Domain Name System Security Extensions", RFC 492 2535, March 1999. 494 [10] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System 495 (DNS)", RFC 2536, March 1999. 497 [11] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name 498 System (DNS)", RFC 3110, May 2001. 500 [12] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource 501 Record (RR)", RFC 3445, December 2002. 503 [13] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS 504 Extensions to Support IP Version 6", RFC 3596, October 2003. 506 Author's Address 508 Michael C. Richardson 509 Sandelman Software Works 510 470 Dawson Avenue 511 Ottawa, ON K1Z 5V7 512 CA 514 EMail: mcr@sandelman.ottawa.on.ca 515 URI: http://www.sandelman.ottawa.on.ca/ 517 |Internet-Draft Storing IPsec keying material in DNS February 2004 519 Full Copyright Statement 521 | Copyright (C) The Internet Society (2004). All Rights Reserved. 523 This document and translations of it may be copied and furnished to 524 others, and derivative works that comment on or otherwise explain it 525 or assist in its implementation may be prepared, copied, published 526 and distributed, in whole or in part, without restriction of any 527 kind, provided that the above copyright notice and this paragraph are 528 included on all such copies and derivative works. However, this 529 document itself may not be modified in any way, such as by removing 530 the copyright notice or references to the Internet Society or other 531 Internet organizations, except as needed for the purpose of 532 developing Internet standards in which case the procedures for 533 copyrights defined in the Internet Standards process must be 534 followed, or as required to translate it into languages other than 535 English. 537 The limited permissions granted above are perpetual and will not be 538 revoked by the Internet Society or its successors or assigns. 540 This document and the information contained herein is provided on an 541 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 542 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 543 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 544 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 545 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 547 Acknowledgement 549 Funding for the RFC Editor function is currently provided by the 550 Internet Society.