idnits 2.17.1 draft-ietf-sipping-update-pai-07.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 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 479. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 492. 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 (October 13, 2008) is 5672 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) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 9 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 October 13, 2008 5 (if approved) 6 Intended status: Informational 7 Expires: April 16, 2009 9 Updates to Asserted Identity in the Session Initiation Protocol (SIP) 10 draft-ietf-sipping-update-pai-07.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 April 16, 2009. 37 Abstract 39 SIP has a mechanism for conveying the asserted identity of the 40 originator of a request by means of the P-Asserted-Identity header 41 field. This header field is specified for use in requests using a 42 number of SIP methods, in particular the INVITE method. However, RFC 43 3325 does not specify the insertion of this header field by a trusted 44 UAC, does not specify the use of P-Asserted-Identity and P-Preferred- 45 Identity header fields with certain SIP methods such as UPDATE, 46 REGISTER, MESSAGE, PUBLISH and ACK, and does not specify how to 47 handle an unexpected number of URIs or unexpected URI schemes in 48 these header fields. This document extends RFC 3325 to cover these 49 situations. 51 This work is being discussed on the sipping@ietf.org mailing list. 53 Table of Contents 55 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Inclusion of P-Asserted-Identity by a UAC . . . . . . . . 4 59 3.2. Inclusion of P-Asserted-Identity in any request . . . . . 5 60 3.3. Dialog implications . . . . . . . . . . . . . . . . . . . 6 61 4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. UAC Behaviour . . . . . . . . . . . . . . . . . . . . . . 7 63 4.2. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Registrar Behaviour . . . . . . . . . . . . . . . . . . . 7 65 4.4. UAS Behaviour . . . . . . . . . . . . . . . . . . . . . . 8 66 4.5. General handling . . . . . . . . . . . . . . . . . . . . . 8 67 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 68 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 Intellectual Property and Copyright Statements . . . . . . . . . . 12 76 1. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 This document uses the concepts of Trust Domain and Spec(T), as 83 specified in section 2.3 of RFC 3324 [RFC3324]. 85 2. Introduction 87 The Session Initiation Protocol (SIP) is specified in RFC 3261 88 [RFC3261]. RFC 3325 [RFC3325] specifies a mechanism for conveying 89 within a Trust Domain the asserted identity of the originator of a 90 SIP request. This is achieved by means of the P-Asserted-Identity 91 header field, which is specified for use in requests using a number 92 of SIP methods, in particular the INVITE method. 94 RFC 3325 does not specify the insertion of the P-Asserted-Identity 95 header field by a UAC in the same Trust Domain as the first proxy. 96 Also RFC 3325 does not specify the use of the P-Asserted-Identity and 97 P-Preferred-Identity header fields with certain SIP methods such as 98 UPDATE [RFC3311], REGISTER, MESSAGE [RFC3428], PUBLISH [RFC3903] and 99 ACK. This document extends RFC 3325 by allowing inclusion of the 100 P-Asserted-Identity header field by a UAC in the same Trust Domain as 101 the first proxy and allowing use of P-Asserted-Identity and 102 P-Preferred-Identity header fields in any request. 104 RFC 3325 allows the P-Asserted-Identity and P-Preferred-Identity 105 header fields each to contain at most two URIs, where one is a SIP or 106 SIPS URI [RFC3261] and the other is a TEL URI [RFC3966]. This may be 107 unduly restrictive in future, for example if there is a need to allow 108 other URI schemes, if there is a need to allow both a SIP and a SIPS 109 URI or if there is a need to allow more than one URI with the same 110 scheme (e.g., a SIP URI based on a telephone number and a SIP URI 111 that is not based on a telephone number). This document therefore 112 provides forwards compatibility by mandating tolerance to the receipt 113 of unexpected URIs. 115 This document does not alter the fact that the asserted identity 116 mechanism has limited applicability, i.e., within a Trust Domain. 117 For general applicability, including operation outside a Trust Domain 118 (e.g., over the public Internet) or between different Trust Domains, 119 a different mechanism is needed. RFC 4474 [RFC4474] specifies the 120 Identity header field, in conjunction with the From header field, for 121 providing authenticated identity in such circumstances. RFC 4916 122 [RFC4916] specifies the use of RFC 4474 in mid-dialog requests, in 123 particular in requests in the reverse direction to the dialog-forming 124 request as a means of providing authenticated connected identity. 126 RFC 3325 is unclear on the use of P-Asserted-Identity in responses. 127 In contrast to requests, there is no means in SIP to challenge a UAS 128 to provide SIP digest authentication in a response. As a result, 129 there is currently no standardised mechanism whereby a proxy can 130 authenticate a UAS. Since authenticating the source of a message is 131 a pre-requisite for asserting an identity, this document does not 132 specify the use of the P-Asserted-Identity header field in responses. 133 This may be the subject of a future update to RFC 3325. Also this 134 document does not specify the use of the P-Preferred-Identity header 135 field in responses, as this would serve no purpose in the absence of 136 the ability for a proxy to insert the P-Asserted-Identity header 137 field. 139 3. Discussion 141 3.1. Inclusion of P-Asserted-Identity by a UAC 143 RFC 3325 does not include procedures for a UAC to include the 144 P-Asserted-Identity header field in a request. This can be 145 meaningful if the UAC is in the same Trust Domain as the first 146 downstream SIP entity. Examples of types of UAC that are often 147 suitable for inclusion in a Trust Domain are: 149 o PSTN gateways; 151 o media servers; 153 o application servers (or B2BUAs) that act as URI list servers 154 [I-D.ietf-sipping-uri-services]; 156 o application servers (or B2BUAs) that perform third party call 157 control. 159 In the particular case of a PSTN gateway, the PSTN gateway might be 160 able to assert an identity received from the PSTN, the proxy itself 161 having no means to authenticate such an identity. Likewise, in the 162 case of certain application server or B2BUA arrangements, the 163 application server or B2BUA may be in a position to assert an 164 identity of a user on the other side of that application server or 165 B2BUA. 167 In accordance with RFC 3325, nodes within a Trust Domain must behave 168 in accordance with a Spec(T), and this principle needs to apply 169 between a UAC and its proxy as part of the condition for considering 170 the UAC to be within the same Trust Domain. Normal proxy procedures 171 of RFC 3325 ensure that the header field is removed or replaced if 172 the first proxy considers the UAC to be outside the Trust Domain. 174 This update to RFC 3325 clarifies that a UAC may include a 175 P-Asserted-Identity header field in a request in certain 176 circumstances. 178 3.2. Inclusion of P-Asserted-Identity in any request 180 There are several use cases that would benefit from the use of the 181 P-Asserted-Identity header field in an UPDATE request. These use 182 cases apply within a Trust Domain where the use of asserted identity 183 is appropriate (see RFC 3325). 185 In one example, an established call passes through a gateway to the 186 PSTN. The gateway becomes aware that the remote party in the PSTN 187 has changed, e.g., due to call transfer. By including the 188 P-Asserted-Identity header field in an UPDATE request, the gateway 189 can convey the identity of the new remote party to the peer SIP UA. 191 Note that the (re-)INVITE method could be used in this situation. 192 However, this forces an offer-answer exchange, which typically is 193 not required in this situation. Also it involves 3 messages 194 rather than 2. 196 In another example, a B2BUA that provides third party call control 197 (3PCC) [RFC3725] wishes to join two calls together, one of which is 198 still waiting to be answered and potentially is forked to different 199 UAs. At this point in time it is not possible to trigger the normal 200 offer-answer exchange between the two joined parties, because of the 201 mismatch between a single dialog on the one side and potentially 202 multiple early dialogs on the other side, so this action must wait 203 until one of the called UAs answers. However, it would be useful to 204 give an early indication to each user concerned of the identity of 205 the user to which they will become connected when the call is 206 answered. In other words, it would provide the new calling UA with 207 the identity of the new called user and provide the new called UA(s) 208 with the identity of the new calling user. This can be achieved by 209 the B2BUA sending an UPDATE request with a P-Asserted-Identity header 210 field on the dialogs concerned. 212 Within a Trust Domain, a P-Asserted-Identity header field could 213 advantageously be used in a REGISTER request between an edge proxy 214 that has authenticated the source of the request and the registrar. 216 Within a Trust Domain, a P-Asserted-Identity header field could 217 advantageously be used in a MESSAGE request to assert the source of a 218 page mode instant message. This would complement its use in an 219 INVITE request to assert the source of an instant message session or 220 any other form of session. Similarly, between a UAC and first proxy 221 that are not within the same Trust Domain, a P-Preferred-Identity 222 header field could be used in a MESSAGE request to express a 223 preference when the user has several identities. 225 Within a Trust Domain, a P-Asserted-Identity header field could 226 advantageously be used in a PUBLISH request to assert the source of 227 published state information. This would complement its use in 228 SUBSCRIBE and NOTIFY requests. Similarly, between a UAC and first 229 proxy that are not within the same Trust Domain, a P-Preferred- 230 Identity header field could be used in a PUBLISH request to express a 231 preference when the user has several identities. 233 Within a Trust Domain, a P-Asserted-Identity header field could 234 advantageously be used in an ACK request. Considering the 3PCC 235 scenario in Flow I of [RFC3725], the asserted identity of user B may 236 not be known when the B2BUA (controller) sends the initial INVITE 237 request to UA A, but might be known when the B2BUA sends the ACK 238 request to UA A. 240 Thus there are several examples where P-Asserted-Identity could be 241 used in requests with methods that are not provided for in RFC 3325 242 or any other RFC. This leaves a few methods for which use cases are 243 less obvious, but the inclusion of P-Asserted Identity would not 244 cause any harm. In any requests, the header field would simply 245 assert the source of that request, whether or not this is of any use 246 to the UAS. Similarly there are examples where P-Preferred-Identity 247 could be used in requests with methods that are not provided for in 248 RFC 3325 or any other RFC. 250 This update to RFC 3325 allows a P-Asserted-Identity or P-Preferred- 251 Identity header field to be included in any request. 253 3.3. Dialog implications 255 A P-Asserted-Identity header field in a received request asserts the 256 identity of the source of that request and says nothing about the 257 source of subsequent received requests claiming to relate to the same 258 dialog. The recipient can make its own deductions about the source 259 of subsequent requests not containing a P-Asserted-Identity header 260 field. This document does not change RFC 3325 in this respect. 262 4. Behaviour 264 This document updates RFC 3325 by allowing a P-Asserted-Identity 265 header field to be included by a UAC within the same Trust Domain and 266 by allowing a P-Asserted-Identity or P-Preferred-Identity header 267 field to appear in any request. 269 4.1. UAC Behaviour 271 A UAC MAY include a P-Asserted-Identity header field in a request to 272 report the identity of the user on behalf of which the UAC is acting 273 and whose identity the UAC is in a position to assert. A UAC SHOULD 274 do so only in cases where it believes it is in the same Trust Domain 275 as the SIP entity to which it sends the request and is connected to 276 that SIP entity in accordance with the security requirements of RFC 277 3325. A UAC SHOULD NOT do so in other circumstances and might 278 instead use the P-Preferred-Identity header field. A UAC MUST NOT 279 include both header fields. 281 A UAC MAY include a P-Asserted-Identity or P-Preferred-Identity 282 header field in any request, i.e., not limited to the methods allowed 283 in RFC 3325. 285 4.2. Proxy Behaviour 287 If a proxy receives a request containing a P-Asserted-Identity header 288 field from a UAC within the Trust Domain it MUST behave as for a 289 request from any other node within the Trust Domain, in accordance 290 with the rules of RFC 3325 for a proxy. 292 Note that this implies that the proxy must have authenticated the 293 sender of the request in accordance with the Spec(T) in force for 294 the Trust Domain and determined that the sender is indeed part of 295 the Trust Domain. 297 If a proxy receives a request containing a P-Asserted-Identity or 298 P-Preferred-Identity header field, it MUST behave in accordance with 299 the rules of RFC 3325 for a proxy, even if the method is not one for 300 which RFC 3325 specifies use of that header field. 302 4.3. Registrar Behaviour 304 If a registrar receives a REGISTER request containing a P-Asserted- 305 Identity header field, it MUST disregard the asserted identity unless 306 received over a secure transport from a node within the Trust Domain. 307 Otherwise it MAY use this as evidence that the registering UA has 308 been authenticated as representing the identity asserted in the 309 header field. 311 4.4. UAS Behaviour 313 If a UAS receives any request containing a P-Asserted-Identity header 314 field, it MUST behave as for any other request in accordance with the 315 rules of RFC 3325 for a UAS, even if the method is not one for which 316 RFC 3325 specifies use of that header field. 318 4.5. General handling 320 If an entity receives a request containing a P-Asserted-Identity or 321 P-Preferred-Identity header field containing an unexpected number of 322 URIs or unexpected URI schemes it MUST act as follows: 324 o ignore any URI with an unexpected URI scheme; 326 o ignore any URI for which the expected maximum number of URIs with 327 the same scheme occurred earlier in the header field; and 329 o ignore any URI whose scheme is not expected to occur in 330 combination with a scheme that occurred earlier in the header 331 field. 333 This document does not change the RFC 3325 requirement that allows 334 each of these header fields to contain at most two URIs, where one is 335 a SIP or SIPS URI and the other is a TEL URI, but future updates to 336 this document may relax that requirement. In the absence of such a 337 relaxation, the requirement above means that an entity receiving a 338 request containing a P-Asserted-Identity or P-Preferred-Identity 339 header field must act as follows: 341 o ignore any URI with a scheme other than SIP, SIPS or TEL; 343 o ignore a second or subsequent SIP URI, a second or subsequent SIPS 344 URI or a second or subsequent TEL URI; and 346 o ignore a SIP URI if a SIPS URI occurred earlier in the header 347 field and vice versa. 349 A proxy MUST NOT forward a URI when forwarding a request if that URI 350 is to be ignored in accordance with the requirement above. 352 5. IANA considerations 354 This document requires no IANA actions. 356 6. Security considerations 358 The use of asserted identity raises a number of security 359 considerations, which are discussed fully in [RFC3325]. This 360 document raises the following additional security considerations. 362 When receiving a request containing a P-Asserted-Identity header 363 field, a proxy will trust the assertion only if the source is known 364 to be within the Trust Domain and behaves in accordance with a 365 Spec(T), which defines the security requirements. This applies 366 regardless of the nature of the resource (UA or proxy). One example 367 where a trusted source might be a UA is a PSTN gateway. In this case 368 the UA can assert an identity received from the PSTN, the proxy 369 itself having no means to authenticate such an identity. A SIP 370 entity must not trust an identity asserted by a source outside the 371 Trust Domain. Typically a UA under the control of an individual user 372 (such as a desk phone or mobile phone) should not be considered part 373 of a Trust Domain. 375 When receiving a response from a node outside the Trust Domain, a 376 proxy has no standardised SIP means to authenticate the node. For 377 this reason, this document does not specify the use of P-Asserted- 378 Identity or P-Preferred-Identity in responses. 380 When receiving a REGISTER request containing a P-Asserted-Identity 381 header field, a proxy will trust the asserted identity only if 382 received over a secure connection from a proxy within the Trust 383 Domain. 385 7. Acknowledgements 387 Useful comments were received from Francois Audet, Jeroen van Bemmel, 388 Hans Erik van Elburg, Vijay Gurbani, Cullen Jennings, Hadriel Kaplan, 389 Paul Kyzivat, Jonathan Rosenberg, Thomas Stach and Brett Tate during 390 drafting and review. 392 8. References 394 8.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 400 A., Peterson, J., Sparks, R., Handley, M., and E. 401 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 402 June 2002. 404 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 405 UPDATE Method", RFC 3311, October 2002. 407 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 408 Identity", RFC 3324, November 2002. 410 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 411 Extensions to the Session Initiation Protocol (SIP) for 412 Asserted Identity within Trusted Networks", RFC 3325, 413 November 2002. 415 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 416 and D. Gurle, "Session Initiation Protocol (SIP) Extension 417 for Instant Messaging", RFC 3428, December 2002. 419 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 420 for Event State Publication", RFC 3903, October 2004. 422 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 423 RFC 3966, December 2004. 425 [I-D.ietf-sipping-uri-services] 426 Camarillo, G. and A. Roach, "Framework and Security 427 Considerations for Session Initiation Protocol (SIP) 428 Uniform Resource Identifier (URI)-List Services", 429 draft-ietf-sipping-uri-services-07 (work in progress), 430 November 2007. 432 8.2. Informative References 434 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 435 Camarillo, "Best Current Practices for Third Party Call 436 Control (3pcc) in the Session Initiation Protocol (SIP)", 437 BCP 85, RFC 3725, April 2004. 439 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 440 Authenticated Identity Management in the Session 441 Initiation Protocol (SIP)", RFC 4474, August 2006. 443 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 444 Protocol (SIP)", RFC 4916, June 2007. 446 Author's Address 448 John Elwell 449 Siemens Enterprise Communications 451 Phone: +44 115 943 4989 452 Email: john.elwell@siemens.com 454 Full Copyright Statement 456 Copyright (C) The IETF Trust (2008). 458 This document is subject to the rights, licenses and restrictions 459 contained in BCP 78, and except as set forth therein, the authors 460 retain all their rights. 462 This document and the information contained herein are provided on an 463 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 464 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 465 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 466 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 467 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 468 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 470 Intellectual Property 472 The IETF takes no position regarding the validity or scope of any 473 Intellectual Property Rights or other rights that might be claimed to 474 pertain to the implementation or use of the technology described in 475 this document or the extent to which any license under such rights 476 might or might not be available; nor does it represent that it has 477 made any independent effort to identify any such rights. Information 478 on the procedures with respect to rights in RFC documents can be 479 found in BCP 78 and BCP 79. 481 Copies of IPR disclosures made to the IETF Secretariat and any 482 assurances of licenses to be made available, or the result of an 483 attempt made to obtain a general license or permission for the use of 484 such proprietary rights by implementers or users of this 485 specification can be obtained from the IETF on-line IPR repository at 486 http://www.ietf.org/ipr. 488 The IETF invites any interested party to bring to its attention any 489 copyrights, patents or patent applications, or other proprietary 490 rights that may cover technology that may be required to implement 491 this standard. Please address the information to the IETF at 492 ietf-ipr@ietf.org.