idnits 2.17.1 draft-darilion-sip-e164-enum-00.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 559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 583. 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 350 has weird spacing: '...Service pro...' -- 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 18, 2008) is 5912 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4474 (ref. '3') (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 4871 (ref. '4') (Obsoleted by RFC 6376) ** Obsolete normative reference: RFC 3761 (ref. '6') (Obsoleted by RFC 6116, RFC 6117) == Outdated reference: A later version (-01) exists of draft-elwell-sip-e164-problem-statement-00 == Outdated reference: A later version (-01) exists of draft-schwartz-sip-e164-ownership-00 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP K. Darilion 3 Internet-Draft enum.at 4 Intended status: Standards Track H. Tschofenig 5 Expires: August 21, 2008 Nokia Siemens Networks 6 February 18, 2008 8 E.164 Ownership using Public Keys stored in ENUM 9 draft-darilion-sip-e164-enum-00.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 August 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 To determine which domain is allowed to claim ownership of a certain 43 telephone number is difficult. This may cause problems when to 44 authenticate endpoints that use telephone number URIs and domain 45 names in their From address. This document investigates a proposal 46 that stores a public key below the corresponding ENUM tree in the 47 DNS. The verifier can determine ownership by performing an ENUM 48 lookup to retrieve the public key from the DNS and to use it for 49 verifying the signature created as part of the SIP Identity 50 mechanism. 52 This document is a contribution to the ongoing discussion on RFC 4474 53 when used in combination with E.164 numbers. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. ENUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. User ENUM . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Infrastructure ENUM . . . . . . . . . . . . . . . . . . . 5 64 3.3. Private ENUM trees . . . . . . . . . . . . . . . . . . . . 5 66 4. Authentication Service Behavior . . . . . . . . . . . . . . . 6 68 5. Verifier Behavior . . . . . . . . . . . . . . . . . . . . . . 6 70 6. Considerations for User Agent . . . . . . . . . . . . . . . . 8 72 7. Considerations for Proxy Servers . . . . . . . . . . . . . . . 8 74 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 9. Caching and Scalability . . . . . . . . . . . . . . . . . . . 9 78 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 10 80 11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 12.1. TBD 'Unable to retrieve Public Key from DNS' Response 84 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 12.2. URI Scheme Registration . . . . . . . . . . . . . . . . . 11 87 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 14.1. Normative References . . . . . . . . . . . . . . . . . . . 12 91 14.2. Informative References . . . . . . . . . . . . . . . . . . 12 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 94 Intellectual Property and Copyright Statements . . . . . . . . . . 14 96 1. Introduction 98 RFC 4474 [3] defines a mechanism whereby an authentication service 99 authenticates a SIP UAC (possibly by sending a Digest authentication 100 challenge) and verifies whether he or she is authorized to use the 101 identity that is populated in the From header field. The 102 authentication service then computes a hash over some particular 103 headers, including the From header field and the bodies in the 104 message. This hash is signed with the certificate for the domain and 105 inserted in the 'Identity' header field in the SIP message. 107 The proxy, as the holder of the private key of its domain, is 108 asserting that the originator of this request has been authenticated 109 and that a specific user is authorized to claim the identity (the SIP 110 address-of-record) that appears in the From header field. The proxy 111 also inserts a companion header field, Identity-Info, that tells the 112 verifying party how to acquire its certificate, in case it is not yet 113 known already. 115 When the verifier receives the SIP message, it verifies the signature 116 provided in the Identity header, and thus can determine whether the 117 domain indicated by the host portion of the AoR in the From header 118 field authenticated the user, and permitted the user to assert that 119 From header field value. 121 The use of phone numbers with SIP was introduced with the TEL URL 122 scheme [5] whereby domain names were not used with the phone numbers. 123 SIP URIs always have domain names. In SIP [2], a translation between 124 SIP URIs and TEL URLs is described: when translating from a SIP URI 125 to a TEL URL, the domain name from the SIP URI is simply dropped. 126 When translating in the other direction (or simply generating a SIP 127 URI from an E.164 number) it is not clear how to populate the domain 128 name. 130 When SIP Identity [3] is applied to E.164 numbers [8] then there is 131 the question what the identity assertion actually means. 132 Additionally, the usage of the domain for an E.164 number is not 133 useful as described in [7]. This document does not make use of a 134 domain field attached to an E.164 number. 136 ****************************************************************** 137 The authors of this document do not claim that the question of 138 what ownership of E.164 numbers means is sufficiently well 139 understood at this point to be fully confident that any solution 140 actually helps to improve the current state-of-the-art. In fact, 141 the entire end-to-end security story when a call originates in the 142 PSTN and terminates somewhere on the Internet may weaken the 143 security of the call to such an extend that additional security 144 mechanisms applied to the communication on the Internet leg of the 145 call may not improve the overall security based on "security is as 146 good as the weakest link". However, strawman proposals (like this 147 one) might help to better understand the different forms of E.164 148 address ownership. The authors have received a large number of 149 intesting comments after distributing an initial proposal. 150 ****************************************************************** 152 This document investigates the ability to store a public key in the 153 ENUM database. The private key corresponding to that public key is 154 then used by the authentication service to compute the digital 155 signature for the 'Identity' header. Additionally, an indication is 156 provided for the verifier inside the Identity-Info header so that it 157 is apparent that the public key is not available at a given URI but 158 rather in the DNS used by ENUM. When the verifier receives a SIP 159 message that contains the 'Identity' header instead of obtaining the 160 certificate it performs a DNS lookup to determine the public key used 161 for the specific E.164 number. Possessing the public key stored with 162 the E.164 number allows verification of the digital signature. 164 From a design point of view we would like to make the following note: 166 This document does not define new SIP headers. Instead, it re- 167 uses existing headers from the SIP Identity specification. The 168 'Identity-Info' header is reused to convey a so-called selector 169 and the ENUM root. Both are required for the verification 170 procedure. The selector allows the authentication service to 171 support multiple concurrent public keys per signing domain and the 172 ENUM root allows to use different ENUM trees. This document 173 suggests to store the selector and the ENUM root as a URI in the 174 'Identity-Info' even though a new and more flexible header is 175 already required by the SIP SAML specification. 177 To summarize the proposed changes; this document suggests an 178 alternative method for storing public keys, namely one based on the 179 DNS in relationship to the ENUM database. This method is 180 conceptually similar to the approach used by DKIM [4]. As a 181 consequence, the mechanism to look-up the public key by the verifier 182 is different to the one proposed in [3]. The suggested modifications 183 are intentially kept at a minimum and only applicable when an E.164 184 number is signed by an authentication service. 186 2. Terminology 188 In this document, several words are used to signify the requirements 189 of the specification. These words are often capitalized. The key 190 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 191 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 192 are to be interpreted as described in [1]. 194 3. ENUM 196 ENUM comes in different deployment variations. The incentives for 197 storing public keys in ENUM with these deployments are different. 198 Mostly, they can be distinguished by the root domain and whether 199 access is restricted or unrestricted. 201 3.1. User ENUM 203 User ENUM is defined in [6]. It uses the root domain e164.arpa and 204 access is not restricted. The right to provison DNS records is given 205 to the user of the corresponding E.164 number. 207 Use cases for putting the public key into user ENUM are the 208 following. A user who has registered its E.164 number into ENUM and 209 has its own SIP infrastructure (like companies have) or users 210 utilizing their own open SIP infrastructure (similar to users running 211 an SMTP server). 213 3.2. Infrastructure ENUM 215 There is no exact definition for Infrastructure ENUM (also called 216 Carrier ENUM). Infrastrucure ENUM is often understood as a public 217 accessible ENUM tree (for example ie164.arpa) where the "carrier-of- 218 record" (the carrier which provide telephony service to the end-user) 219 is allowed to provision the DNS records. It can also be seen as 220 federations of private ENUM. 222 The use case for infrastructure ENUM is similar to user ENUM except 223 that now carriers are able to relate the "carrier of record" to the 224 E.164 number. For example, if a call is routed from carrier A to 225 carrier B via transit carrier T, T will trust A and B will trust T. 226 There is no way for B to verify that the caller is really allowed to 227 use the indicated caller id. 229 3.3. Private ENUM trees 231 Private ENUM trees choose just any available domain as root domain 232 (e.g., e164.example.com) and provide ENUM services below this root 233 domain. Whether access is restricited or not, and the policy for 234 provisioning of DNS records, is defined by the holder of that domain. 235 An example of a private ENUM tree with restricted access is the 3GPP 236 ENUM tree (e164enum.net). 238 Use cases are similar to before, except that the owner of the root 239 domain can decide who is allowed to use the ENUM tree. Furthermore, 240 private ENUM trees can be used if user ENUM is not available in the 241 respective country (for example by using nrenum.net). 243 The main drawback of this proposal is the fact that public ENUM does 244 not enjoy a lot of deployment (see http://enumdata.org/). This 245 document is, however, particularly useful for environments that make 246 use of public ENUM. Private and infrastructure ENUM only need SIP 247 Identity alike mechanisms when interacting with the "external" world 248 since they follow a sort of wallet garden model with a chain-of- 249 trust. There is non-neglectable deployment incentive challenge. As 250 such, this proposal will live or die with the ability to come up with 251 a lucrative deployment story. 253 4. Authentication Service Behavior 255 The authentication service behavior proposed in this document is 256 almost identical to the authentication service described in [3]. 258 Thus, the authentication service behavior is identical to the 259 description in Section 5 of [3] when TEL URIs are used with the 260 following addition for step 4: 262 When a TEL URI scheme is used in context of SIP Identity then the 263 'Identity-Info' header field does not contain a URI pointing to a 264 certificate but rather contains the DomainKeys selector and the 265 ENOM root domain since the procedure described in Section 5 allows 266 the verifier to determine the location of the public key 267 associated with a particular TEL URI. 269 The mechanism for storing a public key in the DNS is re-used from 270 DKIM [4]. 272 5. Verifier Behavior 274 When a verifier receives a SIP message containing an Identity-Info 275 header, it may inspect the signature to verify the identity of the 276 sender of the message. Typically, the results of a verification are 277 provided as input to an authorization process which is outside the 278 scope of this document. If an Identity-Info header is not present in 279 a request, and one is required by either local policy (for example, 280 based on a per-sending-domain policy, or a per-sending-user policy) 281 or remote policy, then 'Use Identity Header' response code MUST be 282 sent. 284 The steps executed by the verifier are outlined in Section 6 of [3] 285 with the exception that step 1 is different primarily because SIP 286 Identity relies on certificates whereas this document stores public 287 keys in the DNS. The following paragraph replaces the text the text 288 in Section 6/step 1 of [3]. This document does not make use of the 289 'Unsupported Certificate' and the 'Bad Identity-Info' response code. 291 Step 1: 293 The verifier MUST obtain the ENUM root domain from the Identity- 294 Info header and apply local policies to find out if the specified 295 ENUM root domain points to a trusted ENUM tree. If the specified 296 ENUM tree is not trusted, the verifier has to cancel the signature 297 verification and the message MUST be treated like an unsigned 298 message. 300 Step 2: 302 The verifier MUST acquire the public key for the signing domain. 303 This document suggests to store the public key in the DNS. 305 This document is only applicable for the usage of tel URIs in the 306 From: header. When the tel URI contains a 'global-number', i.e., 307 a phone number in E.164 format starting with the '+' sign, the 308 domain for retrieving the public key will be constructed according 309 to the following algorithm: 311 1. remove the 'visual-separators' and all parameters from the tel 312 URI 313 2. remove the leading "+" sign 314 3. put dots (".") between each digit 315 4. reverse the order of the digits 316 5. append the ENUM root domain (for example ".e164.arpa") to the 317 end 318 6. prepend the string "._domainkey." 319 7. prepend the selector 321 For example, given the tel URI 322 "tel:+43-1-5056416-36;mobile=false", the selector "2008-02" and 323 the root domain ".e164.arpa", the domain under which the public 324 key is stored is: 326 2008-02._domainkey.6.3.6.1.4.6.5.0.5.1.3.4.e164.arpa 328 Non global-numbers cannot be stored in ENUM and thus they cannot 329 be used in the From: header when signing the request by the 330 authentication service. 332 The 'Unable to retrieve Public Key from DNS' response code is used 333 when an error in fetching the public key from the DNS occurs. 335 6. Considerations for User Agent 337 There are no additional considerations beyond those described in 338 Section 8 of [3]. 340 7. Considerations for Proxy Servers 342 There are no additional considerations beyond those described in 343 Section 8 of [3]. 345 8. Examples 347 The following message exchange highlights the interaction. 349 Calling Auth. Called 350 UA Service proxies Verifier UA 351 ------- ------- -------- -------- ------ -------- 352 | | | | | ^ 353 | INVITE | | | | | 354 |--------->| | | | | 355 | | | | | | 356 | (signs request) | | | | 357 | | | | | | Steps 358 |100 | INVITE | | | | largely 359 |<---------|--------->| | | | based 360 | | | | | | on normal 361 | |100 | INVITE | | | RFC4474 362 | |<---------|--------->| | | processing 363 | | | | | | 364 | | |100 | | | 365 | | |<---------| | V 366 | | | | | ---------- 367 | | | | | ^ 368 | | | (retrieve | | 369 | | | public key | This 370 | | | from DNS) | document 371 | | | | | | 372 | | | | | v 373 | | | | | -------- 374 | | | (validates | ^ 375 | | | signature) | | steps 376 | | | | | | which are 377 | | | | | | part of 378 | | | | | | normal 379 | | | | INVITE | | RFC4474 380 | | | |--------->| V 381 | | | | | ---------- 382 | | | | | 383 | | | | |display 384 | | | | |E.164 number 386 Figure 1: Example Exchange 388 9. Caching and Scalability 390 When the verifier needs to determine the public key of a specific 391 E.164 number then it needs to perform a DNS lookup. This lookup 392 might be cached in the DNS but the lookup is specific for a certain 393 E.164 number and not for a domain. The verifier may cache the public 394 key corresponding to a particular E.164 number but there is no 395 guarantee that the same key will be used by any other E.164 number. 396 Furthermore, a specific E.164 number may have multiple public keys 397 associated with it based on the selector concept that is useful when 398 revocating keys or when delegating the signing process. 400 10. Privacy Considerations 402 The mechanism presented in this draft is compatible with the standard 403 SIP practices for privacy, described in RFC 3323 [9] and also with 404 the privacy considerations of RFC 4474 [3]. 406 11. Security Considerations 408 The mechanism described in this document has different authorization 409 properties than RFC 4474 [3]. A SIP message (including the 410 'Identity' and the 'Identity-Info' header) with an E.164 number in 411 the From: header field has the following property (if successfully 412 processed by the verifier): 414 The entity that uses the private key for creating the SIP Identity 415 header is authorized to attach the corresponding public key to the 416 ENUM database of the respective E.164 number used during the 417 lookup. 419 When using PKI infrastructure, the signature verifier trusts the 420 certificate authority, which attest the identity of the certificate 421 holder. Using ENUM, the signature verifier has to trust the ENUM 422 registry and the registrars. The ENUM registrar typically has to 423 validate that the user who tries to register an ENUM domain is the 424 number right holder. The validation methods usually will be 425 different between user ENUM (the validation methods can be approved 426 by official buddies) and private ENUM trees. 428 It is important to note that with this proposal public keys are 429 essentially for individual users rather than for the entire domain. 430 As such, the authentication service needs to have access to the 431 private keys corresponding to the respective public key. Note, 432 however, that there is nothing special about these key pairs as such 433 and there is no relationship to other (long-term) asymmetric 434 credentials potentially possessed by the user. They are rather used 435 only as a technical vehicle to accomplished the ownership requirement 436 described in this document. 438 This proposal also does not address the case where a call originates 439 in the PSTN and enters the Internet via provider that does not 440 possess the private key corresponding to the public key stored with 441 the E.164 number in the ENUM tree. This is, in some sense, desired 442 since Caller-ID spoofing is very easy in the PSTN and is difficult to 443 differentiate from a call that enters the Internet through a provider 444 that has no relationship with the calling party. This asymmetric 445 routing scenario is, however, quite common today. 447 Additional security considerations can be found in [10]. 449 12. IANA Considerations 451 This document requests IANA to register a new response code. 453 12.1. TBD 'Unable to retrieve Public Key from DNS' Response Code 455 This document registers a new SIP response code, which is described 456 in Section 5. It is used when a verifier tries to retrieve the 457 public key from the DNS and does not succeed and the DNS lookup 458 fails. This response code is defined by the following information, 459 which has been added to the method and response-code sub-registry 460 under http://www.iana.org/assignments/sip-parameters. 462 Response Code Number: TBD 464 Default Reason Phrase: Unable to retrieve Public Key from DNS 466 12.2. URI Scheme Registration 468 [Editor's Note: A future version of this document may register a URI 469 scheme that allows the SIP 'Identity-Info' header to be reused in 470 order to convey parameters from the authentication service to the 471 verifier.] 473 13. Acknowledgments 475 We would like to thank Dan Wing for raising the problems associated 476 with E.164 number-usage in SIP Identity and the discussion during 477 writing of this draft. Further we would like to thank Alexander 478 Mayrhofer for his ideas in [draft-mayrhofer-enum-domainkeys-00]. 480 We would also like to thank Kai Fischer, John Elwell, Hadriel Kaplan, 481 David Schwartz, and Jon Peterson for their off-list comments. 483 14. References 484 14.1. Normative References 486 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 487 Levels", BCP 14, RFC 2119, March 1997. 489 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 490 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 491 Session Initiation Protocol", RFC 3261, June 2002. 493 [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated 494 Identity Management in the Session Initiation Protocol (SIP)", 495 RFC 4474, August 2006. 497 [4] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and 498 M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", 499 RFC 4871, May 2007. 501 [5] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 502 December 2004. 504 [6] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 505 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 506 Application (ENUM)", RFC 3761, April 2004. 508 14.2. Informative References 510 [7] Elwell, J., "SIP E.164 Problem Statement", 511 draft-elwell-sip-e164-problem-statement-00 (work in progress), 512 February 2008. 514 [8] ITU-T, "The international public telecommunication numbering 515 plan", Recommendation E.164, May 1997. 517 [9] Peterson, J., "A Privacy Mechanism for the Session Initiation 518 Protocol (SIP)", RFC 3323, November 2002. 520 [10] Schwartz, D., "E.164 Ownership Problem Statement", 521 Std draft-schwartz-sip-e164-ownership-00.txt, Feb 2008. 523 Authors' Addresses 525 Klaus Darilion 526 enum.at GmbH 527 Karlsplatz 1/9 528 Wien A-1010 529 Austria 531 Phone: +43 1 5056416 36 532 Email: klaus.darilion@enum.at 533 URI: http://www.enum.at/ 535 Hannes Tschofenig 536 Nokia Siemens Networks 537 Linnoitustie 6 538 Espoo 02600 539 Finland 541 Phone: +358 (50) 4871445 542 Email: Hannes.Tschofenig@nsn.com 543 URI: http://www.tschofenig.com 545 Full Copyright Statement 547 Copyright (C) The IETF Trust (2008). 549 This document is subject to the rights, licenses and restrictions 550 contained in BCP 78, and except as set forth therein, the authors 551 retain all their rights. 553 This document and the information contained herein are provided on an 554 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 555 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 556 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 557 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 558 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 559 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 561 Intellectual Property 563 The IETF takes no position regarding the validity or scope of any 564 Intellectual Property Rights or other rights that might be claimed to 565 pertain to the implementation or use of the technology described in 566 this document or the extent to which any license under such rights 567 might or might not be available; nor does it represent that it has 568 made any independent effort to identify any such rights. Information 569 on the procedures with respect to rights in RFC documents can be 570 found in BCP 78 and BCP 79. 572 Copies of IPR disclosures made to the IETF Secretariat and any 573 assurances of licenses to be made available, or the result of an 574 attempt made to obtain a general license or permission for the use of 575 such proprietary rights by implementers or users of this 576 specification can be obtained from the IETF on-line IPR repository at 577 http://www.ietf.org/ipr. 579 The IETF invites any interested party to bring to its attention any 580 copyrights, patents or patent applications, or other proprietary 581 rights that may cover technology that may be required to implement 582 this standard. Please address the information to the IETF at 583 ietf-ipr@ietf.org. 585 Acknowledgment 587 Funding for the RFC Editor function is provided by the IETF 588 Administrative Support Activity (IASA).