[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

SIP WG                                                         J. Elwell
Internet-Draft                         Siemens Enterprise Communications
Intended status:  Informational                         January 21, 2009
Expires:  July 25, 2009


 End-to-End Identity Important in the Session Initiation Protocol (SIP)
             draft-elwell-sip-e2e-identity-important-02.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 July 25, 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  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



Elwell                    Expires July 25, 2009                 [Page 1]


Internet-Draft        End-to-End Identity Important         January 2009


   request (or caller identification).  It describes how identification
   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.












































Elwell                    Expires July 25, 2009                 [Page 2]


Internet-Draft        End-to-End Identity Important         January 2009


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  . . . . . . . . . . . . . . . . . . . . . . . . 11
     4.2.  Example 2  . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.3.  Example 3  . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.4.  Example 4  . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.5.  Example 5  . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.6.  Example 6  . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.7.  Example 7  . . . . . . . . . . . . . . . . . . . . . . . . 13
     4.8.  Example 8  . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.9.  Example 9  . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.10. Example 10 . . . . . . . . . . . . . . . . . . . . . . . . 15
     4.11. Example 11 . . . . . . . . . . . . . . . . . . . . . . . . 15
     4.12. Example 12 . . . . . . . . . . . . . . . . . . . . . . . . 15
   5.  Why end-to-end identification is important . . . . . . . . . . 16
   6.  Why end-to-end authenticated identification is important . . . 16
   7.  Why B2BUAs break SIP Identity signatures . . . . . . . . . . . 17
     7.1.  Changing the SDP body part . . . . . . . . . . . . . . . . 18
     7.2.  Changing the Contact and Call-Id header fields . . . . . . 19
     7.3.  Changing the From URI  . . . . . . . . . . . . . . . . . . 19
     7.4.  Changing the To URI  . . . . . . . . . . . . . . . . . . . 20
     7.5.  Protocol repair  . . . . . . . . . . . . . . . . . . . . . 20
   8.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  Requirements for end-to-end authenticated identification . . . 21
   10. IANA considerations  . . . . . . . . . . . . . . . . . . . . . 21
   11. Security considerations  . . . . . . . . . . . . . . . . . . . 21
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   13. Informative References . . . . . . . . . . . . . . . . . . . . 21
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23









Elwell                    Expires July 25, 2009                 [Page 3]


Internet-Draft        End-to-End Identity Important         January 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 July 25, 2009                 [Page 4]


Internet-Draft        End-to-End Identity Important         January 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 July 25, 2009                 [Page 5]


Internet-Draft        End-to-End Identity Important         January 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 July 25, 2009                 [Page 6]


Internet-Draft        End-to-End Identity Important         January 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 July 25, 2009                 [Page 7]


Internet-Draft        End-to-End Identity Important         January 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 July 25, 2009                 [Page 8]


Internet-Draft        End-to-End Identity Important         January 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 July 25, 2009                 [Page 9]


Internet-Draft        End-to-End Identity Important         January 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 July 25, 2009                [Page 10]


Internet-Draft        End-to-End Identity Important         January 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.

   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.



Elwell                    Expires July 25, 2009                [Page 11]


Internet-Draft        End-to-End Identity Important         January 2009


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.

     bank.com               sp.net                                Alice
       From:sip:bob@bank.com   From:sip:+123456000@bank.com;user=phone
       -------------------->     ---------------------------------->

   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.

     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



Elwell                    Expires July 25, 2009                [Page 12]


Internet-Draft        End-to-End Identity Important         January 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.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.

     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.

     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



Elwell                    Expires July 25, 2009                [Page 13]


Internet-Draft        End-to-End Identity Important         January 2009


   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
        ------------->          -------------->    --------------->

   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).

     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
       ------------------>   ------------------>   ------------------>




Elwell                    Expires July 25, 2009                [Page 14]


Internet-Draft        End-to-End Identity Important         January 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.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.

     client.org         example.com           sp.net             Alice
       From:sip:+123498765   From:sip:+123498765   From:sip:+123498000
       @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).

     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.






Elwell                    Expires July 25, 2009                [Page 15]


Internet-Draft        End-to-End Identity Important         January 2009


     e.com                      uksp.net                        Fred
         From:sip:+123456789             From:sip:+445678000
         @e.com;user=phone               @uksp.net;user=phone
        -------------------->           ------------------------>

   This example does not deliver end-to-end identification.  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

   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.


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



Elwell                    Expires July 25, 2009                [Page 16]


Internet-Draft        End-to-End Identity Important         January 2009


   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@enterprise.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.

   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.


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.



Elwell                    Expires July 25, 2009                [Page 17]


Internet-Draft        End-to-End Identity Important         January 2009


   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 detailed are given in
   [I-D.ietf-sipping-sbc-funcs], but the result is that SBCs frequently
   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.







Elwell                    Expires July 25, 2009                [Page 18]


Internet-Draft        End-to-End Identity Important         January 2009


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 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
   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,



Elwell                    Expires July 25, 2009                [Page 19]


Internet-Draft        End-to-End Identity Important         January 2009


   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
   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.  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.

   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



Elwell                    Expires July 25, 2009                [Page 20]


Internet-Draft        End-to-End Identity Important         January 2009


   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.


9.  Requirements for end-to-end authenticated identification

   To be added.


10.  IANA considerations

   This document requires no IANA actions.


11.  Security considerations

   Authentication of parties involved in a call is an essential part of
   this document and is fully discussed in the preceding sections.
   There are no other security considerations.


12.  Acknowledgements

   The author received valuable comments from Kai Fischer, Hadriel
   Kaplan, Adam Uzelac, Dan Wing and Dan York during drafting.


13.  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.



Elwell                    Expires July 25, 2009                [Page 21]


Internet-Draft        End-to-End Identity Important         January 2009


   [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.

   [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



Elwell                    Expires July 25, 2009                [Page 22]


Internet-Draft        End-to-End Identity Important         January 2009


              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.


Author's Address

   John Elwell
   Siemens Enterprise Communications

   Phone:  +44 115 943 4989
   Email:  john.elwell@siemens.com


































Elwell                    Expires July 25, 2009                [Page 23]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/