Internet Engineering Task Force J. Elwell Internet Draft Siemens draft-elwell-sip-connected-identity-00.txt Expires: April 2006 October 2005 Connected Identity in the Session Initiation Protocol (SIP) Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress. " The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This provides a means of providing a signed connected identity in SIP. Because of retargeting of a dialog-forming request, the UAS can have a different identity from that in the To header. This document provides a means for that UA to supply its identity to the peer UA by means of a request in the reverse direction and for that identity to be signed by an authentication service. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in a TDM network behind a gateway. Elwell Expires - April 2006 [Page 1] Connected Identity in SIP October 2005 Table of Contents 1 Introduction....................................................3 2 Overview of proposed solution...................................4 3 Connected UA behaviour..........................................6 3.1 Connected UA at dialog establishing time......................6 3.2 Identity change during an established dialog..................7 4 Authentication service behaviour................................7 5 Verifier behaviour..............................................9 6 Header syntax..................................................10 7 Examples.......................................................11 7.1 Sending connected identity after answering a call............11 8 IANA considerations............................................12 8.1 Header field names...........................................12 8.2 SIP option tag...............................................12 9 Security Considerations........................................13 10 Acknowledgements..............................................13 11 Author's Addresses............................................13 12 Normative References..........................................14 13 Appendix - Rejected Alternatives (temporary – to be removed)..15 13.1 Changing the From header to reflect connected identity......15 13.2 Conveying the connected identity URI in a body..............15 13.3 Conveying the connected identity URI and the connected identity signature in the same header field...............................15 13.4 Reuse of the Identity header for signing connected identity.15 13.5 Response identity...........................................16 13.6 Establishment of a new dialog using Replaces................16 Elwell Expires - April 2006 [Page 2] Connected Identity in SIP October 2005 1 Introduction An important aspect of the Session Initiation Protocol (SIP) [SIP] is the ability to convey to a User Agent Server (UAS) as part of a request an identity associated with the User Agent Client (UAC) that generated that request. Although the From header performs this function, this header is generated by the UAC client itself and therefore can be subject to falsification. SIP has several means of providing cryptographic authentication of a request’s source identity. One such means is digest authentication, as specified in [SIP]. Although a UAS can require digest authentication, it is not usually feasible between an arbitrary pair of UAs because of reliance on a shared secret. To achieve scalability, methods based on public key cryptography are essential. Another method is specified in [AIB]. This requires a UAC to have a private key and associated certificate in order to sign an Authenticated Identity Body (AIB) in the request. However, this has seen little deployment, since the public key infrastructures needed to support private keys and certificates in every UA are not generally available. A third method is specified in [Identity]. For signature this uses a private key and certificate associated with the domain indicated in the From header URI. The outbound proxy authenticates the UAC by some means, using digest authentication for example, and then inserts an Identity header and an Identity-Info header in the forwarded request. The Identity header contains a signature using the domain’s private key and the Identity-Info header contains the corresponding certificate. Some have argued that there is a need to provide the UAS’s identity to the UAC in a response. This reflects the fact that a request can be retargeted for various reasons before reaching the UAS, and the UAS identity may differ from that in the To header field of the request. Since the URI in the To header field of the response must equal that in the request, the To header field is not suitable for providing the UAS’s identity. Furthermore, any such identity would need to be authenticated in some way. [AIB] provides for this, since the AIB contains a From field, the URI of which identifies the source of the response, not the source of the request (thus differing from the From header field of the message itself). However, there is no equivalent of [Identity] for responses. This reflects the difficulty in the final proxy challenging the UAS to Elwell Expires - April 2006 [Page 3] Connected Identity in SIP October 2005 provide digest authentication, in many circumstances a necessary step in adding an Identity header or equivalent. For dialog-forming requests (such as INVITE), the identity of the UAS is particularly important, since that UA will remain as part of the dialog until the dialog terminates. The identity of that UA often differs from that in the To header of the dialog-forming request owing to retargeting. If the identity is made available to the UAC, the dialog can be terminated early if the UAS identity is not acceptable. For requests that are not part of a new or existing dialog, it can be argued that authenticated UAS identity is less important since any damage arising from reaching an unacceptable UAS has already been done. Furthermore, the identity of a UA involved in a dialog can change during the course of that dialog. One example is where a UA is a PSTN/ISDN gateway and transfer occurs within the PSTN/ISDN. It is not only important to send the identity of the PSTN/ISDN party to the peer UA on dialog establishment, but also to send an updated identity if the party changes. A similar situation can arise with B2BUAs that perform third party call control operations. This document therefore proposes a solution to the general problem of connected identity, which is the provision of the identity of the UAS in a dialog-forming request to the UAC of that request and the provision of a revised identity to the peer UA if identity changes during a dialog. In each case the UA whose identity is provided is known as the connected UA and that UA is known as the connected identity. 2 Overview of proposed solution Because of difficulties providing authenticated identity in the response to a dialog forming request, a request in the reverse direction is used to provide authenticated identity of the UAS in the dialog forming request, i.e., the identity of the connected UA. Likewise, if the identity of either UA changes during the lifetime of the dialog, the new connected identity can be provided in a request issued by that UA. In either case the signalling path must pass through an authentication service acting on behalf of the connected UA, and therefore the proxy concerned must record-route. Note that this may involve different authentication services at the two ends of the dialog. The URI in the From header field of a request in the backward direction (opposite direction to the dialog-forming request) is unsuitable for providing connected identity, since the URI in the From header field must always be the same as the URI in the To header field of the dialog-forming request (see 12.2.1.1/[SIP]). Because of Elwell Expires - April 2006 [Page 4] Connected Identity in SIP October 2005 retargeting of the dialog-forming request, the connected identity can differ from the URI in the From header of a request in the reverse direction. Likewise the URI in the From header of a request in the forward direction (the same direction as the dialog-forming request) is unsuitable for providing a changed connected identity, because the From header field must not change. Therefore a new Header known as Connected-URI is defined to convey the connected identity URI. A UA wishing to indicate its connected identity may include a Connected-URI header field in a request. This can be any request issued by a UA in the context of an early or established dialog. An UPDATE request [UPDATE] can be sent for this purpose if there is no other purpose for sending a request at this time. OPEN ISSUE. RFC 3311 talks about circumstances in which an UPDATE request cannot contain an SDP offer, yet does not explicitly talk about the use of UPDATE requests without SDP offers. It needs to be resolved whether an UPDATE request can be used in order to convey Connected-URI even though no SDP offer needs to be sent at the time. If the outcome is that an UPDATE request must contain an SDP offer, then SDP offer will need to be included when sending Connected-URI is sent. An authentication service on the path of a request containing a Connected-URI header field may add a Connected-Identity header field to sign the request on behalf of the domain part of the URI indicated in the Connected-URI header field. This is similar to an Identity header but the signature covers also the Connected-URI header field and certifies that the UAC has credentials that allow it to register as a contact for that URI. To ascertain this the authentication service would normally challenge the UAC to provide digest authentication, unless TLS is used and the UA has already been authenticated on that connection, e.g., by means of a certificate during the TLS handshake or a shared secret used to respond to a challenge at the application layer. The authentication service also adds an Identity-Info header to provide information about the certificate needed to verify the signature. A proxy that provides an authentication service may also add a Connected-URI header field if not already present in a request or replace an existing one. A UAS receiving a request containing a Connected-URI header field and a valid Connected-Identity header field may use the connected identity for any purpose, such as passing to an application or displaying. A UAS receiving a request containing a Connected-URI header field but no Connected-Identity header field should either discard the connected identity or use it with caution. Elwell Expires - April 2006 [Page 5] Connected Identity in SIP October 2005 OPEN ISSUE: Should we also consider the possibility of including a Connected-URI header in a response? An authentication service would be able to add a Connected-Identity header only if has some means of authenticating the UAS. It cannot challenge the UAS, so it would have to rely on other means, e.g., challenging an earlier request on the same TLS transport). This document also specifies a new option tag, connectedID, to indicate support for or requirement for connected identity. OPEN ISSUE. Is this option tag worthwhile? Use of it a Require header field to force the sending of a Connected-URI header field in a reverse request is not particularly secure, since it does not fall within the signature of the Identity header and could be removed by an attacker. Also, even if the UAS provides a Connected-URI header field in a reverse request, there is no guarantee that an authentication service will be available or be prepared to add a signature in the form of a Connected-Identity header field. 3 Connected UA behaviour 3.1 Connected UA at dialog establishing time When a dialog is established, the connected UA is the UA that acts as UAS for the dialog establishing request and returns a 1xx (not 100) or 2xx response. The behaviour below relies on a connected UA knowing its connected URI, i.e., its AoR. Some UAs register as contacts for multiple AoRs. Provided a UA has registered a different contact URI for each AoR it registers for, then it can associate an incoming request with a particular AoR by examining the Request-URI. After sending the first reliable response (1xx or 2xx) to a dialog forming request, a UA MAY send its identity (the connected identity) if the dialog-forming request contained a Supported header field with the connectedID option tag and MUST send its connected identity if the dialog-forming request contained a REQUIRED header field with the connectedID option tag. To send its connected identity the UA MUST include a Connected-URI header field in a mid-dialog request, e.g., an UPDATE request or a (re-)INVITE request. If there is no other reason to send a mid-dialog request, the UA SHOULD send an UPDATE request for this specific purpose. The UA MUST accurately populate the Connected-URI header field with a value corresponding to an identity that it believes it is authorized to claim. It MUST set the URI portion of the header to Elwell Expires - April 2006 [Page 6] Connected Identity in SIP October 2005 match a SIP, SIPS or TEL URI AoR which it is authorized to use in the domain (including anonymous URIs, as described in [Privacy]). Note that [Identity] defines a number of new 4xx response codes, and these in general are applicable also to connected identity. If a UA supports these response codes, it will be able to respond intelligently to Identity-based error conditions. 3.2 Identity change during an established dialog An identity change can occur at a gateway as a result of action in the legacy network beyond the gateway, e.g., call transfer. During an established dialog the gateway can receive updated identity information from the legacy network that prompts it to adopt a revised identity within the SIP network. This can apply to either the UAC or the UAS of the original dialog establishing request. If during a dialog the identity of a UA changes from that which it indicated previously in the From header or Connected-URI header of a request, the UA MAY send its revised identity if it has received from the peer UA a Supported header field with the connectedID option tag and MUST send its revised identity if it has received from the peer UA a Required header field with the connectedID option tag. To send its revised identity the UA MUST included a Connected-URI header field in a mid-dialog request as specified in 3.1. In this case it will frequently be the case that the UA provides its own authentication service and will therefore add a Connected- Identity header field too. Authentication is on the basis of trusting the identity received from the legacy network. 4 Authentication service behaviour The authentication service described here is an extension to that described in [Identity] except that it authenticates the connected identity. As stated in [Identity], the authentication service role can be instantiated by a proxy server or a user agent. Any entity that instantiates the authentication service role MUST possess the private key of a domain certificate, and MUST be capable of authenticating one or more SIP users that can register in that domain. Commonly, this role will be instantiated by a proxy server, since these entities are more likely to have a static hostname, hold a corresponding certificate, and have access to SIP registrar capabilities that allow them to authenticate users in their domain. A proxy wishing to perform the role of authentication service for a dialog must record-route during dialog establishment, so that mid- dialog requests pass through it. Elwell Expires - April 2006 [Page 7] Connected Identity in SIP October 2005 The behaviour described below applies only to requests containing a Connected-URI header field received in the context of an early or established dialog. Otherwise the authentication service behaviour of [Identity] is applicable (i.e., an Identity header will be added, if applicable). A SIP entity that acts as an authentication service MUST add a Date header field to SIP requests if one is not already present. Similarly, an authentication service MUST add a Content-Length header field to SIP requests if one is not already present; this can help the verifier to double-check that it is hashing exactly as many bytes of message-body as the authentication service when it verifies the message. An entity instantiating the authentication service role performs the following steps, in order, to generate a Connected-Identity header for a SIP request: Step 1: The authentication service MUST extract the identity of the sender from the request. The authentication service takes this value from the Connected-URI header field; this AoR will be referred to here as the 'identity field'. If the identity field contains a SIP or SIPS URI, the authentication service MUST extract the hostname portion of the identity field and compare it to the domain(s) for which it is responsible. If the identity field uses the TEL URI scheme, the policy of the authentication service determines whether or not it is responsible for this identity; see Section 12 of [Identity] for more information. If the authentication service is not responsible for the identity in question, it SHOULD process and forward the request normally, but it MUST NOT add a Connected- Identity header; see below for more information on authentication service handling of an existing Connected-Identity header. Step 2: The authentication service MUST determine whether or not the sender of the request is authorized to claim the identity given in the connected identity field. In order to do so, the authentication service MUST first authenticate the sender of the message. Authentication and authorization considerations are as described in authentication service behaviour step 2 in [Identity]. If the authentication service is unable to authorise the connected identity it MUST reject the request with a 403 response. Step 3: The authentication service SHOULD ensure that any pre- existing Date header in the request is accurate, in accordance with authentication service behaviour step 3 in [Identity]. Step 4: The authentication service MUST form the connected identity signature and add a Connected-Identity header to the request containing this signature. After the Connected-Identity header has Elwell Expires - April 2006 [Page 8] Connected Identity in SIP October 2005 been added to the request, the authentication service MUST also add an Identity-Info header. The Identity-Info header contains a URI from which its certificate can be acquired. Details on the generation of both of these headers are provided in section 6. Finally, the authentication service MUST forward the message normally. 5 Verifier behaviour This document extends the logical role for SIP entities called a 'verifier', as introduced in [Identity]. When a verifier receives a SIP request in the context of an early or established dialog and containing a Connected-Identity header, it may inspect the signature to verify the identity of the sender of the message. Typically, the results of a verification are provided as input to an authorization process which is outside the scope of this document. If neither an Identity header field nor a Connected-Identity header field is present in a request, and one is required by local policy (for example, based on a per-sending-domain policy, or a per-sending-user policy), then a 428 'Use Identity Header' response MUST be sent, which should be interpreted in this case as 'Use Identity header or Connected-Identity header, as appropriate'. In order to verify the identity of the sender of a message containing a Connected-Identity header field together with Connected-URI and Identity-Info header fields, an entity acting as a verifier MUST perform the following steps, in the order here specified. Step 1: The verifier MUST acquire the certificate for the signing domain as described in verifier behaviour step 1 in [Identity]. Step 2: The verifier MUST compare the identity of the signer with the domain portion of the URI in the Connected-URI header field using the method described in verifier behaviour step 2 of [Identity]. Step 3: The verifier MUST verify the signature in the Connected- Identity header field, following the procedures for generating the hashed digest- string described in Section 6. If a verifier determines that the signature on the message does not correspond to the reconstructed digest-string, then a 428 'Invalid Identity Header' response MUST be returned. Step 4: The verifier MUST validate the Date, Contact and Call-ID headers the manner described in Section 14.1 of [IDENTITY]; recipients that wish to verify Connected-Identity signatures MUST support all of the operations described there. Elwell Expires - April 2006 [Page 9] Connected Identity in SIP October 2005 The verifier function is normally located at the UAS of a mid-dialog request. The UA SHOULD render the connected identity and its validity to the user through an appropriate user interface or to an application. A UA MAY also make use of a Connected-URI header field that is not accompanied by a Connected-Identity header field, i.e., an unsigned connected identity, in which case the UA SHOULD distinguish unsigned connected identities from signed connected identities when rendering the information to a user or application. In order to have the possibility of receiving connected identity, a UA MUST include the connectedID option tag in a Supported or Required header field in a SIP message towards the peer UA, e.g., in the dialog-forming request. Use of this option tag in a Required header will cause the request to fail if connected identity is not supported and will cause the Connected-URI to be returned in a request in the reverse direction if connected identity is supported at the UAS. However, although the return of a Connected-URI header can be forced using this mechanism, this does not guarantee that it will be accompanied by a Connected-Identity header field, which will depend on the presence of an authentication service on the path and the ability of the authentication service to authenticate the sender. 6 Header syntax This document specifies two new SIP headers: Connected-URI and Connected-Identity. Each of these headers can appear only once in a SIP message. The grammar for these two headers is: Connected-URI = "Connected-URI" HCOLON ( name-addr / addr-spec ) Connected-Identity = "Identity" HCOLON signed-connected-id-digest signed-connected-id-digest = LDQUOT 32LHEX RDQUOT The signed-connected-id-digest is a signed hash of a canonical string generated from certain components of a SIP request. It is identical to signed-identity-digest in [Identity] except that in the canonical string instead of the addr-spec of the From header field the addr- spec of the Connected-URI header field MUST be used. This document adds the following entries to Table 2 of [SIP]: Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- Connected-URI R r o o - o o - SUB NOT REF INF UPD PRA --- --- --- --- --- --- - o o o o o Elwell Expires - April 2006 [Page 10] Connected Identity in SIP October 2005 Header field where proxy ACK BYE CAN INV OPT REG ------------ ----- ----- --- --- --- --- --- --- Connected-Identity R a o o - o o - SUB NOT REF INF UPD PRA --- --- --- --- --- --- - o o o o o Note, in the table above, only methods that can be used in the context of an early or established dialog are applicable. The CANCEL method is excluded for reasons given in [Identity]. 7 Examples 7.1 Sending connected identity after answering a call. In this example Carol's UA has been reached by retargeting at the proxy and thus her identity (AoR) is not equal to that in the To header field of the received INVITE request (Bob). Carol's UA therefore places a Connected-URI header field in an UPDATE request. The proxy also provides an authentication service and therefore adds a Connected-Identity header field and an Identity-Info header field to the UPDATE request. Alice's UA PROXY Carol's UA INVITE (1) INVITE(2) ----------------> ----------------> 200 (3) 200 (3) <---------------- <---------------- ACK(5) ACK(6) ----------------> ----------------> UPDATE (8) UPDATE (7) <---------------- <---------------- 200 (9) 200 (10) ----------------> ----------------> INVITE (1) and INVITE (2) These include either: Require: connectedID or Supported: connectedID Elwell Expires - April 2006 [Page 11] Connected Identity in SIP October 2005 UPDATE (7) UPDATE sip:ua1@example.com SIP/2.0 From: ;tag=2 To: ;tag=3 Call-ID: 12345600@example.com CSeq: 1 UPDATE Connected-URI: UPDATE (8) UPDATE sip:ua1@example.com SIP/2.0 From: ;tag=2 To: ;tag=3 Call-ID: 12345600@example.com CSeq: 1 UPDATE Connected-URI: Conncected-Identity: "dKJ97..." Identity-Info: ;alg=rsa-sha1 8 IANA considerations This document requests changes to the header fields and option tags registries within the SIP parameters IANA registry. 8.1 Header field names This document specifies two new SIP headers: Connected-URI and Connected-Identity. Their syntax is given in section 6. These headers are defined by the following information, which is to be added to the header sub-registry under http://www.iana.org/assignments/sip-parameters. Header Name: Connected-URI Compact Form: N/A Header Name: Connected-Identity Compact Form: N/A 8.2 SIP option tag This specification registers a new SIP option tag, as per the guidelines in Section 27.1 of RFC 3261. Name: connectedID Description: This option tag is used to identify connected identity and the Connected-URI and Connected-Identity header fields. When used in a Supported header, it indicates support for receiving these header fields and acts as a request to provide this information. When used in a Required header it indicates that the request concerned should be rejected if connected identity information cannot be provided. Elwell Expires - April 2006 [Page 12] Connected Identity in SIP October 2005 9 Security Considerations [Identity] discusses security considerations relating to the Identity header in some detail. Essentially those same considerations apply to the Connected-Identity header. A received Connected-URI header field that is not accompanied by a valid Connected-Identity header field cannot be trusted (except in very closed environments) and should be treated in a similar way to a From header field that is not backed up by a valid Identity header field. A signed connected identity (Connected-URI header field accompanied by a valid Connected-Identity field) provides information about the peer UA in a dialog. In the case of the UA that was the UAS in the dialog-forming request, this identity is not necessarily the same as that in the To header of the dialog-forming request. This is because of retargeting during the routing of the dialog-forming request. A signed connected identity says nothing about the legitimacy of such retargeting, but merely reflects the result of that retargeting. Likewise, when a signed connected identity indicates a change of identity during a dialog, it conveys no information about the reason for such change of identity of its legitimacy. Privacy may be required by the user of a connected UA. To achieve privacy the UA MUST either decline to send the Connected-URI header field or populate it in the way described in [IDENTITY] for the From header field when anonymity is required. Note that if a Require header field has been received with the connectedID option tag, accepting the request but declining to send the Connected-URI header field is not an option, and therefore the UA MUST either decline the request or populate the Connected-URI header field anonymously. 10 Acknowledgements Thanks to Francois Audet, Frank Derks, Steffen Fries and Jon Peterson for providing valuable comments. 11 Author's Addresses John Elwell Siemens Communications Technology Drive Beeston Nottingham, UK, NG9 1LA email: john.elwell@siemens.com Elwell Expires - April 2006 [Page 13] Connected Identity in SIP October 2005 12 Normative References [SIP] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation protocol", RFC 3261. [AIB]J. Peterson, "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893. [Identity] J. Peterson, C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft- ietf-sip-identity-05 (work in progress). [Privacy] J. Peterson, "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323. [UPDATE] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE method", RFC 3311. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, Elwell Expires - April 2006 [Page 14] Connected Identity in SIP October 2005 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. 13 Appendix - Rejected Alternatives (temporary – to be removed) The following alternative solutions were considered and rejected. 13.1 Changing the From header to reflect connected identity [SIP] disallows any change to the From and To header fields during the course of a dialog, since these header fields (along with the Call-Id header field) provide unique identification for a dialog. Although the tag parameters in the From and To header fields are in fact sufficient for dialog identification purposes, for backward compatibility with RFC 2543 changes to the URIs in these header fields are prohibited. It is probable that [SIP]-compliant implementations may break if a URI changes during a dialog. The community has already rejected this approach. 13.2 Conveying the connected identity URI in a body This might have the advantage that the existing Identity header could be used, but this is contrary to the semantics of the Identity header. 13.3 Conveying the connected identity URI and the connected identity signature in the same header field. This has the minor disadvantage that the syntax of the header field would differ from that of the Identity header field. 13.4 Reuse of the Identity header for signing connected identity Elwell Expires - April 2006 [Page 15] Connected Identity in SIP October 2005 The signature in the Identity header basically authenticates the identity in the From header and would not be able to authenticate a different identity (e.g., in a Connected-URI header). 13.5 Response identity Although the proposed solution can under some circumstances provide connected identity in a response, a general solution to response identity is not possible because of the inability to challenge a response to obtain authentication. 13.6 Establishment of a new dialog using Replaces The UA wishing to convey its identity and being unable to do so in the From header field of a request on the existing INVITE-initiated dialog could send a new INVITE request containing a Replaces header field indicating replacement of the existing dialog at the UAS. The From header field of that request would contain the correct identity and could be signed by means of an Identity header in the normal way. There is no normative specification at present covering the fate of the existing session when an existing INVITE-initiated dialog is replaced by a new dialog between the same two UAs. It would be undesirable to interrupt an ongoing session just because the dialog needs to be replaced, particularly if this means the calculation of new security keys for media. The Replaces header is not defined for use in a SUBSCRIBE request, so this technique would not be applicable to SUBSCRIBE-initiated dialogs. It is not clear whether this would matter. This technique would be unsuitable for use on an early dialog, since the replaced dialog might by-pass any proxy that was supervising the early dialog and might wish to cancel it under certain circumstances or take account of any non 2xx final response. This technique would involve additional SIP messages (5, including the BYE request and response on the replaced dialog, rather than 2). Elwell Expires - April 2006 [Page 16]