idnits 2.17.1 draft-ietf-btns-core-05.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 557. 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 == Line 258 has weird spacing: '... addr addr ...' == Line 327 has weird spacing: '... addr addr ...' == Line 362 has weird spacing: '... addr addr ...' -- 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 (September 4, 2007) is 6079 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Q' is mentioned on line 394, but not defined == Missing Reference: 'R' is mentioned on line 283, but not defined == Missing Reference: 'A' is mentioned on line 381, but not defined == Missing Reference: 'B' is mentioned on line 381, but not defined == Missing Reference: 'C' is mentioned on line 395, but not defined == Missing Reference: 'D' is mentioned on line 219, but not defined == Missing Reference: 'SG-A' is mentioned on line 390, but not defined == Missing Reference: 'SG-B' is mentioned on line 344, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-btns-connection-latching-00 == Outdated reference: A later version (-07) exists of draft-ietf-btns-prob-and-applic-05 == Outdated reference: A later version (-04) exists of draft-williams-on-channel-binding-00 -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2408 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 15 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Intended status: Standards Track M. Richardson 5 Expires: March 7, 2008 SSW 6 September 4, 2007 8 Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec 9 draft-ietf-btns-core-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 7, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document specifies how to use the Internet Key Exchange (IKE) 43 protocols, such as IKEv1 and IKEv2, to setup "unauthenticated" 44 security associations (SAs) for use with the IPsec Encapsulating 45 Security Payload (ESP) and the IPsec Authentication Header (AH). No 46 changes to IKEv2 bits-on-the-wire are required, but Peer 47 Authorization Database (PAD) and Security Policy Database (SPD) 48 extensions are specified. Unauthenticated IPsec is herein referred 49 to by its popular acronym, "BTNS" (Better Than Nothing Security). 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Conventions used in this document . . . . . . . . . . . . . 3 55 2. BTNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1. Example #1: A security gateway . . . . . . . . . . . . . . . 6 58 3.2. Example #2: A mixed end-system . . . . . . . . . . . . . . . 8 59 3.3. Example #3: A BTNS-only system . . . . . . . . . . . . . . . 9 60 3.4. Miscellaneous comments . . . . . . . . . . . . . . . . . . . 10 61 4. Security Considerations . . . . . . . . . . . . . . . . . . 11 62 4.1. Connection-Latching and Channel Binding . . . . . . . . . . 11 63 4.2. Leap-of-Faith (LoF) for BTNS . . . . . . . . . . . . . . . . 11 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 14 68 7.2. Informative References . . . . . . . . . . . . . . . . . . . 14 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 70 Intellectual Property and Copyright Statements . . . . . . . 16 72 1. Introduction 74 Here we describe how to establish unauthenticated IPsec SAs using 75 IKEv2 [RFC4306] and unauthenticated public keys. No new on-the-wire 76 protocol elements are added to IKEv2. 78 The [RFC4301] processing model is assumed. 80 This document does not define an opportunistic BTNS mode of IPsec 81 whereby nodes may fallback to unprotected IP when their peers do not 82 support IKEv2, nor does it describe "leap-of-faith" modes, or 83 "connection latching." 85 See [I-D.ietf-btns-prob-and-applic] for the applicability and uses of 86 BTNS and definitions of these terms. 88 This document describes BTNS in terms of IKEv2 and [RFC4301]'s 89 concepts. There is no reason why the same methods cannot be used 90 with IKEv1 [RFC2408] [RFC2409] and [RFC2401], however, those 91 specifications do not include the PAD concepts, and therefore it may 92 not be possible to implement BTNS on all compliant RFC2401 93 implementations. 95 1.1. Conventions used in this document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. BTNS 103 The IPsec processing model is hereby modified as follows: 105 o A new ID type is added, 'PUBLICKEY'; IDs of this type have public 106 keys as values. This ID type is not used on the wire. 108 o PAD entries that match on PUBLICKEY IDs are referred to as "BTNS 109 PAD entries." All other PAD entries are referred to as "non-BTNS 110 PAD entries." 112 o BTNS PAD entries may match on specific peer PUBLICKEY IDs (or 113 public key fingerprints), or on all peer public keys. The latter 114 is referred to as the "wildcard BTNS PAD entry." 116 o BTNS PAD entries MUST logically (see below) follow all other PAD 117 entries (the PAD being an ordered list). 119 o At most one wildcard BTNS PAD entry may appear in the PAD, and, if 120 present, MUST be the last entry in the PAD (see below). 122 o Any peer that uses an IKEv2 AUTH method involving a digital 123 signature (made with a private key to a public key cryptosystem) 124 may match a BTNS PAD entry, provided that it matches no non-BTNS 125 PAD entries. Suitable AUTH methods as of August 2007 are: RSA 126 Digital Signature (method #1) and DSS Digital Signature (method 127 #3); see [RFC4306], section 3.8. 129 o A BTNS capable implementation of IPsec will first search the PAD 130 for non-BTNS entries matching a peer's ID. If no matching non- 131 BTNS PAD entries are found then the peer's ID MUST then be coerced 132 to be of 'PUBLICKEY' type with the peer's public key as its value 133 and the PAD is then searched again for matching BTNS PAD entries. 134 This ensures that BTNS PAD entries logically follow non-BTNS PAD 135 entries. A single PAD search that preserves these semantics is 136 allowed. 138 o A peer that matches a BTNS PAD entry is referred to as a "BTNS 139 peer." Such a peer is "authenticated" by verifying that the 140 signature in its IKEv2 AUTH payload with the public key from the 141 peer's CERT payload. 143 o Of course, if no matching PAD entry is found, then the IKE SA is 144 rejected as usual. 146 o A new flag for SPD entries: 'BTNS_OK'. Traffic to/from peers that 147 match the BTNS PAD entry will match only SPD entries that have the 148 BTNS_OK flag set. The SPD may be searched by address or by ID (of 149 type PUBLICKEY, for BTNS peers), as per the IPsec processing model 150 [RFC4301]; searching by ID in this case requires creation of SPD 151 entries that are bound to public key values (this could be used to 152 build "leap-of-faith" [I-D.ietf-btns-prob-and-applic] Section 4.2 153 behaviour, for example). 155 Nodes MUST reject IKE_SA proposals from peers that match non-BTNS PAD 156 entries but fail to authenticate properly. 158 Nodes wishing to be treated as BTNS nodes by their peers MUST include 159 bare RSA key CERT payloads. Nodes MAY also include any number of 160 certificates that bind the same public key. These certificates need 161 not to have been pre-shared with their peers (e.g., because ephermal, 162 self-signed). RSA keys for use in BTNS may be generated at any time, 163 but "connection latching" [I-D.ietf-btns-connection-latching] 164 requires that they remain constant between IKEv2 exchanges that are 165 used to establish SAs for latched connections. 167 To preserve standard IPsec access control semantics: 169 o BTNS PAD entries MUST logically follow all non-BTNS PAD entries 171 o the wildcard BTNS PAD entry MUST be the last entry in the PAD, 172 logically 174 o the wildcard BTNS PAD entry MUST have ID constraints that do not 175 logically overlap those of other PAD entries. 177 As described above, the logical PAD ordering requirements can easily 178 be implemented by searching the PAD twice at peer authentication 179 time: once using the peer-asserted ID, and if that fails, once using 180 the peer's public key as a PUBLICKEY ID. A single pass 181 implementation that meets this requirement is permitted. 183 The BTNS entry ID constraint non-overlap requirement can easily be 184 implemented by searching the PAD twice: once when BTNS peers 185 authenticate, and again when BTNS peers negotiate child SAs. In the 186 first pass the PAD is searched for a matching PAD entry as described 187 above, and in the second it is searched to make sure that BTNS peers' 188 asserted child SA traffic selectors do not conflict with non-BTNS PAD 189 entries. Single pass implementations that preserve these semantics 190 are feasible. 192 3. Usage Scenarios 194 In order to explain the above rules a number of scenarios will be 195 examined. The goal here is to persuade the reader that the above 196 rules are both sufficient and necessary. 198 This section is informative only. 200 To explain the scenarios a reference diagram describing an example 201 network will be used. It is as follows: 203 [Q] [R] 204 AS1 . . AS2 205 [A]----+----[SG-A].......+....+.......[SG-B]-------[B] 206 ...... \ 207 ..PI.. ----[btns-B] 208 ...... 209 [btns-C].....+....+.......[btns-D] 211 Figure 1: Reference Network Diagram 213 In this diagram, there are six end-nodes: A, B, C and D. Two of the 214 systems are security gateways: SG-A, SG-B, protecting networks on 215 which [A] and [B] reside. There is a node [Q] which is IPsec and 216 BTNS capable, and node [R] is a simple node, with no IPsec or BTNS 217 capability. Nodes [C] and [D] are BTNS capable. 219 Nodes [C] and [Q] have fixed addresses. Node [D] has a non-fixed 220 address. 222 We will examine how these various nodes communicate with node SG-A, 223 and/or how SG-A rejects communications with some such nodes. In the 224 first example, we examine SG-A's point of view. In the second 225 example we look at Q's point of view. In the third example we look 226 at C's point of view. 228 PI is the Public Internet ("The Wild"). 230 3.1. Example #1: A security gateway 232 The machine that we will care in this example is [SG-A], a firewall 233 device of some kind which we wish to configure to respond to BTNS 234 connections from [C]. 236 SG-A has the following PAD and SPD entries: 238 Child SA 240 Rule Remote ID IDs allowed SPD Search by 241 ---- --------- ----------- ------------- 242 1 by-IP 243 2 by-IP 244 3 PUBLICKEY:any ANY by-IP 246 The last entry is the BTNS entry. 248 Figure 2: SG-A PAD table 250 Note that [SG-A]'s PAD entry has one and only one wildcard PAD entry: 251 the BTNS catch-all PAD entry as the last entry, as described in 252 Section 2. 254 and are from [RFC4301] section 255 4.4.3 257 Rule Local Remote Next Layer BTNS Action 258 addr addr Protocol ok 259 ---- ----- ------ ---------- ---- ----------------------- 260 1 [A] [R] ANY N/A BYPASS 261 2 [A] [Q] ANY no PROTECT(ESP,tunnel,AES, 262 SHA256) 263 3 [A] B-net ANY no PROTECT(ESP,tunnel,AES, 264 SHA256) 265 4 [A] ANY ANY yes PROTECT(ESP,transport, 266 integr+conf) 268 Figure 3: [SG-A] SPD table 270 The processing by [SG-A] of SA establishment attempts by various 271 peers is as follows: 273 o [Q] does not match PAD entry #1, but does match PAD entry #2; PAD 274 processing stops, then the SPD is searched by [Q]'s ID to find 275 entry #2; CHILD SAs are then allowed that have [SG-A]'s and [Q]'s 276 addresses as the end-point addresses. 278 o [SG-B] matches PAD entry #1; PAD processing stops, then the SPD is 279 searched by [SG-B]'s ID to find SPD entry #3; CHILD SAs are then 280 allowed that have [SG-A]'s address and any addresses from B's 281 network as the end-point addresses. 283 o [R] does not initiate any IKE SAs; its traffic to [A] is bypassed 284 by SPD entry #1. 286 o [C] does not match PAD entries #1 or #2, but does match entry #3, 287 the BTNS wildcard PAD entry; the SPD is searched by [C]'s address 288 and SPD entry #4 is matched. CHILD SAs are then allowed that have 289 [SG-A]'s address and [C]'s address as the end-point addresses 290 provided that [C]'s address is neither [Q]'s nor any of [B]'s (see 291 Section 2). 293 o A rogue BTNS node attempting to assert [Q]'s or [B]'s addresses 294 will either match the PAD entries for [Q] or [B] and fail to 295 authenticate as [Q] or [B], in which case they are rejected, or 296 they will match PAD entry #3 but will not be allowed to create 297 CHILD SAs with [Q]'s or [B]'s addresses as traffic selectors. 299 o A rogue BTNS nodes attempting to assert [C]'s address will 300 succeed. Protection for [C] requires additional bindings of [C]'s 301 specific BTNS ID (that is, its public key) to its traffic flows 302 through connection-latching and channel binding, or leap-of-faith, 303 none of which are described here. 305 3.2. Example #2: A mixed end-system 307 [Q] is an NFSv4 server. 309 [Q] is a native IPsec implementation, and it's NFSv4 implementation 310 is IPsec-aware. 312 [Q] wants to protect all traffic with [A]. [Q] also wants to protect 313 NFSv4 traffice with all peers. It's PAD and SPD are configured as 314 follows: 316 Child SA 317 Rule Remote ID IDs allowed SPD Search by 318 ---- --------- ----------- ------------- 319 1 <[A]'s ID> <[A]'s address> by-IP 320 2 PUBLICKEY:any ANY by-IP 322 The last entry is the BTNS entry. 324 Figure 4: [Q] PAD table 326 Rule Local Remote Next Layer BTNS Action 327 addr addr Protocol ok 328 ---- ----- ------ ---------- ---- ----------------------- 329 1 [Q] [A] ANY no PROTECT(ESP,tunnel,AES, 330 SHA256) 331 2 [Q] ANY ANY yes PROTECT(ESP,transport, 332 with integr+conf) 334 port 2049 336 Figure 5: [Q] SPD table 338 The same analysis shown above in Section 3.1 applies here with 339 respect to [SG-A], [C] and rogue peers. The second SPD entry permits 340 any BTNS capable node to negotiate a port-specific SA to port 2049, 341 the port on which NFSv4 runs. Additionally [SG-B] is treated as a 342 BTNS peer as it is not known to [Q], and therefore any host behind 343 [SG-B] can access the NFSv4 service on [Q]. As [Q] has no formal 344 relationship with [SG-B], rogues can impersonate [B] (i.e., assert 345 [B]'s addresses). 347 3.3. Example #3: A BTNS-only system 349 [C] supports only BTNS and wants to use BTNS to protect NFSv4 350 traffic. It's PAD and SPD are configured as follows: 352 Child SA 353 Rule Remote ID IDs allowed SPD Search by 354 ---- --------- ----------- ------------- 355 1 PUBLICKEY:any ANY by-IP 357 The last (and only) entry is the BTNS entry. 359 Figure 6: Q PAD table 361 Rule Local Remote Next Layer BTNS Action 362 addr addr Protocol ok 363 ---- ----- ------ ---------- ---- ----------------------- 364 1 [C] ANY ANY yes PROTECT(ESP,transport, 365 with integr+conf) 366 port 367 2049 369 2 [C] ANY ANY N/A BYPASS 371 Figure 7: SG-A SPD table 373 The analysis from Section 3.1 applies as follows: 375 o Communication with [Q] on port 2049 matches SPD entry number 1. 376 This causes [C] to initiate an IKEv2 exchange with [Q]. The PAD 377 entry on [C] causes it to not care what identity [Q] asserts. 378 Further authentication (and channel binding) could occur within 379 the NFSv4 protocol. 381 o Communication with [A], [B] or any other internet machine 382 (including [Q]), occurs in the clear, so long as it is not on port 383 2049. 385 o All analysis about rogue BTNS nodes applies, but they can only 386 assert SAs for port 2049. 388 3.4. Miscellaneous comments 390 If [SG-A] were not BTNS-capable then it would not have PAD and SPD 391 entries #3 and #4, respectively in example #1. Then [C] would be 392 rejected as usual under the standard IPsec model [RFC4301]. 394 Similarly, if [Q] were not BTNS-capable then it would not have PAD 395 and SPD entries #2 in example #2. Then [C] would be rejected as 396 usual under the standard IPsec model [RFC4301]. 398 4. Security Considerations 400 Unauthenticated security association negotiation is subject to MITM 401 attacks and should be used with care. Where security infrastructures 402 are lacking this may indeed be better than nothing. 404 Use with applications that bind authentication at higher network 405 layers to secure channels at lower layers may provide one secure way 406 to use unauthenticated IPsec, but this is not specified herein. 408 The BTNS PAD entry must be last and its child SA ID constraints must 409 be non-overlapping with any other PAD entry, as described in section 410 2, in order to ensure that no BTNS peer can impersonate another IPsec 411 non-BTNS peer. 413 4.1. Connection-Latching and Channel Binding 415 BTNS is subject to MITM attacks. One way to protect against MITM 416 attacks subsequent to initial communications is to use "connection 417 latching" [I-D.ietf-btns-connection-latching]. In connection 418 latching, ULPs cooperate with IPsec to bind discrete packet flows to 419 sequences of similar SAs. Connection latching requires native IPsec 420 implementations. 422 MITMs can be detected by using application-layer authentication 423 frameworks and/or mechanisms, such as the GSS-API [RFC2743], with 424 channel binding [I-D.williams-on-channel-binding]. IPsec "channels" 425 are nothing other than latched connnections. 427 4.2. Leap-of-Faith (LoF) for BTNS 429 "Leap of faith" is the term generally used when a user accepts the 430 assertion that a given key identifies a peer on the first 431 communication, despite a lack of strong evidence for that assertion, 432 and then remembers this association for future communications. 433 Specifically this is a common mode of operation for Secure Shell 434 [RFC4251] client. When a server is encountered for the first time 435 the Secure Shell client may ask the user whether to accept the 436 server's public key. If so, records the server's name (as given by 437 the user) and public key in a database. 439 Leap of faith can work in a similar way for BTNS nodes, but it is 440 currently still being designed and specified by the IETF BTNS WG. 442 5. IANA Considerations 444 This document has no IANA considerations, neither seeking to create 445 new registrations nor new registries. (The new ID type is not used 446 on the wire, therefore it need not be assigned a number from the IANA 447 IKEv2 Identification Payload ID Types registry.) 449 6. Acknowledgements 451 Thanks for the following reviewers: Stephen Kent 453 7. References 455 7.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 461 Internet Protocol", RFC 4301, December 2005. 463 7.2. Informative References 465 [I-D.ietf-btns-connection-latching] 466 Williams, N., "IPsec Channels: Connection Latching", 467 draft-ietf-btns-connection-latching-00 (work in progress), 468 February 2006. 470 [I-D.ietf-btns-prob-and-applic] 471 Touch, J., "Problem and Applicability Statement for Better 472 Than Nothing Security (BTNS)", 473 draft-ietf-btns-prob-and-applic-05 (work in progress), 474 February 2007. 476 [I-D.williams-on-channel-binding] 477 Williams, N., "On the Use of Channel Bindings to Secure 478 Channels", draft-williams-on-channel-binding-00 (work in 479 progress), August 2006. 481 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 482 Internet Protocol", RFC 2401, November 1998. 484 [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet 485 Security Association and Key Management Protocol 486 (ISAKMP)", RFC 2408, November 1998. 488 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 489 (IKE)", RFC 2409, November 1998. 491 [RFC2743] Linn, J., "Generic Security Service Application Program 492 Interface Version 2, Update 1", RFC 2743, January 2000. 494 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 495 Protocol Architecture", RFC 4251, January 2006. 497 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 498 RFC 4306, December 2005. 500 Authors' Addresses 502 Nicolas Williams 503 Sun Microsystems 504 5300 Riata Trace Ct 505 Austin, TX 78727 506 US 508 Email: Nicolas.Williams@sun.com 510 Michael C. Richardson 511 Sandelman Software Works 512 470 Dawson Avenue 513 Ottawa, ON K1Z 5V7 514 CA 516 Email: mcr@sandelman.ottawa.on.ca 517 URI: http://www.sandelman.ottawa.on.ca/ 519 Full Copyright Statement 521 Copyright (C) The IETF Trust (2007). 523 This document is subject to the rights, licenses and restrictions 524 contained in BCP 78, and except as set forth therein, the authors 525 retain all their rights. 527 This document and the information contained herein are provided on an 528 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 529 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 530 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 531 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 532 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 533 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 535 Intellectual Property 537 The IETF takes no position regarding the validity or scope of any 538 Intellectual Property Rights or other rights that might be claimed to 539 pertain to the implementation or use of the technology described in 540 this document or the extent to which any license under such rights 541 might or might not be available; nor does it represent that it has 542 made any independent effort to identify any such rights. Information 543 on the procedures with respect to rights in RFC documents can be 544 found in BCP 78 and BCP 79. 546 Copies of IPR disclosures made to the IETF Secretariat and any 547 assurances of licenses to be made available, or the result of an 548 attempt made to obtain a general license or permission for the use of 549 such proprietary rights by implementers or users of this 550 specification can be obtained from the IETF on-line IPR repository at 551 http://www.ietf.org/ipr. 553 The IETF invites any interested party to bring to its attention any 554 copyrights, patents or patent applications, or other proprietary 555 rights that may cover technology that may be required to implement 556 this standard. Please address the information to the IETF at 557 ietf-ipr@ietf.org. 559 Acknowledgment 561 Funding for the RFC Editor function is provided by the IETF 562 Administrative Support Activity (IASA).