idnits 2.17.1 draft-ietf-ipsec-ciph-aes-gcm-00.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 == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 1) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 27, 2004) is 7303 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: 'RFC2675' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'RFC3610' is defined on line 423, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Viega 3 Internet-Draft Secure Software, Inc. 4 Expires: October 26, 2004 D. McGrew 5 Cisco Systems, Inc. 6 April 27, 2004 8 The Use of Galois/Counter Mode (GCM) in IPsec ESP 9 draft-ietf-ipsec-ciph-aes-gcm-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 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 October 26, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This memo describes the use of the Advanced Encryption Standard (AES) 40 in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security 41 Payload (ESP) mechanism to provide confidentiality and data origin 42 authentication. This method can be efficiently implemented in 43 hardware for speeds of 10 gigabits per second and above, and is also 44 well-suited to software implementations. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1 Conventions Used In This Document . . . . . . . . . . . . . . 3 50 2. AES-GCM . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. ESP Payload Data . . . . . . . . . . . . . . . . . . . . . . . 5 52 3.1 Initialization Vector (IV) . . . . . . . . . . . . . . . . . . 5 53 3.2 Ciphertext . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Nonce Format . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. AAD Construction . . . . . . . . . . . . . . . . . . . . . . . 7 56 6. Integrity Check Value (ICV) . . . . . . . . . . . . . . . . . 8 57 7. Packet Expansion . . . . . . . . . . . . . . . . . . . . . . . 9 58 8. IKE Conventions . . . . . . . . . . . . . . . . . . . . . . . 10 59 8.1 Keying Material and Salt Values . . . . . . . . . . . . . . . 10 60 8.2 Phase 1 Identifier . . . . . . . . . . . . . . . . . . . . . . 10 61 8.3 Phase 2 Identifier . . . . . . . . . . . . . . . . . . . . . . 10 62 8.4 Key Length Attribute . . . . . . . . . . . . . . . . . . . . . 11 63 9. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 11. Design Rationale . . . . . . . . . . . . . . . . . . . . . . . 14 66 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 68 Normative References . . . . . . . . . . . . . . . . . . . . . 17 69 Informative References . . . . . . . . . . . . . . . . . . . . 18 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 71 Intellectual Property and Copyright Statements . . . . . . . . 20 73 1. Introduction 75 This document describes the use of AES in GCM mode (AES-GCM) as an 76 IPSec ESP mechanism for confidentiality and data origin 77 authentication. We refer to this method as AES-GCM-ESP. This 78 mechanism is not only efficient and secure, it also enables 79 high-speed implementations in hardware, and thus allows IPsec 80 connections that can make effective use of emerging 10-gigabit and 81 40-gigabit network devices. 83 Counter mode (CTR) has emerged as the preffered encryption method for 84 high-speed implementations. Unlike conventional encryption modes 85 like CBC and CBC-MAC, CTR can be efficiently implemented at high data 86 rates because it can be pipelined. The ESP CTR protocol describes 87 how this mode can be used with IPsec ESP [RFC3686]. 89 Unfortunately, CTR provides no data origin authentication, and thus 90 the ESP CTR standard requires the use of a data origin authentication 91 algorithm in conjunction with CTR. This requirement is problematic, 92 because none of the standard data origin authentication algorithms 93 can be efficiently implemented for high data rates. GCM solves this 94 problem, because under the hood, it combines CTR mode with a secure, 95 parallelizable and efficient authentication mechanism. 97 This document does not cover implementation details of GCM. Those 98 details can be found in [GCM], along with test vectors. 100 1.1 Conventions Used In This Document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2. AES-GCM 108 GCM is a block cipher mode of operation providing both 109 confidentiality and data origin authentication. The GCM 110 authenticated encryption operation has four inputs: a secret key, an 111 initialization vector (IV), a plaintext, and an input for additional 112 authenticated data (AAD). It has two outputs, a ciphertext whose 113 length is identical to the plaintext, and an authentication tag. In 114 the following, we describe how the IV, plaintext, and AAD are formed 115 from the ESP fields, and how the ESP packet is formed from the 116 ciphertext and authentication tag. 118 ESP also defines an IV. For clarity, we refer to the AES-GCM IV as a 119 nonce in the context of AES-GCM-ESP. The same nonce and key 120 combination MUST NOT be used more than once. 122 Since reusing an nonce/key combination destroys the security 123 guarantees of AES-GCM mode, it can be difficult to use this mode 124 securely when using statically configured keys. For safety's sake, 125 implementations MUST use an automated key mangement system, such as 126 the Internet Key Exchange (IKE) [RFC2409], to ensure that this 127 requirement is met. 129 3. ESP Payload Data 131 The ESP Payload Data is comprised of an eight-octet initialization 132 vector (IV) followed by the ciphertext. The payload field, as 133 defined in [RFC2406], is structured as shown in Figure 1, along with 134 the ICV associated with the payload. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Initialization Vector | 140 | (8 octets) | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | | 143 ~ Ciphertext (variable) ~ 144 | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Figure 1: ESP Payload Encrytped with AES-GCM. 149 3.1 Initialization Vector (IV) 151 The AES-GCM-ESP IV field MUST be eight octets. For a given key, the 152 IV MUST NOT repeat. The most natural way to implement this is with a 153 counter, but it can be anything that guarantees uniqueness, such as a 154 linear feedback shift register (LFSR). Note that the encrypter can 155 use any IV generation method that meets the uniqueness requirement, 156 without coordinating with the decrypter. 158 3.2 Ciphertext 160 The plaintext input to AES-GCM is formed by concatenating the 161 plaintext data described by the Next Header field with the Padding, 162 the Pad Length, and the Next Header field. The Ciphertext field 163 consists of the ciphertext output from the AES-GCM algorithm. The 164 length of the ciphertext is identical to that of the plaintext. 166 Implementations that do not seek to hide the length of the plaintext 167 SHOULD use the minimum amount of padding required, which will be less 168 than four octets. 170 4. Nonce Format 172 The nonce passed to the GCM-AES encryption algorithm has the 173 following layout: 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Salt | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Initialization Vector | 181 | | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 2: Nonce Format 186 The components of the nonce are as follows: 188 Salt 189 The salt field is a four-octet value that is assigned at the 190 beginning of the security association, and then remains constant 191 for the life of the security association. The salt SHOULD be 192 unpredictable (i.e., chosen at random) before it is selected, but 193 need not be secret. We describe how to set the salt for a 194 Security Association established via the Internet Key Exchange in 195 Section 8.1. 197 Initialization Vector 198 The IV field is described in section Section 3.1. 200 5. AAD Construction 202 The data integrity and data origin authentication for the SPI and 203 (Extended) Sequence Number fields is provided without encrypting 204 them. This is done by including those fields in the AES-GCM 205 Additional Authenticated Data (AAD) field. Two formats of the AAD 206 are defined: one for 32-bit sequence numbers, and one for 64-bit 207 extended sequence numbers. The format with 32-bit sequence numbers 208 is shown in Figure 3, and the format with 64-bit extended sequence 209 numbers is shown in Figure 4. 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | SPI | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | 32-bit Sequence Number | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 3: AAD Format with 32-bit Sequence Number 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | SPI | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | 64-bit Extended Sequence Number | 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 4: AAD Format with 64-bit Extended Sequence Number 232 6. Integrity Check Value (ICV) 234 The ICV consists solely of the AES-GCM Authentication Tag. 235 Implementations MUST support a full-length 16-octet ICV, and MAY 236 support 4, 8 or 12 octet ICVs and MUST NOT support other ICV lengths. 237 Although ESP does not require that an ICV be present, AES-GCM-ESP 238 intentionally does not allow a zero-length ICV. This is because GCM 239 provides no integrity protection whatsoever when used with a 240 zero-length Authentication Tag. 242 7. Packet Expansion 244 The IV adds an additional eight octets to the packet and the ICV adds 245 an additional 4, 8, 12 or 16 octets. These are the only sources of 246 packet expansion, other than the 10-13 bytes taken up by the ESP SPI, 247 Sequence Number, Padding, Pad Length, and Next Header fields (if the 248 minimal amount of padding is used). 250 8. IKE Conventions 252 This section describes the conventions used to generate keying 253 material and salt values for use with AES-GCM-ESP using the Internet 254 Key Exchange (IKE) [RFC2409] protocol. The identifiers and 255 attributes needed to negotiate a security association using 256 AES-GCM-ESP are also defined. 258 8.1 Keying Material and Salt Values 260 IKE makes use of a pseudo-random function (PRF) to derive keying 261 material. The PRF is used iteratively to derive keying material of 262 arbitrary size, called KEYMAT. Keying material is extracted from the 263 output string without regard to boundaries. 265 The size of the KEYMAT for the AES-GCM-ESP MUST be four octets longer 266 than is needed for the associated AES key. The keying material is 267 used as follows: 269 AES-GCM-ESP with a 128 bit key 270 The KEYMAT requested for each AES-GCM key is 20 octets. The first 271 16 octets are the 128-bit AES key, and the remaining four octets 272 are used as the salt value in the nonce. 274 AES-GCM-ESP with a 192 bit key 275 The KEYMAT requested for each AES-GCM key is 28 octets. The first 276 24 octets are the 192-bit AES key, and the remaining four octets 277 are used as the salt value in the nonce. 279 AES-GCM-ESP with a 256 bit key 280 The KEYMAT requested for each AES GCM key is 36 octets. The first 281 32 octets are the 256-bit AES key, and the remaining four octets 282 are used as the salt value in the nonce. 284 8.2 Phase 1 Identifier 286 This document does not specify the conventions for using AES-GCM for 287 IKE Phase 1 negotiations. For AES-GCM to be used in this manner, a 288 separate specification is needed, and an Encryption Algorithm 289 Identifier needs to be assigned. Implementations SHOULD use an IKE 290 Phase 1 cipher which is at least as strong as AES-GCM. The use of AES 291 CBC [RFC3602] with the same key size as used by AES-GCM-ESP is 292 RECOMMENDED. 294 8.3 Phase 2 Identifier 296 For IKE Phase 2 negotiations, IANA has assigned as the ESP 297 Transform Identifier for AES-GCM with an eight-byte explicit IV. 299 8.4 Key Length Attribute 301 Since the AES supports three key lengths, the Key Length attribute 302 MUST be specified in the IKE Phase 2 exchange [RFC2407]. The Key 303 Length attribute MUST have a value of 128, 192 or 256. 305 9. Test Vectors 307 Appendix B of [GCM] provides test vectors that will assist 308 implementers with AES-GCM mode. 310 10. Security Considerations 312 GCM is provably secure against adversaries that can adaptively choose 313 plaintexts, ciphertexts, ICVs and the AAD field, under standard 314 cryptographic assumptions (roughly, that the output of the underlying 315 cipher under a randomly chosen key is indistinguishable from a 316 randomly selected output). Essentially, this means that, if used 317 within its intended parameters, a break of GCM implies a break of the 318 underlying block cipher. The proof of security for GCM is available 319 in [GCMP]. 321 The most important security consideration is that the IV never repeat 322 for a given key. In part, this is handled by disallowing the use of 323 AES-GCM when using statically configured keys, as discussed in 324 Section 2. 326 When IKE is used to establish fresh keys between two peer entities, 327 separate keys are established for the two traffic flows. If a 328 different mechanism is used to establish fresh keys, one that 329 establishes only a single key to encrypt packets, then there is a 330 high probability that the peers will select the same IV values for 331 some packets. Thus, to avoid counter block collisions, ESP 332 implementations that permit use of the same key for encrypting and 333 decrypting packets with the same peer MUST ensure that the two peers 334 assign different salt values to the security association (SA). 336 The other consideration is that, as with any encryption mode, the 337 security of all data protected under a given security association 338 decreases slightly with each message. 340 To protect against this problem, implementations MUST generate a 341 fresh key before encrypting 2^64 blocks of data with a given key. 342 Note that it is impossible to reach this limit when using 32-bit 343 Sequence Numbers. 345 Note that, for each message, GCM calls the block cipher once for each 346 full 16-octet block in the payload, once for any remaining octets in 347 the payload, and one additional time in computing the ICV. 349 Clearly, smaller ICV values are more likely to be subject to forgery 350 attacks. Implementations SHOULD use as large a size as reasonable. 352 11. Design Rationale 354 This specification was designed to be as similar to the AES-CCM ESP 355 [CCM-ESP] and AES-CTR ESP [RFC3686] mechanisms as reasonable, while 356 promoting simple, efficient implementations in both hardware and 357 software. We re-use the design and implementation experience from 358 those standards. 360 The major difference with CCM is that the CCM ESP mechanism requires 361 an 11-octet nonce, whereas the GCM ESP mechanism requires using a 362 12-octet nonce. GCM is specially optimized to handle the 12-octet 363 nonce case efficiently. Nonces of other lengths would cause 364 unnecessary additional complexity and delays, particularly in 365 hardware implementations. The additional octet of nonce is used to 366 increase the size of the salt. 368 12. IANA Considerations 370 Currently, no ESP transform numbers have been assigned for use with 371 the AES-GCM transform. 373 13. Acknowledgements 375 This work is closely modeled after Russ Housley's AES-CCM transform 376 [CCM-ESP]. Portions of this document are directly copied from that 377 draft. We thank Russ for his support of this work. 379 Additionally, the GCM mode of operation was originally conceived as 380 an improvement to CWC mode [CWC], the first unencumbered block cipher 381 mode capable of supporting high-speed authenticated encryption. 383 Normative References 385 [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of 386 Operation (GCM)", Submission to NIST. http:// 387 csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/ 388 gcm-spec.pdf, January 2004. 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, March 1997. 393 [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security 394 Payload (ESP)", RFC 2406, November 1998. 396 [RFC2407] Piper, D., "The Internet IP Security Domain of 397 Interpretation for ISAKMP", RFC 2407, November 1998. 399 [RFC3602] Frankel, S., Glenn, R. and S. Kelly, "The AES-CBC Cipher 400 Algorithm and Its Use with IPsec", RFC 3602, September 401 2003. 403 Informative References 405 [CCM-ESP] Housley, R., "Using AES CCM Mode With IPsec ESP", Work In 406 Progress. . 408 [CWC] Kohno, T., Viega, J. and D. Whiting, "CWC: A 409 high-performance conventional authenticated encryption 410 mode", Fast Software Encryption. http://eprint.iacr.org/ 411 2003/106.pdf, February 2004. 413 [GCMP] McGrew, D., "Security Analysis of Galois/Counter Mode 414 (GCM)", http://www.cryptobarn.com/papers/gcm-sec.pdf, 415 March 2004. 417 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 418 (IKE)", RFC 2409, November 1998. 420 [RFC2675] Borman, D., Deering, S. and R. Hinden, "IPv6 Jumbograms", 421 RFC 2675, August 1999. 423 [RFC3610] Whiting, D., Housley, R. and N. Ferguson, "Counter with 424 CBC-MAC (CCM)", RFC 3610, September 2003. 426 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 427 Counter Mode With IPsec Encapsulating Security Payload 428 (ESP)", RFC 3686, January 2004. 430 Authors' Addresses 432 John Viega 433 Secure Software, Inc. 434 4100 Lafayette Center Dr., Suite 100 435 Chantilly, VA 20151 436 US 438 Phone: (703) 814 4402 439 EMail: viega@securesoftware.com 440 David A. McGrew 441 Cisco Systems, Inc. 442 510 McCarthy Blvd. 443 Milpitas, CA 95035 444 US 446 Phone: (408) 525 8651 447 EMail: mcgrew@cisco.com 448 URI: http://www.mindspring.com/~dmcgrew/dam.htm 450 Intellectual Property Statement 452 The IETF takes no position regarding the validity or scope of any 453 intellectual property or other rights that might be claimed to 454 pertain to the implementation or use of the technology described in 455 this document or the extent to which any license under such rights 456 might or might not be available; neither does it represent that it 457 has made any effort to identify any such rights. Information on the 458 IETF's procedures with respect to rights in standards-track and 459 standards-related documentation can be found in BCP-11. Copies of 460 claims of rights made available for publication and any assurances of 461 licenses to be made available, or the result of an attempt made to 462 obtain a general license or permission for the use of such 463 proprietary rights by implementors or users of this specification can 464 be obtained from the IETF Secretariat. 466 The IETF invites any interested party to bring to its attention any 467 copyrights, patents or patent applications, or other proprietary 468 rights which may cover technology that may be required to practice 469 this standard. Please address the information to the IETF Executive 470 Director. 472 Full Copyright Statement 474 Copyright (C) The Internet Society (2004). All Rights Reserved. 476 This document and translations of it may be copied and furnished to 477 others, and derivative works that comment on or otherwise explain it 478 or assist in its implementation may be prepared, copied, published 479 and distributed, in whole or in part, without restriction of any 480 kind, provided that the above copyright notice and this paragraph are 481 included on all such copies and derivative works. However, this 482 document itself may not be modified in any way, such as by removing 483 the copyright notice or references to the Internet Society or other 484 Internet organizations, except as needed for the purpose of 485 developing Internet standards in which case the procedures for 486 copyrights defined in the Internet Standards process must be 487 followed, or as required to translate it into languages other than 488 English. 490 The limited permissions granted above are perpetual and will not be 491 revoked by the Internet Society or its successors or assignees. 493 This document and the information contained herein is provided on an 494 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 495 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 496 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 497 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 498 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 500 Acknowledgment 502 Funding for the RFC Editor function is currently provided by the 503 Internet Society.