idnits 2.17.1 draft-niccolini-speermint-voipthreats-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 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 578. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 584. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (August 30, 2007) is 6078 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC 4033-4035' on line 403 == Unused Reference: '4' is defined on line 505, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 509, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 513, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 517, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 521, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-speermint-architecture-02 == Outdated reference: A later version (-22) exists of draft-zimmermann-avt-zrtp-02 == Outdated reference: A later version (-10) exists of draft-ietf-tls-rfc4346-bis-02 -- Obsolete informational reference (is this intentional?): RFC 3851 (ref. '6') (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '8') (Obsoleted by RFC 8224) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPEERMINT Working Group S. Niccolini 3 Internet-Draft NEC 4 Intended status: Informational E. Chen 5 Expires: March 2, 2008 NTT 6 August 30, 2007 8 VoIP Security Threats relevant to SPEERMINT 9 draft-niccolini-speermint-voipthreats-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 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 2, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This memo presents the different security threats related to 43 SPEERMINT classifying them into threats to the Location Function, to 44 the Signaling Function and to the Media Function. The different 45 instances of the threats are briefly introduced inside the 46 classification. Finally the existing security solutions in SIP and 47 RTP/RTCP are presented to describe the countermeasures currently 48 available for such threats. The objective of this document is to 49 identify and enumerate the SPEERMINT-specific threat vectors in order 50 to specify security-related requirements. Once the requirements are 51 identified, methods and solutions how to achieve such requirements 52 can be selected. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Security Threats relevant to SPEERMINT . . . . . . . . . . . . 5 59 2.1. Threats Relevant to the Location Function (LF) . . . . . . 5 60 2.1.1. Threats to LF Confidentiality . . . . . . . . . . . . 5 61 2.1.2. Threats to LF Integrity . . . . . . . . . . . . . . . 5 62 2.1.3. Threats to LF Availability . . . . . . . . . . . . . . 6 63 2.2. Threats to the Signaling Function (SF) . . . . . . . . . . 6 64 2.2.1. Threats to SF Confidentiality . . . . . . . . . . . . 6 65 2.2.2. Threats to SF Integrity . . . . . . . . . . . . . . . 7 66 2.2.3. Threats to SF Availability . . . . . . . . . . . . . . 8 67 2.3. Threats to the Media Function (MF) . . . . . . . . . . . . 9 68 2.3.1. Threats to MF Confidentiality . . . . . . . . . . . . 9 69 2.3.2. Threats to MF Integrity . . . . . . . . . . . . . . . 9 70 2.3.3. Threats to MF Availability . . . . . . . . . . . . . . 9 72 3. Security Best Practices . . . . . . . . . . . . . . . . . . . 11 73 3.1. General Security Best Practices . . . . . . . . . . . . . 11 74 3.2. Security Best Practices for the LF . . . . . . . . . . . . 11 75 3.2.1. Ensure LF Confidentiality . . . . . . . . . . . . . . 11 76 3.2.2. Ensure LF Integrity . . . . . . . . . . . . . . . . . 11 77 3.2.3. Ensure LF Availability . . . . . . . . . . . . . . . . 11 78 3.3. Security Best Practices for the SF . . . . . . . . . . . . 12 79 3.3.1. Ensure SF Confidentiality . . . . . . . . . . . . . . 12 80 3.3.2. Ensure SF Integrity . . . . . . . . . . . . . . . . . 12 81 3.3.3. Ensure SF Availability . . . . . . . . . . . . . . . . 12 82 3.4. Security Best Practices for the MF . . . . . . . . . . . . 12 83 3.4.1. Ensure MF Confidentiality and Integrity . . . . . . . 12 84 3.4.2. Ensure MF Availability . . . . . . . . . . . . . . . . 12 86 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 92 7. Informative References . . . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 95 Intellectual Property and Copyright Statements . . . . . . . . . . 19 97 1. Introduction 99 With VoIP, the need for security is compounded because there is the 100 need to protect both the control plane and the data plane. In a 101 legacy telephone system, security is a more valid assumption. 102 Intercepting conversations requires either physical access to 103 telephone lines or to compromise the Public Switched Telephone 104 Network (PSTN) nodes or the office Private Branch eXchanges (PBXs). 105 Only particularly security-sensitive organizations bother to encrypt 106 voice traffic over traditional telephone lines. In contrast, the 107 risk of sending unencrypted data across the Internet is more 108 significant (e.g. DTMF tones corresponding to the credit card 109 number). An additional security threat to Internet Telephony comes 110 from the fact that the signaling is sent using the same network as 111 the multimedia data; traditional telephone systems have the signaling 112 network separated from the data network. This is an increased 113 security threat since a hacker could attack the signaling network and 114 its servers with increased damage potential (call hijacking, call 115 drop, DoS attacks, etc.). Therefore there is the need of 116 investigating the different security threats, to extract security- 117 related requirements and to highlight the solutions how to protect 118 from such threats. 120 2. Security Threats relevant to SPEERMINT 122 This section enumerates potential security threats relevant to 123 SPEERMINT. A taxonomy of VoIP security threats is defined in [1]. 124 Such a taxonomy is really comprehensive and takes into account also 125 non-VoIP-specific threats (e.g. loss of power, etc.). Threats 126 relevant to the boundaries of layer-5 SIP networks are extracted from 127 such a taxonomy and mapped to the classification relevant for the 128 SPEERMINT architecture as defined in [2], moreover additional threats 129 for the SPEERMINT architecture are listed and detailed under the same 130 classification: 132 o Location Function (LF); 134 o Signaling Function (SF); 136 o Media Function (MF). 138 An additional category is also included for completeness to address 139 social threats relevant to SPEERMINT even if they are currently out 140 of the scope of the SPEERMINT charter. 142 2.1. Threats Relevant to the Location Function (LF) 144 2.1.1. Threats to LF Confidentiality 146 o numbers/identities harvesting - the attacker harvests numbers 147 and/or user identities by issuing a multitude of location requests 148 with the purpose of discovering the existent ones and their 149 identifiers/addresses for calling them, for using them as spoofed 150 identities or just for retrieving their location in the physical 151 topology; 153 o signaling entities harvesting - the attacker harvests signaling 154 entities (SIP Proxy Servers, etc.) addresses by issuing a specific 155 number of requests with the purpose of discovering their location 156 in the physical topology or for targeting them with subsequent 157 attacks. 159 2.1.2. Threats to LF Integrity 161 o routing directories modification - the attacker modifies routing 162 directories (e.g. DNS, ENUM tree, etc.) in an unauthorized way in 163 order to modify the call routing. The scope could be to reroute 164 the call inserting unauthorized nodes in the path, to exclude 165 authorized nodes from the path, to route the call towards a wrong 166 destination causing a Denial of Service (DoS), to route the call 167 towards a wrong destination causing annoyance for the callee; 169 o call routing modification by Man in the Middle (MitM) - the 170 attacker has already or inserts an unauthorized node in the 171 signaling path in order to modify the call routing. The scope 172 could be to reroute the call inserting other unauthorized nodes in 173 the path, to exclude authorized nodes from the path, to route the 174 call towards a wrong destination causing a Denial of Service 175 (DoS), to route the call towards a wrong destination causing 176 annoyance for the callee; 178 o DNS and ENUM hijacking - the attacker uses a technique called 179 cache poisoning that exploits a flaw in the DNS software and 180 tricks the server into receiving incorrect information. The 181 compromised server would cache and serve the incorrect information 182 locally. This technique can be used to replace arbitrary NAPTR 183 records for a set of ENUM queries with NAPTR records of an 184 attacker's choosing. This allows the attacker to redirect all 185 calls to a malicious destination. 187 o proxy impersonation - the attacker tricks a SIP UA or proxy into 188 communicating with a rogue proxy. VoIP calls established among 189 different peering providers may introduce a number of new 190 opportunities for such attack as intermediate proxies are 191 discovered dynamically during call routing. A successful proxy 192 impersonation allows full access and control to all routed SIP 193 messages. 195 2.1.3. Threats to LF Availability 197 o Denial of Service Attacks to LF - A DoS attack to the location 198 function is possible by sending a large number of queries to the 199 associated ENUM gateways or DNS servers. This prevents a User 200 Agent to look up the NAPTR record of the intended recipient of the 201 call. 203 2.2. Threats to the Signaling Function (SF) 205 Signaling function involves a great number of sensitive information. 206 Through signaling function, user agents (UA) assert identities and 207 VSP operators authorize billable resources. Correct and trusted 208 operations of signaling function is essential for service providers. 209 This section discusses potential security threats to the signaling 210 function to detail the possible attack vectors. 212 2.2.1. Threats to SF Confidentiality 214 o call pattern tracking - the attacker tracks the call patterns of 215 the users violating his/her privacy; 217 2.2.2. Threats to SF Integrity 219 o session black holing - the attacker intentionally drops essential 220 packets (e.g. INVITE) of the VoIP protocol resulting the call 221 initiation to fail, it is needed that the attacker controls (or 222 is) a node in the middle of the signaling path; 224 o session tear down - the attacker uses CANCEL/BYE messages in order 225 to tear down an existing call at SIP layer, it is needed that the 226 attacker replicates the proper SIP header for the hijacking to be 227 successful (To, From, Call-ID, CSeq); 229 o seesion hijacking - the attacker uses SIP messages (e.g. 301 Moved 230 Temporarily) in order to hijack an existing call towards 231 unexisting proxy/endpoint to make the session initiation fail, it 232 is needed that the attacker replicates the proper SIP header for 233 the hijacking to be successful (To, From, Call-ID, CSeq); 235 o SIP message spoofing - There are a number of ways to perform a DoS 236 attack by spoofing SIP messages. An attacker may directly send 237 initial INVITE messages to a User Agent that has no capability to 238 authenticate them. Such messages may cause the UA to ring non- 239 stop and effectively make it unusable. Moreover, if the INVITE 240 appears to come from a SIP server, the UA may keep responding to 241 the server with multiple messages. This may cause a DrDoS 242 (Distributed Reflection DoS) attack to the SIP server if enough 243 UAs are comprimised. Another technique involves injecting faked 244 BYE/CANCEL or error reponses to an ongoing dialogue in order to 245 tear down a session or interrupt a session establishment. 247 o accounting fraud by media oversize - the attacker injects in the 248 network more traffic than declared in the session request in order 249 to avoid paying for the used resources; 251 o session replay - the attacker replays a past session of another 252 user in order to have access to the same resources (e.g. a bank 253 account, etc.). This attack can results in using resources 254 without paying for them, having access to sensitive inforation, 255 loss of money, etc.; 257 o call hijacking - the attacker uses SIP messages (e.g. 301 Moved 258 Temporarily) in order to hijack an existing call towards other 259 proxy/endpoint, it is needed that the attacker replicates the 260 proper SIP header for the hijacking to be successful (To, From, 261 Call-ID, CSeq); 263 o caller ID spoofing - the attacker spoofs the caller identifier in 264 order to make calls avoiding paying for them. 266 o bypassing SF - the attacker sends the session intiation directly 267 to the endpoint (Ua, media gateway, etc.) bypassing signaling 268 entities in order to avoid paying for the used resources. 270 o weak caller ID assertion by peers - a carrier member fails to 271 achieve the level of identity assertion expected by the federation 272 may introduce an entry point for attackers to conduct CID (caller 273 ID) spoofing fraud. This would affect all members in the 274 federation, despite their efforts to strengthen the assertion 275 within their own domains. 277 o illegitimate transit peers - multimedia traffic may be 278 unknowningly delivered through an illegitimate transit peer. This 279 introduces opportunities for a variety of attacks by rough peers. 281 o codec negotiation interruption/modification - signaling function 282 is used to perform handshake regarding the codec(s) to be used 283 during multimedia session. An attacker may intentionally drop or 284 modify only packets involved in the handshake. This attack could 285 interrupt the multimedia communication or degrade the quality 286 achievable in the case o lower quality codec is used. 288 o SIP protocol spefication interruption/modification - signaling 289 function may use specific details of the signaling protocol. 290 Extensions and the signaling associated may vary. An attacker may 291 intentionally drop or modify only packets meant to give evidence 292 or declare such extensions tricking the peering party into wrong 293 assumptions. This attack could make the peering party wrongly 294 allocating protocol mediation function resulting in failure to 295 establish communications or parts of them. Moreover the peering 296 party would unnecessarly use resources in allocating such protocol 297 mediation function resulting in a DoS attack. 299 o bid-down attack to SF - a number of encryption key exchange 300 protocols performs handshake through the Signaling Function. An 301 attacker may intentionally drop or modify only packets involved in 302 the handshake. While this attack does not interrupt the voice 303 communication, calling parties are prenvented from establishing an 304 SRTP session to secure privacy. 306 2.2.3. Threats to SF Availability 308 o SIP malformed requests and messages - the attacker tries to cause 309 a crash or a reboot of the proxy/endpoint by sending SIP malformed 310 requests and messages; 312 o SIP requests and messages flooding - the attacker tries to exhaust 313 the resources of the proxy/endpoint by sending many SIP requests 314 and messages; 316 2.3. Threats to the Media Function (MF) 318 Media function is responsible for the actual delivery of multimedia 319 comunication between the users and carries sensitive information. 320 Through media function, user agents (UA) can establish secure 321 communications and monitor quality of conversations. Correct and 322 trusted operations of media function is essential for privacy and 323 service assurance issues. This section discusses potential security 324 threats to the media function to detail the possible attack vectors. 326 2.3.1. Threats to MF Confidentiality 328 o eavesdropping - the attacker reconstruct the conversation and/or 329 additional data delivered with it (e.g.numbers transmitted with 330 DTMF tones); 332 2.3.2. Threats to MF Integrity 334 o media alteration - the attacker alters some RTP packets in order 335 to modify the conversation between two users; 337 o bid-down attack to MF - a number of encryption key exchange 338 protocols performs handshake through the Media Function. ZRTP [3] 339 is an example of such protocol that exchanges key information 340 using RTP at the beginning before establishing an SRTP session. 341 An attacker may intentionally drop only RTP packets involved in 342 the handshake. While this attack does not interrupt the voice 343 communication, calling parties are prenvented from establishing an 344 SRTP session to secure privacy. 346 2.3.3. Threats to MF Availability 348 o RTP/RTCP malformed messages - the attacker tries to cause a crash 349 or a reboot of the proxy/endpoint by sending RTP/RTCP malformed 350 messages; 352 o RTP/RTCP messages flooding - the attacker tries to exhaust the 353 resources of the proxy/endpoint by sending many RTP/RTCP messages; 355 o RTP/RTCP session tear down - the attacker uses RTCP messages (e.g. 356 BYE) in order to tear down an existing call at RTP layer, the SIP 357 layer will not notice that the RTP flow has been torn down and the 358 call will not result as released; 360 o RTP/RTCP QoS degradation - the attacker sends wrong RTCP reports 361 advertising more packet loss or more jitter than actually 362 experimented resulting in the usage of a poor quality codec 363 degrading the overall quality of the call experience. 365 3. Security Best Practices 367 This section will be completed in the next version 369 3.1. General Security Best Practices 371 In the next version, this section will describe general security best 372 practices such as the following. 374 o source address assurance by ingress filtering 376 o audit trail, trapping and logging 378 o trusted time stamping 380 o critical resource allocation 382 o exception handling 384 o system monitoring 386 o mechanism to timely apply patches and supplementary code 388 o separate network for management 390 3.2. Security Best Practices for the LF 392 In the next version, this section will describe LF security best 393 practices such as the following. 395 3.2.1. Ensure LF Confidentiality 397 o Encryption 399 o stripping proper headers at the border by SM/SBE 401 3.2.2. Ensure LF Integrity 403 o authenticate DNS records with digital certificates [RFC 4033-4035] 405 o strong authentication against intermediate nodes 407 3.2.3. Ensure LF Availability 409 o server redundancy 411 o filter illegitimate traffic 413 3.3. Security Best Practices for the SF 415 In the next version, this section will describe SF security best 416 practices such as the following. 418 3.3.1. Ensure SF Confidentiality 420 o encryption 422 3.3.2. Ensure SF Integrity 424 o encryption 426 o Strong identity assertion 428 o strong authentication against intermediate nodes 430 o shared secret contact info between UA and server to prevent 431 illegitimate INVITE packets 433 3.3.3. Ensure SF Availability 435 o Fuzzing test against all devices before release 437 o Mechanism to timely apply patches 439 o Server redundancy 441 o Rate limitation 443 3.4. Security Best Practices for the MF 445 In the next version, this section will describe MF security best 446 practices such as the following. 448 3.4.1. Ensure MF Confidentiality and Integrity 450 o SRTP [requires consensus outside SPEERMINT on key exchange 451 protocol] 453 3.4.2. Ensure MF Availability 455 o Fuzzing test against all UA devices before release 457 o DBEs provides policing based on active sessions (also cross-layer 458 issue) 460 o verify whether packet rate is consistent with negotiated 461 parameters 463 4. Conclusions 465 This memo presented a the different SPEERMINT security threats 466 classified in groups related to the Location Function, Signaling 467 Function and Media Function respectively. The multiple instances of 468 the threats are presented with a brief explanation. Finally the 469 existing security solutions in VoIP were presented to describe the 470 countermeasures currently available for such threats. The objective 471 of this document is to identify and enumerate the VoIP threat vectors 472 in order to specify security-related requirements specific to 473 SPEERMINT (that will be included in section Section 3). Once the 474 requirements are identified, methods and solutions how to achieve 475 such requirements can be selected. 477 5. Security Considerations 479 This memo is entirely focused on the security threats for SPEERMINT. 481 6. Acknowledgements 483 This memo takes inspiration from VOIPSA VoIP Security and Privacy 484 Threat Taxonomy. The author would like to thank VOIPSA for having 485 produced such a comprehensive taxonomy which is the starting point of 486 this draft. The author would also like to thank Cullen Jennings for 487 the useful slides presented at the VoIP Management and Security 488 workshop in Vancouver. 490 7. Informative References 492 [1] "VOIPSA VoIP Security and Privacy Threat Taxonomy", 493 October 2005. 495 [2] Penno, R., Hammer, M., Khan, S., Malas, D., and A. Uzelac, 496 "SPEERMINT Peering Architecture", 497 draft-ietf-speermint-architecture-02.txt (work in progress), 498 October 2006. 500 [3] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Extensions 501 to RTP for Diffie-Hellman Key Agreement for SRTP", 502 draft-zimmermann-avt-zrtp-02.txt (work in progress), 503 October 2006. 505 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 506 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 507 Session Initiation Protocol", RFC 3261, June 2002. 509 [5] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.2", 510 draft-ietf-tls-rfc4346-bis-02.txt (work in progress), 511 October 2006. 513 [6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 514 (S/MIME) Version 3.1 Message Specification", RFC 3851, 515 July 2004. 517 [7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 518 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 519 RFC 3711, March 2004. 521 [8] Peterson, J. and C. Jennings, "Enhancements for Authenticated 522 Identity Management in the Session Initiation Protocol (SIP)", 523 RFC 4474, August 2006. 525 Authors' Addresses 527 Saverio Niccolini 528 Network Laboratories, NEC Europe Ltd. 529 Kurfuersten-Anlage 36 530 Heidelberg 69115 531 Germany 533 Phone: +49 (0) 6221 4342 118 534 Email: saverio.niccolini@netlab.nec.de 535 URI: http://www.netlab.nec.de 537 Eric Chen 538 Information Sharing Platform Laboratories, NTT 539 3-9-11 Midori-cho 540 Musashino, Tokyo 180-8585 541 Japan 543 Email: eric.chen@lab.ntt.co.jp 544 URI: http://www.ntt.co.jp/index_e.html 546 Full Copyright Statement 548 Copyright (C) The IETF Trust (2007). 550 This document is subject to the rights, licenses and restrictions 551 contained in BCP 78, and except as set forth therein, the authors 552 retain all their rights. 554 This document and the information contained herein are provided on an 555 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 556 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 557 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 558 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 559 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 560 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 562 Intellectual Property 564 The IETF takes no position regarding the validity or scope of any 565 Intellectual Property Rights or other rights that might be claimed to 566 pertain to the implementation or use of the technology described in 567 this document or the extent to which any license under such rights 568 might or might not be available; nor does it represent that it has 569 made any independent effort to identify any such rights. Information 570 on the procedures with respect to rights in RFC documents can be 571 found in BCP 78 and BCP 79. 573 Copies of IPR disclosures made to the IETF Secretariat and any 574 assurances of licenses to be made available, or the result of an 575 attempt made to obtain a general license or permission for the use of 576 such proprietary rights by implementers or users of this 577 specification can be obtained from the IETF on-line IPR repository at 578 http://www.ietf.org/ipr. 580 The IETF invites any interested party to bring to its attention any 581 copyrights, patents or patent applications, or other proprietary 582 rights that may cover technology that may be required to implement 583 this standard. Please address the information to the IETF at 584 ietf-ipr@ietf.org. 586 Acknowledgment 588 Funding for the RFC Editor function is provided by the IETF 589 Administrative Support Activity (IASA).