SIP WG J. Elwell
Internet-Draft Siemens plc
Expires: December 28, 2006 K. Drage
Lucent Technologies
R. Jesske
Deutsche Telekom
June 26, 2006
Analysis of TISPAN requirements for Connected Identity in the Session
Initiation Protocol (SIP)
draft-elwell-sip-tispan-connected-identity-01.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 28, 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
Elwell, et al. Expires December 28, 2006 [Page 1]
Internet-Draft TISPAN Connected ID June 2006
identity, the delivery of callee identity presents some additional
problems. This document discusses the issues and suggests some
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 . . . . . . . . . . . . 4
4. Transporting two callee identities . . . . . . . . . . . . . . 5
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Authentication of connected identity . . . . . . . . . . . 6
5.2. Use of an additional signalling round trip . . . . . . . . 6
5.3. Compatibility with RFC 3261 . . . . . . . . . . . . . . . 8
6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Elwell, et al. Expires December 28, 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.
An example application of the use of two identities is if a user
calls a special hotline for e.g., computer services on +496151830.
This is the main number of a PBX with several extensions. The user
will eventually be connected to a service expert, say on extension
no: +496151835940. So now there is an ID1 (+496151830) that
identifies the PBX, is trusted by the public network and to which all
Elwell, et al. Expires December 28, 2006 [Page 3]
Internet-Draft TISPAN Connected ID June 2006
billing is bound. In addition there is an ID2 identifying the
expert, which is useful information for the caller.
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
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.
Elwell, et al. Expires December 28, 2006 [Page 4]
Internet-Draft TISPAN Connected ID June 2006
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.
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
Option 5: Use of a header parameter within an existing identity, for
example in the Contact header. However it is assumed that any such
header parameter must be covered by the scope of the header itself,
and ID2 is an address of record, whereas the Contact header describes
the current URI of the UA. This option is therefore not considered
further.
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.
Forking has been mentioned as an issue to be considered for the
Elwell, et al. Expires December 28, 2006 [Page 5]
Internet-Draft TISPAN Connected ID June 2006
delivery of ID2. However, if ID2 is provided only within or after
the 2xx final response, no complications with regard to forking are
expected.
5.1. Authentication of connected identity
There is no requirement from TISPAN to provide an authenticated ID2,
because the service provided by TISPAN is based on the so-called
special arrangement from PSTN. This is an arrangement between a
customer and an operator/service provider whereby a customer-supplied
ID2 is not screened by the operator's/service provider's network.
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.
Nevertheless ID1 as an authenticated identity gives enough
information to reach the responsible NGN customer (e.g., switchboard)
and might be considered sufficient.
Secondly, authentication of ID2 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 or the source of a self-signed
certificate used as the basis for encrypted key exchange.
Some members of the community are of the opinion that an
unauthenticated identity in a response is of little or no value.
Other members of the community, including TISPAN, do not see this
value in an unauthenticated callee ID2.
The benefit of option 1 over options 2 and 3 therefore depends on
one's view of the need for authentication.
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.
Elwell, et al. Expires December 28, 2006 [Page 6]
Internet-Draft TISPAN Connected ID June 2006
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.
But nevertheless the call procedure at the PSTN/ISDN gateway will be
delayed and could cause problems on answering the call in a given
timeframe.
If a reliable provision response had been sent to the INVITE request,
then the UPDATE request can be sent before the 2xx response. This
obviously does not provide a solution where the 2xx response is sent
immediately by the destination user.
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
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
Seen from the UA perspective, additional procedures must be
implemented. This might mean implementing the UPDATE method, if not
Elwell, et al. Expires December 28, 2006 [Page 7]
Internet-Draft TISPAN Connected ID June 2006
supported for other reasons. However, there are several other
reasons for implementing the UPDATE method (e.g., session timer,
early session, ICE), so this might not be significant in practice.
Options 2 and 3 are less complex compared with option 1 (using an
additional roundtrip) and option 4 (using SAML). Option 3 adds a
further identity header to SIP.
5.3. Compatibility with RFC 3261
Different opinions have been expressed as to whether option 2
violates RFC 3261, which does not clearly say whether the To header
field URI may change in a response (compared with the request). It
is not clear what harm would be done by changing the To header field
URI, and whether such harm would be to fully compliant SIP
implementations or only to non-compliant SIP implementations. 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 mentioned 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 options 2 and 3 are technically less complex.
A further alternative would be a hybrid solution, e.g., both option 1
and either option 2 or option 3. Option 2 or 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.
Elwell, et al. Expires December 28, 2006 [Page 8]
Internet-Draft TISPAN Connected ID June 2006
[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
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, et al. Expires December 28, 2006 [Page 9]
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
Roland Jesske
Deutsche Telekom
Deutsche-Telekom-Allee 1
Darmstadt,
Germany
Phone: +49 6151 835940
Email: r.jesske@t-com.net
Elwell, et al. Expires December 28, 2006 [Page 10]
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, et al. Expires December 28, 2006 [Page 11]