SIP WG J. Elwell
Internet-Draft Siemens Enterprise Communications
Intended status: BCP October 1, 2008
Expires: April 4, 2009
Identity Handling at a Session Initiation Protocol (SIP) User Agent
draft-elwell-sip-identity-handling-ua-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 April 4, 2009.
Abstract
Session Initiation Protocol (SIP) User Agents (UA) receive
identifiers for the caller and callee during call establishment.
These identifiers can come in a variety of forms, can be delivered by
a variety of means, and may or may not be accompanied by evidence of
authenticity. Furthermore, if media are secured (e.g., using the
Secure Real-Time Protocol, SRTP), the security properties of the
media will depend on binding the media to a received authenticated
identifier. This document examines the various identification
information a UA can receive during call establishment and how a user
agent can use this information to present a caller or callee
identifier to the user and indicate to the user the security
properties of the call, as well as how the user agent might use this
Elwell Expires April 4, 2009 [Page 1]
Internet-Draft Identity Handling at a SIP UA October 2008
information for other purposes, such as authorizing acceptance of a
call.
This work is being discussed on the sip@ietf.org mailing list.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Considerations for caller identifiers received in INVITE
requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Uses of caller identifiers . . . . . . . . . . . . . . . . 4
2.2. Types of URI for caller identifiers . . . . . . . . . . . 5
2.3. Means of delivering caller identifiers . . . . . . . . . . 6
2.4. Reliability of caller identifiers . . . . . . . . . . . . 7
2.5. Message integrity . . . . . . . . . . . . . . . . . . . . 9
2.6. Media security . . . . . . . . . . . . . . . . . . . . . . 10
2.7. Considerations when presenting a received caller
identifier to the user . . . . . . . . . . . . . . . . . . 11
2.8. Considerations for providing a secure call indicator
to the user . . . . . . . . . . . . . . . . . . . . . . . 13
2.9. Considerations for using a received caller identifier
for other purposes . . . . . . . . . . . . . . . . . . . . 14
2.10. Summary of considerations . . . . . . . . . . . . . . . . 15
3. UA best practice for handling received caller identifiers . . 16
4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Security considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. Informative References . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Elwell Expires April 4, 2009 [Page 2]
Internet-Draft Identity Handling at a SIP UA October 2008
1. Introduction
An important aspect of the Session Initiation Protocol (SIP)
[RFC3261] is the delivery of an identifier (in the form of a URI)
representing the source of a request to a User Agent (UA) that
receives the request. In the case of an INVITE request, used to
establish a call, the delivered identifier is taken to represent the
caller's identity. Typically this information is rendered to the
called user in some way. A successful INVITE request results in the
establishment of one or more media sessions. Usually the identified
caller is also taken to be the source of any received media and the
sink of any transmitted media.
Unfortunately, unless proper security measures are taken, there is
scope for delivering an incorrect caller identifier and misleading
the called user. This can have serious consequences in some
circumstances, where the called user relies on receiving a correct
caller identifier in order to decide whether to accept the call and
how to behave during the call (e.g., in terms of information
disclosed to the caller). Also an incorrect caller identifier can
impact any automated call handling at the UA, e.g., authorising
acceptance of the call. This document specifies best practices for
UAs handling received caller identifiers, taking into account any
evidence as to their authenticity.
Similarly a caller's UA can receive an identifier representing the
user who answers a call, i.e., the callee. The callee identifier,
sometimes known as the connected identifier, may differ from the
target identifier used when establishing the call, e.g., because of
call forwarding. The callee identifier can be received in a request
in the reverse direction on the INVITE-initiated dialog. Although
this document primarily talks about caller identifiers, most of the
considerations apply equally to callee identifiers.
Note that although a response to an INVITE request may be considered
an appropriate vehicle for delivering a callee identifier, security
considerations have so far prevented this being standardised.
SIP also delivers to the UA the source identifier of non-INVITE
requests outside the context of an INVITE-initiated dialog. Some of
these, such as MESSAGE requests, result in information being rendered
to the user, and here too a reliable source identifier can be
important to the user. Some requests (such as SUBSCRIBE requests) do
not necessarily result in rendering anything to the user, but still
the source identifier may be important to the UA, e.g., for
authorizing acceptance of the request. Considerations for other
requests are similar to those for INVITE requests, with the exception
that there are no media streams established.
Elwell Expires April 4, 2009 [Page 3]
Internet-Draft Identity Handling at a SIP UA October 2008
OPEN ISSUE. Do we need anything else on non-INVITE requests, later
in the document?
2. Considerations for caller identifiers received in INVITE requests
2.1. Uses of caller identifiers
A UA can make use of caller identifier in a number of ways, for
example:
o for rendering to the user during alerting and during the answered
call (e.g., by means of a display);
o for inclusion in an entry in a call log of missed or answered
calls;
o for making a return call to the caller;
o for authorizing receipt of an incoming call (e.g., by checking
against a white list or black list);
o for look-up in a phone book in order to obtain and render to the
user more information about the caller (e.g., name, customer
number, picture);
o for deciding whether the call requires special treatment, e.g.,
redirecting.
For all of these the authenticity of the caller identifier is
important, and for some uses it is particularly important. For
example, it is particularly important for checking against a white
list. Although an unauthenticated identifier could still be rendered
to the user, in doing so it would need to be made clear to the user
that the identity is not to be relied on.
Similarly a caller can make use of a callee identifier in a number of
ways, e.g.:
o for rendering to the user during the call;
o for inclusion in an entry in a call log of outgoing calls;
o for making a repeat call to the callee.
This information is particularly useful when the callee (the
answering user) is not the anticipated user, as a result of the call
undergoing forwarding, for example. The authenticity of the callee
Elwell Expires April 4, 2009 [Page 4]
Internet-Draft Identity Handling at a SIP UA October 2008
identifier might also be important for some purposes.
2.2. Types of URI for caller identifiers
SIP normally delivers the following types of URI:
o type 1 - a telephone number in a TEL URI (e.g., tel:+123456789);
o type 2 - a telephone number and a domain name in a SIP or SIPS URI
(e.g., sip:+123456789@example.com;user=phone); or
o type 3 - a SIP or SIPS URI not containing a telephone number
(e.g., sip:alice@example.com).
Type 1 can be subdivided according to whether the telephone number is
global E.164 number (type 1a), as denoted by a '+' before the number,
or significant only within a certain context (type 1b). For a type
1b identifier, the TEL URI will contain a phone-context parameter.
Type 2 identifiers are marked as such by user=phone parameter in the
SIP or SIPS URI, in which case the user part of the URI is a
telephone subscriber string, as for a TEL URI. In this case type 2
identifiers can be subdivided according to whether the telephone
number is global (type 2a) or significant only within a certain
context (type 2b). For a type 2b identifier, the telephone
subscriber string will contain a phone-context parameter.
Type 3 identifiers lack a user=phone parameter. The user part is
often not numeric, and this type of identifier is sometimes referred
to as email-style.
Sometimes the user part of a type 3 identifier can be numeric, in
which case often it can represent a phone number and often it is
interpreted by a recipient as representing a phone number. In the
absence of a phone-context parameter associated with the number, the
context is given by the domain part, although the use of "+" in front
of a number by convention tends to mean it is a global E.164 number.
This is a grey area. Strictly speaking such URIs should be treated
as type 3, but in practice they are often treated as type 2. For the
purposes of this document they are treated as type 3.
For type 1 identifiers, the only information is the telephone number,
plus the context in the case of type 1b. The number (plus the
context in the case of type 1b) should be rendered to the user and/or
used for other purposes by the UA.
For type 2 identifiers, the domain part might also be significant.
In theory, given the presence of a user=phone parameter, the user
Elwell Expires April 4, 2009 [Page 5]
Internet-Draft Identity Handling at a SIP UA October 2008
part alone (including phone context in the case of type 2b) is
globally unique. However, the domain part might still be useful
information. For example, a user who does not recognise the number
might recognise the domain name. Note that the domain part does not
necessarily imply that the number is owned by that domain, but it
does mean that the number is meaningful within that domain and that
the user of that number is reachable via that domain. Where a phone-
context parameter is present, this may or may not be redundant
information (i.e., it could indicate the same domain that is in the
domain part).
Herein lies a potential problem, however. It is sometimes the
practice of intermediaries to change the domain part of a type 2
identifier to their own domain name. Since the user part is globally
unique, this apparently does no harm. Effectively it says that, by
routing through my domain, you can reach the identified user.
However, this reduces the value of a type 2 URI received by a UA.
For example, if all requests arrive via the user's service provider
and that service provider always substitutes its own domain name, the
UA and its user will always receive the same domain name and will not
receive the original domain name. This renders the domain part of a
type 2 identifier useless.
For type 3 identifiers, the user part alone is not significant, even
if it might look like a telephone number. A UA must always take the
domain part into account when rendering to a user and for other
purposes.
Although URI schemes other than TEL, SIP and SIPS can be encountered,
this is unusual and is not considered further in this document.
2.3. Means of delivering caller identifiers
SIP provides 3 ways of delivering the source of a request and hence
the caller identifier.
o the From header field;
o the P-Asserted-Identity header field [RFC3325];
o an S/MIME [RFC3851] body part known as Authenticated Identity Body
(AIB) [RFC3893].
As S/MIME has not seen any deployment in SIP, the last of these
methods in practice is not available, even though it would provide an
authenticated identifier. A major obstacle is the need for UAs to
have PKI-based certificates. Therefore in practice the options are
the From header field and the P-Asserted-Identity header field. In
Elwell Expires April 4, 2009 [Page 6]
Internet-Draft Identity Handling at a SIP UA October 2008
many cases a UA may receive both.
There may also be an Identity header field [RFC4474] providing a
signature over the From header field URI and other parts of the
message (this technique being known as SIP Identity).
A UA can receive more than one caller identifier: up to two
identifiers can be received in P-Asserted-Identity (one TEL URI
and/or one SIP or SIPS URI) and one identifier can be received in
From (a TEL, SIP or SIPS URI). The choice of which to use is not a
straightforward decision. It will be influenced by the extent to
which each received identifier is trusted. There can be grounds for
making use of more than one received identifier.
Similar mechanisms can be used to deliver the callee identifier in a
request in the reverse direction. Doing this using the From and
Identity header fields is specified in [RFC4916]. Note that, other
than S/MIME, there is currently no available mechanism for delivering
an authenticated identity in a response.
An identifier delivered in a From or P-Asserted-Identifier header
field can be accompanied by a "display-name" field giving further
information about the caller, typically the name.
2.4. Reliability of caller identifiers
The From header field is always present in a request (even though it
might be anonymised), and hence a URI is always available (except
that it could be a special URI denoting anonymity). Without a valid
signature in an Identity header field, the From URI is easily forged,
either by the UAC or by an intermediary. Thus an unsigned From URI
is the least trustworthy of the caller identifiers that can be
received.
If accompanied by an Identity header field containing a valid
signature signed using a certificate whose certification authority
(or chain of certification authorities) is trusted, a far higher
degree of trust can be placed in the From URI. The request is known
to have come from the signing domain (the domain in the From URI),
and, if that domain can be trusted, the request is known to have come
from the entity identified in the user part of the From URI. The
From URI can only be a SIP or SIPS URI in this case, not a TEL URI.
The signature does not cover the display-name part of the From header
field, and therefore the display-name cannot be relied upon.
A P-Asserted-Identity URI is asserted by the last proxy. This
assertion may be on the basis of an assertion by the previous proxy,
and so on. Therefore it relies on transitive trust. Moreover, an
Elwell Expires April 4, 2009 [Page 7]
Internet-Draft Identity Handling at a SIP UA October 2008
entity should trust its next upstream entity only if the SIP message
is delivered over a secure transport (e.g., TLS). Even though a UA
may trust its inbound proxy, it generally has no idea what further
proxies and domains upstream have been involved in delivering the
request and whether secure transport has been used on all signalling
hops. Even if a received request has been delivered over TLS and has
a SIPS Request-URI, the UA can never be sure that a secure transport
has been used on all signalling hops, as explained in
[I-D.ietf-sip-sips]. This transitive trust model is designed for use
only in closed environments where all involved entities can be
trusted, but as those environments open up to accepting traffic from
other domains, the model breaks down. Consequently, a P-Asserted-
Identity URI is generally less trustworthy than a signed From URI,
but more trustworthy than an unsigned From URI.
Furthermore, although a P-Asserted-Identity header field can contain
a display-name, the assertion strictly speaking covers only the URI,
and therefore the display-name is even less trustworthy than the URI.
Verifying a SIP Identity header field is not a simple matter,
involving steps such as fetching the certificate (if not already
cached), verifying the certification chain and performing the
cryptographic operations. Often this job is done by the inbound
proxy, which can then insert a P-Asserted-Identity header field to
assert the identifier that it has just verified in the From header
field. If this procedure has taken place, there may be grounds for
placing a higher level of trust in the P-Asserted-Identity URI, but
how does the UA know that this has taken place? One possibility
would be for the inbound proxy always to remove invalid Identity
header fields, so that on receipt of request containing an Identity
header field the UA can assume that it has been verified by the
inbound proxy (assuming the request can be shown to have arrived via
the inbound proxy).
Similar considerations apply to callee identifiers.
Additional considerations arise for calls from PSTN via a gateway.
The gateway cannot authenticate the caller or callee identifier
received from the PSTN, and strictly speaking should not assert such
an identifier using P-Asserted-Identity or SIP Identity. It can, of
course, assert its own identity, e.g.:
sip:gateway1@example.com
By asserting:
sip:+123456789@example.com;user=phone
Elwell Expires April 4, 2009 [Page 8]
Internet-Draft Identity Handling at a SIP UA October 2008
it at least makes it clear that the call has been delivered via
example.com, but example.com cannot have claimed to have
authenticated the telephone number. Unfortunately there is no
mechanism available at present whereby the UA can know that such an
assertion is being made by a PSTN gateway. An assertion of:
tel:+123456789
is even more misleading, since it does not even convey a domain name.
Unfortunately assertions of telephone numbers by PSTN gateways is
common practice. This undermines the reliability of caller
identifiers based on telephone numbers (identifier types 1 and 2).
2.5. Message integrity
There is limited benefit in trusting the source identifier of a SIP
request if other parts of the message could have been tampered with
en route. In particular, for an INVITE request conveying a Session
Description Protocol (SDP) offer, modifying the SDP can benefit an
attacker, e.g., by forcing all media to terminate at a device chosen
by the attacker rather than the device that has originated the
request, by downgrading security capabilities(e.g., removing any
option of using SRTP) or by downgrading a codec (e.g., to one that
makes breaking SRTP encryption easier).
The Identity header field signature provides integrity protection
over a considerable part of a request, including the entire body (and
therefore any SDP body part) and certain the header fields, but
omitting header fields that normally would be changed by proxies
(e.g., Via, Record-Route) and header fields of lesser importance
(e.g., Call-Info, User-Agent). Also the display-name part of the
From header field is omitted from the signature. By including the
Date, Call-Id and CSeq header fields in the signature, a measure of
protection against replay attack is also provided.
It has been argued that the Identity header field signs too much, and
does not cater for the legitimate needs of B2BUAs (such as session
border controllers, SBCs) that need to perform media steering (e.g.,
to force media onto a high quality route) and therefore need to alter
IP addresses and ports in SDP. Also B2BUAs often change the Call-Id,
CSeq and Contact header fields. This may prevent the deployment of
SIP Identity in certain environments. In the absence of any solution
to this at present, this document assumes SIP Identity, as specified
in [RFC4474], as the means for delivering an authenticated caller
identifier along with message integrity protection.
Elwell Expires April 4, 2009 [Page 9]
Internet-Draft Identity Handling at a SIP UA October 2008
Note that one work-around could be for B2BUAs that break the
Identity header field signature in this way to re-sign the
request, but this would no longer provide end-to-end integrity
protection and authentication. Also it would involve using the
B2BUA's own domain certificate, and since the domain name in the
certificate must match that in the domain part of the SIP/SIPS URI
(according to [RFC4474]), this might involve changing the domain
part of the SIP/SIPS URI, which is possible only if the user part
is globally unique (as, for example, in the case of a fully
qualified E.164 number).
In the absence of the Identity header field, message integrity
protection is achievable only on a hop-by-hop basis, by using a
secure transport (e.g., TLS) on each hop. Even if a received request
has been delivered over TLS and has a SIPS Request-URI, the UA can
never be sure that a secure transport has been used on all signalling
hops. Also it cannot be sure that a malicious intermediary has not
altered parts of the message that should not have been altered.
P-Asserted-Identity provides no form of message integrity protection,
but instead relies on hop-by-hop assertions that integrity has not
been compromised.
2.6. Media security
Knowing that a SIP INVITE request comes from a given user is not
particularly useful unless the recipient can be sure that media it
transmits and receives is transported to and from that same user. To
some extent the use of SIP Identity helps, because it provides
integrity protection over ports and IP addresses in SDP. However,
that does not help against attacks that spoof IP addresses or
intercept media. Often the user's needs are met only by
authentication, integrity protection and encryption of media. For
the purposes of this document, only real-time media (e.g., audio,
video) transported over the Real-time Transport Protocol (RTP)
[RFC3550] are considered, but similar considerations apply to other
types of media. With RTP, these security properties can be obtained
using the Secure Real-time Transport Protocol (SRTP) [RFC3711].
In order to use SRTP, a security context, including master keys and
salts, has to be negotiated between UAs. There are several
standardised ways of doing this, each with various advantages and
disadvantages. The most recent mechanism standardised by the IETF
(and having superior security properties compared with earlier
mechanisms) is based on Datagram TLS (DTLS) [RFC4347] and is known as
DTLS-SRTP [I-D.ietf-sip-dtls-srtp-framework]. With DTLS-SRTP,
authentication of the SRTP streams depends on mutual authentication
of the UAs during the DTLS handshake, which agrees the security
Elwell Expires April 4, 2009 [Page 10]
Internet-Draft Identity Handling at a SIP UA October 2008
context. This in turn depends on certificates held by the UAs.
Although these can be issued by a PKI, deployment of PKI-based
certificates to UAs can be problematic, as already noted (this being
the reason why S/MIME has not been deployed). Self-signed
certificates alone provide no means of authentication, but if used in
conjunction with SIP Identity, they can suffice. This is achieved by
including a fingerprint (hash) of the certificate in SDP, which
therefore gets signed as part of the Identity header field signature
and is therefore integrity protected. This effectively binds the
certificate to the signed From URI, and hence binds the media streams
to that same identifier.
Consequently, a UA using DTLS-SRTP needs to submit a fingerprint of
its own certificate in the SDP it sends, and needs to check the
fingerprint in the SDP it receives to ensure that it matches the
fingerprint of the certificate received during DTLS handshake. If
this check fails (or if any other aspect of DTLS-SRTP negotiation
fails, the media concerned cannot be considered secure.
The calling UA can submit its fingerprint in the SDP offer sent in
the INVITE request. The callee UA can submit its fingerprint in the
SDP answer in a response to the INVITE request, but there is no way
of using the Identity header field in a response. Therefore to
provide authentication and integrity protection, the callee's UA must
send a further SDP offer, including its fingerprint, in a new request
in accordance with [RFC4916]. Until this has been received and
validated, the caller's UA cannot consider the media fully secure.
All this depends on the integrity of the Identity header field
signature being preserved. As observed in Section 2.5, some B2BUAs
(such as SBCs) on the signalling path can alter parts of the request
and hence break the signature in certain circumstances. In such
situations the security properties of the media are diminished.
Additional considerations arise for calls from and to PSTN. Media
security is known about only as far as the gateway. Even if the PSTN
is considered secure, there may be insecure hops beyond the PSTN.
2.7. Considerations when presenting a received caller identifier to the
user
When a UA receives a caller identifier, careful consideration needs
to be given to what information is displayed to the user.
For type 1 identifiers, clearly the telephone number should be
presented, but also the phone-context parameter (if present) could
contain important information.
Elwell Expires April 4, 2009 [Page 11]
Internet-Draft Identity Handling at a SIP UA October 2008
For type 2 identifiers, both the telephone number and the domain
should be presented, because either could be useful to the user.
Also the phone-context parameter (if present) could contain important
information, although it might just duplicate what is in the domain
part.
For type 3 identifiers, both the user part and the domain part should
be presented, because neither is necessarily sufficient on its own.
Note that for type 2 and type 3 identifiers where the domain part
is an IP address, presentation of the IP address is less likely to
be useful.
The user should also be provided with an indication of
trustworthiness, taking into account the considerations in
Section 2.4. For example, an unauthenticated From URI should be
distinguishable from an authenticated From URI. The degree of trust
in a P-Asserted-Identity URI will be a matter of policy. Because it
is impossible to distinguish a call originating from the PSTN, any
identifier based on a telephone number probably has to be treated as
untrusted. However, most users are not aware of the implications of
security indicators and should not be overloaded by them.
If a display-name is received, the general advice is not to present
it to the user. Presenting an authenticated identifier along with an
unauthenticated display-name would be misleading. A preferred
solution is to obtain a name by phone-book look-up, based on the
received authenticated identifier, and present that. If an
unauthenticated identifier is presented (and indicated as not to be
trusted), little additional harm would arise from also presenting the
display-name.
When a UA receives more than one caller identifier, the choice of
which one to present to the user will be influenced by
trustworthiness. Generally the most trustworthy should be chosen.
When two of equal trust are received (e.g., a TEL URI and a SIP URI
in the P-Asserted-Identity header field), there may be grounds for
presenting each (or elements of each), if this is possible, because
either or both could be of use to the user.
Similar considerations apply to callee identifiers.
For a call from or to PSTN via a gateway, it is possible that two
identifiers are delivered: a type 3 URI identifying the gateway (as
a From URI with SIP Identity) and a type 1 or type 2 identifier (as a
P-Asserted-Identifier URI) giving the telephone number received from
the PSTN, e.g.:
Elwell Expires April 4, 2009 [Page 12]
Internet-Draft Identity Handling at a SIP UA October 2008
From: sip:gateway@example.com
P-Asserted-Identity: tel:+123456789
If both are presented to the user, the former could be indicated as a
trusted identifier and the latter as an untrusted identifier.
However, for many users this would be information overload and might
lead to confusion, so careful consideration has to be given to how
such information is presented.
2.8. Considerations for providing a secure call indicator to the user
Users generally regarded calls over the PSTN to be secure, rightly or
wrongly. Only for particularly sensitive applications were
additional end-to-end security measures used. With calls over an IP
network, many more service providers, at both the transport level and
the session level, are potentially involved, and the basic network
infrastructure is inherently insecure. By default, calls must be
regarded as insecure, unless appropriate measures have been taken to
secure both signalling and media. Because many calls will not have
the required security properties, either because measures are not
available or not requested, users need to be made aware of the
security status of a call. This is analogous to accessing web pages
via HTTP or HTTPS, whereby a browser will display a security icon
when HTTPS is used and the server has been satisfactorily
authenticated.
A user interested in the security of a call will not, in general,
understand the difference between signalling and media. The general
expectation is that anything spoken (or transmitted in some other
medium) is delivered to the remote party without eavesdropping or
alteration, that anything heard (or received in some other medium)
has come from the remote party without eavesdropping or alteration,
and that the remote party is as expected. Although in some cases the
user might rely on voice recognition (or face recognition in the case
of video) to ensure that the remote party is as expected, the remote
party might not be known sufficiently for this to happen. For
example, the remote party might be known by name, but not by voice or
sight. As another example, the remote party might not be known by
name, but only by function or affiliation (e.g., an employee of a
particular bank). In these cases, caller identification (or callee
identification) plays an important role (or indeed the only role) in
ensuring that the remote party is as expected.
Therefore, to meet a user's security expectations, real-time media
need to be secured using SRTP (and other media need to be similarly
secured). Also media need to be bound to an authenticated caller (or
callee) identifier. Assuming DTLS-SRTP is used with self-signed
Elwell Expires April 4, 2009 [Page 13]
Internet-Draft Identity Handling at a SIP UA October 2008
certificates for negotiating the security context for SRTP, this
requires the Identity header field to be used to sign the From URI
and the DTLS-SRTP certificate fingerprint. Unless a UA has verified
that DTLS-SRTP is used, that a verified authenticated identifier for
the remote party has been received, and that media are bound to the
signalling and hence to the authenticated identifier, the call should
not be indicated as secure.
A call from PSTN should be indicated as insecure, unless the
presented identifier is clearly that of the gateway rather than that
of the PSTN caller. Where the identifier is based on a telephone
number, the call probably has to be indicated as insecure.
2.9. Considerations for using a received caller identifier for other
purposes
When a UA receives a caller identifier, in addition to presentation
to the user, it can be used for many other purposes, including those
listed in Section 2.1. Whether an identifier is usable for any given
purpose might depend on its trustworthiness. For example, for
authorising acceptance of a call, authenticated identity will be
necessary, whereas for making a return call attempt it might not be
considered necessary.
Some actions might depend on the type of identifier received. For
example, call forwarding might apply to calls from a particular
telephone number or range of telephone numbers (e.g., area code,
country code) or to calls from a particular domain. In the case of a
telephone number, behaviour should probably be independent of whether
the number is received in a type 1 or type 2 identifier. Likewise,
in the case of a domain, behaviour should be independent of whether
the domain is received in a type 2 or type 3 identifier. In
configuring a UA to take special action depending on the received
identifier, account needs to be taken of the different forms in which
the identifier can be received.
Note that certain SIP service provider practices can make things
difficult for a user programming a UA to take account of caller
identifiers. For example, if a UA expects a URI of the form:
sip:+123456789@mybank.example.com;user=phone
and that gets changed by a service provider to:
sip:+123456789@serviceprovider.example.net;user=phone
the UA would not find a match and the desired behaviour would fail to
take place. If the user is able to predict this and program the UA
Elwell Expires April 4, 2009 [Page 14]
Internet-Draft Identity Handling at a SIP UA October 2008
to take account of such aliases, it could be made to work, but this
makes things difficult for the user and won't work when a call
arrives via an unanticipated service provider.
Similarly, if the UA is programmed to take a particular action on
calls from example1.com, this will not work if the domain is changed
to example2.net.
Another issue concerns non-global telephone numbers. Even though a
type 1 or type 2 identifier containing a locally-significant number
should contain a phone-context to make it globally unique, tolerance
of local numbers can be difficult to program at a UA. Generally,
global numbers should be given, although the use of local numbers
within the domain for which they are significant is generally easier
to accommodate. For example, within an enterprise it might be
feasible to use numbers of the form:
sip:6789;phone-context=zone1.example1.com@example1.com;user=phone
within zone 1 of example1.com, but outside that zone it is preferable
to use global numbers.
Some of these considerations apply also to callee identifiers.
2.10. Summary of considerations
A UA can use received caller or callee identifiers for many purposes,
including presentation to the user. A received identifier can take
various forms (type 1, type 2 and type 3), and sometimes more than
one identifier can be received. Furthermore an identifier can be
delivered by various means, including the From and P-Asserted-
Identity header fields. The trustworthiness of an identifier depends
on its type, how it is delivered and, in the case of the From header
field, whether it is accompanied by a valid signature using the
Identity header field. Finally, the media may or may not be secured
using SRTP, and if so the source/destination of media may or may not
be authenticated, based on the binding of media to signalling and
receipt of an authenticated identifier for the signalling.
It is the UA's task to make use of all this information in a
meaningful way (e.g., for purposes such as white list checking,
automatic call handling, phone book look-up, etc.) and somehow
present salient facts to the user. A typical user probably just
wants to know the identity of the caller or callee and whether the
call is secure, although this might be over-simplification of the
true situation and knowledgeable users might want more information
(e.g., similar to what might be obtained by clicking on the padlock
icon on a web browser).
Elwell Expires April 4, 2009 [Page 15]
Internet-Draft Identity Handling at a SIP UA October 2008
3. UA best practice for handling received caller identifiers
OPEN ISSUE. Placeholder for normative statements.
4. IANA considerations
This document requires no IANA actions.
5. Security considerations
Security of caller identifiers, signalling and media are discussed
throughout this document. There are no additional security
considerations.
6. Acknowledgements
Thanks to Kai Fischer and Dan Wing for reviewing the initial draft.
7. Informative References
[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.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893,
Elwell Expires April 4, 2009 [Page 16]
Internet-Draft Identity Handling at a SIP UA October 2008
September 2004.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[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.ietf-sip-dtls-srtp-framework]
Fischl, J., Tschofenig, H., and E. Rescorla, "Framework
for Establishing an SRTP Security Context using DTLS",
draft-ietf-sip-dtls-srtp-framework-03 (work in progress),
August 2008.
[I-D.ietf-sip-sips]
Audet, F., "The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", draft-ietf-sip-sips-08 (work
in progress), February 2008.
Author's Address
John Elwell
Siemens Enterprise Communications
Phone: +44 115 943 4989
Email: john.elwell@siemens.com
Elwell Expires April 4, 2009 [Page 17]
Internet-Draft Identity Handling at a SIP UA October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Elwell Expires April 4, 2009 [Page 18]