idnits 2.17.1 draft-rescorla-tls-suiteb-10.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.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 520. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (October 31, 2008) is 5655 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Salter 3 Internet-Draft National Security Agency 4 Intended status: Informational E. Rescorla 5 Expires: May 4, 2009 Network Resonance 6 R. Housley 7 Vigil Security 8 October 31, 2008 10 Suite B Profile for Transport Layer Security (TLS) 11 draft-rescorla-tls-suiteb-10.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 4, 2009. 38 Abstract 40 The United States Government has published guidelines for "NSA Suite 41 B Cryptography", which defines cryptographic algorithm policy for 42 national security applications. This document defines a profile of 43 TLS version 1.2 which is fully conformant with Suite B. This document 44 also defines a transitional profile for use with TLS version 1.0 and 45 TLS version 1.1 employ Suite B algorithms to the greatest extent 46 possible. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 52 3. Suite B Requirements . . . . . . . . . . . . . . . . . . . . . 4 53 4. Suite B Compliance and Interoperability Requirements . . . . . 4 54 4.1. Security Levels . . . . . . . . . . . . . . . . . . . . . 7 55 4.2. Acceptable Curves . . . . . . . . . . . . . . . . . . . . 8 56 4.3. Certificates . . . . . . . . . . . . . . . . . . . . . . . 8 57 4.4. signature_algorithms extension . . . . . . . . . . . . . . 9 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 65 Intellectual Property and Copyright Statements . . . . . . . . . . 12 67 1. Introduction 69 United States Government posted a Fact Sheet on National Security 70 Agency (NSA) Suite B Cryptography [NSA], and at the time of this 71 writing, it states: 73 To complement the existing policy for the use of the Advanced 74 Encryption Standard (AES) to protect national security systems 75 and information as specified in The National Policy on the use of 76 the Advanced Encryption Standard (AES) to Protect National 77 Security Systems and National Security Information (CNSSP-15), 78 the National Security Agency (NSA) announced Suite B Cryptography 79 at the 2005 RSA Conference. In addition to the AES, Suite B 80 includes cryptographic algorithms for hashing, digital 81 signatures, and key exchange. 83 Suite B only specifies the cryptographic algorithms to be 84 used. Many other factors need to be addressed in determining 85 whether a particular device implementing a particular set of 86 cryptographic algorithms should be used to satisfy a particular 87 requirement. 89 Among those factors are "requirements for interoperability both 90 domestically and internationally". 92 This document does not define any new cipher suites; instead, it 93 defines two profiles: 95 o A Suite B compliant profile for use with TLS version 1.2 [RFC5246] 96 and the cipher suites defined in [RFC5289]. This profile uses 97 only Suite B algorithms. 98 o An transitional profile for use with TLS version 1.0 [RFC2246] or 99 TLS version 1.1 [RFC4346] and the cipher suites defined in 100 [RFC4492]. This profile uses the Suite B cryptographic algorithms 101 to the greatest extent possible and provides backward 102 compatiblity. While the transitional profile is not Suite B 103 compliant, it provides a transition path towards the Suite B 104 compliant profile. 106 2. Conventions Used In This Document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 3. Suite B Requirements 114 The Fact Sheet on Suite B Cryptography requires that key 115 establishment and authentication algorithms be based on Elliptic 116 Curve Cryptography, and that the encryption algorithm be AES [AES]. 117 Suite B defines two security levels, of 128 and 192 bits. 119 In particular, Suite B includes: 121 Encryption: Advanced Encryption Standard (AES) [AES] - 122 FIPS 197 (with keys sizes of 128 and 256 123 bits) 125 Digital Signature: Elliptic Curve Digital Signature Algorithm 126 (ECDSA) [DSS] - FIPS 186-2 (using the 127 curves with 256 and 384-bit prime moduli) 129 Key Exchange: Elliptic Curve Diffie-Hellman (ECDH) - NIST 130 Special Publication 800-56A [PWKE] (using the 131 curves with 256 and 384-bit prime moduli) 133 The 128-bit security level corresponds to an elliptic curve size of 134 256 bits and AES-128; it also makes use of SHA-256 [SHS]. The 192- 135 bit security level corresponds to an elliptic curve size of 384 bits 136 and AES-256; it also makes use of SHA-384 [SHS]. 138 Note: Some people refer to the two security levels based on the AES 139 key size that is employed instead of the overall security provided by 140 the combination of Suiet B algorithms. At the 128-bit security 141 level, an AES key length of 128 bits is used, which does not lead to 142 any confusion. However, at the 192-bit security level, an AES key 143 length of 256 bits is used, which sometimes leads to an expectation 144 of more security than is offered by the combination of Suite B 145 algorithms. 147 To accommodate backward compatibility, a Suite B compliant client or 148 server can be configured to accept a cipher suite that is not part of 149 Suite B. However, whenever a Suite B compliant client and a Suite B 150 compliant server establish a TLS version 1.2 session, only Suite B 151 algorithms are employed. 153 4. Suite B Compliance and Interoperability Requirements 155 TLS version 1.1 [RFC4346] and earlier does not support Galois Counter 156 Mode (GCM) cipher suites [RFC5289]. However, TLS version 1.2 157 [RFC5246] and later does support GCM. For Suite B TLS compliance, 158 GCM cipher suites are REQUIRED to be used whenever both the client 159 and the server support the necessary cipher suites. Also, for Suite 160 B TLS compliance, Cipher Block Chaining (CBC) cipher suites are 161 employed when GCM cipher suites cannot be employed. 163 For a client to implement the Suite B compliant profile, it MUST 164 implement TLS version 1.2 or later and the following cipher suite 165 rules apply: 167 o A Suite B compliant TLS version 1.2 or later client MUST offer at 168 least two cipher suites for each supported security level. For 169 the 128 bit security level, 170 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and 171 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 MUST be offered in this 172 order in the ClientHello message. For the 192 bit security level, 173 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and 174 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 MUST be offered in this 175 order in the ClientHello message. One of these cipher suites MUST 176 be the first (most preferred) cipher suite in the ClientHello 177 message. 178 o A Suite B compliant TLS version 1.2 or later client that offers 179 backward compatibility with TLS version 1.1 or earlier servers MAY 180 offer an additional cipher suite for each supported security 181 level. If these cipher suites are offered, they MUST appear after 182 the ones discussed above. For the 128 bit security level, 183 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA MAY be offered in the 184 ClientHello message. For the 192 bit security level, 185 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA MAY be offered in the 186 ClientHello message. 187 o A Suite B compliant TLS version 1.2 or later client that offers 188 interoperability with non-Suite B compliant servers MAY offer 189 additional cipher suites. If any additional cipher suites are 190 offered, they MUST appear after the ones discussed above in the 191 ClientHello message. 193 For a client to implement the Suite B transitional profile, it MUST 194 implement TLS version 1.1 or earlier the following cipher suite rules 195 apply: 197 o A Suite B transitional TLS version 1.1 or earlier client MUST 198 offer one cipher suite for each supported security level. For the 199 128 bit security level, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA MUST 200 be offered in the ClientHello message. For the 192 bit security 201 level, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA MUST be offered in the 202 ClientHello message. One of these cipher suites MUST be the first 203 (most preferred) cipher suite in the ClientHello message. 204 o A Suite B transitional TLS version 1.1 or earlier client that 205 offers interoperability with non-Suite B compliant servers MAY 206 offer additional cipher suites. If any additional cipher suites 207 are offered, they MUST appear after the ones discussed above in 208 the ClientHello message. 210 A Suite B compliant TLS server MUST be configured to support the 128- 211 bit security level, the 192-bit security level, or both security 212 levels. The cipher suite rules for each of these security levels is 213 described below. If a Suite B compliant TLS server is configured to 214 support both security levels, then the configuration MUST prefer one 215 security level over the other. In practice, this means that the 216 cipher suite rules associated with the cipher suites listed in 217 Section 4.1 for the preferred security level are processed before the 218 cipher suite rules for the less preferred security level. 220 For a server to implement the Suite B conformant profile at the 128- 221 bit security level, the following cipher suite rules apply: 223 o A Suite B compliant TLS version 1.2 or later server MUST accept 224 the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite if it is 225 offered. 226 o If the previous cipher suite is not offered, then a Suite B 227 compliant TLS version 1.2 or later server MUST accept the 228 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 cipher suite if it is 229 offered. 230 o If neither of the previous two cipher suites is offered, then a 231 Suite B compliant TLS version 1.2 or later server that offers 232 backward compatibility with TLS version 1.1 or earlier clients MAY 233 accept the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite if it 234 is offered. 235 o If the server is not offered any of the previous three cipher 236 suites and interoperability with clients that are not compliant or 237 interoperable with Suite B is desired, then the server MAY accept 238 another offered cipher suite that is considered acceptable by the 239 server administrator. 241 For a server to implement the Suite B transitional profile at the 242 128-bit security level, the following cipher suite rules apply: 244 o A Suite B transitional TLS version 1.1 or earlier server MUST 245 accept the TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA cipher suite if it 246 is offered. 247 o If the server is not offered the previous cipher suite and 248 interoperability with clients that are not Suite B transitional is 249 desired, then the server MAY accept another offered cipher suite 250 that is considered acceptable by the server administrator. 252 For a server to implement the Suite B conformant profile at the 192- 253 bit security level, the following cipher suite rules apply: 255 o A Suite B compliant TLS version 1.2 or later server MUST accept 256 the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite if it is 257 offered. 258 o If the previous cipher suite is not offered, then then a Suite B 259 compliant TLS version 1.2 or later server MUST accept the 260 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 cipher suite if it is 261 offered. 262 o If neither of the previous two cipher suites is offered, then a 263 Suite B compliant TLS version 1.2 or later server that offers 264 backward compatibility with TLS version 1.1 or earlier clients MAY 265 accept the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if it 266 is offered. 267 o If the server is not offered any of the previous three cipher 268 suites and interoperability with clients that are not compliant or 269 interoperable with Suite B is desired, then the server MAY accept 270 another offered cipher suite that is considered acceptable by the 271 server administrator. 273 For a server to implement the Suite B transitional profile at the 274 192-bit security level, the following cipher suite rules apply: 276 o A Suite B transitional TLS version 1.1 or earlier server MUST 277 accept the TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA cipher suite if it 278 is offered. 279 o If the server is not offered the previous cipher suite and 280 interoperability with clients that are not Suite B transitional is 281 desired, then the server MAY accept another offered cipher suite 282 that is considered acceptable by the server administrator. 284 Note that these rules explicitly permit the use of CBC cipher suites 285 in TLS version 1.2 connections in order to permit operation between 286 Suite B compliant and non-Suite B compliant implementations. For 287 instance, a Suite B compliant TLS version 1.2 client might offer TLS 288 version 1.2 with both GCM and CBC cipher suites when communicating 289 with a non-Suite B TLS version 1.2 server which then selected the CBC 290 cipher suites. This connection would nevertheless meet the 291 requirements of this specification. However, any two Suite B 292 compliant implementations will negotiate a GCM cipher suite when 293 doing TLS version 1.2. 295 4.1. Security Levels 297 As described in Section 1, Suite B specifies two security levels: 298 128 bit and 192 bit. The following table lists the cipher suites for 299 each security level. Within each security level, the cipher suites 300 are listed in their preferred order for selection by a TLS version 301 1.2 implementation. 303 +-----------------------------------------+----------------+ 304 | Cipher Suite | Security Level | 305 +-----------------------------------------+----------------+ 306 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | 128 | 307 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 | 128 | 308 | TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA | 128 | 309 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | 192 | 310 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 | 192 | 311 | TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA | 192 | 312 +-----------------------------------------+----------------+ 314 4.2. Acceptable Curves 316 RFC 4492 defines a variety of elliptic curves. For cipher suites 317 defined in this specification, only secp256r1(23) or secp384r1(24) 318 may be used. These are the same curves that appear in FIPS 186-2 319 [DSS] as P-256 and P-384, respectively. For cipher suites at the 320 128-bit security level, secp256r1 MUST be used. For cipher suites at 321 the 192-bit security level, secp384r1 MUST be used. RFC 4492 322 requires that uncompressed(0) form be supported. 323 ansiX962_compressed_prime(1) point formats MAY also be supported. 325 Clients desiring to negotiate only a Suite B-compliant connection 326 MUST generate a "Supported Elliptic Curves Extension" containing only 327 the allowed curves. These curves MUST match the cipher suite 328 security levels being offered. Clients which are willing to do both 329 Suite B-compliant and non-Suite B-compliant connections MAY omit the 330 extension or send the extension but offer other curves as well as the 331 appropriate Suite B ones. 333 Servers desiring to negotiate a Suite B-compliant connection SHOULD 334 check for the presence of the extension, but MUST NOT negotiate 335 inappropriate curves even if they are offered by the client. This 336 allows a Client which is willing to do either Suite B-compliant or 337 non-Suite B-compliant modes to interoperate with a server which will 338 only do Suite B-compliant modes. If the client does not advertise an 339 acceptable curve, the server MUST generate a fatal 340 "handshake_failure" alert and terminate the connection. Clients MUST 341 check the chosen curve to make sure it is acceptable. 343 4.3. Certificates 345 Server and client certificates used to establish a Suite B-compliant 346 connection MUST be signed with ECDSA. For certificates used at the 347 128-bit security level, the subject public key MUST use the P-256 348 curve, and the digital signature MUST be calculated using the P-256 349 curve and the SHA-256 hash algorithm. For certificates used at the 350 192-bit security level, the subject public key MUST use the P-384 351 curve, and the digital signature MUST be calculated using the P-384 352 curve and the SHA-384 hash algorithm. 354 While the key exchange algorithm used in TLS_ECDHE_ECDSA-collection 355 of cipher suites require the server's certificate to be signed with a 356 particular signature scheme, this specification does not impose 357 restrictions on signature schemes used elsewhere in the certification 358 path. (Often such restrictions will be useful, and it is expected 359 that this will be taken into account in practices of certification 360 authorities. However, such restrictions are not strictly required, 361 even if it is beyond the capabilities of a client to completely 362 validate a given certification path, the client may be able to 363 validate the server's certificate by relying on a trusted 364 certification authority whose certificate appears as one of the 365 intermediate certificates in the certification path.) 367 Likewise, this specification does not impose restrictions on 368 signature schemes used in the certification path for the client's 369 certificate when mutual authentication is employed. 371 4.4. signature_algorithms extension 373 The signature_algorithms extension is defined in Section 7.4.1.4.1 of 374 TLS version 1.2 [RFC5246]. A Suite B compliant TLS version 1.2 or 375 later client MUST include the signature_algorithms extension. For 376 the 128 bit security level, SHA-256 with ECDSA MUST be offered in the 377 signature_algorithms extension. For the 192 bit security level, SHA- 378 384 with ECDSA MUST be offered in the signature_algorithms extension. 379 Other offerings MAY be included to indicate the signature algorithms 380 that are acceptable in cipher suites that are offered for 381 interoperability with servers that are not compliant with Suite B and 382 to indicate the signature algorithms that are acceptable for 383 certification path validation. 385 5. Security Considerations 387 Most of the security considerations for this document are described 388 in TLS 1.2 [RFC5246], Elliptic Curve Cryptography (ECC) Cipher Suites 389 for TLS [RFC4492], AES-GCM Cipher Suites for TLS [RFC5288], and TLS 390 ECC Cipher Suites with SHA-256/384 and AES-GCM [RFC5289]. Readers 391 should consult those documents. 393 In order to meet the goal of a consistent security level for the 394 entire cipher suite, in Suite B mode TLS implementations MUST ONLY 395 use the curves defined in Section 4.2. Otherwise, it is possible to 396 have a set of symmetric algorithms with much weaker or stronger 397 security properties than the asymmetric (ECC) algorithms. 399 6. IANA Considerations 401 This document defines no actions for IANA. 403 7. Acknowledgements 405 This work was supported by the US Department of Defense. 407 8. References 409 8.1. Normative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, March 1997. 414 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 415 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 416 for Transport Layer Security (TLS)", RFC 4492, May 2006. 418 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 419 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 421 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 422 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 423 August 2008. 425 [AES] National Institute of Standards and Technology, 426 "Specification for the Advanced Encryption Standard 427 (AES)", FIPS 197, November 2001. 429 [DSS] National Institute of Standards and Technology, "Digital 430 Signature Standard", FIPS 186-2, January 2000. 432 [PWKE] National Institute of Standards and Technology, 433 "Recommendation for Pair-Wise Key Establishment Schemes 434 Using Discrete Logarithm Cryptography (Revised)", NIST 435 Special Publication 800-56A, March 2007. 437 [SHS] National Institute of Standards and Technology, "Secure 438 Hash Standard", FIPS 180-2, August 2002. 440 8.2. Informative References 442 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 443 RFC 2246, January 1999. 445 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 446 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 448 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 449 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 450 August 2008. 452 [NSA] National Security Agency, "Fact Sheet NSA Suite B 453 Cryptography", 454 . 456 Authors' Addresses 458 Margaret Salter 459 National Security Agency 460 9800 Savage Rd. 461 Fort Meade 20755-6709 462 USA 464 Email: msalter@restarea.ncsc.mil 466 Eric Rescorla 467 Network Resonance 468 2064 Edgewood Drive 469 Palo Alto 94303 470 USA 472 Email: ekr@rtfm.com 474 Russ Housley 475 Vigil Security 476 918 Spring Knoll Drive 477 Herndon 21070 478 USA 480 Email: housley@vigilsec.com 482 Full Copyright Statement 484 Copyright (C) The IETF Trust (2008). 486 This document is subject to the rights, licenses and restrictions 487 contained in BCP 78, and except as set forth therein, the authors 488 retain all their rights. 490 This document and the information contained herein are provided on an 491 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 492 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 493 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 494 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 495 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 496 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 498 Intellectual Property 500 The IETF takes no position regarding the validity or scope of any 501 Intellectual Property Rights or other rights that might be claimed to 502 pertain to the implementation or use of the technology described in 503 this document or the extent to which any license under such rights 504 might or might not be available; nor does it represent that it has 505 made any independent effort to identify any such rights. Information 506 on the procedures with respect to rights in RFC documents can be 507 found in BCP 78 and BCP 79. 509 Copies of IPR disclosures made to the IETF Secretariat and any 510 assurances of licenses to be made available, or the result of an 511 attempt made to obtain a general license or permission for the use of 512 such proprietary rights by implementers or users of this 513 specification can be obtained from the IETF on-line IPR repository at 514 http://www.ietf.org/ipr. 516 The IETF invites any interested party to bring to its attention any 517 copyrights, patents or patent applications, or other proprietary 518 rights that may cover technology that may be required to implement 519 this standard. Please address the information to the IETF at 520 ietf-ipr@ietf.org.