idnits 2.17.00 (12 Aug 2021) /tmp/idnits50995/draft-elwell-sip-connected-identity-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 647. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 661), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 254: '...ng request, a UA MAY send its identity...' RFC 2119 keyword, line 256: '...D option tag and MUST send its connect...' RFC 2119 keyword, line 257: '...uest contained a REQUIRED header field...' RFC 2119 keyword, line 260: '... identity the UA MUST include a Connec...' RFC 2119 keyword, line 263: '... request, the UA SHOULD send an UPDATE...' (35 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 256 has weird spacing: '...dentity if...' == Line 455 has weird spacing: '... where prox...' == Line 463 has weird spacing: '... where prox...' == Line 568 has weird spacing: '...that is not b...' -- 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 2005) is 6062 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) == Missing Reference: 'AIB' is mentioned on line 114, but not defined == Missing Reference: 'IDENTITY' is mentioned on line 586, but not defined == Outdated reference: draft-ietf-sip-identity has been published as RFC 4474 Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Elwell 3 Internet Draft Siemens 5 draft-elwell-sip-connected-identity-00.txt 6 Expires: April 2006 October 2005 8 Connected Identity in the Session Initiation Protocol (SIP) 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-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 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2005). All Rights Reserved. 35 Abstract 37 This provides a means of providing a signed connected identity in 38 SIP. Because of retargeting of a dialog-forming request, the UAS can 39 have a different identity from that in the To header. This document 40 provides a means for that UA to supply its identity to the peer UA by 41 means of a request in the reverse direction and for that identity to 42 be signed by an authentication service. The same mechanism can be 43 used to indicate a change of identity during a dialog, e.g., because 44 of some action in a TDM network behind a gateway. 46 Table of Contents 48 1 Introduction....................................................3 49 2 Overview of proposed solution...................................4 50 3 Connected UA behaviour..........................................6 51 3.1 Connected UA at dialog establishing time......................6 52 3.2 Identity change during an established dialog..................7 53 4 Authentication service behaviour................................7 54 5 Verifier behaviour..............................................9 55 6 Header syntax..................................................10 56 7 Examples.......................................................11 57 7.1 Sending connected identity after answering a call............11 58 8 IANA considerations............................................12 59 8.1 Header field names...........................................12 60 8.2 SIP option tag...............................................12 61 9 Security Considerations........................................13 62 10 Acknowledgements..............................................13 63 11 Author's Addresses............................................13 64 12 Normative References..........................................14 65 13 Appendix - Rejected Alternatives (temporary – to be removed)..15 66 13.1 Changing the From header to reflect connected identity......15 67 13.2 Conveying the connected identity URI in a body..............15 68 13.3 Conveying the connected identity URI and the connected identity 69 signature in the same header field...............................15 70 13.4 Reuse of the Identity header for signing connected identity.15 71 13.5 Response identity...........................................16 72 13.6 Establishment of a new dialog using Replaces................16 74 1 Introduction 76 An important aspect of the Session Initiation Protocol (SIP) [SIP] is 77 the ability to convey to a User Agent Server (UAS) as part of a 78 request an identity associated with the User Agent Client (UAC) that 79 generated that request. Although the From header performs this 80 function, this header is generated by the UAC client itself and 81 therefore can be subject to falsification. SIP has several means of 82 providing cryptographic authentication of a request’s source 83 identity. 85 One such means is digest authentication, as specified in [SIP]. 86 Although a UAS can require digest authentication, it is not usually 87 feasible between an arbitrary pair of UAs because of reliance on a 88 shared secret. To achieve scalability, methods based on public key 89 cryptography are essential. 91 Another method is specified in [AIB]. This requires a UAC to have a 92 private key and associated certificate in order to sign an 93 Authenticated Identity Body (AIB) in the request. However, this has 94 seen little deployment, since the public key infrastructures needed 95 to support private keys and certificates in every UA are not 96 generally available. 98 A third method is specified in [Identity]. For signature this uses a 99 private key and certificate associated with the domain indicated in 100 the From header URI. The outbound proxy authenticates the UAC by some 101 means, using digest authentication for example, and then inserts an 102 Identity header and an Identity-Info header in the forwarded request. 103 The Identity header contains a signature using the domain’s private 104 key and the Identity-Info header contains the corresponding 105 certificate. 107 Some have argued that there is a need to provide the UAS’s identity 108 to the UAC in a response. This reflects the fact that a request can 109 be retargeted for various reasons before reaching the UAS, and the 110 UAS identity may differ from that in the To header field of the 111 request. Since the URI in the To header field of the response must 112 equal that in the request, the To header field is not suitable for 113 providing the UAS’s identity. Furthermore, any such identity would 114 need to be authenticated in some way. [AIB] provides for this, since 115 the AIB contains a From field, the URI of which identifies the source 116 of the response, not the source of the request (thus differing from 117 the From header field of the message itself). 119 However, there is no equivalent of [Identity] for responses. This 120 reflects the difficulty in the final proxy challenging the UAS to 121 provide digest authentication, in many circumstances a necessary step 122 in adding an Identity header or equivalent. 124 For dialog-forming requests (such as INVITE), the identity of the UAS 125 is particularly important, since that UA will remain as part of the 126 dialog until the dialog terminates. The identity of that UA often 127 differs from that in the To header of the dialog-forming request 128 owing to retargeting. If the identity is made available to the UAC, 129 the dialog can be terminated early if the UAS identity is not 130 acceptable. For requests that are not part of a new or existing 131 dialog, it can be argued that authenticated UAS identity is less 132 important since any damage arising from reaching an unacceptable UAS 133 has already been done. 135 Furthermore, the identity of a UA involved in a dialog can change 136 during the course of that dialog. One example is where a UA is a 137 PSTN/ISDN gateway and transfer occurs within the PSTN/ISDN. It is not 138 only important to send the identity of the PSTN/ISDN party to the 139 peer UA on dialog establishment, but also to send an updated identity 140 if the party changes. A similar situation can arise with B2BUAs that 141 perform third party call control operations. 143 This document therefore proposes a solution to the general problem of 144 connected identity, which is the provision of the identity of the UAS 145 in a dialog-forming request to the UAC of that request and the 146 provision of a revised identity to the peer UA if identity changes 147 during a dialog. In each case the UA whose identity is provided is 148 known as the connected UA and that UA is known as the connected 149 identity. 151 2 Overview of proposed solution 153 Because of difficulties providing authenticated identity in the 154 response to a dialog forming request, a request in the reverse 155 direction is used to provide authenticated identity of the UAS in the 156 dialog forming request, i.e., the identity of the connected UA. 157 Likewise, if the identity of either UA changes during the lifetime of 158 the dialog, the new connected identity can be provided in a request 159 issued by that UA. In either case the signalling path must pass 160 through an authentication service acting on behalf of the connected 161 UA, and therefore the proxy concerned must record-route. Note that 162 this may involve different authentication services at the two ends of 163 the dialog. 165 The URI in the From header field of a request in the backward 166 direction (opposite direction to the dialog-forming request) is 167 unsuitable for providing connected identity, since the URI in the 168 From header field must always be the same as the URI in the To header 169 field of the dialog-forming request (see 12.2.1.1/[SIP]). Because of 170 retargeting of the dialog-forming request, the connected identity can 171 differ from the URI in the From header of a request in the reverse 172 direction. Likewise the URI in the From header of a request in the 173 forward direction (the same direction as the dialog-forming request) 174 is unsuitable for providing a changed connected identity, because the 175 From header field must not change. 177 Therefore a new Header known as Connected-URI is defined to convey 178 the connected identity URI. A UA wishing to indicate its connected 179 identity may include a Connected-URI header field in a request. This 180 can be any request issued by a UA in the context of an early or 181 established dialog. An UPDATE request [UPDATE] can be sent for this 182 purpose if there is no other purpose for sending a request at this 183 time. 185 OPEN ISSUE. RFC 3311 talks about circumstances in which an UPDATE 186 request cannot contain an SDP offer, yet does not explicitly talk 187 about the use of UPDATE requests without SDP offers. It needs to be 188 resolved whether an UPDATE request can be used in order to convey 189 Connected-URI even though no SDP offer needs to be sent at the time. 190 If the outcome is that an UPDATE request must contain an SDP offer, 191 then SDP offer will need to be included when sending Connected-URI is 192 sent. 194 An authentication service on the path of a request containing a 195 Connected-URI header field may add a Connected-Identity header field 196 to sign the request on behalf of the domain part of the URI indicated 197 in the Connected-URI header field. This is similar to an Identity 198 header but the signature covers also the Connected-URI header field 199 and certifies that the UAC has credentials that allow it to register 200 as a contact for that URI. To ascertain this the authentication 201 service would normally challenge the UAC to provide digest 202 authentication, unless TLS is used and the UA has already been 203 authenticated on that connection, e.g., by means of a certificate 204 during the TLS handshake or a shared secret used to respond to a 205 challenge at the application layer. The authentication service also 206 adds an Identity-Info header to provide information about the 207 certificate needed to verify the signature. 209 A proxy that provides an authentication service may also add a 210 Connected-URI header field if not already present in a request or 211 replace an existing one. 213 A UAS receiving a request containing a Connected-URI header field and 214 a valid Connected-Identity header field may use the connected 215 identity for any purpose, such as passing to an application or 216 displaying. A UAS receiving a request containing a Connected-URI 217 header field but no Connected-Identity header field should either 218 discard the connected identity or use it with caution. 220 OPEN ISSUE: Should we also consider the possibility of including a 221 Connected-URI header in a response? An authentication service would 222 be able to add a Connected-Identity header only if has some means of 223 authenticating the UAS. It cannot challenge the UAS, so it would have 224 to rely on other means, e.g., challenging an earlier request on the 225 same TLS transport). 227 This document also specifies a new option tag, connectedID, to 228 indicate support for or requirement for connected identity. 230 OPEN ISSUE. Is this option tag worthwhile? Use of it a Require header 231 field to force the sending of a Connected-URI header field in a 232 reverse request is not particularly secure, since it does not fall 233 within the signature of the Identity header and could be removed by 234 an attacker. Also, even if the UAS provides a Connected-URI header 235 field in a reverse request, there is no guarantee that an 236 authentication service will be available or be prepared to add a 237 signature in the form of a Connected-Identity header field. 239 3 Connected UA behaviour 241 3.1 Connected UA at dialog establishing time 243 When a dialog is established, the connected UA is the UA that acts as 244 UAS for the dialog establishing request and returns a 1xx (not 100) 245 or 2xx response. 247 The behaviour below relies on a connected UA knowing its connected 248 URI, i.e., its AoR. Some UAs register as contacts for multiple AoRs. 249 Provided a UA has registered a different contact URI for each AoR it 250 registers for, then it can associate an incoming request with a 251 particular AoR by examining the Request-URI. 253 After sending the first reliable response (1xx or 2xx) to a dialog 254 forming request, a UA MAY send its identity (the connected identity) 255 if the dialog-forming request contained a Supported header field with 256 the connectedID option tag and MUST send its connected identity if 257 the dialog-forming request contained a REQUIRED header field with the 258 connectedID option tag. 260 To send its connected identity the UA MUST include a Connected-URI 261 header field in a mid-dialog request, e.g., an UPDATE request or a 262 (re-)INVITE request. If there is no other reason to send a mid-dialog 263 request, the UA SHOULD send an UPDATE request for this specific 264 purpose. The UA MUST accurately populate the Connected-URI header 265 field with a value corresponding to an identity that it believes it 266 is authorized to claim. It MUST set the URI portion of the header to 267 match a SIP, SIPS or TEL URI AoR which it is authorized to use in the 268 domain (including anonymous URIs, as described in [Privacy]). 270 Note that [Identity] defines a number of new 4xx response codes, and 271 these in general are applicable also to connected identity. If a UA 272 supports these response codes, it will be able to respond 273 intelligently to Identity-based error conditions. 275 3.2 Identity change during an established dialog 277 An identity change can occur at a gateway as a result of action in 278 the legacy network beyond the gateway, e.g., call transfer. During an 279 established dialog the gateway can receive updated identity 280 information from the legacy network that prompts it to adopt a 281 revised identity within the SIP network. This can apply to either the 282 UAC or the UAS of the original dialog establishing request. 284 If during a dialog the identity of a UA changes from that which it 285 indicated previously in the From header or Connected-URI header of a 286 request, the UA MAY send its revised identity if it has received from 287 the peer UA a Supported header field with the connectedID option tag 288 and MUST send its revised identity if it has received from the peer 289 UA a Required header field with the connectedID option tag. To send 290 its revised identity the UA MUST included a Connected-URI header 291 field in a mid-dialog request as specified in 3.1. 293 In this case it will frequently be the case that the UA provides its 294 own authentication service and will therefore add a Connected- 295 Identity header field too. Authentication is on the basis of trusting 296 the identity received from the legacy network. 298 4 Authentication service behaviour 300 The authentication service described here is an extension to that 301 described in [Identity] except that it authenticates the connected 302 identity. As stated in [Identity], the authentication service role 303 can be instantiated by a proxy server or a user agent. Any entity 304 that instantiates the authentication service role MUST possess the 305 private key of a domain certificate, and MUST be capable of 306 authenticating one or more SIP users that can register in that 307 domain. Commonly, this role will be instantiated by a proxy server, 308 since these entities are more likely to have a static hostname, hold 309 a corresponding certificate, and have access to SIP registrar 310 capabilities that allow them to authenticate users in their domain. 312 A proxy wishing to perform the role of authentication service for a 313 dialog must record-route during dialog establishment, so that mid- 314 dialog requests pass through it. 316 The behaviour described below applies only to requests containing a 317 Connected-URI header field received in the context of an early or 318 established dialog. Otherwise the authentication service behaviour of 319 [Identity] is applicable (i.e., an Identity header will be added, if 320 applicable). 322 A SIP entity that acts as an authentication service MUST add a Date 323 header field to SIP requests if one is not already present. 324 Similarly, an authentication service MUST add a Content-Length header 325 field to SIP requests if one is not already present; this can help 326 the verifier to double-check that it is hashing exactly as many bytes 327 of message-body as the authentication service when it verifies the 328 message. 330 An entity instantiating the authentication service role performs the 331 following steps, in order, to generate a Connected-Identity header 332 for a SIP request: 334 Step 1: The authentication service MUST extract the identity of the 335 sender from the request. The authentication service takes this value 336 from the Connected-URI header field; this AoR will be referred to 337 here as the 'identity field'. If the identity field contains a SIP 338 or SIPS URI, the authentication service MUST extract the hostname 339 portion of the identity field and compare it to the domain(s) for 340 which it is responsible. If the identity field uses the TEL URI 341 scheme, the policy of the authentication service determines whether 342 or not it is responsible for this identity; see Section 12 of 343 [Identity] for more information. If the authentication service is not 344 responsible for the identity in question, it SHOULD process and 345 forward the request normally, but it MUST NOT add a Connected- 346 Identity header; see below for more information on authentication 347 service handling of an existing Connected-Identity header. 349 Step 2: The authentication service MUST determine whether or not the 350 sender of the request is authorized to claim the identity given in 351 the connected identity field. In order to do so, the authentication 352 service MUST first authenticate the sender of the message. 353 Authentication and authorization considerations are as described in 354 authentication service behaviour step 2 in [Identity]. If the 355 authentication service is unable to authorise the connected identity 356 it MUST reject the request with a 403 response. 358 Step 3: The authentication service SHOULD ensure that any pre- 359 existing Date header in the request is accurate, in accordance with 360 authentication service behaviour step 3 in [Identity]. 362 Step 4: The authentication service MUST form the connected identity 363 signature and add a Connected-Identity header to the request 364 containing this signature. After the Connected-Identity header has 365 been added to the request, the authentication service MUST also add 366 an Identity-Info header. The Identity-Info header contains a URI 367 from which its certificate can be acquired. Details on the 368 generation of both of these headers are provided in section 6. 370 Finally, the authentication service MUST forward the message 371 normally. 373 5 Verifier behaviour 375 This document extends the logical role for SIP entities called a 376 'verifier', as introduced in [Identity]. When a verifier receives a 377 SIP request in the context of an early or established dialog and 378 containing a Connected-Identity header, it may inspect the signature 379 to verify the identity of the sender of the message. Typically, the 380 results of a verification are provided as input to an authorization 381 process which is outside the scope of this document. If neither an 382 Identity header field nor a Connected-Identity header field is 383 present in a request, and one is required by local policy (for 384 example, based on a per-sending-domain policy, or a per-sending-user 385 policy), then a 428 'Use Identity Header' response MUST be sent, 386 which should be interpreted in this case as 'Use Identity header or 387 Connected-Identity header, as appropriate'. 389 In order to verify the identity of the sender of a message containing 390 a Connected-Identity header field together with Connected-URI and 391 Identity-Info header fields, an entity acting as a verifier MUST 392 perform the following steps, in the order here specified. 394 Step 1: The verifier MUST acquire the certificate for the signing 395 domain as described in verifier behaviour step 1 in [Identity]. 397 Step 2: The verifier MUST compare the identity of the signer with the 398 domain portion of the URI in the Connected-URI header field using the 399 method described in verifier behaviour step 2 of [Identity]. 401 Step 3: The verifier MUST verify the signature in the Connected- 402 Identity header field, following the procedures for generating the 403 hashed digest- string described in Section 6. If a verifier 404 determines that the signature on the message does not correspond to 405 the reconstructed digest-string, then a 428 'Invalid Identity Header' 406 response MUST be returned. 408 Step 4: The verifier MUST validate the Date, Contact and Call-ID 409 headers the manner described in Section 14.1 of [IDENTITY]; 410 recipients that wish to verify Connected-Identity signatures MUST 411 support all of the operations described there. 413 The verifier function is normally located at the UAS of a mid-dialog 414 request. The UA SHOULD render the connected identity and its validity 415 to the user through an appropriate user interface or to an 416 application. A UA MAY also make use of a Connected-URI header field 417 that is not accompanied by a Connected-Identity header field, i.e., 418 an unsigned connected identity, in which case the UA SHOULD 419 distinguish unsigned connected identities from signed connected 420 identities when rendering the information to a user or application. 422 In order to have the possibility of receiving connected identity, a 423 UA MUST include the connectedID option tag in a Supported or Required 424 header field in a SIP message towards the peer UA, e.g., in the 425 dialog-forming request. Use of this option tag in a Required header 426 will cause the request to fail if connected identity is not supported 427 and will cause the Connected-URI to be returned in a request in the 428 reverse direction if connected identity is supported at the UAS. 429 However, although the return of a Connected-URI header can be forced 430 using this mechanism, this does not guarantee that it will be 431 accompanied by a Connected-Identity header field, which will depend 432 on the presence of an authentication service on the path and the 433 ability of the authentication service to authenticate the sender. 435 6 Header syntax 437 This document specifies two new SIP headers: Connected-URI and 438 Connected-Identity. Each of these headers can appear only once in a 439 SIP message. The grammar for these two headers is: 441 Connected-URI = "Connected-URI" HCOLON ( name-addr / addr-spec ) 443 Connected-Identity = "Identity" HCOLON signed-connected-id-digest 445 signed-connected-id-digest = LDQUOT 32LHEX RDQUOT 447 The signed-connected-id-digest is a signed hash of a canonical string 448 generated from certain components of a SIP request. It is identical 449 to signed-identity-digest in [Identity] except that in the canonical 450 string instead of the addr-spec of the From header field the addr- 451 spec of the Connected-URI header field MUST be used. 453 This document adds the following entries to Table 2 of [SIP]: 455 Header field where proxy ACK BYE CAN INV OPT REG 456 ------------ ----- ----- --- --- --- --- --- --- 457 Connected-URI R r o o - o o - 459 SUB NOT REF INF UPD PRA 460 --- --- --- --- --- --- 461 - o o o o o 463 Header field where proxy ACK BYE CAN INV OPT REG 464 ------------ ----- ----- --- --- --- --- --- --- 465 Connected-Identity R a o o - o o - 467 SUB NOT REF INF UPD PRA 468 --- --- --- --- --- --- 469 - o o o o o 471 Note, in the table above, only methods that can be used in the 472 context of an early or established dialog are applicable. The CANCEL 473 method is excluded for reasons given in [Identity]. 475 7 Examples 477 7.1 Sending connected identity after answering a call. 479 In this example Carol's UA has been reached by retargeting at the 480 proxy and thus her identity (AoR) is not equal to that in the To 481 header field of the received INVITE request (Bob). Carol's UA 482 therefore places a Connected-URI header field in an UPDATE request. 483 The proxy also provides an authentication service and therefore adds 484 a Connected-Identity header field and an Identity-Info header field 485 to the UPDATE request. 487 Alice's UA PROXY Carol's UA 488 INVITE (1) INVITE(2) 489 ----------------> ----------------> 491 200 (3) 200 (3) 492 <---------------- <---------------- 494 ACK(5) ACK(6) 495 ----------------> ----------------> 497 UPDATE (8) UPDATE (7) 498 <---------------- <---------------- 500 200 (9) 200 (10) 501 ----------------> ----------------> 503 INVITE (1) and INVITE (2) 504 These include either: 505 Require: connectedID 506 or 507 Supported: connectedID 509 UPDATE (7) 511 UPDATE sip:ua1@example.com SIP/2.0 512 From: ;tag=2 513 To: ;tag=3 514 Call-ID: 12345600@example.com 515 CSeq: 1 UPDATE 516 Connected-URI: 518 UPDATE (8) 520 UPDATE sip:ua1@example.com SIP/2.0 521 From: ;tag=2 522 To: ;tag=3 523 Call-ID: 12345600@example.com 524 CSeq: 1 UPDATE 525 Connected-URI: 526 Conncected-Identity: "dKJ97..." 527 Identity-Info: ;alg=rsa-sha1 529 8 IANA considerations 531 This document requests changes to the header fields and option tags 532 registries within the SIP parameters IANA registry. 534 8.1 Header field names 536 This document specifies two new SIP headers: Connected-URI and 537 Connected-Identity. Their syntax is given in section 6. These 538 headers are defined by the following information, which is to be 539 added to the header sub-registry under 540 http://www.iana.org/assignments/sip-parameters. 541 Header Name: Connected-URI 542 Compact Form: N/A 543 Header Name: Connected-Identity 544 Compact Form: N/A 546 8.2 SIP option tag 548 This specification registers a new SIP option tag, as per the 549 guidelines in Section 27.1 of RFC 3261. 550 Name: connectedID 551 Description: This option tag is used to identify connected identity 552 and the Connected-URI and Connected-Identity header fields. When used 553 in a Supported header, it indicates support for receiving these 554 header fields and acts as a request to provide this information. When 555 used in a Required header it indicates that the request concerned 556 should be rejected if connected identity information cannot be 557 provided. 559 9 Security Considerations 561 [Identity] discusses security considerations relating to the Identity 562 header in some detail. Essentially those same considerations apply to 563 the Connected-Identity header. 565 A received Connected-URI header field that is not accompanied by a 566 valid Connected-Identity header field cannot be trusted (except in 567 very closed environments) and should be treated in a similar way to a 568 From header field that is not backed up by a valid Identity header 569 field. 571 A signed connected identity (Connected-URI header field accompanied 572 by a valid Connected-Identity field) provides information about the 573 peer UA in a dialog. In the case of the UA that was the UAS in the 574 dialog-forming request, this identity is not necessarily the same as 575 that in the To header of the dialog-forming request. This is because 576 of retargeting during the routing of the dialog-forming request. A 577 signed connected identity says nothing about the legitimacy of such 578 retargeting, but merely reflects the result of that retargeting. 580 Likewise, when a signed connected identity indicates a change of 581 identity during a dialog, it conveys no information about the reason 582 for such change of identity of its legitimacy. 584 Privacy may be required by the user of a connected UA. To achieve 585 privacy the UA MUST either decline to send the Connected-URI header 586 field or populate it in the way described in [IDENTITY] for the From 587 header field when anonymity is required. Note that if a Require 588 header field has been received with the connectedID option tag, 589 accepting the request but declining to send the Connected-URI header 590 field is not an option, and therefore the UA MUST either decline the 591 request or populate the Connected-URI header field anonymously. 593 10 Acknowledgements 595 Thanks to Francois Audet, Frank Derks, Steffen Fries and Jon Peterson 596 for providing valuable comments. 598 11 Author's Addresses 600 John Elwell 601 Siemens Communications 602 Technology Drive 603 Beeston 604 Nottingham, UK, NG9 1LA 605 email: john.elwell@siemens.com 607 12 Normative References 609 [SIP] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation 610 protocol", RFC 3261. 612 [AIB]J. Peterson, "Session Initiation Protocol (SIP) Authenticated 613 Identity Body (AIB) Format", RFC 3893. 615 [Identity] J. Peterson, C. Jennings, "Enhancements for Authenticated 616 Identity Management in the Session Initiation Protocol (SIP)", draft- 617 ietf-sip-identity-05 (work in progress). 619 [Privacy] J. Peterson, "A Privacy Mechanism for the Session 620 Initiation Protocol (SIP)", RFC 3323. 622 [UPDATE] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 623 method", RFC 3311. 625 Intellectual Property Statement 627 The IETF takes no position regarding the validity or scope of any 628 Intellectual Property Rights or other rights that might be claimed to 629 pertain to the implementation or use of the technology described in 630 this document or the extent to which any license under such rights 631 might or might not be available; nor does it represent that it has 632 made any independent effort to identify any such rights. Information 633 on the IETF's procedures with respect to rights in IETF Documents can 634 be found in BCP 78 and BCP 79. 636 Copies of IPR disclosures made to the IETF Secretariat and any 637 assurances of licenses to be made available, or the result of an 638 attempt made to obtain a general license or permission for the use of 639 such proprietary rights by implementers or users of this 640 specification can be obtained from the IETF on-line IPR repository at 641 http://www.ietf.org/ipr. 643 The IETF invites any interested party to bring to its attention any 644 copyrights, patents or patent applications, or other proprietary 645 rights that may cover technology that may be required to implement 646 this standard. Please address the information to the IETF at ietf- 647 ipr@ietf.org. 649 Disclaimer of Validity 651 This document and the information contained herein are provided on an 652 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 653 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 654 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 655 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 656 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 657 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 659 Copyright Statement 661 Copyright (C) The Internet Society (2005). 663 This document is subject to the rights, licenses and restrictions 664 contained in BCP 78, and except as set forth therein, the authors 665 retain all their rights. 667 Acknowledgement 669 Funding for the RFC Editor function is currently provided by the 670 Internet Society. 672 13 Appendix - Rejected Alternatives (temporary – to be removed) 674 The following alternative solutions were considered and rejected. 676 13.1 Changing the From header to reflect connected identity 678 [SIP] disallows any change to the From and To header fields during 679 the course of a dialog, since these header fields (along with the 680 Call-Id header field) provide unique identification for a dialog. 681 Although the tag parameters in the From and To header fields are in 682 fact sufficient for dialog identification purposes, for backward 683 compatibility with RFC 2543 changes to the URIs in these header 684 fields are prohibited. It is probable that [SIP]-compliant 685 implementations may break if a URI changes during a dialog. The 686 community has already rejected this approach. 688 13.2 Conveying the connected identity URI in a body 690 This might have the advantage that the existing Identity header could 691 be used, but this is contrary to the semantics of the Identity 692 header. 694 13.3 Conveying the connected identity URI and the connected identity 695 signature in the same header field. 697 This has the minor disadvantage that the syntax of the header field 698 would differ from that of the Identity header field. 700 13.4 Reuse of the Identity header for signing connected identity 701 The signature in the Identity header basically authenticates the 702 identity in the From header and would not be able to authenticate a 703 different identity (e.g., in a Connected-URI header). 705 13.5 Response identity 707 Although the proposed solution can under some circumstances provide 708 connected identity in a response, a general solution to response 709 identity is not possible because of the inability to challenge a 710 response to obtain authentication. 712 13.6 Establishment of a new dialog using Replaces 714 The UA wishing to convey its identity and being unable to do so in 715 the From header field of a request on the existing INVITE-initiated 716 dialog could send a new INVITE request containing a Replaces header 717 field indicating replacement of the existing dialog at the UAS. The 718 From header field of that request would contain the correct identity 719 and could be signed by means of an Identity header in the normal way. 721 There is no normative specification at present covering the fate of 722 the existing session when an existing INVITE-initiated dialog is 723 replaced by a new dialog between the same two UAs. It would be 724 undesirable to interrupt an ongoing session just because the dialog 725 needs to be replaced, particularly if this means the calculation of 726 new security keys for media. 728 The Replaces header is not defined for use in a SUBSCRIBE request, so 729 this technique would not be applicable to SUBSCRIBE-initiated 730 dialogs. It is not clear whether this would matter. 732 This technique would be unsuitable for use on an early dialog, since 733 the replaced dialog might by-pass any proxy that was supervising the 734 early dialog and might wish to cancel it under certain circumstances 735 or take account of any non 2xx final response. 737 This technique would involve additional SIP messages (5, including 738 the BYE request and response on the replaced dialog, rather than 2).