idnits 2.17.1 draft-ietf-sip-connected-identity-05.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 984. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 995. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1002. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1008. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3261, updated by this document, for RFC5378 checks: 2000-07-17) -- 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 25, 2007) is 6263 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 870 ** Obsolete normative reference: RFC 4474 (ref. '3') (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 2543 (ref. '6') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 4244 (ref. '7') (Obsoleted by RFC 7044) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG J. Elwell 3 Internet-Draft Siemens Enterprise Communications 4 Updates: RFC 3261 Limited 5 (if approved) February 25, 2007 6 Intended status: Standards Track 7 Expires: August 29, 2007 9 Connected Identity in the Session Initiation Protocol (SIP) 10 draft-ietf-sip-connected-identity-05.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 29, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document provides a means for a Session Initiation Protocol 44 (SIP) User Agent (UA) that receives a dialog-forming request to 45 supply its identity to the peer UA by means of a request in the 46 reverse direction and for that identity to be signed by an 47 Authentication Service. Because of retargeting of a dialog-forming 48 request (changing the value of the Request-URI), the UA that receives 49 it (the User Agent Server, UAS) can have a different identity from 50 that in the To header field. The same mechanism can be used to 51 indicate a change of identity during a dialog, e.g., because of some 52 action in the Public Switched Telephone Network (PSTN) behind a 53 gateway. This document normatively updates RFC 3261 (SIP). 55 Table of Contents 57 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Overview of solution . . . . . . . . . . . . . . . . . . . . . 4 60 4. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Behaviour of a UA that issues an INVITE request 62 outside the context of an existing dialog . . . . . . . . 6 63 4.2. Behaviour of a UA that receives an INVITE request 64 outside the context of an existing dialog . . . . . . . . 6 65 4.3. Behaviour of a UA whose identity changes during an 66 established INVITE-initiated dialog . . . . . . . . . . . 7 67 4.4. General UA behaviour . . . . . . . . . . . . . . . . . . . 7 68 4.4.1. Sending a mid-dialog request . . . . . . . . . . . . . 7 69 4.4.2. Receiving a mid-dialog request . . . . . . . . . . . . 8 70 4.5. Authentication Service Behaviour . . . . . . . . . . . . . 8 71 4.6. Verifier Behaviour . . . . . . . . . . . . . . . . . . . . 9 72 4.7. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 9 73 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.1. Sending connected identity after answering a call . . . . 10 75 5.2. Sending revised connected identity during a call . . . . . 15 76 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 77 7. Security considerations . . . . . . . . . . . . . . . . . . . 21 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 22 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 83 Intellectual Property and Copyright Statements . . . . . . . . . . 24 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 RFC 2119 [2]. 91 This specification defines the following additional terms: 93 caller: the user of the UA that issues an INVITE request to 94 initiate a call. 96 caller identity: the identity (Address of Record) of a caller. 98 callee: the user of the UA that answers a call by issuing a 2xx 99 response to an INVITE request. 101 callee identity: the identity (Address of Record) of a callee. 103 potential callee: the user of any UA to which an INVITE request 104 is targeted resulting in formation of an early dialog, but 105 because of parallel or serial forking of the request, not 106 necessarily the user that answers the call. 108 connected user: any user involved in an established call, 109 including the caller, the callee or any user that replaces the 110 caller or callee following a call re-arrangement such as call 111 transfer. 113 connected identity: the identity (Address of Record) of a 114 connected user. 116 2. Introduction 118 SIP (RFC 3261 [1]) initiates sessions but it also provides 119 information on the identities of the parties at both ends of a 120 session. Users need this information to help determine how to deal 121 with communications initiated by SIP. The identity of the party who 122 answers a call can differ from that of the initial called party for 123 various reasons such as call forwarding, call distribution and call 124 pick-up. Furthermore, once a call has been answered, a party can be 125 replaced by a different party with a different identity for reasons 126 such as call transfer, call park and retrieval, etc.. Although in 127 some cases there can be reasons for not disclosing these identities, 128 it is desirable to have a mechanism for providing this information. 130 This document extends the use of the From header field to allow it to 131 convey what is commonly called "connected identity" information (the 132 identity of the connected user) in either direction within the 133 context of an existing INVITE-initiated dialog. It can be used to 134 convey: 135 o the callee identity to a caller when a call is answered; 136 o the identity of a potential callee prior to answer; or 137 o the identity of a user that replaces the caller or callee 138 following a call re-arrangement such as call transfer carried out 139 within the PSTN or within a B2BUA using third party call control 140 techniques. 142 Note that the use of standard SIP call transfer techniques, 143 involving the REFER method, leads to establishment of a new dialog 144 and hence normal mechanisms for caller and callee identity apply. 146 The provision of the identity of the responder in a response 147 (commonly called "response identity") is outside the scope of this 148 document. 150 Note that even if identity were to be conveyed somehow in a 151 response, there would in general be difficulty authenticating the 152 UAS except in cases where the UA is connected to its proxy by TLS 153 and has already been authenticated. Providing identity in a 154 separate request allows normal authentication techniques to be 155 used. 157 3. Overview of solution 159 A mid-dialog request is used to provide connected identity. The UAC 160 for that request inserts its identity in the From header field of the 161 request. To provide authentication, the Identity header field (RFC 162 4474 [3]) is inserted by a suitable Authentication Service on the 163 path of the mid-dialog request. Unless provided at the UAC, the 164 Authentication Service is expected to be at a proxy that record 165 routes and is able to authenticate the UAC. 167 A request in the opposite direction to the INVITE request prior to or 168 at the time the call is answered can indicate the identity of the 169 potential callee or callee respectively. A request in the same 170 direction as the INVITE request prior to answer can indicate a change 171 of caller. A request in either direction after answer can indicate a 172 change of connected user. In all cases a dialog (early or confirmed) 173 has to be established before such a request can be sent. 175 This solution uses the UPDATE method (RFC 3311 [4]) for the request, 176 or in some circumstances the re-INVITE method. To send the callee 177 identity the UAS for the INVITE request sends the UPDATE request 178 after sending the 2xx response to the INVITE request and receiving an 179 ACK request. To send the potential callee identity, RFC 3262 [5] is 180 expected to be supported. In this case the UAS for the INVITE 181 request sends the UPDATE request after receiving and responding to a 182 PRACK request (which occurs after sending a reliable 1xx response to 183 the INVITE request). The UPDATE request could conceivably be used 184 for other purposes too, e.g., during an early dialog it could be used 185 to send the potential callee identity at the same time as an SDP 186 offer for early media. To indicate a connected identity change 187 during an established call, either the UPDATE method or the re-INVITE 188 method can be used. The re-INVITE method would be used if required 189 for other purposes (e.g., when a B2BUA performs transfer using 3PCC 190 techniques it has to issue a re-INVITE request without an SDP offer 191 to solicit an SDP offer from the UA). 193 This solution involves changing the URI (not the tags) in the To and 194 From header fields of mid-dialog requests and their responses, 195 compared with the corresponding values in the dialog forming request 196 and response. Changing the To and From header field URIs was 197 contemplated in Section 12.2.1.1 of RFC 3261 [1], which says: 199 "Usage of the URI from the To and From fields in the original 200 request within subsequent requests is done for backwards 201 compatibility with RFC 2543 [6], which used the URI for dialog 202 identification. In this specification, only the tags are used for 203 dialog identification. It is expected that mandatory reflection 204 of the original To and From URI in mid-dialog requests will be 205 deprecated in a subsequent revision of this specification." 207 This document therefore deprecates mandatory reflection of the 208 original To and From URIs in mid-dialog requests and their responses, 209 which constitutes a change to RFC 3261 [1]. This document makes no 210 provision for proxies that are unable to tolerate a change of URI, 211 since changing the URI has been expected for a considerable time. To 212 cater for any UAs that are not able to tolerate a change of URI, a 213 new option tag "from-change" is introduced for providing a positive 214 indication of support in the Supported header field. By sending a 215 request with a changed From header field URI only to targets that 216 have indicated support for this option, there is no need to send this 217 option tag in a Require header field. 219 In addition to allowing the From header field URI to change during a 220 dialog to reflect the connected identity, this document also requires 221 a UA that has received a connected identity in the URI of the From 222 header field of a mid-dialog request to use that URI in the To header 223 field of any subsequent mid-dialog request sent by that UA. 225 In the absence of a suitable Authentication Service on the path of 226 the mid-dialog request, the UAS will receive an unauthenticated 227 connected identity (i.e., without a corresponding Identity header 228 field). The implications of this are discussed in Section 7 230 4. Behaviour 232 4.1. Behaviour of a UA that issues an INVITE request outside the 233 context of an existing dialog 235 When issuing an INVITE request, a UA compliant with this 236 specification MUST include the "from-change" option tag in the 237 Supported header field. 239 Note that sending the "from-change" option tag does not guarantee 240 that connected identity will be received in subsequent requests. 242 4.2. Behaviour of a UA that receives an INVITE request outside the 243 context of an existing dialog 245 After receiving an INVITE request, a UA compliant with this 246 specification MUST include the "from-change" option tag in the 247 Supported header field of any dialog-forming response. 249 Note that sending the "from-change" option tag does not guarantee 250 that connected identity will be received in the event of a change 251 of caller. 253 After an early dialog has been formed, if the "from-change" option 254 tag has been received in a Supported header field the UA MAY issue an 255 UPDATE request (RFC 3311 [4]) on the same dialog, subject to having 256 sent a reliable provisional response to the INVITE request and having 257 received and responded to a PRACK request. After a full dialog has 258 been formed (after sending a 2xx final response to the INVITE 259 request), if the "from-change" option tag has been received in a 260 Supported header field and an UPDATE request has not already been 261 sent on the early dialog, the UA MUST issue an UPDATE request on the 262 same dialog. In either case the UPDATE request MUST contain the 263 callee's (or potential callee's) identity in the URI of the From 264 header field (or an anonymous identity if anonymity is required). 266 Note that even if the URI does not differ from that in the To 267 header field URI of the INVITE request, sending a new request 268 allows the Authentication Service to assert authentication of this 269 identity and confirms to the peer UA that the connected identity 270 is the same as that in the To header field URI of the INVITE 271 request. 273 4.3. Behaviour of a UA whose identity changes during an established 274 INVITE-initiated dialog 276 If the "from-change" option tag has been received in a Supported 277 header field during an INVITE-initiated dialog and if the identity 278 associated with the UA changes (e.g., due to transfer) compared to 279 the last identity indicated in the From header field of a request 280 sent by that UA, the UA MUST issue a request on the same dialog 281 containing the new identity in the URI of the From header field (or 282 an anonymous identity if anonymity is required). For this purpose 283 the UA MUST use the UPDATE method unless for other reasons the re- 284 INVITE method is being used at the same time. 286 4.4. General UA behaviour 288 4.4.1. Sending a mid-dialog request 290 When sending a mid-dialog request a UA MUST observe the requirements 291 of RFC 4474 [3] when populating the From header field URI, including 292 provisions for achieving anonymity. 294 This will allow an Authentication Service on the path of the mid- 295 dialog request to insert an Identity header field. 297 When sending a mid-dialog request a UA MUST populate the To header 298 field URI with the current value of the remote URI for that dialog, 299 where this is subject to update in accordance with the rules of 300 Section 4.4.2 of this document rather than being fixed at the 301 beginning of the dialog in accordance with RFC 3261 [1]. 303 After sending a request with a revised From header field URI (i.e., 304 revised compared to the URI sent in the From header field of the 305 previous request on this dialog or in the To header field of the 306 received dialog-forming INVITE request if no request has been sent), 307 the UA MUST send the same URI in the From header field of any future 308 requests on the same dialog, unless the identity changes again. Also 309 the UA MUST be prepared to receive the revised URI in the To header 310 field of subsequent mid-dialog requests and MUST also continue to be 311 prepared to receive the old URI at least until a request containing 312 the revised URI in the To header field has been received. 314 The mid-dialog request can be rejected in accordance with RFC 4474 315 [3] if the UAS does not accept the connected identity. If the UAC 316 receives a 428, 436, 437 or 438 response to a mid-dialog request it 317 SHOULD regard the dialog as terminated in the case of a dialog- 318 terminating request and SHOULD take no action in the case of any 319 other request. 321 Any attempt to repeat the request or send any other mid-dialog 322 request is likely to result in the same response, since the UA has 323 no control over actions of the Authentication Service. 325 4.4.2. Receiving a mid-dialog request 327 If a UA receives a mid-dialog request from the peer UA, the UA can 328 make use of the identity in the From header field URI (e.g., by 329 indicating to the user). The UA MAY discriminate between signed and 330 unsigned identities. In the case of a signed identity, the UA SHOULD 331 invoke a Verifier (see Section 4.6) if it cannot rely on the presence 332 of a Verifier on the path of the request. 334 If a UA receives a mid-dialog request from the peer UA in which the 335 From header field URI differs from that received in the previous 336 request on that dialog or that sent in the To header field of the 337 original INVITE request and if the UA sends a 2xx response, the UA 338 MUST update the remote URI for this dialog, as defined in RFC 3261 339 [1]. This will cause the new value to be used in the To header field 340 of subsequent requests that the UA sends, in accordance with the 341 rules of Section 4.4.1. If any other final response is sent the UA 342 MUST NOT update the remote URI for this dialog. 344 4.5. Authentication Service Behaviour 346 An Authentication Service MUST behave in accordance with RFC 4474 [3] 347 when dealing with mid-dialog requests. 349 Note that RFC 4474 is silent on how to behave if the identity in 350 the From header field is not one that the UAC is allowed to 351 assert, and therefore it is a matter for local policy whether to 352 reject the request or forward it without an Identity header field. 353 Policy can be different for a mid-dialog request compared with 354 other requests. 356 Note that when UAs conform with this specification the 357 Authentication Service should (subject to the normal rules for 358 authentication) be able to authenticate the sender of a request as 359 being the entity identified in the From header field and hence 360 will be able provide a signature for this identity. This is in 361 contrast to UAs that do not support this specification, where 362 retargeting and mid-dialog identity changes can render the From 363 header field inaccurate as a means of identifying the sender of 364 the request. 366 4.6. Verifier Behaviour 368 When dealing with mid-dialog requests, an Authentication Service MUST 369 behave in accordance with RFC 4474 [3] updated as stated below. 371 RFC 4474 [3] states that it is a matter of policy whether to reject a 372 request with a 428 (Use Identity Header) response if there is no 373 Identity header field in the request. A UA MAY adopt a different 374 policy for mid-dialog requests compared with other requests. 376 4.7. Proxy Behaviour 378 A proxy that receives a mid-dialog request MUST be prepared for the 379 To header field URI and/or the From header field URI to differ from 380 those that appeared in the dialog-forming request and response. 382 A proxy that is able to provide an Authentication Service for mid- 383 dialog requests MUST record route if Supported: from-change is 384 indicated in the dialog forming request received by the proxy from 385 the UAC. 387 5. Examples 389 In the examples below, several messages contain unfolded lines longer 390 than 72 characters. These are captured between tags. The single 391 unfolded line is reconstructed by directly concatenating all lines 392 appearing between the tags (discarding any line-feeds or carriage 393 returns). 395 In the examples the domain example.com is assumed to have the 396 following private key (rendered in OpenSSL format). The private key 397 is used by the Authentication Service for generating the signature in 398 the Identity header field. 400 -----BEGIN RSA PRIVATE KEY----- 401 MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO 402 aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc 403 IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB 404 AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt 405 PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw 406 +rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30 407 tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H 408 0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0 409 J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C 410 DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r 411 xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU 412 6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK 413 Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk 414 -----END RSA PRIVATE KEY----- 416 5.1. Sending connected identity after answering a call 418 In this example Carol's UA has been reached by retargeting at the 419 proxy and thus her identity (AoR) is not equal to that in the To 420 header field of the received INVITE request (Bob). Carol's UA 421 conveys Carol's identity in the From header field of an UPDATE 422 request. The proxy also provides an Authentication Service and 423 therefore adds Identity and Identity-Info header fields to the UPDATE 424 request. 426 Alice's UA PROXY + Carol's UA 427 Authentication 428 Service 430 INVITE(1) INVITE(2) 431 ----------------> ----------------> 433 200(4) 200(3) 434 <---------------- <---------------- 436 ACK(5) ACK(6) 437 ----------------> ----------------> 439 UPDATE(8) UPDATE(7) 440 <---------------- <---------------- 442 200(9) 200(10) 443 ----------------> ----------------> 445 INVITE (1): 447 INVITE sip:Bob@example.com SIP/2.0 448 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8 449 To: Bob 450 From: Alice ;tag=13adc987 451 Call-ID: 12345600@ua1.example.com 452 CSeq: 1 INVITE 453 Max-Forwards: 70 454 Date: Thu, 21 Feb 2002 13:02:03 GMT 455 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE 456 Supported: from-change 457 Contact: 458 Content-Type: application/sdp 459 Content-Length: 154 461 v=0 462 o=UserA 2890844526 2890844526 IN IP4 ua1.example.com 463 s=Session SDP 464 c=IN IP4 ua1.example.com 465 t=0 0 466 m=audio 49172 RTP/AVP 0 467 a=rtpmap:0 PCMU/8000 469 INVITE (2): 471 INVITE sip:Carol@ua2.example.com SIP/2.0 472 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds 473 474 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2. 475 1 476 477 To: Bob 478 From: Alice ;tag=13adc987 479 Call-ID: 12345600@ua1.example.com 480 CSeq: 1 INVITE 481 Max-Forwards: 69 482 Date: Thu, 21 Feb 2002 13:02:03 GMT 483 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE 484 Supported: from-change 485 Contact: 486 Record-Route: 487 488 Identity: "xN6gCHR6KxGM+nyiEM13LcWgAFQD3lkni1DPkwgadxh4BB7G+VwY1 489 3uRv5hbCI2VSvKuZ4LYN0JNoe7v8VAzruKMyi4Bi4nUghR/fFGBrpBSjztmfffLT 490 p6SFLxo9XQSVrkm1O4c/4UrKn2ejRz+5BULu9n9kWswzKDNjlYlmmc=" 491 492 Identity-Info: ;alg=rsa-sha1 493 Content-Type: application/sdp 494 Content-Length: 154 496 v=0 497 o=UserA 2890844526 2890844526 IN IP4 ua1.example.com 498 s=Session SDP 499 c=IN IP4 ua1.example.com 500 t=0 0 501 m=audio 49172 RTP/AVP 0 502 a=rtpmap:0 PCMU/8000 504 200 (3): 506 SIP/2.0 200 OK 507 508 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds;received=192. 509 0.2.2 510 511 512 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2. 513 1 514 515 To: Bob ;tag=2ge46ab5 516 From: Alice ;tag=13adc987 517 Call-ID: 12345600@ua1.example.com 518 CSeq: 1 INVITE 519 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE 520 Supported: from-change 521 Contact: 522 Record-Route: 523 Content-Type: application/sdp 524 Content-Length: 154 526 v=0 527 o=UserB 2890844536 2890844536 IN IP4 ua2.example.com 528 s=Session SDP 529 c=IN IP4 ua2.example.com 530 t=0 0 531 m=audio 49172 RTP/AVP 0 532 a=rtpmap:0 PCMU/8000 534 200 (4): 536 SIP/2.0 200 OK 537 538 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2. 539 1 540 541 To: Bob ;tag=2ge46ab5 542 From: Alice ;tag=13adc987 543 Call-ID: 12345600@ua1.example.com 544 CSeq: 1 INVITE 545 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE 546 Supported: from-change 547 Contact: 548 Record-Route: 549 Content-Type: application/sdp 550 Content-Length: 154 552 v=0 553 o=UserB 2890844536 2890844536 IN IP4 ua2.example.com 554 s=Session SDP 555 c=IN IP4 ua2.example.com 556 t=0 0 557 m=audio 49172 RTP/AVP 0 558 a=rtpmap:0 PCMU/8000 560 ACK (5): 562 ACK sip:carol@ua2.example.com SIP/2.0 563 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9 564 From: Alice ;tag=13adc987 565 To: Bob ;tag=2ge46ab5 566 Call-ID: 12345600@ua1.example.com 567 CSeq: 1 ACK 568 Max-Forwards: 70 569 Route: 570 Content-Length: 0 572 ACK (6): 574 ACK sip:carol@ua2.example.com SIP/2.0 575 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdt 576 577 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9;received=192.0.2. 578 1 579 580 From: Alice ;tag=13adc987 581 To: Bob ;tag=2ge46ab5 582 Call-ID: 12345600@ua1.example.com 583 CSeq: 1 ACK 584 Max-Forwards: 69 585 Content-Length: 0 587 UPDATE (7): 589 UPDATE sip:Alice@ua1.example.com SIP/2.0 590 Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1 591 From: Carol ;tag=2ge46ab5 592 To: Alice ;tag=13adc987 593 Call-ID: 12345600@ua1.example.com 594 CSeq: 2 UPDATE 595 Max-Forwards: 70 596 Date: Thu, 21 Feb 2002 13:02:15 GMT 597 Route: 598 Contact: 599 Content-Length: 0 601 Note that the URI in the From header field differs from that in 602 the To header field in the INVITE request/response. However, the 603 tag is the same as that in the INVITE response. 605 UPDATE (8): 607 UPDATE sip:Alice@ua1.example.com SIP/2.0 608 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu 609 610 Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2. 611 3 612 613 From: Carol ;tag=2ge46ab5 614 To: Alice ;tag=13adc987 615 Call-ID: 12345600@ua1.example.com 616 CSeq: 2 UPDATE 617 Max-Forwards: 69 618 Date: Thu, 21 Feb 2002 13:02:15 GMT 619 Contact: 620 621 Identity: "g8WJiVEzrbYum+z2lnS3pL+MIhuI439gDiMCHm01fwX5D8Ft5Ib9t 622 ewLfBT9mDOUSn6wkPSWVQfqdMF/QBPkpsIIROIi2sJOYBEMXZpNrhJd8/uboXMl9 623 KRujDFQefZlmXV8dwD6XsPnMgcH8jAcaZ5aS04NyfWadIwTnGeuxko=" 624 625 Identity-Info: ;alg=rsa-sha1 626 Content-Length: 0 628 200 (9): 630 SIP/2.0 200 OK 631 632 Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu;received=192. 633 0.2.2 634 635 636 Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2. 637 3 638 639 From: Carol ;tag=2ge46ab5 640 To: Alice ;tag=13adc987 641 Call-ID: 12345600@ua1.example.com 642 CSeq: 2 UPDATE 643 Contact: 644 Content-Length: 0 646 200 (10): 648 SIP/2.0 200 OK 649 650 Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2. 651 3 652 653 From: Carol ;tag=2ge46ab5 654 To: Alice ;tag=13adc987 655 Call-ID: 12345600@ua1.example.com 656 CSeq: 2 UPDATE 657 Contact: 658 Content-Length: 0 660 5.2. Sending revised connected identity during a call 662 In this example a call is established between Alice and Bob, where 663 Bob (not shown) lies behind a B2BUA. Bob's identity is conveyed by 664 an UPDATE request. Then the B2BUA executes call transfer using third 665 party call control (3PCC) techniques as described in RFC 3725 [8] 666 (e.g., under the control of a click-to-dial application). As a 667 result, Alice becomes connected to Carol (also not shown), and a re- 668 INVITE request is issued allowing the session to be renegotiated. 669 The B2BUA provides the Authentication Service and thus generates the 670 Identity header field in the re-INVITE request to provide 671 authentication of Carol's identity. 673 Alice's UA B2BUA 675 INVITE(1) 676 ----------------> 678 200(2) 679 <---------------- 681 ACK(3) 682 ----------------> 684 UPDATE(4) 685 <---------------- 687 200(5) 688 ----------------> 690 re-INVITE(6) 691 <---------------- 693 200(7) 694 ----------------> 696 ACK(8) 697 <--------------- 699 INVITE (1): 701 INVITE sip:Bob@example.com SIP/2.0 702 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8 703 To: Bob 704 From: Alice ;tag=13adc987 705 Call-ID: 12345600@ua1.example.com 706 CSeq: 1 INVITE 707 Max-Forwards: 70 708 Date: Thu, 21 Feb 2002 13:02:03 GMT 709 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE 710 Supported: from-change 711 Contact: 712 Content-Type: application/sdp 713 Content-Length: 154 715 v=0 716 o=UserA 2890844526 2890844526 IN IP4 ua1.example.com 717 s=Session SDP 718 c=IN IP4 ua1.example.com 719 t=0 0 720 m=audio 49172 RTP/AVP 0 721 a=rtpmap:0 PCMU/8000 723 200 (2) 725 SIP/2.0 200 OK 726 727 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2. 728 1 729 730 To: Bob ;tag=2ge46ab5 731 From: Alice ;tag=13adc987 732 Call-ID: 12345600@ua1.example.com 733 CSeq: 1 INVITE 734 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE 735 Supported: from-change 736 Contact: 737 Content-Type: application/sdp 738 Content-Length: 154 740 v=0 741 o=UserB 2890844536 2890844536 IN IP4 ua2.example.com 742 s=Session SDP 743 c=IN IP4 ua2.example.com 744 t=0 0 745 m=audio 49172 RTP/AVP 0 746 a=rtpmap:0 PCMU/8000 748 ACK (3) 750 ACK sip:xyz@b2bua.example.com SIP/2.0 751 Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9 752 From: Alice ;tag=13adc987 753 To: Bob ;tag=2ge46ab5 754 Call-ID: 12345600@ua1.example.com 755 CSeq: 1 ACK 756 Max-Forwards: 70 757 Content-Length: 0 759 UPDATE (4) 761 UPDATE sip:alice@ua1.example.com SIP/2.0 762 Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1 763 From: Bob ;tag=2ge46ab5 764 To: Alice ;tag=13adc987 765 Call-ID: 12345600@ua1.example.com 766 CSeq: 2 UPDATE 767 Max-Forwards: 70 768 Date: Thu, 21 Feb 2002 13:02:12 GMT 769 Contact: 770 771 Identity: "AQFLSjCDRhO2eXlWmTajk99612hkJii9giDMWki5uT6qc4BrekywO 772 UuObcwZI3qhJReZCN7ybMBNYFZ5yFXWdyet4j3zLNCONU9ma+rs8ZOv0+z/Q3Z5c 773 D26HrmitU+OCKWPLObaxbkGQry9hQxOmwRmlUgSjkeCEjgnc1iQc3E=" 774 775 Identity-Info: ;alg=rsa-sha1 776 Content-Length: 0 778 200 (5) 780 SIP/2.0 200 OK 781 782 Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1;received=192.0. 783 2.2 784 785 From: Bob ;tag=2ge46ab5 786 To: Alice ;tag=13adc987 787 Call-ID: 12345600@ua1.example.com 788 CSeq: 2 UPDATE 789 Contact: 790 Content-Length: 0 792 re-INVITE (6) 794 INVITE sip:alice@ua1.example.com SIP/2.0 795 Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy 796 From: Carol ;tag=2ge46ab5 797 To: Alice ;tag=13adc987 798 Call-ID: 12345600@ua1.example.com 799 CSeq: 3 INVITE 800 Max-Forwards: 70 801 Date: Thu, 21 Feb 2002 13:03:20 GMT 802 Contact: 803 804 Identity: "KCd3YLQHj51SlCQhFMnpQjmP6wHh7JGRO8LsB4v5SGEr/Mwu7j6Gp 805 al8ckVM2vd1zqH/F4WJXYDlB525uuJm/fN3O1A2xsZ9BxRkh4N4U19TL9I2Tok3U 806 3kGg8To/6w1mEXpUQjo3OgNYqOBtawHuZI5nrOVaV3IrbQh1b2KgLo=" 807 808 Identity-Info: ;alg=rsa-sha1 809 Content-Length: 0 811 200 (7) 813 SIP/2.0 200 OK 814 815 Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy;received=192.0. 816 2.2 817 818 From: Carol ;tag=2ge46ab5 819 To: Alice ;tag=13adc987 820 Call-ID: 12345600@ua1.example.com 821 CSeq: 3 INVITE 822 Contact: 823 Content-Length: 154 825 v=0 826 o=UserA 2890844526 2890844526 IN IP4 ua1.example.com 827 s=Session SDP 828 c=IN IP4 ua1.example.com 829 t=0 0 830 m=audio 49172 RTP/AVP 0 831 a=rtpmap:0 PCMU/8000 833 ACK (8) 835 ACK sip:alice@ua1.example.com SIP/2.0 836 Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxz 837 From: Carol ;tag=2ge46ab5 838 To: Alice ;tag=13adc987 839 Call-ID: 12345600@ua1.example.com 840 CSeq: 3 ACK 841 Max-Forwards: 70 842 Content-Length: 154 844 v=0 845 o=UserC 2890844546 2890844546 IN IP4 ua3.example.com 846 s=Session SDP 847 c=IN IP4 ua3.example.com 848 t=0 0 849 m=audio 49172 RTP/AVP 0 850 a=rtpmap:0 PCMU/8000 852 6. IANA considerations 854 This specification registers a new SIP option tag, as per the 855 guidelines in Section 27.1 of RFC 3261 [1]. 857 This document defines the SIP option tag "from-change". 859 The following row shall be added to the "Option Tags" section of the 860 SIP Parameter Registry: 862 +------------+------------------------------------------+-----------+ 863 | Name | Description | Reference | 864 +------------+------------------------------------------+-----------+ 865 | from-change| This option tag is used to indicate that | [RFCXXXX] | 866 | | a UA supports changes to URIs in From | | 867 | | and To header fields during a dialog. | | 868 +------------+------------------------------------------+-----------+ 870 Editor Note: [RFCXXXX] should be replaced with the designation of 871 this document. 873 7. Security considerations 875 RFC 4474 [3] discusses security considerations relating to the 876 Identity header field in some detail. Those same considerations 877 apply when using the Identity header field to authenticate a 878 connected identity in the From header field URI of a mid-dialog 879 request. 881 A received From header field URI in a mid-dialog request for which no 882 valid Identity header field (or other means of authentication) has 883 been received either in this request or in an an earlier request on 884 this dialog cannot be trusted (except in very closed environments) 885 and is expected to be treated in a similar way to a From header field 886 in a dialog-initiating request that is not backed up by a valid 887 Identity header field. However, it is recommended not to reject a 888 mid-dialog request on the grounds that the Identity header field is 889 missing (since this would interfere with ongoing operation of the 890 call). The absence of a valid Identity header field can influence 891 the information given to the user. A UA can clear the call if policy 892 or user preference dictates. 894 A signed connected identity in a mid-dialog request (URI in the From 895 header field accompanied by a valid Identity header field) provides 896 information about the peer UA in a dialog. In the case of the UA 897 that was the UAS in the dialog-forming request, this identity is not 898 necessarily the same as that in the To header field of the dialog- 899 forming request. This is because of retargeting during the routing 900 of the dialog-forming request. A signed connected identity says 901 nothing about the legitimacy of such retargeting, but merely reflects 902 the result of that retargeting. History information (RFC 4244 [7]) 903 can provide additional hints as to how the connected user has been 904 reached. 906 Likewise, when a signed connected identity indicates a change of 907 identity during a dialog, it conveys no information about the reason 908 for such change of identity or its legitimacy. 910 Use of the sips URI scheme can minimise the chances of attacks in 911 which inappropriate connected identity information is sent, either at 912 call establishment time or during a call. 914 Anonymity can be required by the user of a connected UA. For 915 anonymity the UA is expected to populate the URI in the From header 916 field of a mid-dialog request in the way described in RFC 4474 [3]. 918 8. Acknowledgments 920 Thanks to Francois Audet, Frank Derks, Steffen Fries, Vijay Gurbani, 921 Cullen Jennings, Paul Kyzivat, Hans Persson, Jon Peterson, Eric 922 Rescorla, Jonathan Rosenberg, Schida Schubert, Ya-Ching Tan and Dan 923 Wing for providing valuable comments. 925 9. References 927 9.1. Normative References 929 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 930 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 931 Session Initiation Protocol", RFC 3261, June 2002. 933 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 934 Levels", BCP 14, RFC 2119, March 1997. 936 [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated 937 Identity Management in the Session Initiation Protocol (SIP)", 938 RFC 4474, August 2006. 940 [4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 941 Method", RFC 3311, September 2002. 943 [5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 944 Responses in the Session Initiation Protocol (SIP)", RFC 3262, 945 June 2002. 947 9.2. Informative References 949 [6] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, 950 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 952 [7] Barnes, M., "An Extension to the Session Initiation Protocol 953 (SIP) for Request History Information", RFC 4244, November 2005. 955 [8] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 956 "Best Current Practices for Third Party Call Control (3pcc) in 957 the Session Initiation Protocol (SIP)", RFC 3725, June 2002. 959 Author's Address 961 John Elwell 962 Siemens Enterprise Communications Limited 963 Technology Drive 964 Beeston, Nottingham NG9 1LA 965 UK 967 Phone: +44 115 943 4989 968 Email: john.elwell@siemens.com 970 Full Copyright Statement 972 Copyright (C) The IETF Trust (2007). 974 This document is subject to the rights, licenses and restrictions 975 contained in BCP 78, and except as set forth therein, the authors 976 retain all their rights. 978 This document and the information contained herein are provided on an 979 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 980 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 981 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 982 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 983 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 984 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 986 Intellectual Property 988 The IETF takes no position regarding the validity or scope of any 989 Intellectual Property Rights or other rights that might be claimed to 990 pertain to the implementation or use of the technology described in 991 this document or the extent to which any license under such rights 992 might or might not be available; nor does it represent that it has 993 made any independent effort to identify any such rights. Information 994 on the procedures with respect to rights in RFC documents can be 995 found in BCP 78 and BCP 79. 997 Copies of IPR disclosures made to the IETF Secretariat and any 998 assurances of licenses to be made available, or the result of an 999 attempt made to obtain a general license or permission for the use of 1000 such proprietary rights by implementers or users of this 1001 specification can be obtained from the IETF on-line IPR repository at 1002 http://www.ietf.org/ipr. 1004 The IETF invites any interested party to bring to its attention any 1005 copyrights, patents or patent applications, or other proprietary 1006 rights that may cover technology that may be required to implement 1007 this standard. Please address the information to the IETF at 1008 ietf-ipr@ietf.org. 1010 Acknowledgment 1012 Funding for the RFC Editor function is provided by the IETF 1013 Administrative Support Activity (IASA).