One document matched: draft-elwell-sip-e2e-identity-important-03.txt
Differences from draft-elwell-sip-e2e-identity-important-02.txt
SIP WG J. Elwell
Internet-Draft Siemens Enterprise Communications
Intended status: Informational February 25, 2009
Expires: August 29, 2009
End-to-End Identity Important in the Session Initiation Protocol (SIP)
draft-elwell-sip-e2e-identity-important-03.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 August 29, 2009.
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 surveys existing mechanisms in the Session Initiation
Protocol (SIP) for identifying and authenticating the source of a SIP
request (or caller identification). It describes how identification
Elwell Expires August 29, 2009 [Page 1]
Internet-Draft End-to-End Identity Important February 2009
and authentication are not always end-to-end and the problems that
this can lead to, particularly since media security based on
techniques such as DTLS-SRTP is dependent on end-to-end authenticated
identification of parties.
This work is being discussed on the sip@ietf.org mailing list.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of existing mechanisms and their shortcomings . . . . 6
3.1. The From header field URI . . . . . . . . . . . . . . . . 6
3.2. The P-Asserted-Identity (PAI) header field . . . . . . . . 6
3.3. Authenticated Identity Body (AIB) . . . . . . . . . . . . 7
3.4. SIP Certs . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5. SIP Identity . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Return routability checks . . . . . . . . . . . . . . . . 9
3.7. Problems with SIP URIs based on E.164 numbers . . . . . . 9
3.8. Other causes of URI change at intermediate domains . . . . 10
3.9. Problems with PSTN interworking . . . . . . . . . . . . . 10
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Example 6 . . . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Example 7 . . . . . . . . . . . . . . . . . . . . . . . . 14
4.8. Example 8 . . . . . . . . . . . . . . . . . . . . . . . . 15
4.9. Example 9 . . . . . . . . . . . . . . . . . . . . . . . . 15
4.10. Example 10 . . . . . . . . . . . . . . . . . . . . . . . . 16
4.11. Example 11 . . . . . . . . . . . . . . . . . . . . . . . . 16
4.12. Example 12 . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Why end-to-end identification is important . . . . . . . . . . 17
6. Why end-to-end authenticated identification is important . . . 19
7. Why B2BUAs break SIP Identity signatures . . . . . . . . . . . 20
7.1. Changing the SDP body part . . . . . . . . . . . . . . . . 20
7.2. Changing the Contact and Call-Id header fields . . . . . . 21
7.3. Changing the From URI . . . . . . . . . . . . . . . . . . 21
7.4. Changing the To URI . . . . . . . . . . . . . . . . . . . 22
7.5. Protocol repair . . . . . . . . . . . . . . . . . . . . . 22
8. Analysis of changes to SIP requests by B2BUAs . . . . . . . . 23
8.1. addr-spec of From header field . . . . . . . . . . . . . . 23
8.2. addr-spec of To header field . . . . . . . . . . . . . . . 24
8.3. call-id of Call-Id header field and digit of CSeq
header field . . . . . . . . . . . . . . . . . . . . . . . 24
Elwell Expires August 29, 2009 [Page 2]
Internet-Draft End-to-End Identity Important February 2009
8.4. method of CSeq header field . . . . . . . . . . . . . . . 25
8.5. Date header field . . . . . . . . . . . . . . . . . . . . 25
8.6. addr-spec of Contact header field . . . . . . . . . . . . 25
8.7. SDP body part . . . . . . . . . . . . . . . . . . . . . . 25
8.8. Other body parts . . . . . . . . . . . . . . . . . . . . . 26
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Requirements for end-to-end authenticated identification . . . 27
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28
12. Security considerations . . . . . . . . . . . . . . . . . . . 29
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
14. Informative References . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
Elwell Expires August 29, 2009 [Page 3]
Internet-Draft End-to-End Identity Important February 2009
1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] provides two basic
mechanisms for identifying users involved in a session or call: the
From header field URI [RFC3261] and the P-Asserted-Identity header
field [RFC3325]. Used alone, these are vulnerable to misuse, but two
mechanisms exist for providing authentication of the From header
field URI: Authenticated Identity Body [RFC3893] and the Identity
and Identity-Info header fields (SIP Identity, [RFC4474]). These
various mechanisms provide to the recipient of a SIP request (the
User Agent Server, UAS, and its user) identification (with or without
authentication) of the source of a SIP request (the User Agent
Client, UAC). The identifier given as the source of a request is
generally assigned to a user. However, a UAC will have been given
the necessary credentials to use this identifier on behalf of a user,
so the use of such an identifier to indicate the source of a request
strictly speaking means that the request has come from a UAC with the
credentials of the user. Implicitly it means the request has come
from the user, assuming that the user concerned really is the user of
the UAC. This depends on the UAC's user interface (e.g., whether it
requires the user to enter a PIN to unlock the user's credentials)
and also on human behaviour (e.g., whether the user refuses to allow
his/her unlocked device to be used by somebody else).
Further, by binding an end of a secure bidirectional medium using
SRTP [RFC3711] to a SIP request whose source has been identified, the
recipient of that SIP request can know the identity of the user who
is the source and sink of that medium. This is the principle behind
DTLS-SRTP [I-D.ietf-sip-dtls-srtp-framework], which uses certificates
in the endpoints to agree a security context for SRTP. DTLS-SRTP
also exchanges fingerprints of those certificates in SIP messages,
thereby binding the media to those SIP messages. If a SIP message
carrying such a certificate fingerprint also includes the
authenticated identification of the user on behalf of which the SIP
message has been sent, the secure media are bound to that user.
DTLS-SRTP currently relies on the From header field URI and SIP
Identity to achieve this.
This is the theory, but there are a number of practical
considerations that make this very difficult to deploy in many
situations, particularly when there are intermediaries that change
identification information or break signatures. This has led to a
number of proposed work-arounds, but has also has led to a
questioning of the need for end-to-end authenticated identification.
This document explains why end-to-end authenticated identification is
important.
Although the primary function of SIP is to initiate sessions (Session
Elwell Expires August 29, 2009 [Page 4]
Internet-Draft End-to-End Identity Important February 2009
Initiation Protocol), it also includes some methods for use outside
the context of a session, e.g., MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH.
Although the main focus of this document is on identifying users
involved in sessions, many of the considerations apply equally to
other uses of SIP.
2. Terminology
This document uses the following terms:
end-to-end In the context of a SIP request, operating from the
domain of the UAC to the domain of the UAS.
end-to-end identification The delivery of an identifier representing
the source of a request unchanged from the domain of the UAC to
the domain of the UAS.
end-to-end authenticated identification The delivery of an
identifier representing the source of a request together with
evidence of authenticity unchanged from the domain of the UAC to
the domain of the UAS.
End-to-end identification or end-to-end authenticated identification
can originate at the UAC and terminate at the UAS, in which case it
is truly end-to-end. However, for the use cases considered in this
document, it is generally sufficient that end-to-end identification
or end-to-end authenticated identification originate within the
domain of the UAC. For example, a proxy or B2BUA in that domain can
insert the correct identifier, based on digest authentication of the
UAC, and (in the case of authenticated identification) can provide
evidence of authenticity. On the receiving side, it might be
sufficient for the domain of the UAS to verify the evidence of
authenticity and communicate that somehow to the UAS. In such cases,
the term end-to-end is, strictly speaking, shorthand for end-domain-
to-end-domain. With end-to-end identification or end-to-end
authenticated identification, the important thing is that
intermediate domains play no part in providing the identifier or
evidence of authenticity.
In contrast to end-to-end identification or end-to-end authenticated
authentication, hop-by-hop identification or hop-by-hop authenticated
identification involves an intermediate domain modifying the
identifier or providing evidence of authenticity, leading to the need
for transitive trust.
It should also be noted that end-to-end identification or
authenticated identification operates only within the SIP
Elwell Expires August 29, 2009 [Page 5]
Internet-Draft End-to-End Identity Important February 2009
environment. Where PSTN interworking is involved, the end domain is
the domain of the SIP-PSTN gateway. True end-to-end operation
depends on the PSTN, is outside the scope of this document, and in
practice is probably unachievable.
3. Overview of existing mechanisms and their shortcomings
3.1. The From header field URI
Although a UAC should place its Address of Record (AoR) in the From
header field of a SIP request, it is a well known fact that in
practice a UAC is free to place any value there. SIP proxies are not
allowed to change the value, but a SIP proxy could demand that the
UAC authenticate itself (using SIP digest authentication) and reject
a request if the From URI does not match the authenticated user. A
B2BUA could also do this, or could rectify the From URI and forward
the request, as an alternative to rejecting the request.
However, a user is likely to have a SIP digest authentication shared
secret only with a SIP entity (proxy or B2BUA) in the same domain,
and any downstream SIP entities (in other domains) will not be in a
position to challenge for digest authentication. Those SIP entities
will have no means of knowing whether the request has been validated
by an entity in the source user's domain, and therefore no means of
trusting the From URI.
3.2. The P-Asserted-Identity (PAI) header field
This was introduced to counter some of the problems with the From
URI. A SIP entity that has validated the source of a SIP request can
include a PAI header field containing the validated URI, which may
differ from the From URI. A downstream entity in the same trust
domain will place some trust in this value. Entities within the same
trust domain must exchange SIP messages over a secure transport
(e.g., TLS), so that the upstream entity is authenticated. That
upstream entity is then trusted to provide a correct identifier in
the PAI header field. In the context of a session or call, PAI in
the INVITE request can assert the identifier of the calling user and
PAI in a request in the reverse direction can assert the identifier
of the connected user.
This mechanism was introduced for use in closed environments where a
trust domain could be established, rather than for use on the
Internet. However, it has seen very considerable deployment.
The problem lies in its notion of transitive trust, i.e., A asserts
an identifier and sends it over a secure transport to B. B trusts the
Elwell Expires August 29, 2009 [Page 6]
Internet-Draft End-to-End Identity Important February 2009
assertion, and passes the assertion on over a secure transport to C.
C trusts B, and passes the assertion on over a secure transport to D,
and so on. D trusts C, and has to rely on C's trust of any upstream
entities (in this case B). C has to rely on B's trust of any
upstream entities (in this case A). The problem is, a downstream
entity does not know the entire upstream path of trust, so in
trusting its neighbour it does not know who else it is being forced
to trust. As SIP continues to grow, eventually a bad actor or
malicious site will be trusted by another party many hops away.
Furthermore, when an entity receives a request from outside its trust
domain it can place a default value in the PAI header field when
forwarding the request. For example, when a service provider
receives a request from an enterprise, if it does not trust the PAI
received from the enterprise it is common practice to insert the
default number for the enterprise, e.g., that of an attendant or
reception desk. This can be misleading, particularly if the request
originated outside the enterprise and has been forwarded by the
enterprise to the service provider. Arguably it also violates
[RFC3325], since the default number is being placed into PAI without
having authenticated that number as the source of the SIP request.
This practice can also cause the PAI URI to deviate from the From URI
(typically they are the same in many simple situations), causing a
dilemma for the UAS - which one to present to the user (or a dilemma
for the user if both are presented).
3.3. Authenticated Identity Body (AIB)
With AIB [RFC3893], the UAC copies the From URI and some other header
fields into a body of the SIP request and signs it using S/MIME
[RFC3851]. The ability to include S/MIME in [RFC3261] (and likewise
PGP [RFC2015] in the original version of SIP [RFC2543]) demonstrates
that end-to-end security has always been considered important in SIP,
and AIB binds the From URI to the end-to-end authentication that
S/MIME provides. In the context of a session or call, AIB in the
INVITE request can provide authenticated identification of the
calling user and AIB in the 200 response or in a request in the
reverse direction can provide authenticated identification of the
connected user.
AIB has not been deployed because S/MIME has not been deployed, and
that in turn can probably be blamed on the need for each SIP UA to
have its own certificate and private key and the infrastructure
needed to manage that. However, the mechanism is in theory capable
of true end-to-end authenticated identification.
Elwell Expires August 29, 2009 [Page 7]
Internet-Draft End-to-End Identity Important February 2009
3.4. SIP Certs
A partial solution to the certificate problem associated with S/MIME
and hence AIB is available in [I-D.ietf-sip-certs]. This allows a
SIP UA to retrieve its user's certificate from a certificate store.
However, a certificate per user is still required, and this appears
to be a barrier.
3.5. SIP Identity
SIP Identity addresses the impracticalities of AIB by having a SIP
entity that has validated the source of a SIP request (e.g., using
SIP digest authentication) place a signature over the From header
field URI and other parts of the message to assert the correctness of
the From URI and provide integrity protection over the signed parts.
The signature is placed in the Identity header field and information
needed for validating the signature is placed in the Identity-Info
header field. This provides authenticated identification between the
source domain and the UAS, or between the source domain and a
verifying entity in the destination domain. Therefore it can be
considered to provide end-domain-to-end-domain authentication. In
the context of a session or call, SIP Identity in the INVITE request
can provide authenticated identification of the calling user and SIP
Identity in the reverse direction [RFC4916] can provide authenticated
identification of the connected user. DTLS-SRTP relies on SIP
Identity to bind SRTP media to a calling or connected user.
However, SIP Identity has seen little (if any) deployment, and that
is partly due to lack of a perceived need (many regard PAI as
sufficient) and partly because it has been shown not to work in many
common situations. Concerning the need for SIP Identity (or a
similar mechanism), sections 4, 5 and 6 show why end-to-end (or end-
domain-to-end-domain) authenticated identification is important, and
therefore why PAI is insufficient.
The reason SIP Identity does not work in common situations is that
B2BUAs, and in particular Session Border Controllers (SBCs), have
reasons to change some parts of the signed information when
forwarding a SIP request, thus breaking the signature. The broken
signature can either be forwarded as is (which has no value), can be
removed, or can be replaced with a new signature. This last option,
if carried out by an intermediate domain, means that authenticated
identification is no longer end-domain-to-end-domain. Moreover, an
entity can generate a new signature only if the domain part of the
From URI matches the domain's certificate, and hence the From URI
will need to change to match the new signing domain (an action that
in principle is feasible with E.164-based SIP URIs), so the
identifier is now no longer end-to-end. The breaking of signatures
Elwell Expires August 29, 2009 [Page 8]
Internet-Draft End-to-End Identity Important February 2009
by intermediaries is discussed further in Section 7.
3.6. Return routability checks
In the absence of a means for delivering authenticated identification
to a UAS, the UAS (or its domain proxy or B2BUA) can gain some
measure of confidence in the delivered identifier by attempting to
send a return request, using the received identifier as target. The
result of the return request should provide some evidence that the
source of the original request (the UAS or its domain) has been
reached. This assumes that intermediate domains are not malicious,
and will route correctly even though they are unable to cooperate in
the provision of end-to-end authenticated identification.
One proposal for a return routability check is in
[I-D.kuthan-sip-derive]. In that proposal, the return request is a
SUBSCRIBE request for the dialog event package with a filter for
information about the dialog that the original request is attempting
to establish. Evidence that the source of the request has been
reached is achieved if the SUBSCRIBE request is successful and if a
NOTIFY request identifying that same dialog is received, the
assumption being that any other recipient of the SUBSCRIBE request
would know nothing about that dialog. This particular proposal has
some limitations. For example, it requires the UAC to support
filtering, it will not work through B2BUAs that change dialog
identifiers and it does not apply to requests that do not involve
dialogs. However, the principle of return routability checking may
yield a solution that gives a better-than-nothing assertion of the
correctness of an identifier.
3.7. Problems with SIP URIs based on E.164 numbers
If a user receives a caller or connected identifier in the form of a
SIP URI containing a global E.164 number (e.g.,
sip:+123456789@example.com;user=phone), and if this information is
made available to the user, how would the user interpret it? The
user might recognise the telephone number and ignore the domain part.
The user might treat the domain part as significant and disregard the
number (particularly if she fails to recognise the number). Or the
user might take account of both items of information.
Problems arise when the user attaches importance to the domain part,
because there is no defined meaning for the domain part (other than
that by routing a request to that URI to that domain, that domain
should be able to route it onwards towards the user of the telephone
number). In practice, the domain part is often changed by
intermediate domains (typically to reflect their own domain), so a
request starting out with sip:+123456789@mybank.com;user=phone in the
Elwell Expires August 29, 2009 [Page 9]
Internet-Draft End-to-End Identity Important February 2009
From or PAI header field could end up with
sip:+123456789@serviceprovider.net;user=phone in that header field
when delivered to the UAS, where serviceprovider.net is the last
domain it passed through. The recipient would not see that the
request really originated in mybank.com, and this information may
have been important to the recipient.
Moreover, any such change of From URI breaks the SIP Identity
signature, as described earlier.
Clearly these problems do not exist with tel URIs [RFC3966] since
there is no domain part and therefore no scope for change. Therefore
they have the advantage of not providing a false or misleading domain
part, but the disadvantage of not providing a domain part at all for
users who would benefit from this information. Also tel URIs cannot
be used with SIP Identity.
The E.164 problem is described in more detail in
[I-D.elwell-sip-e164-problem-statement].
3.8. Other causes of URI change at intermediate domains
As described in Section 3.7, intermediate domains can change a URI
based on an E.164 number, such that the recipient does not receive
the original identifier. This is not the sole circumstance in which
intermediate domains are known to change an identifier identifying
the source of a SIP request. Another circumstance is where a domain
does not accept a received identifier as a valid source and
substitutes a default value. This often occurs when an enterprise
submits an identifier to a service provider, the identifier not being
within the range recognised by the service provider as belonging to
that enterprise. There are legitimate reasons why an enterprise
might submit an identifier outside the recognised range, as
highlighted by some of the examples in Section 4. When delivered to
the UAS, the new identifier might be misleading.
3.9. Problems with PSTN interworking
A PSTN gateway will generally deliver a number received from PSTN as
the From or PAI URI. The gateway has no means of validating that
number and has either to trust the PSTN or disregard the number
(placing its own identifier or an anonymous value in the From URI).
There are known means of a false caller number in PSTN (depending on
country), and therefore trusting a number from PSTN can be dangerous.
Furthermore, from a DTLS-SRTP perspective, it can be dangerous to
assume that media are secured all the way to a PSTN user. First, the
PSTN has known vulnerabilities in terms of interception of calls for
Elwell Expires August 29, 2009 [Page 10]
Internet-Draft End-to-End Identity Important February 2009
legal or other reasons. Second, there is no way of detecting whether
the PSTN user is attached to the PSTN via an unsecured IP network.
Therefore, at best, a call can be considered secure only as far as
the gateway and true end-to-end (or end-domain-to-end-domain)
security is not achievable. Solutions are required to the problem of
misleading the user concerning the end-to-end security status of a
call to/from PSTN, but this issue is not discussed further in this
document.
4. Examples
In Section 3.7 and Section 3.8 it was shown how the identifier
representing the source of SIP request can be modified by SIP
intermediaries before being delivered to the UAS. Furthermore,
Section 3.5 mentioned how an intermediate domain could change the
From URI in order to "fix" a broken RFC 4474 signature. In these
cases, identification delivery is not end-to-end and often fails to
deliver information needed by the recipient. In this section a
number of example use cases are given, only some of which deliver
end-to-end identification.
Where a SIP intermediary modifies the From URI, it can do so in
several ways:
o conversion, whereby a SIP intermediary substitutes an identifier
that does not identify the original source of the SIP request
(e.g., substituting a default identifier for the enterprise
concerned);
o translation, whereby a SIP intermediary substitutes a form of
identifier that still identifies the original source of the SIP
request (e.g., by adding prefix digits or a phone-context
parameter to make it globally unique, or by changing the domain
part of an E.164-based SIP URI);
o normalisation (e.g., removing whitespace, adding "+", converting
from dial string by removing prefix digits such as "0").
Of these, conversion is the most problematic, because it results in
an identifier that no longer identifies the originator of the
request. This means that it will probably prevent a return SIP
request (e.g., a return call) reaching the user who originated the
original request.
Translation might cause difficulties for the user recognizing the
source of the request or for the UAS trying to match entries in a
phone book or white list. It might also cause return routability to
Elwell Expires August 29, 2009 [Page 11]
Internet-Draft End-to-End Identity Important February 2009
fail if the result is not globally unique.
Normalisation might actually help recognition and matching. Note
that the addition of removal or "user=phone" in practice might be
considered normalisation, although in theory two URIs differing only
in the presence or absence of user=phone identify different entities.
All three forms of modification break any SIP Identity signature, so
even if they do not prevent end-to-end identification, they prevent
end-to-end authenticated identification (see Section 6.
In the figures associated with the examples below, caller
identification is shown in the From header field URI, but a similar
problem can arise with PAI.
The examples are all to do with caller identification (where the
called user wants to know who is calling), but corresponding examples
can be derived for connected identification (where the caller wants
some assurance that the correct called party has been reached).
4.1. Example 1
Consider a call from an employee Bob at bank.com to Alice, who
obtains a SIP service from service provider sp.net. Alice would be
prepared to accept a call from her bank. Bob's identifier is
sip:bob@bank.com. In this case, hopefully Alice would receive this
identifier unchanged. She might not know Bob, but at least she knows
the call is from her bank and can accept the call on that basis.
bank.com sp.net Alice
From:sip:bob@bank.com From:sip:bob@bank.com
-----------------------> ------------------------>
This example delivers end-to-end identification, but in practice it
is likely that any RFC 4474 signature provided by the originating
domain will be broken because an intermediate B2BUA modifies signed
information.
4.2. Example 2
Suppose the service provider removes Bob's identifier and substitutes
the default for the bank, based on the bank's default telephone
number +123456000 and the bank's domain name. Alice would receive
sip:+123456000@bank.com;user=phone. This is an example of
conversion.
bank.com sp.net Alice
From:sip:bob@bank.com From:sip:+123456000@bank.com;user=phone
Elwell Expires August 29, 2009 [Page 12]
Internet-Draft End-to-End Identity Important February 2009
--------------------> ---------------------------------->
This example does not deliver end-to-end identification. In this
case Alice still knows the call is from her bank but there is no
indication of who at the bank is calling. Furthermore, if she were
to make a return call to the bank, it would arrive at a default user
(e.g., attendant, receptionist) and would not reach Bob. This may be
what the bank desires (in which case it would not disclose Bob's
identifier to the service provider), but in many cases it may not be
what the bank desires.
4.3. Example 3
Suppose the service provider removes Bob's identifier and substitutes
the default for the bank, based on the bank's default telephone
number +123456000 and the service provider's domain name. Alice
would receive sip:+123456000@sp.net;user=phone. This is an example
of conversion.
bank.com sp.net Alice
From:sip:bob@bank.com From:sip:+123456000@sp.net;user=phone
--------------------> ---------------------------------->
This example does not deliver end-to-end identification. In this
case Alice cannot tell from the received identifier that the call is
from her bank, unless she happens to recognise the telephone number.
This is no worse than PSTN (or no worse than if a tel: URI were used
in SIP), but SIP has the potential to be better than PSTN. As for
example 2, there is also a problem with return calls.
4.4. Example 4
Bob's identifier is sip:+123456789@bank.com;user=phone. If the
service provider delivers this to Alice she will see it is from her
bank. She may or may not recognise the telephone number as belonging
to Bob or to the bank.
bank.com sp.net Alice
From:sip:+123456789 From:sip:+123456789
@bank.com;user=phone @bank.com;user=phone
--------------------> ---------------------->
This example delivers end-to-end identification, but in practice it
is likely that any RFC 4474 signature provided by the originating
domain will be broken because an intermediate B2BUA modifies signed
information.
Elwell Expires August 29, 2009 [Page 13]
Internet-Draft End-to-End Identity Important February 2009
4.5. Example 5
Suppose the service provider substitutes its own domain name for the
bank's domain name. Alice would receive
sip:+123456789@sp.net;user=phone. This is an example of translation.
bank.com sp.net Alice
From:sip:+123456789 From:sip:+123456789
@bank.com;user=phone @sp.net;user=phone
--------------------> ---------------------->
This example does not deliver end-to-end identification. In this
case Alice cannot see that the call is from her bank, unless she
happens to recognise the telephone number. However, the number is
delivered end-to-end, which may be sufficient for some purposes.
4.6. Example 6
Suppose the service provider substitutes its own domain name for the
bank's domain name, and also substitutes the default telephone number
for the bank. Alice would receive sip:+123456000@sp.net;user=phone.
This is an example of conversion.
bank.com sp.net Alice
From:sip:+123456789 From:sip:+123456000
@bank.com;user=phone @sp.net;user=phone
--------------------> ---------------------->
This example does not deliver end-to-end identification. Alice
receives the same identifier as in example 3, and the same
considerations apply.
4.7. Example 7
Consider a call from Carol at client.org to Dave at example.com.
Dave is working at home and has arranged for calls to be forwarded to
him via his SIP service provider sp.net. Suppose Carol's identifier
is carol@client.org and this identifier reaches example.com, where it
is forwarded, with the INVITE request, to sp.net. If sp.net delivers
this unchanged to Dave at home, Dave will see that the call is from
Carol at his client and can accept the call on that basis. Also he
can make a return call, e.g., if he is unable to answer at the time
and Carol's identifier is stored in his missed call log.
client.org example.com sp.net Alice
From:sip:carol From:sip:carol From:sip:carol
@client.org @client.org @client.org
-------------> --------------> --------------->
Elwell Expires August 29, 2009 [Page 14]
Internet-Draft End-to-End Identity Important February 2009
This example delivers end-to-end identification, but in practice it
is likely that any RFC 4474 signature provided by the originating
domain will be broken because an intermediate B2BUA modifies signed
information.
4.8. Example 8
Suppose the service provider does not accept sip:carol@client.org as
an identifier received from example.com and substitutes the default
identifier for example.com, based on its default number and its
domain name (sip:+123456000@example.com;user=phone). This is an
example of conversion.
client.org example.com sp.net Alice
From:sip:carol From:sip:carol From:sip:+123456000
@client.org @client.org @example.com
;user=phone
-------------> --------------> ------------------>
This example does not deliver end-to-end identification. Dave will
now see that the call comes from his own company, and will not have a
clue that it comes from his client. Similarly if the service
provider's domain name is used (sip:+123456000@sp.net;user=phone),
Dave would presumably recognise his company's own default telephone
number but would not see that the call is from his client. Also any
attempted return call would just go to his company's default
answering point.
4.9. Example 9
Suppose Carol's identifier is E.164-based:
sip:+123498765@client.org;user=phone. If this is delivered to Dave,
he will see the calling telephone number, which he may recognise (or
software in his phone may match it with an existing contact) and he
will also see that it is from client.org.
client.org example.com sp.net Alice
From:sip:+123498765 From:sip:+123498765 From:sip:+123498765
@client.org @client.org @client.org
;user=phone ;user=phone ;user=phone
------------------> ------------------> ------------------>
This example delivers end-to-end identification, but in practice it
is likely that any RFC 4474 signature provided by the originating
domain will be broken because an intermediate B2BUA modifies signed
information.
Elwell Expires August 29, 2009 [Page 15]
Internet-Draft End-to-End Identity Important February 2009
4.10. Example 10
Suppose the identifier in the last example is not accepted by the
service provider, not only because of the domain part (client.org
rather than example.com) but also because the telephone number does
not fall within the range assigned to example.com. As in example 8
it might substitute a default identifier. This is an example of
conversion.
client.org example.com sp.net Alice
From:sip:+123498765 From:sip:+123498765 From:sip:+123456000
@client.org @client.org @sp.net
;user=phone ;user=phone ;user=phone
------------------> ------------------> ------------------>
This example does not deliver end-to-end identification.
Consequences are similar to those in example 8.
4.11. Example 11
Eve in the US office of enterprise e.com
(sip:+123456789@e.com;user=phone) makes a call to Fred, who has a UK
telephone number (+44...) and is served by UK service provider
uksp.net. The US proxy in e.com forwards the request to the UK proxy
of e.com, where the call "breaks out" to uksp.net. The service
provider does not accept a non-UK identifier and substitutes a
default value for the enterprise (sip:+445678000@e.com;user=phone).
This is an example of conversion.
e.com uksp.net Fred
From:sip:+123456789 From:sip:+445678000
@e.com;user=phone @e.com;user=phone
--------------------> ------------------------>
This example does not deliver end-to-end identification. In this
case Fred still knows the call is from e.com, but is not aware that
Eve is calling or that that the caller is in the US.
4.12. Example 12
Suppose the service provider uses its own domain name in the modified
SIP URI.
e.com uksp.net Fred
From:sip:+123456789 From:sip:+445678000
@e.com;user=phone @uksp.net;user=phone
--------------------> ------------------------>
Elwell Expires August 29, 2009 [Page 16]
Internet-Draft End-to-End Identity Important February 2009
This example does not deliver end-to-end identification and is
another example of conversion. In this case Fred does not know that
the call is from e.com (unless he happens to recognise the UK
telephone number). Also Fred is not aware that Eve is calling or
that that the caller is in the US.
5. Why end-to-end identification is important
The conclusions from the different examples above can be summarized
as follows.
Elwell Expires August 29, 2009 [Page 17]
Internet-Draft End-to-End Identity Important February 2009
+------------+-------------------------------------------------+
| Example 1 | Delivers end-to-end identification |
+------------+-------------------------------------------------+
| Example 2 | Delivers end-to-end identification, but only |
| | domain, not user |
+------------+-------------------------------------------------+
| Example 3 | Fails to deliver end-to-end identification |
| | (substitutes telephone number instead) |
+------------+-------------------------------------------------+
| Example 4 | Delivers end-to-end identification |
+------------+-------------------------------------------------+
| Example 5 | Delivers end-to-end identification, but only |
| | the telephone number, not the domain |
+------------+-------------------------------------------------+
| Example 6 | Fails to deliver end-to-end identification |
| | (changes telephone number and domain) |
+------------+-------------------------------------------------+
| Example 7 | Delivers end-to-end identification |
+------------+-------------------------------------------------+
| Example 8 | Fails to deliver end-to-end identification |
| | (forwarding enterprise's identity instead) |
+------------+-------------------------------------------------+
| Example 9 | Delivers end-to-end identification |
+------------+-------------------------------------------------+
| Example 10 | Fails to deliver end-to-end identification |
| | (forwarding enterprise's identity instead) |
+------------+-------------------------------------------------+
| Example 11 | Fails to deliver end-to-end identification |
| | (delivers domain but changes telephone number) |
+------------+-------------------------------------------------+
| Example 12 | Fails to deliver end-to-end identification |
| | (changes telephone number and domain) |
+------------+-------------------------------------------------+
Examples 1, 4, 7 and 9 are fine, because identification of the caller
is end-to-end (although, as pointed out, any RFC 4474 signature might
be broken). In the remaining examples, identification is not end-to-
end, leading to problems.
More complex examples can be derived with more domains involved.
Clearly the more domains involved, the more there is scope for
failure to deliver an identifier end-to-end, and the greater the
consequences for the recipient, both in terms of recognising the
source of the call and being able to make a return call. These
examples illustrate the importance of delivering an identifier end-
to-end, without changing it at intermediate domains.
Elwell Expires August 29, 2009 [Page 18]
Internet-Draft End-to-End Identity Important February 2009
6. Why end-to-end authenticated identification is important
Assuming an identifier is delivered end-to-end, where authenticated
identification is required it is important that the assertion of
authenticity is provided at source, or at least in the originating
domain. This is what SIP Identity aims to achieve. However, because
of the difficulties with SIP Identity, as described in Section 3.5,
some have asked why hop-by-hop assertions are insufficient. PAI is
one solution to hop-by-hop assertions. Another possibility would be
for each domain to provide its own cryptographic signature. Note
that SIP Identity does not allow this, because the signer has to have
the same domain name as that in the From URI, so only the originating
domain can sign (unless the identifier is also changed, which would
mean that requirements for end-to-end identification would not be
met).
With end-to-end authentication, the relying party has to trust the
originating domain, which also means trusting the certificate chain
up to the top level certification authority. This is similar to
other applications using PKI-based security, such as secure web
pages. In many cases there will just be the signing domain's
certificate and a single CA certificate. The relying party can see
the whole chain and make its own judgements.
With hop-by-hop authentication based on PAI, the relying party knows
only that the upstream neighbour domain is asserting that domain. It
does not know how many further upstream domains there are, what those
domains are, and how far the trust domain extends. Just because the
relying party trusts its own domain and perhaps its upstream
neighbour domain, does not mean that it would trust further domains
that its upstream neighbour domain trusts.
For example, consider a call from Alice in enterprise1.biz
(sip:alice@enterprise1.biz), via service provider sp1.net, via second
service provider sp2.org, and terminating at Bob in enterprise2.com
(sip:bob@enterprise2.com). The call is routed that way because
enterprise1.biz routes all external calls through sp1.net, and
enterprise2.com only accepts external calls that have arrived via
sp2.org. Bob is happy to accept a secure call from enterprise1.biz.
With hop-by-hop authentication, Bob would have to rely on an
assertion by enterprise2.com, which in turn would rely on an
assertion by sp2.org, and so on. Bob has no visibility of the
upstream entities, although he would probably be aware of his
enterprise's own service provider (sp2.org). He would be unlikely to
be aware of sp1.net, and even if he were aware, he may not have heard
of sp1.net and may not wish to trust such an assertion. It could be
that sp1.net is located in a country where practices are not of the
standard expected in Bob's country.
Elwell Expires August 29, 2009 [Page 19]
Internet-Draft End-to-End Identity Important February 2009
Suppose also that DTLS-SRTP is to be used to secure media between
Alice and Bob. If authentication is hop-by hop, Bob can be sure that
media is secured as far as sp2.org, but cannot be sure that there is
no man-in-the-middle between sp2.org and enterpise1.biz. End-to-end
authentication is required to give Bob the assurance he needs.
Referring back to the examples in Section 4, those that deliver end-
to-end identification have the potential to deliver end-to-end
authentication, but in practice, SIP Identity as specified in
[RFC4474] is often broken by the actions of B2BUAs. The remaining
examples, because they do not deliver end-to-end identification,
cannot deliver end-to-end authentication. In addition, normlisation
of the From URI breaks SIP Identity.
7. Why B2BUAs break SIP Identity signatures
As mentioned in Section 3.5, SIP Identity signatures are broken when
B2BUAs (in particular SBCs) modify signed parts of a SIP request when
forwarding. This prevents the provision of end-to-end (or end-
domain-to-end-domain) authenticated identification.
Common functions of SBCs are described in
[I-D.ietf-sipping-sbc-funcs]. To achieve some of these functions, an
SBC could act as a proxy, but to achieve other function an SBC might
need to act as a B2BUA in a way that is harmful to end-to-end
authenticated identification.
7.1. Changing the SDP body part
Because SIP Identity signs the entire body of a SIP request, this
includes any SDP body part, which typically is present in an INVITE
request, for example. For reasons of media steering, SBCs frequently
modify IP addresses and ports in SDP in order to force media to take
a particular path, e.g., to ensure it does indeed pass through the
operator's network, or to force it along a route that can provide
appropriate quality of service. Also an SBC might modify SDP in
order to limit bandwidth to what is available or authorised, e.g., by
stripping out bandwidth-hungry codecs and forcing endpoints to select
low bandwidth codecs. SBCs, together with an associated media relay,
often carry out NAT traversal functions, resulting in a need to
modify SDP. Although NAT traversal can be achieved by other means
such as ICE, which does not require modification of SDP at the point
of NAT traversal, such means are dependent on endpoint support.
Furthermore SBCs sometimes use an associated media relay to perform
conversion between IP versions (IPv4 and IPv6), again requiring
modifications to SDP. More details are given in
[I-D.ietf-sipping-sbc-funcs], but the result is that SBCs frequently
Elwell Expires August 29, 2009 [Page 20]
Internet-Draft End-to-End Identity Important February 2009
modify SDP and will therefore break a SIP Identity signature.
It should be noted that end-to-end authenticated identification does
not necessarily need to traverse some SDP-modifying functions that
SBCs or other intermediaries perform. For example, if an SBC steers
media through a media relay that decrypts and re-encrypts media
(e.g., for call recording purposes), media encryption is not end-to-
end, and therefore end-to-end authenticated identification can be
considered inappropriate. If SIP Identity is used to bind media
security to the source of a SIP request, the identified source should
correspond to the place where media security terminates, which is the
media relay. Any attempt at trying to pretend security is end-to-end
would conceal the possibility of a man-in-the-middle attack.
Similarly, if an SBC steers media through a transcoder, the
transcoder can potentially change the media, so again end-to-end
authenticated identification can be considered inappropriate. In
this case, if the media is secured, the transcoder would also need to
decrypt and re-encrypt.
7.2. Changing the Contact and Call-Id header fields
B2BUAs, including SBCs, often modify Contact and Call-Id header
fields. One reason is for topology hiding, if these fields convey
information that might reveal information about the rest of an
operator's network (e.g., by identifying specific gateways behind the
SBC). Another reason for changing Contact is to replace IP addresses
by host names.
Another reason is because of 3rd party call control (3PCC) functions
performed by an SBC. For example, if a B2BUA uses 3PCC techniques to
perform transfer, a call leg on one side will be joined to a call leg
on the other side, that was not part of the original call, and
therefore it will necessarily have a different Call-Id value, as well
as different To and From tags. The resulting call will have
different Call-Id and tag values on either side of the B2BUA. In
other words, it will comprise a concatenation of two different
dialogs, even if the original call comprised only a single dialog.
Therefore when a request is sent end-to-end along the new call,
Call-Id and tag values will need to be changed as the request passes
through the B2BUA. Also the Contact URI might need to change. These
actions will break any SIP Identity signature.
7.3. Changing the From URI
Changing the From header field URI when forwarding a request will
break a SIP Identity signature. Reasons for changing the URI are
discussed in [I-D.kaplan-sip-uris-change]. In particular, it is
common practice to modify the host part to reflect a domain's own
Elwell Expires August 29, 2009 [Page 21]
Internet-Draft End-to-End Identity Important February 2009
domain name when entering a domain, or to reflect the next domain's
name when exiting a domain. Reasons are not entirely clear, but one
reason might be to adapt to broken implementations that cannot accept
other domain names. Another reason might be to hide a domain's
relationship with other domains. Changing the host part of a SIP URI
based on a fully qualified E.164 number does not necessarily
invalidate the user part, i.e., the E.164 number can still be
considered valid, whatever the domain part. However, some of the
examples in Section 4 require the original domain part to be
delivered, and therefore by changing the domain part, end-to-end
identification cannot be claimed. With SIP URIs not based on E.164
numbers (e.g., based on a name), changing is less straightforward,
although it can in theory be done by encapsulating the entire
original URI in the user part of the new URI, together with a new
domain part, resulting in a complex URI that might not be interpreted
correctly by the UAS or its user.
Other reasons for From URI changing are given in
[I-D.kaplan-sip-uris-change], but some of these disappear if good
practices are observed, such as avoiding IP addresses in host parts,
avoiding non-normalised forms of user parts (e.g., containing prefix
digits or without country code), and avoiding identifiers based on
host names rather than domain names.
Although on the one hand, changing a From URI can break a SIP
Identity signature, changing the From URI can also be part of the
solution for rectifying a broken SIP Identity signature, since re-
signing the request requires the From URI to have a domain part the
same as the signing domain. Therefore whether or not the From URI
has changed anyway, re-signing a request will involve changing the
From URI unless the request is still within the original domain.
Although re-signing can rectify a broken SIP Identity signature, it
does not lead to end-to-end authenticated identification. Also, for
URIs not based on E.164 numbers, changes result in complex URIs that
might not be interpreted correctly. Furthermore, re-signing by an
intermediate domain imposes greater computational costs on that
domain, for the benefit of end domains.
7.4. Changing the To URI
Changing the To header field URI when forwarding a request will break
a SIP Identity signature. Reasons for change are similar to some of
the reasons for changing the From URI.
7.5. Protocol repair
Protocol repair by an SBC or B2BUA can break a SIP Identity signature
if the repair impacts any of the signed elements. Of the signed
Elwell Expires August 29, 2009 [Page 22]
Internet-Draft End-to-End Identity Important February 2009
elements, SDP is certainly an area that has attracted many bad
implementations and is a prime target for repair, to avoid an error
being perpetuated as a SIP request traverses domains. Whilst this
can be seen as beneficial in some circumstances, cosmetic repairs are
unnecessary and some repairs can be harmful in other ways (e.g.,
"repairing" a valid new extension to SIP or SDP that is not supported
and therefore not understood by the SBC).
8. Analysis of changes to SIP requests by B2BUAs
This section analyses in more detail those parts of a SIP request
that are signed by RFC 4474 to see which parts really need to be
allowed to be changed by B2BUAs (i.e., any mechanism for end-to-end
authenticated identification needs to be tolerant of such changes)
and which do not need to be changed (i.e., any mechanism for end-to-
end authenticated identification can expect to fail in the presence
of such changes). Any identity-related header fields not signed by
RFC 4474 (e.g., History-Info, Geolocation) are not considered.
8.1. addr-spec of From header field
Conversion of the From URI is generally harmful, in that after
conversion the From URI no longer identifies the source of the
request. Conversion might involve just a change of user-info part,
such that the domain is still correct, or might involve a change of
domain too. Therefore it is not required that a mechanism for end-
to-end authenticated identification be tolerant of conversion of the
From URI.
Translation of the From URI is generally less harmful, in that after
translation it still identifies the source of the request. However,
there are several sub-categories of translation, each with different
consequences:
o Translating from a non-global URI to a global URI is generally
helpful, but on the other hand could and should be done by the
originating domain before signing the request, thereby removing
the need for this form of translation by B2BUAs in intermediate
domains.
o Translation involving changing the domain part of an E.164-based
SIP URI is harmful, since the domain from which the request
originated is lost.
o Translation of a name-based SIP URI to an alias number-based SIP
URI or vice versa with the same domain part may or may not be
harmful, depending on whether the translated URI is meaningful to
Elwell Expires August 29, 2009 [Page 23]
Internet-Draft End-to-End Identity Important February 2009
the UAS its user.
o Translation of a name- or number-based SIP URI to a TEL URI is
harmful in that the domain is lost. Effectively this is what has
to be done at PSTN gateways, where it cannot be avoided, but it
should not be done by B2BUAs. In any case, RFC 4474 cannot be
used with a TEL URI.
Normalisation in general is not harmful, although it should be
carried out at the originating domain before signing.
Any form of modification of the From URI (conversion, translation or
normalization) is either harmful if carried out by an intermediate
domain or is better carried out by the originating domain. Therefore
a mechanism for end-to-end authenticated identification does not need
to be tolerant of changes to the From URI by intermediate domains.
TODO. Do changes to phone-context or to any URI parameters need to
be considered explicitly, or are they all covered by conversion,
translation or normalisation?
8.2. addr-spec of To header field
Although the To URI does not identify the caller, it does identify
the original targeted user. Any normalisation or translation to a
globally unique identifier should be carried out by the originating
domain, in which case there should be no reason for modification by
an intermediate domain. Therefore a mechanism for end-to-end
authenticated identification does not need to be tolerant of changes
to the To URI by intermediate domains.
8.3. call-id of Call-Id header field and digit of CSeq header field
These do not impact the identity characteristics of a request. For
topology hiding and 3PCC reasons, B2BUAs on the path of a call may
modify call-id and digit when forwarding a request. Therefore a
mechanism for end-to-end authenticated identification needs to be
tolerant of changes to call-id and digit by intermediate domains.
Note that although call-id and digit were apparently included in the
RFC 4474 signature for replay prevention purposes, it is not clear
that this would work. There are cases related to forking,
redirection and retransmission over UDP transport where the verifier
could legitimately receive repeated requests with the same call-id
and digit values, perhaps with different values in the Request-URI by
intermediate domains.
Elwell Expires August 29, 2009 [Page 24]
Internet-Draft End-to-End Identity Important February 2009
8.4. method of CSeq header field
This does not impact the identity characteristics of a request. It
seems very unlikely that an SBC would modify this field. Therefore a
mechanism for end-to-end authenticated identification does not need
to be tolerant of changes to method by intermediate domains.
8.5. Date header field
This does not impact the identity characteristics of a request, but
in RFC 4474 it is essential to provisions for preventing replay
attacks. Therefore a mechanism for end-to-end authenticated
identification does not need to be tolerant of changes to method by
intermediate domains.
8.6. addr-spec of Contact header field
Substitution of a B2BUA's own contact URI (e.g., for topology hiding
or 3PCC reasons) does not impact the identity characteristics of a
request, as far as the current call is concerned. If a substituted
contact URI is subsequently used as the target of a separate request,
outside the context of the original dialog, the B2BUA would need to
be able to restore the original contact URI and forward the request,
even if the original dialog has terminated, which requires some
stateful or algorithmic mechanism at the B2BUA, but B2BUAs should be
able to do this.
Although substitution of the Contact URI does not impact end-to-end
identification, it was apparently included in the RFC 4474 signature
for replay prevention purposes. It is not clear whether it really
helps prevent replay, since a man-in-the-middle can pervert the
routing of subsequent mid-dialog requests by manipulating Record-
Route (which is not signed) rather than Contact.
8.7. SDP body part
For media steering purposes, B2BUAs in intermediate domains need to
modify the IP address c-lines and the port in m-lines. This does not
impact the identity characteristics of a request, although it means
that the IP address and port for media cannot be assumed to relate to
the source of the SIP request. In that sense, media steering in this
way is harmful, in that a man-in-the-middle could become the media
terminator. This is not a problem if SRTP is used and there is a
mechanism for authenticating the media terminator during key
establishment (e.g., by binding the media terminator to authenticated
source of a SIP request) - in this situation the IP address and port
are unimportant.
Elwell Expires August 29, 2009 [Page 25]
Internet-Draft End-to-End Identity Important February 2009
Clearly an a=fingerprint line should not be modified by intermediate
domains, since this would destroy authentication for the media
concerned (whether this uses SRTP, TLS or some other secure
transport).
Insertion of m-lines can be harmful, since this introduces media that
does not potentially does not terminate where the request originated
(unless they use the same IP addresses and ports as existing media).
Adding media to provide alternatives to what is already proposed can
sometimes be helpful (e.g., RTP/AVP as an alternative to or instead
of RTP/AVPF, to assist interoperability) but can also be harmful
(e.g., adding RTP/AVP as an alternative to or instead of RTP/SAVP,
since that could also be seen as a bid-down attack).
SDP capability negotiation complicates the picture even further,
since the various attribute lines (e.g., a=pcfg, a=tcap, etc.) can
modify the meaning of the SDP in very many ways, some of which might
be harmful and others might be helpful. For example, if providing
media steering, a B2BUA might legitimately want to modify ports and
IP addresses related to media being negotiated.
Formatting changes to SDP (e.g., removal or insertion of white
space), although in most respects harmless, but on the other hand
there is no justification for an intermediate domain to do this.
This seems to indicate that a mechanism for end-to-end authenticated
identification needs to be tolerant of some types of change to SDP by
intermediate domains but should be intolerant of others types of
change. Any mechanism must take account of future evolution of SDP,
perhaps by being tolerant of specific changes (e.g., IP address in
c-line and port in m-line) but intolerant of changes to the rest,
including any future extensions.
8.8. Other body parts
There is generally no justification for an intermediate domain to
add, modify or delete other body parts (e.g., PIDF-LO, SAML
assertions), and therefore any mechanism for end-to-end authenticated
identification should be intolerant of such changes.
9. Conclusions
This document has demonstrated the importance of end-to-end (or at
least end-domain-to-end-domain) identification and authenticated
identification in SIP. Although in many simple cases hop-by-hop
identification or hop-by-hop assertions can be shown to be adequate,
there are many cases where this is simply not the case.
Elwell Expires August 29, 2009 [Page 26]
Internet-Draft End-to-End Identity Important February 2009
This document has also illustrated why current mechanisms are unable
to deliver end-to-end authenticated identification in many practical
situations. In particular, SIP Identity [RFC4474] will not work in
practical situations, because B2BUAs in intermediate domains modify
certain aspects of SIP requests, resulting in the signature being
broken. A good example of a change that breaks the signature is
media steering, whereby a B2BUA modifies IP addresses and ports in
SDP to ensure that media is steered onto a path that can provide the
appropriate quality of service.
The problem can be broken down into two parts:
o Loss of end-to-end authenticated identification caused by the
breaking of SIP Identity signatures on non-E.164-based SIP URIs by
B2BUAs in intermediate domains performing legitimate functions
such as media steering.
o Loss of end-to-end authenticated identification caused by the
breaking of SIP Identity signatures on E.164-based SIP URIs by
B2BUAs in intermediate domains performing legitimate functions
such as media steering, and also by B2BUAs modifying the URI by
changing the domain part and possibly creating a new SIP Identity
signature.
The second part may be harder to solve than the first part. This is
discussed further in [I-D.rosenberg-sip-rfc4474-concerns], which
concludes that there is no simple remedy and instead just the
problems associated with phone numbers and RFC 4474 be documented.
It is assumed that end-to-end authenticated identification is not
achievable when PSTN is involved, as discussed in Section 3.9.
Any solution for end-to-end authenticated identification must be
tolerant of certain legitimate changes to SIP requests as they
traverse intermediate domains. Details of which changes are to be
tolerant need further work, although Section 8 provides some
considerations.
10. Requirements for end-to-end authenticated identification
Consider the following legitimate call from user1 at UA1 in
enterprise1 to user2 at UA2 in enterprise2, via intermediate domains
ITSP-A, ITSP-B and ITSP-C:
Elwell Expires August 29, 2009 [Page 27]
Internet-Draft End-to-End Identity Important February 2009
+----------+ +----------+ +----------+
+---+ SBC SBC +---+ SBC SBC +---+ SBC SBC +---+
| +----------+ +----------+ +----------+ |
| ITSP-A ITSP-B ITSP-C |
| |
+------+------+ +------+------+
| enterprise1 | | enterprise2 |
+------+------+ +------+------+
| |
user1/UA1 user2/UA2
From:sip:user1@enterprise1.com
To:sip:user2@enterprise2.com
We need to differentiate the above legitimate call from the following
illegitimate call where user3 at UA3 in enterprise3 is calling UA2
and is spoofing the identity of user1:
user3/UA3
|
+------+------+
| enterprise3 |
+------+------+
|
+----------+ +----+-----+ +----------+
+---+ SBC SBC +---+ SBC SBC +---+ SBC SBC +---+
| +----------+ +----------+ +----------+ |
| ITSP-A ITSP-B ITSP-C |
| |
+------+------+ +------+------+
| enterprise1 | | enterprise2 |
+------+------+ +------+------+
| |
user1/UA1 user2/UA2
This needs to work both where user1's AoR is not E.164-based (as
shown in the figures) and preferably also where user1's AoR is E.164-
based (e.g., sip:+123456789@enterprise1.com;user=phone). However,
the latter may not be achievable.
TODO: Add specific requirements.
11. IANA considerations
This document requires no IANA actions.
Elwell Expires August 29, 2009 [Page 28]
Internet-Draft End-to-End Identity Important February 2009
12. 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.
13. Acknowledgements
The author received valuable comments from Keith Drage, Kai Fischer,
Cullen Jennings, Hadriel Kaplan, Eric Rescorla, Hannes Tschofenig,
Adam Uzelac, Dean Willis, Dan Wing and Dan York during drafting.
14. Informative References
[RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy
(PGP)", RFC 2015, October 1996.
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[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.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893,
September 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
Elwell Expires August 29, 2009 [Page 29]
Internet-Draft End-to-End Identity Important February 2009
[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-e164-problem-statement]
Elwell, J., "SIP E.164 Problem Statement",
draft-elwell-sip-e164-problem-statement-01 (work in
progress), October 2008.
[I-D.kaplan-sip-uris-change]
Kaplan, H., "Why URIs Are Changed Crossing Domains",
draft-kaplan-sip-uris-change-00 (work in progress),
February 2008.
[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-05 (work in progress),
October 2008.
[I-D.ietf-sipping-sbc-funcs]
Hautakorpi, J., Camarillo, G., Penfield, B., Hawrylyshen,
A., and M. Bhatia, "Requirements from SIP (Session
Initiation Protocol) Session Border Control Deployments",
draft-ietf-sipping-sbc-funcs-08 (work in progress),
January 2009.
[I-D.ietf-sip-certs]
Jennings, C. and J. Fischl, "Certificate Management
Service for The Session Initiation Protocol (SIP)",
draft-ietf-sip-certs-07 (work in progress), November 2008.
[I-D.kuthan-sip-derive]
Kuthan, J., Sisalem, D., Coeffic, R., and V. Pascual,
"Dialog Event foR Identity VErification",
draft-kuthan-sip-derive-00 (work in progress),
October 2008.
[I-D.rosenberg-sip-rfc4474-concerns]
Rosenberg, J., "Concerns around the Applicability of RFC
4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in
progress), February 2008.
Elwell Expires August 29, 2009 [Page 30]
Internet-Draft End-to-End Identity Important February 2009
Author's Address
John Elwell
Siemens Enterprise Communications
Phone: +44 1908 855608
Email: john.elwell@siemens.com
Elwell Expires August 29, 2009 [Page 31]
| PAFTECH AB 2003-2026 | 2026-04-24 06:52:43 |