idnits 2.17.1 draft-ietf-sipping-update-pai-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 523. 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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3325, but the abstract doesn't seem to directly say this. It does mention RFC3325 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3325, updated by this document, for RFC5378 checks: 2002-05-28) -- 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 14, 2008) is 5887 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG J. Elwell 3 Internet-Draft Siemens Enterprise Communications 4 Updates: RFC 3325 GmbH & Co KG 5 (if approved) February 14, 2008 6 Intended status: Informational 7 Expires: August 17, 2008 9 Updates to Asserted Identity in the Session Initiation Protocol (SIP) 10 draft-ietf-sipping-update-pai-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 17, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 SIP has a mechanism for conveying the asserted identity of the 44 originator of a request by means of the P-Asserted-Identity header 45 field. This header field is specified for use in requests using a 46 number of SIP methods, in particular the INVITE method. However, RFC 47 3325 does not specify the insertion of this header field by a trusted 48 UAC, does not specify the use of this header field with the SIP 49 UPDATE, MESSAGE or PUBLISH methods, and is unclear on the use of this 50 header field in responses. This document extends RFC 3325 to cover 51 these situations. 53 This work is being discussed on the sipping@ietf.org mailing list. 55 Table of Contents 57 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Inclusion of P-Asserted-Identity by a UAC . . . . . . . . 4 61 3.2. Inclusion of P-Asserted-Identity in an UPDATE request . . 4 62 3.3. Inclusion of P-Asserted-Identity or 63 P-Preferred-Identity in a MESSAGE request . . . . . . . . 5 64 3.4. Inclusion of P-Asserted-Identity or 65 P-Preferred-Identity in a PUBLISH request . . . . . . . . 5 66 3.5. Inclusion of P-Asserted-Identity or 67 P-Preferred-Identity in a response . . . . . . . . . . . . 6 68 4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. UAC Behaviour . . . . . . . . . . . . . . . . . . . . . . 7 70 4.1.1. Request handling . . . . . . . . . . . . . . . . . . . 7 71 4.1.2. Response handling . . . . . . . . . . . . . . . . . . 8 72 4.2. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 8 73 4.2.1. Request handling . . . . . . . . . . . . . . . . . . . 8 74 4.2.2. Response handling . . . . . . . . . . . . . . . . . . 9 75 4.3. UAS Behaviour . . . . . . . . . . . . . . . . . . . . . . 9 76 4.3.1. Request handling . . . . . . . . . . . . . . . . . . . 9 77 4.3.2. Response handling . . . . . . . . . . . . . . . . . . 9 78 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 79 6. Security considerations . . . . . . . . . . . . . . . . . . . 10 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 81 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 Intellectual Property and Copyright Statements . . . . . . . . . . 12 85 1. Terminology 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 2. Introduction 93 SIP [RFC3261] has a mechanism for conveying within a Trust Domain the 94 asserted identity of the originator of a request by means of the 95 P-Asserted-Identity header field [RFC3325]. This header field is 96 specified for use in requests using a number of SIP methods, in 97 particular the INVITE method. However, RFC 3325 does not specify the 98 insertion of this header field by a UAC in the same Trust Domain as 99 the first proxy. 101 Also RFC 3325 does not specify the use of the P-Asserted-Identity 102 header field with the SIP UPDATE method [RFC3311], the SIP MESSAGE 103 method [RFC3428] or the SIP PUBLISH method [RFC3903], and is unclear 104 on the use of this header field in responses. There are similar 105 omissions concerning the P-Preferred-Identity header field. 107 This document extends RFC 3325 by allowing inclusion of the 108 P-Asserted-Identity header field by a UAC in the same Trust Domain as 109 the first proxy, allowing use of this header field in UPDATE, MESSAGE 110 and PUBLISH requests and, under certain conditions, allowing use of 111 this header field in SIP responses. It also allows the use of the 112 P-Preferred-Identity header field in some of these situations. 114 OPEN ISSUE 1: Should we allow use of PAI in REGISTER requests 115 (between an authenticating edge proxy and the registrar)? 117 OPEN ISSUE 2: Should we allow use of PAI in all mid-dialog requests 118 (including PRACK, INFO, BYE etc.) rather than just UPDATE? The 119 present motivation in this document is that an identity may change 120 mid-dialog, and although the new identity can at present be 121 conveyed in a re-INVITE request, this needs extending to UPDATE 122 requests. I don't think any other method would need to be used to 123 convey a new identity mid-dialog. Therefore the only motivation 124 for extending to all mid-dialog requests is to provide an explicit 125 assertion that the source of each request has been authenticated. 127 3. Discussion 128 3.1. Inclusion of P-Asserted-Identity by a UAC 130 RFC 3325 does not include procedures for a UAC to include the 131 P-Asserted-Identity header field in a request. This can be 132 meaningful if the UAC is in the same Trust Domain as the first proxy. 133 Examples of types of UAC that are often suitable for inclusion in a 134 Trust Domain are: 136 o PSTN gateways; 138 o media servers; 140 o application servers (or B2BUAs) that act as URI list servers 141 [I-D.ietf-sipping-uri-services]; 143 o application servers (or B2BUAs) that perform third party call 144 control. 146 In the particular case of a PSTN gateway, the PSTN gateway might be 147 able to assert an identity received from the PSTN, the proxy itself 148 having no means to authenticate such an identity. Likewise, in the 149 case of certain application server or B2BUA arrangements, the 150 application server or B2BUA may be in a position to assert an 151 identity of a user on the other side of that application server or 152 B2BUA. 154 In accordance with RFC 3325, nodes within a Trust Domain must be 155 connected using TLS with a certain cipher suite, and this principle 156 needs to apply to the connection between a UAC and its proxy as part 157 of the condition for considering the UAC to be within the same Trust 158 Domain. Normal proxy procedures of RFC 3325 ensure that the header 159 field is removed or replaced if the first proxy considers the UAC to 160 be outside the Trust Domain. 162 3.2. Inclusion of P-Asserted-Identity in an UPDATE request 164 There are several use cases that would benefit from the use of the 165 P-Asserted-Identity header field in an UPDATE request. These use 166 cases apply within a Trust Domain where the use of asserted identity 167 is appropriate (see RFC 3325). 169 In one example, an established call passes through a gateway to the 170 PSTN. The gateway becomes aware that the remote party in the PSTN 171 has changed, e.g., due to call transfer. By including the 172 P-Asserted-Identity header field in an UPDATE request, the gateway 173 can convey the identity of the new remote party to the peer SIP UA. 175 Note that the (re-)INVITE method could be used in this situation. 176 However, this forces an offer-answer exchange, which typically is 177 not required in this situation. Also it involves 3 messages 178 rather than 2. 180 In another example, a B2BUA that provides third party call control 181 (3PCC) wishes to join two calls together, one of which is still 182 waiting to be answered and potentially is forked to different UAs. 183 At this point in time it is not possible to trigger the normal offer- 184 answer exchange between the two joined parties, because of the 185 mismatch between a single dialog on the one side and potentially 186 multiple early dialogs on the other side, so this action must wait 187 until one of the called UAs answers. However, it would be useful to 188 give an early indication to each user concerned of the identity of 189 the user to which they will become connected when the call is 190 answered. This can be achieved by the B2BUA sending an UPDATE 191 request with a P-Asserted-Identity header field on the dialogs 192 concerned. 194 OPEN ISSUE 3: Are there any use cases that justify the use of 195 P-Preferred-Identity in an UPDATE request? 197 3.3. Inclusion of P-Asserted-Identity or P-Preferred-Identity in a 198 MESSAGE request 200 Within a Trust Domain, a P-Asserted-Identity header field could 201 advantageously be used in a MESSAGE request to assert the source of a 202 page mode instant message. This would complement its use in an 203 INVITE request to assert the source of an instant message session or 204 any other form of session. Similarly, between a UAC and first proxy 205 that are not within the same Trust Domain, a P-Preferred-Identity 206 header field could be used in a MESSAGE request to express a 207 preference when the user has several identities. 209 3.4. Inclusion of P-Asserted-Identity or P-Preferred-Identity in a 210 PUBLISH request 212 Within a Trust Domain, a P-Asserted-Identity header field could 213 advantageously be used in a PUBLISH request to assert the source of 214 published state information. This would complement its use in 215 SUBSCRIBE and NOTIFY requests. Similarly, between a UAC and first 216 proxy that are not within the same Trust Domain, a P-Preferred- 217 Identity header field could be used in a PUBLISH request to express a 218 preference when the user has several identities. 220 3.5. Inclusion of P-Asserted-Identity or P-Preferred-Identity in a 221 response 223 There are cases where the inclusion of the P-Asserted-Identity header 224 field in responses would be useful. Retargeting of a request can 225 result in the responding entity having a different identity from that 226 placed in the To URI of the request. Inclusion of asserted identity 227 in a response would provide the UAC with the identity of the sender. 228 Some examples of the benefits to be gained include: 230 o Asserted identity in a 2xx response to an INVITE request would 231 indicate the identity of the connected user. 233 o Asserted identity in a provisional response to an INVITE request 234 would indicate the contacted (e.g., alerted) user. 236 o Asserted identity in a 2xx response to a MESSAGE request would 237 give provide confirmation of where the message was delivered to. 239 o Asserted identity in certain 4xx/5xx/6xx responses would provide 240 an indication of where the response originated. 242 In the case of a request that results in the formation of a dialog, a 243 mid-dialog request (e.g., UPDATE) in the reverse direction can 244 provide the identity of the user at the destination end of that 245 dialog, and therefore the need to include asserted identity in a 246 response to the dialog-forming request is debatable. There can be 247 some benefits in terms of ease of interworking with PSTN, where such 248 information is placed in the response to a call establishment 249 request. For other responses, including successful responses to 250 requests such as MESSAGE and PUBLISH and unsuccessful responses, the 251 use of a request in the reverse direction is unsuitable. 253 RFC 3325 is ambiguous on inclusion of P-Asserted-Identity in a 254 response. For example, section 4 of RFC 3325 talks about inclusion 255 of the header field in messages, as opposed to requests. Moreover 256 section 5 explicitly mentions "message (request or response)". 257 However, there are other places (e.g., sections 6, 7 and 8) that talk 258 only about requests. 260 Section 5 of RFC 3325 requires a proxy to authenticate the originator 261 of a message before adding a P-Asserted-Identity header field to the 262 forwarded message. In practice there is no SIP means to authenticate 263 the sender of a SIP response message. However, authentication may be 264 possible by other means. For example, if the proxy has TLS 265 connectivity with the originator of the response and has previously 266 authenticated the connected entity (e.g., using SIP digest 267 authentication at registration time), then the originator of the 268 response can be considered to be authenticated. In such 269 circumstances it is permissible for a proxy to insert a P-Asserted- 270 Identity header field in a SIP response. 272 OPEN ISSUE 4: It has been suggested that we must be precise (at 273 least in the normative section) as to the conditions under which a 274 proxy may assert an identity in the response. One approach would 275 be to say that the only acceptable condition is that given above 276 as an example. Are there any other acceptable conditions? 278 It should also be permissible for a UAS to insert a P-Asserted- 279 Identity header field into a response if it is within the same Trust 280 Domain as the proxy from which the request was received (the last 281 proxy). 283 Between a UAS and last proxy that are not within the same Trust 284 Domain, a P-Preferred-Identity header field could be used in a 285 response, in order to express a preference when the authenticated 286 user has several identities. 288 4. Behaviour 290 This updates RFC 3325 by allowing a P-Asserted-Identity header field 291 to be included by a UAC within the same Trust Domain, by allowing a 292 P-Asserted-Identity header field to appear in an UPDATE, MESSAGE or 293 PUBLISH request, and by allowing a P-Asserted-Identity header field 294 to appear in a response in certain circumstances. It also allows a 295 P-Preferred-Identity header field to appear in a MESSAGE or PUBLISH 296 request or in a response. 298 4.1. UAC Behaviour 300 4.1.1. Request handling 302 A UAC MAY include a P-Asserted-Identity header field in a request to 303 report the identity of the user on behalf of which the UAC is acting 304 and whose identity the UAC is in a position to assert. A UAC SHOULD 305 do so only in cases where it believes it is in the same Trust Domain 306 as the first proxy and is connected to the first proxy in accordance 307 with the security requirements of RFC 3325. A UAC SHOULD NOT do so 308 in other circumstances and might instead use the P-Preferred-Identity 309 header field. A UAC MUST NOT include both header fields. 311 A UAC MAY include a P-Asserted-Identity header field in an UPDATE 312 request to report a changed identity mid-dialog. This can be an 313 UPDATE request sent specially for this purpose or an UPDATE request 314 sent for some other purpose. A UAC SHOULD do so only in cases where 315 it believes it is in the same Trust Domain as the first proxy and is 316 connected to the first proxy in accordance with the security 317 requirements of RFC 3325. 319 A UAC MAY include a P-Asserted-Identity or P-Preferred-Identity 320 header field in a MESSAGE or PUBLISH request. A UAC SHOULD include a 321 P-Asserted-Identity header field only in cases where it believes it 322 is in the same Trust Domain as the first proxy and is connected to 323 the first proxy in accordance with the security requirements of RFC 324 3325. 326 4.1.2. Response handling 328 Typically a UA renders the value of a P-Asserted-Identity header 329 field that it receives in a response to its user. It may consider 330 the identity provided by a Trust Domain to be privileged, or 331 intrinsically more trustworthy than other information in the 332 response. However, any particular behaviour is specific to 333 implementations or services. This document also does not mandate any 334 UA handling for multiple P-Asserted-Identity header field values that 335 happen to appear in a response (such as a SIP URI alongside a tel 336 URL). 338 However, if a UAC receives a response from a previous element outside 339 the Trust Domain, it MUST NOT use the P-Asserted-Identity header 340 field in any way. 342 If a UA is part of the Trust Domain from which it received a response 343 containing a P-Asserted-Identity header field, then it can use the 344 value freely but it MUST ensure that it does not forward the 345 information to any element that is not part of the Trust Domain if 346 the user has requested that asserted identity information be kept 347 private. 349 4.2. Proxy Behaviour 351 4.2.1. Request handling 353 If a proxy receives a request from a UAC within the Trust Domain it 354 MUST behave as for a request from any other node within the Trust 355 Domain, in accordance with the rules of RFC 3325 for a proxy. 357 If a proxy receives an UPDATE, MESSAGE or PUBLISH request containing 358 a P-Asserted-Identity header field, it MUST behave as for any other 359 request in accordance with the rules of RFC 3325 for a proxy. 361 If a proxy receives a MESSAGE or PUBLISH request containing a 362 P-Preferred-Identity header field, it MUST behave as for any other 363 request in accordance with the rules of RFC 3325 for a proxy. 365 4.2.2. Response handling 367 The proxy behaviour specified in RFC 3325 is applicable to responses 368 with the following qualifications. A proxy that receives a response 369 from a node outside the Trust Domain cannot directly authenticate the 370 UAS by SIP means. Therefore it MUST NOT include a P-Asserted- 371 Identity header field when forwarding the response unless it has 372 authenticated the UAS by other means. If a proxy receives a response 373 from a UAS within the Trust Domain it MUST behave as for a response 374 from any other node within the Trust Domain, in accordance with the 375 rules of RFC 3325 for a proxy. 377 One possible circumstance in which a proxy can include a 378 P-Asserted-Identity header field when forwarding a response from a 379 node outside the Trust Domain is when the proxy has direct TLS 380 connectivity with the UAS and has authenticated the UA by some 381 other means (e.g., SIP digest authentication) during that same TLS 382 session. 384 The proxy behaviour specified in RFC 3325 for handling a received 385 P-Preferred-Identity header field is applicable also to responses, 386 subject to the qualification above concerning authentication of the 387 UAS as a pre-requisite for inserting a P-Asserted-Identity header 388 field. 390 4.3. UAS Behaviour 392 4.3.1. Request handling 394 If a UAS receives an UPDATE, MESSAGE or PUBLISH request containing a 395 P-Asserted-Identity header field, it MUST behave as for any other 396 request in accordance with the rules of RFC 3325 for a UAS. 398 4.3.2. Response handling 400 A UAS MAY include a P-Asserted-Identity or P-Preferred-Identity 401 header field in a response to report the identity of the user on 402 behalf of which the UAS is acting and whose identity the UAS is in a 403 position to assert. A UAS SHOULD include a P-Asserted-Identity 404 header field only in cases where it believes it is in the same Trust 405 Domain as the last proxy and is connected to the last proxy in 406 accordance with the security requirements of RFC 3325. 408 5. IANA considerations 410 None 412 6. Security considerations 414 The use of asserted identity raises a number of security 415 considerations, which are discussed fully in [RFC3325]. This 416 document raises the following additional security considerations. 418 When receiving a request or response containing a P-Asserted-Identity 419 header field directly from a UA (rather than from another proxy), a 420 proxy will trust the UA only if it is known to be within the Trust 421 Domain and is connected by means of TLS as specified in RFC 3325. 422 One example where this might be true is a UA that is a PSTN gateway. 423 In this case the UA can assert an identity received from the PSTN, 424 the proxy itself having no means to authenticate such an identity. A 425 proxy must not trust an identity asserted by a UA outside the Trust 426 Domain. 428 When receiving a response from a node outside the Trust Domain, a 429 proxy has no direct SIP means to authenticate the node. However, if 430 authentication has taken place by other means (e.g., an earlier use 431 of SIP digest authentication) and the entity sending the response is 432 known to be the same entity (e.g., connected via the same TLS 433 session) this can be sufficient grounds for asserting an identity. 434 In other circumstances a proxy must not assert identity for a 435 responding user. 437 7. Acknowledgements 439 Useful comments were received from Jonathan Rosenberg and Cullen 440 Jennings during drafting. 442 8. Normative References 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, March 1997. 447 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 448 A., Peterson, J., Sparks, R., Handley, M., and E. 449 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 450 June 2002. 452 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 453 UPDATE Method", RFC 3311, October 2002. 455 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 456 Extensions to the Session Initiation Protocol (SIP) for 457 Asserted Identity within Trusted Networks", RFC 3325, 458 November 2002. 460 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 461 and D. Gurle, "Session Initiation Protocol (SIP) Extension 462 for Instant Messaging", RFC 3428, December 2002. 464 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 465 for Event State Publication", RFC 3903, October 2004. 467 [I-D.ietf-sipping-uri-services] 468 Camarillo, G. and A. Roach, "Framework and Security 469 Considerations for Session Initiation Protocol (SIP) 470 Uniform Resource Identifier (URI)-List Services", 471 draft-ietf-sipping-uri-services-07 (work in progress), 472 November 2007. 474 Author's Address 476 John Elwell 477 Siemens Enterprise Communications GmbH & Co KG 478 Hofmannstrasse 51 479 D-81379 Munich 480 Germany 482 Phone: +44 115 943 4989 483 Email: john.elwell@siemens.com 485 Full Copyright Statement 487 Copyright (C) The IETF Trust (2008). 489 This document is subject to the rights, licenses and restrictions 490 contained in BCP 78, and except as set forth therein, the authors 491 retain all their rights. 493 This document and the information contained herein are provided on an 494 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 495 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 496 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 497 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 498 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 499 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 501 Intellectual Property 503 The IETF takes no position regarding the validity or scope of any 504 Intellectual Property Rights or other rights that might be claimed to 505 pertain to the implementation or use of the technology described in 506 this document or the extent to which any license under such rights 507 might or might not be available; nor does it represent that it has 508 made any independent effort to identify any such rights. Information 509 on the procedures with respect to rights in RFC documents can be 510 found in BCP 78 and BCP 79. 512 Copies of IPR disclosures made to the IETF Secretariat and any 513 assurances of licenses to be made available, or the result of an 514 attempt made to obtain a general license or permission for the use of 515 such proprietary rights by implementers or users of this 516 specification can be obtained from the IETF on-line IPR repository at 517 http://www.ietf.org/ipr. 519 The IETF invites any interested party to bring to its attention any 520 copyrights, patents or patent applications, or other proprietary 521 rights that may cover technology that may be required to implement 522 this standard. Please address the information to the IETF at 523 ietf-ipr@ietf.org. 525 Acknowledgment 527 Funding for the RFC Editor function is provided by the IETF 528 Administrative Support Activity (IASA).