Internet DRAFT - draft-elwell-dispatch-identity-reqs
draft-elwell-dispatch-identity-reqs
DISPATCH WG J. Elwell
Internet-Draft Siemens Enterprise Communications
Intended status: Informational V. Pascual
Expires: April 9, 2010 Tekelec
October 6, 2009
Requirements for secure caller identification in the Session Initiation
Protocol (SIP)
draft-elwell-dispatch-identity-reqs-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 April 9, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document examines requirements for secure caller identification
Elwell & Pascual Expires April 9, 2010 [Page 1]
Internet-Draft SIP Secure Caller ID Requirements October 2009
in SIP. Although existing mechanisms exist to achieve this, there
are some known shortcomings or deployment difficulties.
This work is being discussed on the dispatch@ietf.org mailing list.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Caller identification versus sender identification . . . . . . 4
4. Connected user identification . . . . . . . . . . . . . . . . 4
5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Uses of caller identification . . . . . . . . . . . . . . . . 5
7. Forms of caller identification . . . . . . . . . . . . . . . . 6
8. Security of caller identification . . . . . . . . . . . . . . 6
9. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Security considerations . . . . . . . . . . . . . . . . . . . 9
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9
14. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 10
15. Informative References . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Elwell & Pascual Expires April 9, 2010 [Page 2]
Internet-Draft SIP Secure Caller ID Requirements October 2009
1. Introduction
This document examines requirements for secure caller identification
in the Session Initiation Protocol (SIP) [RFC3261]. The primary
purpose of SIP is establishment of a session, or call, between two
users, each represented by a user agent (UA). One UA (the calling
UA) originates the call (on behalf of the calling user or caller) and
the other UA (the called UA) receives the call (on behalf of the
called user or callee). Call establishment is achieved using the SIP
INVITE method. Caller identification is the provision of calling
user identification to the called UA, which can then make it
available to the called user.
Caller identification can be used for many purposes, some of which
require the information to be secure (e.g., not subject to forgery).
SIP already has some mechanisms for achieving caller identification,
and some of these mechanisms can be secure, depending on how they are
deployed. One mechanism uses the From header field, with
authentication provided by the Identity header field (SIP Identity)
[RFC4474]. Alternatively, in trusted environments, the P-Asserted-
Identity header field [RFC3325] can be used. Doubts have been
expressed as to whether these mechanisms are sufficient to address
all requirements for secure caller identification. This document
examines requirements for secure caller identification and secure
connected user identification as a step towards evaluating existing
mechanisms and proposing new or modified mechanisms where
requirements are not yet met.
The importance of secure end-to-end identification is discussed in
more detail in [I-D.elwell-sip-e2e-identity-important].
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This specification defines the following additional terms:
o Sender identification: Identification of the user whose SIP UA
sends a SIP request.
o Caller identification: Identification of the user whose SIP UA
initiates a call by issuing a SIP INVITE request and with which
information is exchanged during that call.
Elwell & Pascual Expires April 9, 2010 [Page 3]
Internet-Draft SIP Secure Caller ID Requirements October 2009
o Connected user identification: Identification of the user whose
SIP UA successfully accepts a call by sending a SIP 200 response
to a SIP INVITE request and with which information is exchanged
during that call.
The other terms and concepts used in this document are consistent
with [RFC3261], [RFC4474] and [RFC4916].
3. Caller identification versus sender identification
Existing SIP mechanisms (SIP Identity and P-Asserted-Identity) serve
the purpose of providing secure identification of the sender of a SIP
request (sender identification). They can be applied to a variety of
request types, including:
o INVITE requests (for initiating a call);
o other dialog-initiating requests (e.g. SUBSCRIBE, REFER);
o mid-dialog requests (e.g., BYE or re-INVITE requests during an
INVITE-initiated dialog, NOTIFY requests);
o stand-alone requests (e.g., MESSAGE, PUBLISH).
Therefore in one sense, caller identification is a particular
instance of sender identification (i.e., the sender of an INVITE
request). However, caller identification is more than that, because
a call comprises not only the signalling messages exchanged between
UAs, but also the media streams established as a result of that
signalling. The average user does not distinguish signalling and
media, and expects caller identification to identify the other party
in the call (i.e., both signalling and media).
4. Connected user identification
A caller sometimes needs to know to which user the call has been
delivered. Because of serial or parallel forking of an INVITE
request, a call can be offered to more than one called UA, perhaps
representing different called users. The call is normally awarded to
the first UA that answers, which might not represent the user that
the caller expected to reach. Identification of the user whose UA
successfully answers a call is known as connected user identification
(often shortened to "connected identity"). This needs to be
delivered to the calling UA securely. An existing mechanism for
achieving secure connected user identification is specified in
[RFC4916] and builds on the SIP Identity mechanism [RFC4474].
Elwell & Pascual Expires April 9, 2010 [Page 4]
Internet-Draft SIP Secure Caller ID Requirements October 2009
5. Scope
There is some overlap between requirements for caller identification
and requirements for sender identification, but this document focuses
on requirements for caller identification. Because there are both
similarities and differences in requirements between caller
identification and sender identification, it may or may not be
possible to use a single mechanism to solve the two problems.
This document also covers requirements for connected user
identification, which are similar to those for caller identification.
6. Uses of caller identification
Caller identification is delivered to the called UA, which can use it
for a number of purposes, for example:
o presentation to the called user;
o access to other information about the caller (e.g., account
details);
o automatic call handling (e.g., rejection of unwanted calls,
forwarding to voice mail, forwarding to another user);
o logging of received and missed calls;
o facilitating the establishment of a return call.
The called user can use this information for a number of purposes,
for example:
o deciding whether to answer a call, ignore a call, reject a call or
cause a call to be forwarded to voicemail or elsewhere;
o deciding how to greet the caller;
o deciding how to behave during the call (e.g., whether it is safe
to disclose sensitive information).
Recognition of the caller by voice or video is clearly an alternative
means of accomplishing the last of these, but only if the called user
knows the caller in person.
Sometimes decisions can be made on the basis of the name, telephone
number or other form of identification of the particular caller, but
on other occasions the caller's affiliation may be of more use. For
Elwell & Pascual Expires April 9, 2010 [Page 5]
Internet-Draft SIP Secure Caller ID Requirements October 2009
example, a called user may not know a particular employee of company
X, but can make useful decisions in the knowledge that the call is
from company X.
Handling of received identification information by a UA and use by a
user is discussed in more detail in
[I-D.elwell-sip-identity-handling-ua].
7. Forms of caller identification
Caller identification, as delivered to the called UA, is in the form
of a SIP (or SIPS) URI or a TEL URI. In practice it is usually a SIP
URI.
A SIP URI can be based on an E.164 telephone number, in which case
the meaning of the domain part is unclear. However, generally the
call will have arrived from or via the indicated domain. If all
calls arriving via the called user's service provider carry that
service provider's domain name, the domain name says nothing about
the origin of the call. The domain part would be far more useful if
it represented the originating domain. This is particularly true if
the called user or called UA does not recognise the particular
telephone number. For example, if caller identification
sip:+123456789@example.com;user=phone
is received, even if the telephone number is not recognised, the fact
that the call has come from the example.com domain might be of use,
but not if all calls arrive via example.com. In some cases the
telephone number alone may be useful and the domain part can be
ignored.
In the case of a SIP URI not based on an E.164 number (e.g., with a
name or private telephone number in the user part) either the domain
part alone or the domain part plus user part might be of use to the
called UA or called user. The user part alone might be of use, but
only if it is fairly unique.
8. Security of caller identification
A user often needs to know whether a call is secure. Typically a
user's expectation is that information (media) cannot be eavesdropped
during a secure call, e.g., anything spoken cannot be overheard by
third parties. Another reasonable expectation is that information
received has not been inserted, removed or modified by a third party.
These expectations imply that the user must know with certainty who
Elwell & Pascual Expires April 9, 2010 [Page 6]
Internet-Draft SIP Secure Caller ID Requirements October 2009
is the other party in the call. Therefore secure caller or connected
user identification plays an important part in determining whether a
call is secure. The need for a visual indication that caller
identification can be trusted is discussed in
[I-D.york-sip-visual-identifier-trusted-identity].
Identification information in a SIP message can be subject to
forgery, unless a trusted entity can assert that the information is
correct. Any assertion must itself be protected against forgery, and
must be accompanied by evidence that the assertion is made by an
entity that possesses secret information (e.g., a private key known
only to the trusted entity or a shared secret known only to the
trusted party and a relying party). The asserting entity has to be
trusted not to disclose the secret information to other parties and
to assert only what it knows to be true.
For example, a user might trust his/her local SIP service provider to
assert the identity of the other user. This is the solution provided
by P-Asserted-Identity, the assertion being secured by using TLS
transport between the local proxy and the UA, the UA having
authenticated the proxy at TLS establishment time. However, if the
remote user is not within the local domain, the local domain must
rely on an assertion from an upstream domain. Depending on how many
domains the call passes through, there could be a chain of assertions
of arbitrary length. The first domain should have based its
assertion on authentication of its user (e.g., using SIP digest
authentication). It is not uncommon for a call to pass through 4
domains (e.g., enterprise 1, service provider 1, service provider 2
and enterprise 2), resulting in a chain of assertions. There can be
more domains in the case of a forwarded call. The UA receiving an
assertion is not aware of the length of the chain or the intermediate
domains whose assertions are being relied upon.
As another example, a user might trust the other user's domain to
assert the identity of that user, this assertion being based on
authentication of the user (e.g., using SIP digest authentication).
Authentication of the asserting domain requires that the UA knows in
advance the expected certificate of that domain or the expected
certification authority (CA) certificate. This is the solution
provided by SIP Identity. The assertion has to pass through any
intermediate domains en route to the validating UA, and this tends to
encounter deployment difficulties. In particular, the common
practice of performing media steering results in changes to SDP at
intermediate domains and breaking the SIP Identity signature.
As yet another example, a UA could initiate some form or return
routability check. For example, on receipt of an INVITE request, the
UA could send a SIP request to the identified calling user or domain.
Elwell & Pascual Expires April 9, 2010 [Page 7]
Internet-Draft SIP Secure Caller ID Requirements October 2009
Trust then is in any intermediate domains to route only to the target
domain or user, and in the target domain or user to reject the
request if it cannot be correlated with an outbound call request.
In all cases, the identified calling or connected user is the user
that the calling or connected UA is acting on behalf of. Whether it
really is that particular user or another person gaining authorised
or unauthorised access to the device cannot be known. It depends on
the user interface provided by the UA (e.g., whether it is password
protected) and user discipline (e.g., not leaving the device
unattended and unlocked, not disclosing the password to others).
This aspect of the problem cannot be solved by protocols and is not
addressed in this document.
9. Requirements
Based on the above discussion, the following requirements can be
identified for secure caller identification. These requirements are
not intended to replace any existing sender identification
requirements for SIP messages outside the context of a call (e.g.,
using the MESSAGE method).
REQ1 - It MUST be possible to ensure that sensitive information sent
and received during a call cannot be eavesdropped by a third party
(confidentiality) and assert such a property to a caller or called
user.
REQ2 - It MUST be possible to ensure that information sent and
received during a call is not inserted, modified or deleted by a
third party (integrity) and assert such a property to a caller or
called user.
REQ3 - It MUST be possible to provide a called user with verified
information identifying the party to which information is sent and
from which information is received during a call (authenticated
caller identification).
REQ4 - It MUST be possible for a called user to receive caller
identification that includes the calling user's domain and the
calling user's name or telephone number within that domain.
REQ5 - It MUST be possible for a called UA to receive an assertion
from the calling user's domain that the call originates in that
domain and that caller identification is correct, based on that
domain having authenticated the calling UA.
REQ6 - It MUST be possible for a called UA to verify such an
Elwell & Pascual Expires April 9, 2010 [Page 8]
Internet-Draft SIP Secure Caller ID Requirements October 2009
assertion based on a trust anchor, such as a CA certificate.
REQ7 - It MUST be possible to bind the source and sink of secure
media (e.g., using SRTP or TLS) to an asserted caller identification.
REQ8 - It MUST be possible to bind sensitive end-to-end information
sent by the calling UA in call-related SIP messages to an asserted
caller identification.
REQ9 - The solution MUST work when a call traverses multiple domains,
including cases where domains perform media steering.
REQ10 - It MUST be possible for a calling user to receive connected
user identification meeting corresponding requirements to those above
for caller identification.
REQ11 - The resulting mechanisms MUST be backward compatible with
[RFC3261].
10. IANA considerations
This document requires no IANA actions.
11. Security considerations
Authentication of parties involved in a call is an essential part of
this document and is fully discussed in the preceding sections.
There are no other security considerations.
12. Acknowledgements
The authors were motivated to write this document by the extensive
discussions on the subject in the former SIPPING Working Group and
more recently in the DISPATCH Working Group.
13. Open Issues
This current draft does not address PSTN interworking, where clearly
considerations are very different.
This current draft does not address 3PCC situations.
Does anything need to be said about the special requirements of
conferences?
Elwell & Pascual Expires April 9, 2010 [Page 9]
Internet-Draft SIP Secure Caller ID Requirements October 2009
14. Change log
-00 New document.
-01 Shortening of Introduction and moving remaining material into
separate sections. Additional requirements. Change to requirement
concerning multiple domains. Minor changes.
15. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] 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.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007.
[I-D.elwell-sip-e2e-identity-important]
Elwell, J., "End-to-End Identity Important in the Session
Initiation Protocol (SIP)",
draft-elwell-sip-e2e-identity-important-03 (work in
progress), February 2009.
[I-D.elwell-sip-identity-handling-ua]
Elwell, J., "Identity Handling at a Session Initiation
Protocol (SIP) User Agent",
draft-elwell-sip-identity-handling-ua-00 (work in
progress), October 2008.
[I-D.york-sip-visual-identifier-trusted-identity]
York, D., "The Importance of a Visual Identifier of
Trusted Identity",
draft-york-sip-visual-identifier-trusted-identity-01 (work
in progress), November 2008.
Elwell & Pascual Expires April 9, 2010 [Page 10]
Internet-Draft SIP Secure Caller ID Requirements October 2009
Authors' Addresses
John Elwell
Siemens Enterprise Communications
Phone: +44 1908 855608
Email: john.elwell@siemens-enterprise.com
Victor Pascual Avila
Tekelec
Am Borsigturm 11
Berlin
Germany
Email: victor@iptel.org
Elwell & Pascual Expires April 9, 2010 [Page 11]
