idnits 2.17.1 draft-elwell-sip-connected-identity-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 798. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 775. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 782. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 788. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 19, 2006) is 6633 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) == Unused Reference: '7' is defined on line 752, but no explicit reference was found in the text -- Duplicate reference: RFC3893, mentioned in '5', was also mentioned in '4'. -- Duplicate reference: RFC3893, mentioned in '6', was also mentioned in '5'. -- Obsolete informational reference (is this intentional?): RFC 2543 (ref. '7') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) Summary: 3 errors (**), 0 flaws (~~), 3 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 plc 4 Expires: August 23, 2006 February 19, 2006 6 Connected Identity in the Session Initiation Protocol (SIP) 7 draft-elwell-sip-connected-identity-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 23, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 Because of retargeting of a dialog-forming request, the UAS can have 41 a different identity from that in the To header. This document 42 provides a means for that UA to supply its identity to the peer UA by 43 means of a request in the reverse direction and for that identity to 44 be signed by an authentication service. The same mechanism can be 45 used to indicate a change of identity during a dialog, e.g., because 46 of some action in a PSTN behind a gateway. 48 This work is being discussed on the sip@ietf.org mailing list. 50 Table of Contents 52 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Existing mechanisms for conveying identity in the context 55 of a call . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Existing methods for providing authenticated identity 57 information . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Overview of solution . . . . . . . . . . . . . . . . . . . . . 5 59 6. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 6.1. Behaviour of a UA that issues an INVITE request . . . . . 6 61 6.2. Behaviour of a UA that receives an INVITE request . . . . 7 62 6.3. Behaviour of a UA during an established 63 INVITE-initiated dialog . . . . . . . . . . . . . . . . . 8 64 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 7.1. Sending connected identity after answering a call . . . . 8 66 7.2. Sending revised connected identity during a call . . . . . 11 67 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 68 9. Security considerations . . . . . . . . . . . . . . . . . . . 16 69 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 72 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 Intellectual Property and Copyright Statements . . . . . . . . . . 19 76 1. Conventions and Definitions 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 RFC-2119 [2]. 82 2. Introduction 84 SIP[1]initiates sessions but it also provides information on the 85 identities of the parties at both ends of a session. Users need this 86 information to help determine how to deal with communications 87 initiated by SIP. As a call proceeds, these identities may change. 88 This can happen for many reasons: calls are forwarded, calls are 89 parked and picked up, calls are transferred, calls are queued to be 90 picked up by a pool of agents, and so on. This can have impact on 91 the identity of the party that answers a call. It can also cause the 92 identity of a party to change during an established call. 94 This document extends the use of the From header field to allow it to 95 convey "connected identity" information in either direction within 96 the context of an existing INVITE-initiated dialog. 98 The provision of "response identity" for requests outside the context 99 of an INVITE-initiated dialog is outside the scope of this document. 101 3. Existing mechanisms for conveying identity in the context of a call 103 When establishing a call and its session, the SIP From header field 104 in the INVITE request provides a means for conveying the identity of 105 the caller from the User Agent Client (UAC) to the User Agent Server 106 (UAS), thereby allowing the caller's identity to be presented to the 107 callee. There is no corresponding mechanism specified for conveying 108 the identity of the callee from the UAS to the UAC, to allow the 109 callee's identity to be presented to the caller. The identity of the 110 callee is normally expected to be the identity placed in the To 111 header field of the INVITE request, but often this expectation is not 112 met because a different party answers the call, e.g., because of call 113 forwarding. 115 History information [5] gathered during the routing of a request 116 and returned in the response can provide additional information to 117 the UAC. However, this does not necessarily clearly indicate the 118 AoR of the UAS. Also the methods described in Section 4 for 119 authentication do not apply to history information, which relies 120 instead on hop-by-hop security and transitive trust. 122 The Reply-To header field has its own meaning and cannot be relied 123 on in all circumstances. 124 The Contact header field provides a contact URI, which may not 125 reveal the identity (Address of Record) of the user on whose 126 behalf the response is sent. 128 Parties involved in a call can change owing to actions such as call 129 transfer. If such actions are achieved by issuing a new INVITE 130 request (with a Replaces header field) between the two UAs that are 131 to be involved in the re-arranged call, the SIP From header field in 132 the INVITE request can provide identity information in one direction, 133 but again there is no mechanism for conveying identity information in 134 the reverse direction. 136 However, call re-arrangements are not always carried out using a new 137 INVITE request. Sometimes a B2BUA performs call re-arrangements 138 using third party call control (3PCC) techniques. With such 139 techniques the UA involved in the original call and still involved in 140 the re-arranged call receives only a re-INVITE or UPDATE request in 141 the context of the original dialog between that UA and the B2BUA. 142 This forces the UA to re-negotiate the session with the new remote 143 party, but introduces a need to convey the identity of the new remote 144 party to the UA. Because there is no new INVITE request (outside the 145 context of the existing dialog), techniques applicable to new calls 146 do not apply. 148 Another case where call re-arrangements are not carried out using a 149 new INVITE request is where one of the UAs is a gateway to a PSTN and 150 a call re-arrangement such as call transfer has occurred within the 151 PSTN. The gateway then has a need to convey the identity of the new 152 party within the PSTN to the remote UA. This needs to be done within 153 the context of the existing dialog between the gateway and the remote 154 UA. In this case there is probably not even any need to re-negotiate 155 the session - the only requirement is to update the identity 156 information. 158 4. Existing methods for providing authenticated identity information 160 Because the From header field in a request is generated by the UAC 161 itself it can be subject to falsification. SIP has several means of 162 providing cryptographic authentication of a request's source 163 identity. 165 One such means for requests is HTTP-based digest authentication, as 166 specified in [1]. Although a UAS can require digest authentication, 167 it is not usually feasible between an arbitrary pair of UAs because 168 of reliance on a shared secret. To achieve scalability, methods 169 based on public key cryptography are essential. 171 Another method is specified in [6], and is applicable to responses as 172 well as requests. This requires a UA to have a private key and 173 associated certificate in order to sign an Authenticated Identity 174 Body (AIB) in the request or response. However, this has seen little 175 deployment, since the public key infrastructures needed to support 176 private keys and certificates in every UA are not generally 177 available. 179 A third method is specified in [3]. For signature this uses a 180 private key and certificate associated with the domain indicated in 181 the From header URI. An authentication service, typically located at 182 the outbound proxy, authenticates the UAC by some means, using digest 183 authentication for example, and then inserts an Identity header and 184 an Identity-Info header in the forwarded request. The Identity 185 header contains a signature using the domain's private key and the 186 Identity-Info header references the corresponding certificate. 188 5. Overview of solution 190 A mid-dialog request is used to provide connected identity. The UAC 191 for that request inserts its identity in the From header field of the 192 request and the Identity header can be used to provide 193 authentication. 195 A request in the opposite direction to the INVITE request prior to or 196 at the time the call is answered can indicate the identity of the 197 alerting or answering party. A request in the same direction as the 198 INVITE request prior to answer can indicate a change of calling 199 party. A request in either direction after answer can indicate a 200 change of party. In all cases a dialog (early or confirmed) must be 201 established before such a request can be sent. 203 Note that it might also be possible to provide a means of 204 indicating the identity of the alerting or answering party in the 205 response to the INVITE request. However, at present the problem 206 of authenticating a response is still subject to study. In the 207 absence of a solution to the response identity problem, the simple 208 solution of using a request in the opposite direction to the 209 INVITE request is sufficient. 211 This solution involves changing the URI (not the tags) in the To and 212 From header fields of mid-dialog requests and their responses, 213 compared with the corresponding values in the dialog forming request 214 and response. Changing the To and From header field URIs was 215 contemplated in Section 12.2.1.1 of RFC 3261, which says "Usage of 216 the URI from the To and From fields in the original request within 217 subsequent requests is done for backwards compatibility with RFC 218 2543, which used the URI for dialog identification. In this 219 specification, only the tags are used for dialog identification. It 220 is expected that mandatory reflection of the original To and From URI 221 in mid-dialog requests will be deprecated in a subsequent revision of 222 this specification." 224 This document therefore deprecates mandatory reflection of the 225 original To and From URIs in mid-dialog requests and their responses. 226 It is assumed that deployed proxies will already be able to tolerate 227 a change of URI, since this has been expected for a considerable 228 time. To cater for any UAs that are not able to tolerate a change of 229 URI, a new option tag "dialogUriChange" is introduced for providing a 230 positive indication of support in the Supported header field. 232 OPEN ISSUE. Should this be extended to allow a URI in the To 233 header field of a response to change compared with the To header 234 field in a request? This could convey a connected identity in a 235 response to an INVITE request, but it would not be authenticated. 236 Authentication would have to rely on transitive trust, which might 237 be feasible in a closed environment where the sips URI scheme is 238 used. 240 6. Behaviour 242 6.1. Behaviour of a UA that issues an INVITE request 244 When issuing an INVITE request, a UA that supports changes of URI in 245 the From and To headers during a dialog SHOULD include the 246 dialogUriChange option tag in the Supported header field. 248 After a dialog has been formed (after receipt of a reliable response 249 to the INVITE request), if the dialogUriChange option tag has been 250 received in a Supported header field and if the identity associated 251 with the UA changes, the UA SHOULD issue a request on the same dialog 252 containing the new identity in the URI of the From header field. 253 Unless there is a need to invoke any other method, the UPDATE method 254 [4] SHOULD be used if supported by the peer UA. If the UPDATE method 255 is not supported by the peer UA, the re-INVITE method SHOULD be used. 256 but this necessitates waiting until the dialog is confirmed. 258 OPEN ISSUE. RFC 3311 talks about circumstances in which an UPDATE 259 request cannot contain an SDP offer, yet does not explicitly talk 260 about the use of UPDATE requests without SDP offers. It needs to 261 be resolved whether an UPDATE request can be used in order to 262 convey just a revised URI in the From header field even though no 263 SDP offer needs to be sent at the time. If the outcome is that an 264 UPDATE request must contain an SDP offer, then SDP offer will need 265 to be included in the UPDATE request. 267 After sending a request with a revised URI in the From header field, 268 the UA SHALL send the same URI in the From header field of any future 269 requests on the same dialog, unless the identity changes again. 271 If the UA has received a request from the peer UA in which the From 272 header field URI differs from the To header field in the last request 273 the UA sent on that dialog, the UA MAY indicate the revised identity 274 to the user. In addition the UA SHOULD use this revised URI in the 275 To header field of any future requests it sends on the same dialog. 276 OPEN ISSUE. Is this a good idea to change the content of the To 277 header field URI on subsequent requests? How should a UAS for a 278 subsequent request react it if receives the wrong value in the To 279 header field URI, e.g., it receives the old URI when it has 280 already sent an UPDATE request containing a new From header field 281 URI? 283 6.2. Behaviour of a UA that receives an INVITE request 285 After receiving an INVITE request, a UA that supports changes of URI 286 in the From and To headers during a dialog SHOULD include the 287 dialogUriChange option tag in the Supported header field of any 288 dialog-forming response. 290 After a dialog has been formed (after sending a reliable response to 291 the INVITE request, i.e., a 2xx response or a reliable 1xx response), 292 if the dialogUriChange option tag has been received in a Supported 293 header field and if the identity associated with the UA differs from 294 that received in the To header field of the INVITE request, the UA 295 SHOULD issue a request on the same dialog containing the new identity 296 in the URI of the From header field. Unless there is a need to 297 invoke any other method, the UPDATE method SHOULD be used. 299 After sending a request with a revised URI in the From header field, 300 the UA SHALL send the same URI in the From header field of any future 301 requests on the same dialog, unless the identity changes again. 303 If the UA has received a request from the peer UA in which the From 304 header field URI differs from that received in the previous request 305 on that dialog, the UA MAY indicate the revised identity to the user. 306 In addition the UA SHOULD use this revised URI in the To header field 307 of any future requests it sends on the same dialog. 309 6.3. Behaviour of a UA during an established INVITE-initiated dialog 311 If the dialogUriChange option tag has been received in a Supported 312 header field and if the identity associated with the UA differs from 313 that received in the To header field of the INVITE request, the UA 314 SHOULD issue a request on the same dialog containing the new identity 315 in the URI of the From header field. Unless there is a need to 316 invoke any other method, the UPDATE method SHOULD be used. 318 After sending a request with a revised URI in the From header field, 319 the UA SHALL send the same URI in the From header field of any future 320 requests on the same dialog, unless the identity changes again. 322 If the UA has received a request from the peer UA in which the From 323 header field URI differs from that received in the previous request 324 on that dialog, the UA MAY indicate the revised identity to the user. 325 In addition the UA SHOULD use this revised URI in the To header field 326 of any future requests it sends on the same dialog. 328 7. Examples 330 7.1. Sending connected identity after answering a call 332 In this example Carol's UA has been reached by retargeting at the 333 proxy and thus her identity (AoR) is not equal to that in the To 334 header field of the received INVITE request (Bob). Carol's UA 335 therefore conveys it identity in the From header field of an UPDATE 336 request. The proxy also provides an authentication service and 337 therefore adds Identity and Identity-Info header field to the UPDATE 338 request. 340 Alice's UA PROXY Carol's UA 342 INVITE(1) INVITE(2) 343 ----------------> ----------------> 345 200(3) 200(4) 346 <---------------- <---------------- 348 ACK(5) ACK(6) 349 ----------------> ----------------> 351 UPDATE(8) UPDATE(7) 352 <---------------- <---------------- 354 200(9) 200(10) 356 ----------------> ----------------> 358 INVITE (1): 360 INVITE sip:Bob@example.com SIP/2.0 361 From: ;tag=1 362 To: 363 Call-ID: 12345600@example.com 364 CSeq: 1 INVITE 365 Supported: dialogUriChange 366 Contact: 367 etc. 369 INVITE(2): 371 INVITE sip:Carol@ua2.example.com SIP/2.0 372 From: ;tag=1 373 To: 374 Call-ID: 12345600@example.com 375 CSeq: 1 INVITE 376 Supported: dialogUriChange 377 Contact: 378 Identity: "dKJ97..." 379 Identity-Info: ;alg=rsa-sha1 380 etc. 382 200(3): 384 SIP/2.0 200 OK 385 From: ;tag=1 386 To: ;tag=2 387 Call-ID: 12345600@example.com 388 CSeq: 1 INVITE 389 Supported: dialogUriChange 390 Contact: 391 etc. 393 200(4): 395 SIP/2.0 200 OK 396 From: ;tag=1 397 To: ;tag=2 398 Call-ID: 12345600@example.com 399 CSeq: 1 INVITE 400 Supported: dialogUriChange 401 Contact: 402 etc. 404 ACK (5): 406 ACK sip:Bob@example.com SIP/2.0 407 From: ;tag=1 408 To: 409 Call-ID: 12345600@example.com 410 CSeq: 1 ACK 411 etc. 413 ACK (6): 415 ACK sip:Bob@example.com SIP/2.0 416 From: ;tag=1 417 To: 418 Call-ID: 12345600@example.com 419 CSeq: 1 ACK 420 etc. 422 UPDATE (7): 424 UPDATE sip:Alice@ua1.example.com SIP/2.0 425 From: ;tag=2 426 To: ;tag=1 427 Call-ID: 12345600@example.com 428 CSeq: 2 UPDATE 429 Contact: 430 etc. 432 Note that the URI in the From header differs from that in the To 433 header in the INVITE request/response. However, the tag is the 434 same as that in the INVITE response. 436 UPDATE (8): 438 UPDATE sip:Alice@ua1.example.com SIP/2.0 439 From: ;tag=2 440 To: ;tag=1 441 Call-ID: 12345600@example.com 442 CSeq: 2 UPDATE 443 Contact: 444 Identity: "cdKJH43..." 445 Identity-Info: ;alg=rsa-sha1 446 etc. 448 200(9): 450 SIP/2.0 200 OK 451 From: ;tag=2 452 To: ;tag=1 453 Call-ID: 12345600@example.com 454 CSeq: 2 UPDATE 455 Contact: 456 etc. 458 200(10): 460 SIP/2.0 200 OK 461 From: ;tag=2 462 To: ;tag=1 463 Call-ID: 12345600@example.com 464 CSeq: 2 UPDATE 465 Contact: 466 etc. 468 7.2. Sending revised connected identity during a call 470 In this example a call is established between Alice and Bob, where 471 Bob lies behind a B2BUA or gateway to a PSTN. Then call transfer 472 occurs in the B2BUA or PSTN, such that Alice becomes connected to 473 Carol, and a re-INVITE request is issued allowing the session to be 474 renegotiated. The B2BUA (or an entity behind it) or the gateway 475 provides the authentication service and thus generates the Identity 476 header in the re-INVITE request to provide authentication of Carol's 477 identity. 479 Alice's UA PROXY B2BUA or gateway 481 INVITE(1) INVITE(2) 482 ----------------> ----------------> 483 200(3) 200(3) 484 <---------------- <---------------- 486 ACK(5) ACK(6) 487 ----------------> ----------------> 489 UPDATE(8) UPDATE(7) 490 <---------------- <---------------- 492 200(9) 200(10) 493 ----------------> ----------------> 495 re-INVITE(11) re-INVITE(12) 496 <---------------- <---------------- 498 200(13) 200(14) 499 ----------------> ----------------> 501 ACK(15) ACK(16) 502 <--------------- <---------------- 504 INVITE (1): 506 INVITE sip:Bob@example.com SIP/2.0 507 From: ;tag=1 508 To: 509 Call-ID: 12345600@example.com 510 CSeq: 1 INVITE 511 Supported: dialogUriChange 512 Contact: 513 etc. 515 INVITE(2): 517 INVITE sip:Bob@example.com SIP/2.0 518 From: ;tag=1 519 To: 520 Call-ID: 12345600@example.com 521 CSeq: 1 INVITE 522 Supported: dialogUriChange 523 Contact: 524 Identity: "dKJ97..." 525 Identity-Info: ;alg=rsa-sha1 526 etc. 528 200(3): 530 SIP/2.0 200 OK 531 From: ;tag=1 532 To: ;tag=2 533 Call-ID: 12345600@example.com 534 CSeq: 1 INVITE 535 Supported: dialogUriChange 536 Contact: 537 etc. 539 200(4): 541 SIP/2.0 200 OK 542 From: ;tag=1 543 To: ;tag=2 544 Call-ID: 12345600@example.com 545 CSeq: 1 INVITE 546 Supported: dialogUriChange 547 Contact: 548 etc. 550 ACK (5): 552 ACK sip:Bob@example.com SIP/2.0 553 From: ;tag=1 554 To: 555 Call-ID: 12345600@example.com 556 CSeq: 1 ACK 557 etc. 559 ACK (6): 561 ACK sip:Bob@example.com SIP/2.0 562 From: ;tag=1 563 To: 564 Call-ID: 12345600@example.com 565 CSeq: 1 ACK 566 etc. 568 UPDATE (7): 570 UPDATE sip:Alice@ua1.example.com SIP/2.0 571 From: ;tag=2 572 To: ;tag=1 573 Call-ID: 12345600@example.com 574 CSeq: 2 UPDATE 575 Contact: 576 Identity: "cdKJH43..." 577 Identity-Info: ;alg=rsa-sha1 578 etc. 580 UPDATE (8): 582 UPDATE sip:Alice@ua1.example.com SIP/2.0 583 From: ;tag=2 584 To: ;tag=1 585 Call-ID: 12345600@example.com 586 CSeq: 2 UPDATE 587 Contact: 588 Identity: "cdKJH43..." 589 Identity-Info: ;alg=rsa-sha1 590 etc. 592 200(9): 594 SIP/2.0 200 OK 595 From: ;tag=2 596 To: ;tag=1 597 Call-ID: 12345600@example.com 598 CSeq: 2 UPDATE 599 Contact: 600 etc. 602 200(10): 604 SIP/2.0 200 OK 605 From: ;tag=2 606 To: ;tag=1 607 Call-ID: 12345600@example.com 608 CSeq: 2 UPDATE 609 Contact: 610 etc. 612 re-INVITE (11): 614 INVITE sip:Alice@ua1.example.com SIP/2.0 615 From: ;tag=2 616 To: ;tag=1 617 Call-ID: 12345600@example.com 618 CSeq: 3 INVITE 619 Contact: 620 Identity: "ecdFG24..." 621 Identity-Info: ;alg=rsa-sha1 622 etc. 624 re-INVITE (12): 626 INVITE sip:Alice@ua1.example.com SIP/2.0 627 From: ;tag=2 628 To: ;tag=1 629 Call-ID: 12345600@example.com 630 CSeq: 3 INVITE 631 Contact: 632 Identity: "ecdFG24..." 633 Identity-Info: ;alg=rsa-sha1 634 etc. 636 200(13): 638 SIP/2.0 200 OK 639 From: ;tag=2 640 To: ;tag=1 641 Call-ID: 12345600@example.com 642 CSeq: 3 INVITE 643 Contact: 644 etc. 646 200(14): 648 SIP/2.0 200 OK 649 From: ;tag=2 650 To: ;tag=1 651 Call-ID: 12345600@example.com 652 CSeq: 3 INVITE 653 Contact: 654 etc. 656 ACK (15): 658 ACK sip:Alice@ua1.example.com SIP/2.0 659 From: ;tag=2 660 To: ;tag=1 661 Call-ID: 12345600@example.com 662 CSeq: 3 ACK 663 etc. 665 ACK (16): 667 ACK sip:Alice@ua1.example.com SIP/2.0 668 From: ;tag=2 669 To: ;tag=1 670 Call-ID: 12345600@example.com 671 CSeq: 3 ACK 672 etc. 674 8. IANA considerations 676 This specification registers a new SIP option tag, as per the 677 guidelines in Section 27.1 of RFC 3261. 679 Name: dialogUriChange 681 Description: This option tag is used to indicate that a UA supports 682 changes to URIs in From and To header fields during a dialog. 684 9. Security considerations 686 [3] discusses security considerations relating to the Identity header 687 in some detail. Those same considerations apply when using the 688 Identity header to authenticate a connected identity in the From 689 header URI of a mid-dialog request. 691 A received From header field in a mid-dialog request that is not 692 accompanied by a valid Identity header field (or other means of 693 authentication) cannot be trusted (except in very closed 694 environments) and should be treated in a similar way to a From header 695 field in a dialog-initiating request that is not backed up by a valid 696 Identity header field. 698 A signed connected identity in a mid-dialog request (URI in the From 699 header field accompanied by a valid Identity header field) provides 700 information about the peer UA in a dialog. In the case of the UA 701 that was the UAS in the dialog-forming request, this identity is not 702 necessarily the same as that in the To header field of the dialog- 703 forming request. This is because of retargeting during the routing 704 of the dialog-forming request. A signed connected identity says 705 nothing about the legitimacy of such retargeting, but merely reflects 706 the result of that retargeting. 708 Likewise, when a signed connected identity indicates a change of 709 identity during a dialog, it conveys no information about the reason 710 for such change of identity or its legitimacy. 712 Use of the sips URI scheme can minimise the chances of attacks in 713 which inappropriate connected identity information is sent, either at 714 call establishment time or during a call. 716 Privacy may be required by the user of a connected UA. To achieve 717 privacy the UA MUST either decline to change the URI in the From 718 header field of a mid-dialog request or populate it in the way 719 described in [3] when anonymity is required. 721 10. Acknowledgments 723 Thanks to Francois Audet, Frank Derks, Steffen Fries, Cullen Jennings 724 and Jon Peterson for providing valuable comments. 726 11. References 728 11.1. Normative References 730 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 731 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 732 Session Initiation Protocol", RFC 3261, June 2002. 734 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 735 Levels", BCP 14, RFC 2119, March 1997. 737 [3] Peterson, J. and C. Jennings, "Enhancements for Authenticated 738 Identity Management in the Session Initiation Protocol (SIP)", 739 draft-ietf-sip-identity-06 (work in progress), October 2005. 741 [4] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 742 Method", RFC 3893, September 2002. 744 [5] Barnes, M., "An Extension to the Session Initiation Protocol 745 (SIP) for Request History Information", RFC 3893, November 2005. 747 11.2. Informative References 749 [6] Peterson, J., "Session Initiation Protocol (SIP) Authenticated 750 Identity Body (AIB) Format", RFC 3893, September 2004. 752 [7] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, 753 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 755 Author's Address 757 John Elwell 758 Siemens plc 759 Technology Drive 760 Beeston, Nottingham NG9 1LA 761 UK 763 Phone: +44 115 943 4989 764 Email: john.elwell@siemens.com 766 Intellectual Property Statement 768 The IETF takes no position regarding the validity or scope of any 769 Intellectual Property Rights or other rights that might be claimed to 770 pertain to the implementation or use of the technology described in 771 this document or the extent to which any license under such rights 772 might or might not be available; nor does it represent that it has 773 made any independent effort to identify any such rights. Information 774 on the procedures with respect to rights in RFC documents can be 775 found in BCP 78 and BCP 79. 777 Copies of IPR disclosures made to the IETF Secretariat and any 778 assurances of licenses to be made available, or the result of an 779 attempt made to obtain a general license or permission for the use of 780 such proprietary rights by implementers or users of this 781 specification can be obtained from the IETF on-line IPR repository at 782 http://www.ietf.org/ipr. 784 The IETF invites any interested party to bring to its attention any 785 copyrights, patents or patent applications, or other proprietary 786 rights that may cover technology that may be required to implement 787 this standard. Please address the information to the IETF at 788 ietf-ipr@ietf.org. 790 Disclaimer of Validity 792 This document and the information contained herein are provided on an 793 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 794 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 795 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 796 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 797 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 798 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 800 Copyright Statement 802 Copyright (C) The Internet Society (2006). This document is subject 803 to the rights, licenses and restrictions contained in BCP 78, and 804 except as set forth therein, the authors retain all their rights. 806 Acknowledgment 808 Funding for the RFC Editor function is currently provided by the 809 Internet Society.