idnits 2.17.1 draft-kaplan-sip-baiting-attack-02.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 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 484. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 497. 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 22, 2008) is 5905 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4572 (Obsoleted by RFC 8122) -- Obsolete informational reference (is this intentional?): RFC 4871 (ref. 'DKIM') (Obsoleted by RFC 6376) == Outdated reference: A later version (-07) exists of draft-ietf-avt-dtls-srtp-01 == Outdated reference: A later version (-07) exists of draft-ietf-sip-dtls-srtp-framework-00 == Outdated reference: A later version (-02) exists of draft-wing-sip-identity-media-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group H. Kaplan 3 Internet Draft Acme Packet 4 Intended status: Informational D. Wing 5 Cisco Systems 6 Expires: August 22, 2008 February 22, 2008 8 The SIP Identity Baiting Attack 9 draft-kaplan-sip-baiting-attack-02 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 24 months and may be updated, replaced, or obsoleted by other documents 25 at any 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/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 August 22, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document identifies a potential SPIT and Phishing attack, which 43 subverts the RFC 4474 SIP Identity and RFC 4916 Connected Identity 44 mechanisms in a particular way. The attack is termed "Baiting", as 45 it uses a RFC4474-signed call as the bait for malicious use. 47 Table of Contents 49 1. Introduction................................................2 50 1.1. Background.............................................3 51 2. Terminology.................................................3 52 3. Applicability...............................................4 53 4. Overview of the Attack......................................4 54 5. Harvesting Signed Invites...................................5 55 6. RFC-4474 Cut-Paste Protection...............................6 56 7. Baiting with Offer-less Invites.............................7 57 8. Baiting with ICE............................................7 58 9. Baiting with SRTP...........................................7 59 10. Baiting with non-INVITE Requests............................7 60 11. Attack Success Conditions...................................8 61 12. Possible Solutions?.........................................8 62 12.1. SIP Identity and SIP Connected Identity................8 63 12.2. Secured Media with a Secret............................9 64 13. Security Considerations.....................................9 65 14. IANA Considerations.........................................9 66 15. References..................................................9 67 15.1. Informative References.................................9 68 Authors' Addresses...............................................10 69 Intellectual Property Statement..................................12 70 Full Copyright Statement.........................................12 71 Acknowledgment...................................................12 73 1. Introduction 75 SIP Identity, defined in [RFC4474], defines a mechanism for 76 originating domains to sign SIP requests with a certificate, in 77 order to prove the legitimacy of the From identity and the request's 78 body content. The motivation of the work derived from the need to 79 provide a form of cryptographically strong end-to-end (or end-domain 80 to end-domain) identity, in order to avoid malicious use of identity 81 fraud. 83 While not specifically called out, many people consider the 84 [RFC4474] mechanism as useful for preventing SPIT and Phishing 85 attacks, because strong identity is a basis for many anti-SPIT 86 techniques [SIP-SPAM]. This draft describes a form of attack which 87 shows that is not the case. 89 Furthermore, [RFC4916] defines a way to use the same Identity 90 mechanism to perform called party identification, by issuing a re- 91 INVITE or UPDATE request from the called party to the caller. This 92 draft describes a way to mis-use that mechanism to aid in the 93 attack. 95 It should be noted that neither [RFC4474] nor [RFC4916] claim to 96 prevent this form of attack, nor in fact is Baiting an attack on the 97 mechanisms themselves. It uses the mechanisms for malicious use, 98 and shows that the mechanisms should not be assumed to provide 99 benefits they do not. Lastly, one of the motivations in writing 100 this draft was to show that one does not need to truly be a man-in- 101 the-middle in order to perform a cut-paste form of attack such as 102 Baiting. 104 1.1. Background 106 SIP [RFC3261] has a transitive trust model, whereby SIP requests get 107 routed through various intermediaries. In this model, the 108 initiating User Agents (UAs) must generally rely on the 109 intermediaries to be secure. Such a trust model has many security 110 issues, one of which is identity proof. As in email, if the 111 identity of the sender of a message cannot be secured, various forms 112 of impersonation attacks are possible. 114 Two very common issues in email today are SPAM and Phishing attacks, 115 which both benefit from impersonation. For SIP-based applications, 116 SPIT (SPAM for Internet Telephony) is not yet a serious problem, due 117 mostly to the early stage of SIP deployment, a closed service model, 118 and fees for use. As it grows in popularity and decreases in cost, 119 however, its potential for attracting SPIT will grow. 121 [RFC4474] follows a similar general model as [DKIM] for source-based 122 identity authentication, but the resulting symptoms caused by some 123 of DKIM's weaknesses has greater importance for SIP as a real-time 124 session-setup protocol than Email does. SPAM, for example, would be 125 far less tolerated for phone calls than they would for email, even 126 if the called party ignored the call but the phone rang. 128 2. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119. The 133 terminology in this document conforms to RFC 2828, "Internet 134 Security Glossary". 136 3. Applicability 138 This draft applies to the [RFC4474] SIP Identity and [RFC4916] 139 Connected Identity mechanisms. 141 4. Overview of the Attack 143 The general form of the attack is as follows: 145 1. An attacker, Bob, is registered at a typical [RFC3261] 146 compliant domain: example.net. Bob wishes to attack 147 alice@example.com. 148 2. Bob "harvests" an [RFC4474] signed request from a legitimate 149 party, such as Bank. This can be done through various means, 150 such as filling out a web form for the Bank to call him, 151 leaving a voicemail, or whatever - or possibly using the 152 [RFC4916] connected-identity mechanism, as described later in 153 this document. 154 3. Bank sends a [RFC4474] signed Invite with SDP to Bob. 155 4. Bob terminates the call attempt from Bank with a failure 156 response. 157 5. Bob takes the received SIP Invite request from Bank, inserts 158 a Via and Record-Route header of his UA's address, and 159 changes the request-URI with a new target of 160 sip:alice@example.com, the ultimate victim of the attack. 161 Bob may also change the From tag, delete the received Via's, 162 and/or possibly insert a History-Info header. 163 6. Bob sends the Invite through his domain example.net, or 164 directly to example.com, or through another domain. 165 7. The signed request is routed based on the request-URI, 166 eventually leading to Alice's Identity verifier. 167 8. Alice's domain receives the request, and verifies the 168 [RFC4474] identity signature. In the previous steps, Bob has 169 not changed anything which was signed by [RFC4474], so the 170 validation succeeds. Note that the To URI will most likely 171 be sip:bob@example.net, but per [RFC3261] Alice's domain does 172 not verify that the To domain is the same as Alice's domain - 173 nor could it, because the request may have simply been 174 forwarded through re-targeting, which is legitimate. 175 9. Alice's phone rings, with Bank appearing as the source 176 caller. At this point, Bob has already succeeded in annoying 177 Alice, because her phone rang, and she thought it was Bank. 178 10. Alice picks up the phone, which sends a 200 ok response to 179 Bob. 180 11. Bob receives the SDP answer in the 200 ok, which tells him 181 where to send media to Alice. Bob sends an ACK to Alice. 183 12. Bob then sends his SPIT audio RTP to Alice, possibly spoofing 184 the IP Address and port in the SDP offer sent by Bank. Bank 185 will not be sending RTP itself, because it does not get the 186 200 ok, and (in step 4) Bob terminated the call from Bank. 187 13. At this point Bob is successfully SPAM-ing Alice. Alice may 188 send media to Bank, but since Bob terminated the call from 189 Bank (in step 4), Bank discards/ignores the media from Alice. 190 14. Alternatively, Bob may attempt Phishing by inserting a Call- 191 Info header with a HTTP URL or even a DATA URL, and the audio 192 may tell Alice to click on the link or view the DATA URL 193 content. Alice receives a cryptographic assertion that the 194 call is from Bank, and thus the phishing attack has a higher 195 chance of success. 197 Note that this form of the attack creates one-way media, from Bob to 198 Alice, which Alice believes is from Bank. Bob can use the one-way 199 media to announce an advertisement, such as: 201 "Your Bank urges you to vote for during the upcoming 202 election. Thank you and have a nice day." 204 Or Bob might use the one-way audio for phishing, such as: 206 "This is a recording from your Bank. Your account has been 207 compromised. Please call us, at , to 208 restore service to your bank account. Thank you and have a 209 nice day." 211 When Alice calls the attacker's phone number, the attacker will now 212 have bi-directional audio with the victim. 214 5. Harvesting Signed Invites 216 There are several ways in which an attacker, Bob, can try to harvest 217 multiple [RFC4474] signed Invite requests for malicious use: 219 1. Bob can have Bank call him, by submitting web contact forms, 220 leaving voicemail, etc. 221 2. If Bank calls Bob, Bob can issue 3xx redirect responses to 222 redirect the call request to another alias account, or even to 223 himself again. This may even yield new Call-Id's for each 224 redirected request, and minimally new CSeq values - each of 225 these will have a valid [RFC4474] signature. 226 3. If Bank calls Bob, and Bank supports [RFC4028] Session Timers, 227 Bob can respond with a low Session-Expires header duration 228 (e.g., 90 seconds), with a refresher=uac parameter, and an 229 Allow header which does not include UPDATE as an allowed 230 Method, in an attempt to get Bank to issue signed re-INVITEs 231 continuously and often. 233 4. Bob can make a SIP call to Bank, such as Bank's 800-number IVR 234 system, expecting Bank to support [RFC4916] Connected Identity. 235 Bob can send an Allow header which does not include UPDATE as 236 an allowed Method, in an attempt to get Bank to issue a re- 237 INVITE to prove its identity. 238 5. For calls initiated by Bob, Bob could include the [RFC4028] 239 'timer' Supported option tag and Session-Expires header of 240 short duration (e.g., 90 seconds), with a refresher=uas 241 parameter, in order to get Bank to issue re-INVITE's 242 continuously and often. 243 6. Bob could try to passively monitor legitimate, unencrypted, SIP 244 traffic. 245 7. Bob could try to become a "Man-in-the-Middle", for example by 246 compromising a legitimate Proxy. 248 Note that any signed INVITE, whether within a dialog or not, is 249 potentially useful for performing a Baiting attack. [RFC4474] does 250 not sign the To-tag, and thus it can simply be removed for re-use as 251 a "new" INVITE. Stateful verifiers may or may not detect such re- 252 use. And Bob can simply send them to different target domains, to 253 avoid hitting the same verifier. 255 Even if Bob sends multiple such INVITEs, with the same Call-Id, to 256 the same target domain, [RFC4474] is not explicit about how a 257 Verifier should behave. Each harvested request would have a unique 258 CSeq value, and thus unique signature, and not be detected as a 259 strict replay attack per [RFC4474]. It is not clear how it really 260 could be detected as a replay, either, given the need to support 261 legitimate signed re-INVITEs within a dialog, and dialog matching 262 based on Call-Id and tags (not Call-Id alone). 264 6. RFC-4474 Cut-Paste Protection 266 It is important to note that [RFC4474] signs the Call-Id in an 267 attempt to prevent such cut-paste attacks. The assumption is that 268 the verifying domain keeps track of the call-id's for the duration 269 of the Date interval (typically 1 hour), and does not allow a 270 duplicate request using the same Call-Id. This Baiting attack sends 271 the request to a domain other than the one in the To-URI, and thus 272 one harvested [RFC4474]-signed INVITE can be sent to numerous target 273 domains. 275 Interestingly, Bob can use one of the listed harvesting techniques 276 within a dialog or through 3xx redirects, to get additional signed 277 requests to use against different users of the *same* target domain. 278 Thus Bob could attack multiple users in the same target domain from 279 one [RFC4474] call from or to Bank. Furthermore, if verification is 280 performed by the end UA's and not by a centralized verifier system 281 for the end-domain, this attack would succeed against *all* users of 282 that domain from one harvested INVITE (because the end UAs would not 283 be able to protect each other from cut-and-pasted Call-IDs). 285 7. Baiting with Offer-less Invites 287 If Bank were to generate an Invite without SDP, the attack is still 288 possible, but even more severe because the attacker (Bob) can end up 289 with a bi-directional media call. Bob would be able to send media 290 on Alice's SDP offer in her response, and Bob could create his own 291 ACK with his SDP answer. If Alice expects an identity-signed ACK, 292 Bob could even answer Bank's call and use Bank's signed ACK in the 293 same way as the Invite. Note that [RFC4474] provides no mechanism 294 to determine when ACKs need to be signed, and since an ACK cannot be 295 responded to, Alice cannot really reject it either - it would be 296 silently ignored. 298 8. Baiting with ICE 300 The NAT traversal mechanism defined in [ICE] would seem to aid the 301 attacker. The password and username fragment are signed by 302 [RFC4474], but they will be clearly viewable to the attacker, and 303 thus the attacker should be able to generate STUN connectivity 304 checks using them, impersonating the legitimate caller. We believe 305 this would mean ICE would actually enable the attacker to achieve 306 bi-directional media, for the malicious call. [This is TBD, pending 307 review by an ICE expert (a glaciologist?)] 309 9. Baiting with SRTP 311 The Baiting attack is just as successful with the [RFC4568] 312 security-descriptions key exchange mechanism, because the keys are 313 in cleartext for the attacker. The attacker can thus generate the 314 SRTP packets to the victim. For [DTLS-SRTP], coupled with [DTLS- 315 SRTP-FRAMEWORK], the fingerprint being signed prevents a Baiting 316 attack from succeeding, because the attacker cannot successfully 317 modify the fingerprint in the [RFC4474]-signed SDP. 319 10. Baiting with non-INVITE Requests 321 It should be clear that the main focus of the Baiting attack 322 outlined in this draft is the INVITE request, however one can apply 323 Baiting to other requests. All SIP requests outside of a dialog are 324 routed based on the request-URI or Route headers, and thus any 325 harvested request can be cut-paste to a new target. However it is 326 harder to harvest such requests in general, and to do so in such a 327 way that it provides any real gain to cut-paste them, other than for 328 annoyance purposes. 330 11. Attack Success Conditions 332 What makes the attack successful are the following issues with the 333 [RFC4474] mechanism: 335 1) Requests in SIP are routed based on the Request-URI and/or 336 Route headers, not the To-URI. The To-URI is signed, but 337 it doesn't prevent the request being sent elsewhere and 338 accepted by parties other than that indicated in the To- 339 URI. Email-based [DKIM] has a similar issue, but at least 340 with email the To information is displayed, whereas it 341 rarely is with SIP. 342 2) Unlike Email, where all of the sensitive content is 343 contained in the body of the request, SIP is used as a 344 rendezvous and session setup protocol for the sensitive 345 content: the media. That is why [RFC4474] signs the SDP: 346 in order to provide some protection for the ultimate 347 content. But as this attack shows, it cannot truly do so 348 alone. 349 3) [RFC4474] does not sign the Call-Info header. 350 4) [RFC4474] does not sign the tags of the request. While it 351 provides no clear use to do so for initial requests (which 352 have no To-tag), it would protect requests within a 353 dialog. [RFC4916] simply re-uses the [RFC4474] mechanism, 354 and thus would benefit from this as well. 356 12. Possible Solutions? 358 12.1. SIP Identity and SIP Connected Identity 360 The purpose of this draft is to outline a security issue with 361 [RFC4474] and [RFC4916], not to fix it. However, we outline a few 362 possible corrections to [RFC4474] to address parts of the attack: 364 1. Sign the Call-Info header. It is "sensitive" in a similar way 365 as SDP or bodies. 366 2. Include the tags, or at least the To-tag, in the signed headers 367 list. This would prevent harvested in-dialog requests from 368 being re-used outside the dialog. 369 3. Clearly specify how Verifiers should act with respect to two 370 signed requests of the same Call-Id+CSeq but different tags, 371 vs. same Call-Id but different tags+CSeq should behave. 372 4. Possibly specify that UPDATE requests without bodies are not 373 signed? Seems like a massive overhead for session-timers to 374 sign such requests. 376 To address the general issue of request routing having nothing to do 377 with the signed To-URI, one possible solution is to have the UAS or 378 Verifier have a list of AoR's/To-URI's they are willing to accept 379 requests for. In other words, if Alice's UAS or Verifier knew that 380 only requests with a To-URI of "sip:alice@example.com", and whatever 381 other aliases and lists/groups she is a member of, were allowed, 382 then the UAS or verifier could simply reject baited requests. [in 383 fact, such a thing is probably generally useful regardless of 384 Identity signatures] This "access list" could be provisioned by 385 Alice into her UAS, or her UAS could publish such information into 386 the Verifier, or her UAS or Verifier could learn it from her 387 Registrar through a subscribe package or config-framework, etc. 389 Such an access list mechanism would only work for native SIP users, 390 however. One could not, for example, be able to create an access 391 list for a SIP-PSTN gateway, since such gateways handle calls to any 392 PSTN destination user. This may or may not be a good property to 393 have for Identity verification, but it severely limits the 394 usefulness of [RFC4474]. 396 12.2. Secured Media with a Secret 398 For SIP methods involving media, such as an INVITE, the use of 399 secure media with proof of possession of a secret (such as a private 400 key) can prevent the Baiting attack. Examples of this include 401 comedia-tls [RFC4572], [IDENTITY-MEDIA], and [E2E-SEC-MEDIA]. 403 13. Security Considerations 405 The purpose of this draft is to identify a security issue. 407 14. IANA Considerations 409 None; this document is informational. 411 15. References 413 15.1. Informative References 415 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 416 A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 417 Session Initiation Protocol", RFC 3261, June 2002. 419 [RFC4028] Donovan, S., "Session Timers in the Session Initiation 420 Protocol (SIP)", RFC 4028, April 2005. 422 [RFC4474] Peterson, J., Jennings, C., "Enhancements for 423 Authenticated Identity Management in the Session Initiation Protocol 424 (SIP)", RFC 4474, August 2006. 426 [RFC4568] Andreasen, F., Baugher, M., Wing, D., "Session 427 Description Protocol (SDP) Security Descriptions for Media Streams", 428 RFC 4568, July 2006. 430 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 431 Transport Layer Security (TLS) Protocol in the Session Description 432 Protocol (SDP)", RFC4572, July 2006. 434 [DKIM] Allman, E., et al, "DomainKeys Identified Mail (DKIM) 435 Signatures", RFC 4871, May 2007. 437 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 438 Protocol (SIP)", RFC 4916, June 2007. 440 [SIP-SPAM] Rosenberg, J., Jennings, C., "The Session Initiation 441 Protocol (SIP) and Spam", RFC 5039, January 2008. 443 [DTLS-SRTP] McGrew, D., Rescorla, E., "Datagram Transport Layer 444 Security (DTLS) Extension to Establish Keys for Secure Real-time 445 Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-01.txt, 446 November 2007. 448 [DTLS-SRTP-FRAMEWORK] Fischl, J., Tschofenig, H., Rescorla, E., 449 "Framework for Establishing an SRTP Security Context using DTLS" 450 draft-ietf-sip-dtls-srtp-framework-00.txt, November 2007. 452 [E2E-SEC-MEDIA] Fischer, K., "End-to-End Security for DTLS-SRTP", 453 draft-fischer-sip-e2e-sec-media-00.txt, January 2008. 455 [ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): 456 A Protocol for Network Address Translator (NAT) Traversal for 457 Offer/Answer Protocols", draft-ietf-mmusic-ice-19.txt, October 2007. 459 [IDENTITY-MEDIA] Wing, D., Kaplan, H., "SIP Identity using Media 460 Path", draft-wing-sip-identity-media-01, November 2007. 462 Authors' Addresses 464 Hadriel Kaplan 465 Acme Packet 466 71 Third Ave. 467 Burlington, MA 01803, USA 468 Email: hkaplan@acmepacket.com 469 Dan Wing 470 Cisco Systems, Inc. 471 170 West Tasman Drive 472 San Jose, CA 95134 473 Email: dwing@cisco.com 475 Intellectual Property Statement 477 The IETF takes no position regarding the validity or scope of any 478 Intellectual Property Rights or other rights that might be claimed 479 to pertain to the implementation or use of the technology described 480 in this document or the extent to which any license under such 481 rights might or might not be available; nor does it represent that 482 it has made any independent effort to identify any such rights. 483 Information on the procedures with respect to rights in RFC 484 documents can be found in BCP 78 and BCP 79. 486 Copies of IPR disclosures made to the IETF Secretariat and any 487 assurances of licenses to be made available, or the result of an 488 attempt made to obtain a general license or permission for the use 489 of such proprietary rights by implementers or users of this 490 specification can be obtained from the IETF on-line IPR repository 491 at http://www.ietf.org/ipr. 493 The IETF invites any interested party to bring to its attention any 494 copyrights, patents or patent applications, or other proprietary 495 rights that may cover technology that may be required to implement 496 this standard. Please address the information to the IETF at ietf- 497 ipr@ietf.org. 499 Full Copyright Statement 501 Copyright (C) The IETF Trust (2007). 503 This document is subject to the rights, licenses and restrictions 504 contained in BCP 78, and except as set forth therein, the authors 505 retain all their rights. 507 This document and the information contained herein are provided on 508 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 509 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 510 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 511 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 512 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 513 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 514 FOR A PARTICULAR PURPOSE. 516 Acknowledgment 518 Funding for the RFC Editor function is provided by the IETF 519 Administrative Support Activity (IASA).