SIP WG J. Elwell Internet-Draft Siemens plc Expires: December 21, 2006 K. Drage Lucent Technologies June 19, 2006 Analysis of TISPAN requirements for Connected Identity in the Session Initiation Protocol (SIP) draft-elwell-sip-tispan-connected-identity-00.txt 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. This Internet-Draft will expire on December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract ETSI TISPAN has presented Next Generation Network (NGN) requirements for the delivery of two identities for the caller and two identities for the callee in a SIP INVITE-initiated dialog. Although the solution for this in SIP is relatively straightforward for caller identity, the delivery of callee identity presents some additional problems. This document discusses the issues and suggests some Elwell & Drage Expires December 21, 2006 [Page 1] Internet-Draft TISPAN Connected ID June 2006 candidate solutions. This work is being discussed on the sip@ietf.org mailing list. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of the two identities . . . . . . . . . . . . . . . . 3 3. Transporting the two caller identities . . . . . . . . . . . . 3 4. Transporting two callee identities . . . . . . . . . . . . . . 4 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Authentication of connected identity . . . . . . . . . . . 5 5.2. Use of an additional signalling round trip . . . . . . . . 6 5.3. Compatibility with RFC 3261 . . . . . . . . . . . . . . . 7 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Elwell & Drage Expires December 21, 2006 [Page 2] Internet-Draft TISPAN Connected ID June 2006 1. Introduction ETSI TISPAN has presented Next Generation Network (NGN) requirements [4] for the delivery of two identities for the caller and two identities for the callee in a SIP [1] INVITE-initiated dialog. Although the solution for this in SIP is relatively straightforward for caller identity, the delivery of callee identity presents some additional problems. This document discusses the issues and suggests some candidate solutions. 2. Overview of the two identities The first type of identity (ID1) is used by the NGN for billing and authorization purposes (e.g. for the provision of services by the NGN) and therefore must be authenticated by the NGN or a trusted partner. It typically identifies the NGN's customer. The second type of identity (ID2) can be used by the peer user for purposes such as call logging or making return or repeat calls. This too may identify the NGN's customer, or alternatively it may identify a particular user within the customer's domain. A typical case where ID1 and ID2 can differ is where the caller (or callee) is in an enterprise network. ID1 might identify the enterprise, which would be billed for any charges incurred. Although it might be possible to use ID1 for making a return or repeat call, it would lead to a default user, e.g., an attendant. ID2 might identity the particular calling or called user within the enterprise. Neither identity necessarily represents an address back to the terminal or other user equipment making the call, i.e. they are not a GRUU. Neither identity has a rigorously defined usage, and both identities are expected to be presented to the other user. As such both identities are expected to be subject to privacy requirements as detailed in RFC 3323. There are existing solutions to this problem in the ISDN/PSTN and any SIP solution needs to interwork with these ISDN/PSTN mechanisms, both in the enterprise network and in the public network. 3. Transporting the two caller identities TISPAN has chosen the P-Asserted-Identity header [5] for ID1. This follows the equivalent decision made by 3GPP. The NGN identifies and authenticates the customer by some means and then uses that identity Elwell & Drage Expires December 21, 2006 [Page 3] Internet-Draft TISPAN Connected ID June 2006 in the P-Asserted-Identity header to identify the customer to downstream entities in its own network, to other downstream networks and to the downstream user. The From header field URI is used for ID2 and is placed there by the UAC. This is, of course, open to forgery, but it can be authenticated by means of the Identity header [2] added by an authentication service within the caller's domain. If this is added by an enterprise network, the From header field URI and the Identity header can then be delivered to the NGN for delivery unchanged to the UAS. Figure 1 shows an example of this. Use of the From header for this purpose would preclude both TISPAN and 3GPP using the Identity header mechanism for ID1. UAC Enterprise NGN proxy UAS proxy 1 INVITE request 2 INVITE request 3 INVITE request From: ID2 From: ID2 From: ID2 Identity: Identity P-AI: ID1 --------------> -------------> -------------> Figure 1 In 1 the UAC issues the INVITE request with a From header field URI, which will be ID2. In 2 the enterprise proxy adds an Identity header to authenticate the From header field URI (the proxy having authenticated the UAC by some means, e.g., HTTP digest authentication), i.e., to authenticate ID2. In 3 the NGN proxy adds the P-Asserted-Identity header field URI (ID1) based on authentication of the enterprise network by some means (e.g., TLS). Note: 1 could also include a P-Preferred-Identity, but this adds little value in this particular scenario, as the full set of valid P-Asserted-Numbers may well not be known at the UAC in the enterprise network. 4. Transporting two callee identities The same principle can apply to callee (connected) identities. TISPAN. However, whereas TISPAN plans to use the P-Asserted-Identity header in the 2xx response to the INVITE request for ID1, the transport of ID2 is less clear. Three options have been suggested. Elwell & Drage Expires December 21, 2006 [Page 4] Internet-Draft TISPAN Connected ID June 2006 Option 1: Use [3], i.e., send a subsequent request such as UPDATE in the reverse direction containing the ID2 in the From header field URI and the Identity header to provide authentication. Option 2: Use the To header field URI in the 2xx response to provide unauthenticated ID2. Option 3: Use a new header field in the 2xx response to provide unauthenticated ID2. Option 4: Longer term it is possible that SAML could also be used to carry the appropriate assertions about the identities. This work however is still under consideration in the SIP WG and it is too early to assess its applicability 5. Discussion All the proposals above assume that distinct mechanisms are used to transport the multiple identities, and any other identities that are transported directly as headers between the UAC and UAS. No solution has the ability to repeat the header field in order to indicate a different identity with different semantics for generation or assertion. Therefore due consideration has to given to the impact of using a mechanism for one purpose, when other entities on the path wish to use that mechanism for other purposes. There are two key differences between option 1 and the other options: option 1 provides authentication of the identity, and option 1 requires an extra round trip of signalling. Between option 2 and option 3, the issue is compatibility with RFC 3261. These issues are discussed in more detail below. 5.1. Authentication of connected identity Although not laid down as a requirement by TISPAN, authentication of callee ID2 could be of significant value, both to users within the same enterprise network and to users who otherwise have some form of relationship with the enterprise network. Firstly it prevents falsification beyond the bounds of what the NGN is able to guarantee and therefore provides the recipient with greater confidence. Secondly, it may be of use in conjunction with certain key management methods for media encryption. For example, by using the Identity header in both directions, this could provide cryptographic authentication of the source of Diffie-Hellman components used for key agreement. Elwell & Drage Expires December 21, 2006 [Page 5] Internet-Draft TISPAN Connected ID June 2006 Some members of the community are of the opinion that an unauthenticated identity in a response is of little or no value. Therefore option 1 has considerable benefit over options 2 and 3. 5.2. Use of an additional signalling round trip The main issue here is interworking with PSTN. PSTN signalling protocols provide callee ID2 in the same message that indicates answer. This has impact on calls in the direction PSTN to SIP. The PSTN gateway would need to wait for the UPDATE request, as shown in figure 2. UAC Enterprise NGN proxy UAS proxy PSTN Gateway NGN proxy Enterprise 1 Call Request 2 INVITE request 3 INVITE request --------------> -------------> -------------> 5 2xx 4 2xx <------------- <------------- 6 ACK 7 ACK -------------> -------------> 10 Call answer 9 UPDATE request 8 UPDATE request <-------------- <------------- <------------- 11 2xx 12 2xx -------------> -------------> Figure 2 It can be seen that the gateway must wait for the UPDATE request (9), which will contain callee ID2 in the From header field with authentication by means of the Identity header field, before generating the PSTN call answer message (10). This is not a severe problem, unless the UPDATE request fails to arrive, which would happen if the UAS does not support [3]. This could be avoided by defining an option tag indicating support of connected identity and using this tag in the Supported header of the 2xx response to the INVITE request (4)(5) to indicate that an UPDATE request will follow. Further, any solution must also deal with the case where the PSTN gateway does not support this extension. There is no point in the enterprise network sending the subsequent request if the PSTN gateway has no way of handling the Identity header that is included. The INVITE request that initiated the dialog will contain an indication that the gateway supports the UPDATE method, but this will not indicate what applications this can be used for. Consideration should also therefore be given to an option-tag in the INVITE request Elwell & Drage Expires December 21, 2006 [Page 6] Internet-Draft TISPAN Connected ID June 2006 indicating that the gateway is capable of waiting for the UPDATE request and the contained Identity header, and then processing that for use in the ISDN/PSTN 5.3. Compatibility with RFC 3261 Option 2 violates RFC 3261, which does not permit the To header field URI to change in a response (compared with the request). It is not clear what harm would be done by changing the To header field URI. An option tag could be used to ensure support at the UAC, but there is no way to ensure that proxies would not be harmed. Unlike the change of the From header field URI mid-dialog, as specified in [3], the change of To header field URI in a response is not anticipated in RFC 3261. 6. Summary If authentication is considered important, option 1 should be adopted. This probably needs the additional option tag proposed above to improve PSTN interworking. Otherwise option 3 is probably safer than option 2. A further alternative (option 4) would be a hybrid solution, e.g., both option 1 and option 3. Option 3 would be used when option 1 is not available. It could also be used prior to option 1 to avoid the delay in sending the answer signal to the PSTN. However, this would give potential for the authenticated callee ID2 in the UPDATE request to differ from that in the 2xx response to the INVITE request. 7. Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-06 (work in progress), October 2005. [3] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", draft-ietf-sip-connected-identity-00 (work in progress), April 2006. [4] Jesske, R., Alexeitsev, D., and M. Garcia-Martin, "Input Requirements for the Session Initiation Protocol (SIP) in support for the European Telecommunications Standards Elwell & Drage Expires December 21, 2006 [Page 7] Internet-Draft TISPAN Connected ID June 2006 Institute", draft-jesske-sipping-tispan-requirements-o2 (work in progress), October 2005. [5] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, October 2005. Elwell & Drage Expires December 21, 2006 [Page 8] Internet-Draft TISPAN Connected ID June 2006 Authors' Addresses John Elwell Siemens plc Technology Drive Beeston, Nottingham NG9 1LA UK Phone: +44 115 943 4989 Email: john.elwell@siemens.com Keith Drage Lucent Technologies Optimus, Windmill Hill Business Park Swindon, Wilts UK Phone: +44 1793 776249 Email: drage@lucent.com Elwell & Drage Expires December 21, 2006 [Page 9] Internet-Draft TISPAN Connected ID June 2006 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 procedures with respect to rights in RFC 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, 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 (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Elwell & Drage Expires December 21, 2006 [Page 10]