[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-elwell-sip-connected-identity) 00 01 02 03 04 05 RFC 4916

SIP WG                                                         J. Elwell
Internet-Draft                                               Siemens plc
Intended status: Informational                            August 8, 2006
Expires: February 9, 2007


      Connected Identity in the Session Initiation Protocol (SIP)
                draft-ietf-sip-connected-identity-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 9, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Because of retargeting of a Session Initiation Protocol (SIP) dialog-
   forming request, the User Agent Server (UAS) can have a different
   identity from that in the To header field.  This document provides a
   means for that User Agent (UA) to supply its identity to the peer UA
   by means of a request in the reverse direction and for that identity
   to be signed by an Authentication Service.  The same mechanism can be
   used to indicate a change of identity during a dialog, e.g., because
   of some action in a Public Switched Telephone Network (PSTN) behind a



Elwell                  Expires February 9, 2007                [Page 1]

Internet-Draft              SIP Connected ID                 August 2006


   gateway.  This document normatively updates RFC 3261 (SIP).

   This work is being discussed on the sip@ietf.org mailing list.


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Existing mechanisms for conveying identity in the context
       of a call  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Existing methods for providing authenticated identity
       information  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Overview of solution . . . . . . . . . . . . . . . . . . . . .  6
   6.  Behaviour  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.1.  Behaviour of a UA that issues an INVITE request
           outside the context of an existing dialog  . . . . . . . .  8
     6.2.  Behaviour of a UA that receives an INVITE request
           outside the context of an existing dialog  . . . . . . . .  8
     6.3.  Behaviour of a UA whose identity changes during an
           established INVITE-initiated dialog  . . . . . . . . . . .  8
     6.4.  General UA behaviour . . . . . . . . . . . . . . . . . . .  9
     6.5.  Authentication Service Behaviour . . . . . . . . . . . . .  9
     6.6.  Proxy Behaviour  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Sending connected identity after answering a call  . . . . 11
     7.2.  Sending revised connected identity during a call . . . . . 16
   8.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 21
   9.  Security considerations  . . . . . . . . . . . . . . . . . . . 21
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     11.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 24
















Elwell                  Expires February 9, 2007                [Page 2]

Internet-Draft              SIP Connected ID                 August 2006


1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [2].

   This specification defines the following additional terms:

        caller: the user of the UA that issues an INVITE request to
        initiate a call.

        caller identity: the identity (Address of Record) of a caller.

        callee: the user that answers a call by issuing a 2xx response
        to an INVITE request.

        callee identity: the identity (Address of Record) of a callee.

        potential callee: the user of any UA to which an INVITE request
        is targeted resulting in formation of an early dialog, but
        because of parallel or serial forking of the request, not
        necessarily the user that answers the call.

        connected user: any user involved in an established call,
        including the caller, the callee or any user that replaces the
        caller or callee following a call re-arrangement such as call
        transfer.

        connected identity: the identity (Address of Record) of a
        connected user.


2.  Introduction

   SIP [1] initiates sessions but it also provides information on the
   identities of the parties at both ends of a session.  Users need this
   information to help determine how to deal with communications
   initiated by SIP.  As a call proceeds, these identities may change.
   This can happen for many reasons: calls are forwarded, calls are
   parked and picked up, calls are transferred, calls are queued to be
   picked up by a pool of agents, and so on.  This can have impact on
   the identity of the party that answers a call.  It can also cause the
   identity of a party to change during an established call.

   This document extends the use of the From header field to allow it to
   convey "connected identity" information in either direction within
   the context of an existing INVITE-initiated dialog.




Elwell                  Expires February 9, 2007                [Page 3]

Internet-Draft              SIP Connected ID                 August 2006


   The provision of the identity of the responder in a response
   ("response identity") is outside the scope of this document.


3.  Existing mechanisms for conveying identity in the context of a call

   When establishing a call and its session, the SIP From header field
   in the INVITE request provides a means for conveying the identity of
   the caller (caller identity) from the User Agent Client (UAC) to the
   User Agent Server (UAS), thereby allowing the caller identity to be
   presented to the callee (or a potential callee prior to the call
   being answered).  There is no corresponding mechanism specified for
   conveying the identity of the callee from the UAS to the UAC, to
   allow the callee's identity to be presented to the caller.  The
   identity of the callee is normally expected to be the identity placed
   in the To header field of the INVITE request, but often this
   expectation is not met because a different party answers the call,
   e.g., because of call forwarding.

      The identity in the To header field does not change during the
      routing of an INVITE request and the same value is reflected back
      in the response.  Therefore this is of no use for determining the
      identity of the callee.
      History information [7] gathered during the routing of a request
      and returned in the response can provide additional information to
      the UAC.  However, this does not necessarily clearly indicate the
      Address of Record (AoR) of the UAS.  Also the methods described in
      Section 4 for authentication do not apply to history information,
      which relies instead on hop-by-hop security and transitive trust.
      The Reply-To header field has its own meaning and cannot be relied
      on in all circumstances.
      The Contact header field provides a contact URI, which may not
      reveal the identity (Address of Record) of the user on whose
      behalf the response is sent.

   Parties involved in a call can change owing to actions such as call
   transfer.  If such actions are achieved by issuing a new INVITE
   request (with a Replaces header field) between the two User Agents
   (UA) that are to be involved in the re-arranged call, the SIP From
   header field in the INVITE request can provide identity information
   in one direction, but again there is no mechanism for conveying
   identity information in the reverse direction.

   However, call re-arrangements are not always carried out using a new
   INVITE request.  Sometimes a Back-to-Back User Agent (B2BUA) performs
   call re-arrangements using third party call control (3PCC)
   techniques.  For example, when call transfer is carried out by a
   B2BUA the transferred UA normally receives only a re-INVITE request



Elwell                  Expires February 9, 2007                [Page 4]

Internet-Draft              SIP Connected ID                 August 2006


   in the context of the original dialog between that UA and the B2BUA.
   This forces the UA to re-negotiate the session with the new remote
   party, but introduces a need to convey the identity of the new remote
   party to the UA.  Because there is no new INVITE request (outside the
   context of the existing dialog), techniques applicable to new calls
   do not apply.

   Another case where call re-arrangements are not carried out using a
   new INVITE request is where one of the UAs is a gateway to a Public
   Switched Telephone Network (PSTN) and a call re-arrangement such as
   call transfer has occurred within the PSTN.  The gateway then has a
   need to convey the identity of the new party within the PSTN to the
   remote UA.  This needs to be done within the context of the existing
   dialog between the gateway and the remote UA.  In this case there is
   probably not even any need to re-negotiate the session - the only
   requirement is to update the identity information.  This is achieved
   using a Re-INVITE or UPDATE request.

   This document defines a mechanism for conveying the callee identity
   to a caller when a call is answered.  The same mechanism can be used
   to convey the identity of a user that replaces the caller or callee
   following a call re-arrangement such as call transfer.  In general
   the mechanism delivers connected identity, or the identity of a
   connected user.  The same mechanism can also be used to convey the
   identity of a potential callee prior to answer.


4.  Existing methods for providing authenticated identity information

   Delivery of connected identity is of limited value unless it can be
   authenticated.  This section explores existing means for
   authenticating caller identity and their potential for authenticating
   connected identity.

   The UAC can falsify the From header field in a request.  SIP has
   several means of providing cryptographic authentication of a
   request's source identity.

   One such means for providing authenticated identity in requests is
   HTTP-based digest authentication, as specified in [1].  Although a
   UAS can require digest authentication, it is not usually feasible
   between an arbitrary pair of UAs because of reliance on a shared
   secret.  To achieve scalability, methods based on public key
   cryptography are essential.  Similar issues would apply if this were
   to be used for connected identity.

   Another method, Authenticated Identity Body (AIB) is specified in
   [5], and is applicable to responses as well as requests.  This



Elwell                  Expires February 9, 2007                [Page 5]

Internet-Draft              SIP Connected ID                 August 2006


   requires a UA to have a private key and associated certificate in
   order to sign an identity in a body in the request or response.
   Potentially it could be used for connected identity.  However, this
   has seen little deployment, since the public key infrastructures
   needed to support private keys and certificates in every UA are not
   generally available.

   A third method, SIP Identity, is specified in [3].  For signature
   this uses a private key and certificate associated with the domain
   indicated in the From header field URI.  An Authentication Service,
   typically located at the outbound proxy, authenticates the UAC by
   some means, using digest authentication for example, and then inserts
   an Identity header field and an Identity-Info header field in the
   forwarded request.  The Identity header field contains a signature
   using the domain's private key and the Identity-Info header field
   references the corresponding certificate.  This third method, which
   avoids the need for private keys and certificates in UAs, is adopted
   as the basis for authenticating connected identity.


5.  Overview of solution

   A mid-dialog request is used to provide connected identity.  The UAC
   for that request inserts its identity in the From header field of the
   request and the Identity header field can be used to provide
   authentication.

   A request in the opposite direction to the INVITE request prior to or
   at the time the call is answered can indicate the identity of the
   potential callee or callee respectively.  A request in the same
   direction as the INVITE request prior to answer can indicate a change
   of caller.  A request in either direction after answer can indicate a
   change of user.  In all cases a dialog (early or confirmed) must be
   established before such a request can be sent.

      Note that it might also be possible to provide a means of
      indicating the identity of the potential callee or callee in the
      response to the INVITE request.  However, at present the problem
      of authenticating a response is still subject to study.  In the
      absence of a solution to this problem, the simple solution of
      using a request in the opposite direction to the INVITE request is
      sufficient.  Furthermore a Globally Routable User agent URI (GRUU)
      [8], if used in the Contact header field in a dialog-forming
      response to an INVITE request, can reveal the identity of the
      potential callee (subject to there being no need for anonymity and
      subject to policy for allocating GRUUs), but this does not deal
      with the problem of a connected identity changing mid-dialog.




Elwell                  Expires February 9, 2007                [Page 6]

Internet-Draft              SIP Connected ID                 August 2006


   This solution uses the UPDATE method for the additional request.  To
   send the callee identity the UAS for the INVITE request sends the
   UPDATE request after sending the 2xx response to the INVITE request
   and receiving an ACK request.  To send the potential callee identity
   the UAS for the INVITE request sends the UPDATE request after sending
   a reliable 1xx response to the INVITE request and after receiving a
   PRACK request and responding to it.  The UPDATE request could
   conceivably be used for other purposes too, e.g., during an early
   dialog it could be used to send the potential callee identity at the
   same time as an SDP offer for early media.  To indicate a connected
   identity change during an established call, the re-INVITE method can
   be used if required for other purposes (e.g., when a B2BUA performs
   transfer using 3PCC techniques it may need to issue a re-INVITE
   request without an SDP offer to solicit an SDP offer from the UA).

   This solution involves changing the URI (not the tags) in the To and
   From header fields of mid-dialog requests and their responses,
   compared with the corresponding values in the dialog forming request
   and response.  Changing the To and From header field URIs was
   contemplated in Section 12.2.1.1 of RFC 3261, which says:

      "Usage of the URI from the To and From fields in the original
      request within subsequent requests is done for backwards
      compatibility with RFC 2543, which used the URI for dialog
      identification.  In this specification, only the tags are used for
      dialog identification.  It is expected that mandatory reflection
      of the original To and From URI in mid-dialog requests will be
      deprecated in a subsequent revision of this specification."

   This document therefore deprecates mandatory reflection of the
   original To and From URIs in mid-dialog requests and their responses.
   It is assumed that deployed proxies will already be able to tolerate
   a change of URI, since this has been expected for a considerable
   time.  To cater for any UAs that are not able to tolerate a change of
   URI, a new option tag "id-change" is introduced for providing a
   positive indication of support in the Supported header field.

   In addition to allowing the From header field URI to change during a
   dialog to reflect the connected identity, this document also requires
   a UA that has received a connected identity in the URI of the From
   header field of a mid-dialog request to use that URI in the To header
   field of any subsequent mid-dialog request sent by that UA.


6.  Behaviour






Elwell                  Expires February 9, 2007                [Page 7]

Internet-Draft              SIP Connected ID                 August 2006


6.1.  Behaviour of a UA that issues an INVITE request outside the
      context of an existing dialog

   When issuing an INVITE request, a UA that supports changes of URI in
   the From and To header fields during a dialog MUST include the id-
   change option tag in the Supported header field.

6.2.  Behaviour of a UA that receives an INVITE request outside the
      context of an existing dialog

   After receiving an INVITE request, a UA that supports changes of URI
   in the From and To header fields during a dialog MUST include the id-
   change option tag in the Supported header field of any dialog-forming
   response.

   After an early dialog has been formed (after sending a reliable
   provisional response the INVITE request), if the id-change option tag
   has been received in a Supported header field, the UA MAY issue an
   UPDATE request [4] on the same dialog.  After a full dialog has been
   formed (after sending a 2xx provisional response the INVITE request),
   if the id-change option tag has been received in a Supported header
   field and an UPDATE request has not already been sent on the early
   dialog, the UA MUST issue an UPDATE request on the same dialog.  In
   either case the UPDATE request MUST contain the callee's (or
   potential callee's) identity in the URI of the From header field (or
   an anonymous identity if anonymity is required).

      Note that even if the URI does not differ from that in the To
      header field URI of the INVITE request, sending a new request
      allows the Authentication Service to assert authentication of this
      identity and confirms to the peer UA that the connected identity
      is the same as that in the To header field URI of the INVITE
      request.

6.3.  Behaviour of a UA whose identity changes during an established
      INVITE-initiated dialog

   If the id-change option tag has been received in a Supported header
   field during an INVITE-initiated dialog and if the identity
   associated with the UA changes (e.g., due to transfer) compared to
   that last indicated in the From header field of a request sent by
   that UA, the UA MUST issue a request on the same dialog containing
   the new identity in the URI of the From header field (or an anonymous
   identity if anonymity is required).  For this purpose the UA MUST use
   the UPDATE method unless for other reasons the re-INVITE method is
   being used at the same time.





Elwell                  Expires February 9, 2007                [Page 8]

Internet-Draft              SIP Connected ID                 August 2006


6.4.  General UA behaviour

   When sending a mid-dialog request a UA MUST observe the requirements
   of [3] when populating the From header field URI, including
   provisions for achieving anonymity.

   After sending a request with a revised From header field URI (i.e.,
   revised compared to the URI sent in the From header field of the
   previous request on this dialog or in the To header field of the
   received dialog-forming INVITE request if no request has been sent),
   the UA MUST be prepared to receive the revised URI in the To header
   field of subsequent mid-dialog requests and MUST also continue to be
   prepared to receive the old URI at least until a request containing
   the revised URI has been received.

   After receiving a 2xx response to a request with a revised URI in the
   From header field (i.e., revised compared to the URI sent in the From
   header field of the previous request on this dialog or in the To
   header field of the received dialog-forming INVITE request if no
   request has been sent), the UA MUST send the same URI in the From
   header field of any future requests on the same dialog, unless the
   identity changes again.

   If a UA receives a mid-dialog request from the peer UA, the UA may
   make use of the identity in the From header field URI (e.g., by
   indicating to the user).  The UA MAY act in accordance with [3] and
   verify any signature in the Identity header field and discriminate
   between signed and unsigned identities.

   If a UA receives a mid-dialog request from the peer UA in which the
   From header field URI differs from that received in the previous
   request on that dialog or that sent in the To header field of the
   original INVITE request and if the UA sends a 2xx response, the UA
   MUST use this revised URI in the To header field of any future
   requests it sends on the same dialog (irrespective of whether the
   received identity is supported by a valid signature).

6.5.  Authentication Service Behaviour

   An Authentication Service MUST behave in accordance with [3] when
   dealing with mid-dialog requests.

      Note that [3] is silent on how to behave if the identity in the
      From header field is not one that the UAC is allowed to assert,
      and therefore it is a matter for local policy whether to reject
      the request or forward it without an Identity header field.
      Policy may be different for a mid-dialog request compared with
      other requests.



Elwell                  Expires February 9, 2007                [Page 9]

Internet-Draft              SIP Connected ID                 August 2006


6.6.  Proxy Behaviour

   A proxy that record routes during an INVITE request MUST be tolerant
   of changes of the From header field URI compared with that in the
   initial INVITE request for mid-dialog requests in the same direction
   as the INVITE request and MUST be tolerant of changes of the From
   header field URI compared with the To header field URI in the initial
   INVITE request for mid-dialog requests in the opposite direction.  A
   proxy that record routes MUST also be tolerant of changes of the To
   header field URI in mid dialog requests to reflect changes of the
   From header field URI in mid-dialog requests in the opposite
   direction.


7.  Examples

   In the examples the domain example.com is assumed to have the
   following private key and certificate rendered in OpenSSL format).
   The private key is used by the Authentication Service for generating
   the signature in the Identity header field.































Elwell                  Expires February 9, 2007               [Page 10]

Internet-Draft              SIP Connected ID                 August 2006


      -----BEGIN RSA PRIVATE KEY-----
      MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO
      aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc
      IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB
      AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt
      PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw
      +rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30
      tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H
      0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0
      J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C
      DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r
      xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU
      6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK
      Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk
      -----END RSA PRIVATE KEY-----
      -----BEGIN CERTIFICATE-----
   TODO
      -----END CERTIFICATE-----

7.1.  Sending connected identity after answering a call

   In this example Carol's UA has been reached by retargeting at the
   proxy and thus her identity (AoR) is not equal to that in the To
   header field of the received INVITE request (Bob).  Carol's UA
   conveys Carol's identity in the From header field of an UPDATE
   request.  The proxy also provides an Authentication Service and
   therefore adds Identity and Identity-Info header fields to the UPDATE
   request.























Elwell                  Expires February 9, 2007               [Page 11]

Internet-Draft              SIP Connected ID                 August 2006


Alice's UA        PROXY +          Carol's UA
              Authentication
                 Service

      INVITE(1)            INVITE(2)
  ---------------->   ---------------->

       200(4)                200(3)
  <----------------   <----------------

       ACK(5)                ACK(6)
  ---------------->   ---------------->

      UPDATE(8)            UPDATE(7)
  <----------------   <----------------

       200(9)                200(10)
  ---------------->   ---------------->

INVITE (1):

INVITE sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: id-change
Contact: <sip:alice@ua1.example.com>
Content-Type: application/sdp
Content-Length: 154

v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

INVITE (2):

INVITE sip:Carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.1



Elwell                  Expires February 9, 2007               [Page 12]

Internet-Draft              SIP Connected ID                 August 2006


To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: id-change
Contact: <sip:alice@ua1.example.com>
Record-Route: <sip:proxy.example.com;lr>
Identity: "dKJ97..."
Identity-Info: <https://example.com/example.cer>;alg=rsa-sha1
Content-Type: application/sdp
Content-Length: 154

v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

200 (3):

SIP/2.0 200 OK
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhds;received=192.0.2.2
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.1
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: id-change
Contact: <sip:carol@ua2.example.com>
Record-Route: <sip:proxy.example.com;lr>
Content-Type: application/sdp
Content-Length: 154

v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

200 (4):



Elwell                  Expires February 9, 2007               [Page 13]

Internet-Draft              SIP Connected ID                 August 2006


SIP/2.0 200 OK
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.1
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: id-change
Contact: <sip:carol@ua2.example.com>
Record-Route: <sip:proxy.example.com;lr>
Content-Type: application/sdp
Content-Length: 154

v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

ACK (5):

ACK sip:carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Route: <sip:proxy.example.com;lr>
Content-Length: 0

ACK (6):

ACK sip:carol@ua2.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdt
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9;received=192.0.2.1
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0

UPDATE (7):

UPDATE sip:Alice@ua1.example.com SIP/2.0



Elwell                  Expires February 9, 2007               [Page 14]

Internet-Draft              SIP Connected ID                 August 2006


Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:15 GMT
Route: <sip:proxy.example.com;lr>
Contact: <sip:Carol@ua2.example.com>
Content-Length: 0

      Note that the URI in the From header field differs from that in
      the To header field in the INVITE request/response.  However, the
      tag is the same as that in the INVITE response.





































Elwell                  Expires February 9, 2007               [Page 15]

Internet-Draft              SIP Connected ID                 August 2006


UPDATE (8):

UPDATE sip:Alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.3
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:15 GMT
Contact: <sip:Carol@ua2.example.com>
Identity: "TODO"
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0

200 (9):

SIP/2.0 200 OK
Via: SIP/2.0/TLS proxy.example.com;branch=z9hG4bK776asdhdu;received=192.0.2.2
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.3
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0

200 (10):

SIP/2.0 200 OK
Via: SIP/2.0/TLS ua2.example.com;branch=z9hG4bKnashdt1;received=192.0.2.3
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0

7.2.  Sending revised connected identity during a call

   In this example a call is established between Alice and Bob, where
   Bob (not shown) lies behind a B2BUA.  Bob's identity is conveyed by
   an UPDATE request.  Then call transfer occurs in the B2BUA, such that
   Alice becomes connected to Carol (also not shown), and a re-INVITE
   request is issued allowing the session to be renegotiated.  The B2BUA
   provides the Authentication Service and thus generates the Identity
   header field in the re-INVITE request to provide authentication of



Elwell                  Expires February 9, 2007               [Page 16]

Internet-Draft              SIP Connected ID                 August 2006


   Carol's identity.


















































Elwell                  Expires February 9, 2007               [Page 17]

Internet-Draft              SIP Connected ID                 August 2006


Alice's UA        B2BUA

      INVITE(1)
  ---------------->

       200(2)
  <----------------

       ACK(3)
  ---------------->

      UPDATE(4)
  <----------------

       200(5)
  ---------------->

    re-INVITE(6)
  <----------------

       200(7)
  ---------------->

       ACK(8)
  <---------------

INVITE (1):

INVITE sip:Bob@example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: id-change
Contact: <sip:alice@ua1.example.com>
Content-Type: application/sdp
Content-Length: 154

v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0



Elwell                  Expires February 9, 2007               [Page 18]

Internet-Draft              SIP Connected ID                 August 2006


a=rtpmap:0 PCMU/8000

200 (2)

SIP/2.0 200 OK
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds8;received=192.0.2.1
To: Bob <sip:bob@example.com>;tag=2ge46ab5
From: Alice <sip:alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE
Supported: id-change
Contact: <sip:xyz@b2bua.example.com>
Content-Type: application/sdp
Content-Length: 154

v=0
o=UserB 2890844536 2890844536 IN IP4 ua2.example.com
s=Session SDP
c=IN IP4 ua2.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

ACK (3)

ACK sip:xyz@b2bua.example.com SIP/2.0
Via: SIP/2.0/TLS ua1.example.com;branch=z9hG4bKnashds9
From: Alice <sip:Alice@example.com>;tag=13adc987
To: Bob <sip:Bob@example.com>;tag=2ge46ab5
Call-ID: 12345600@ua1.example.com
CSeq: 1 ACK
Max-Forwards: 70
Content-Length: 0

UPDATE (4)

UPDATE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1
From: Bob <sip:Bob@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:12 GMT
Contact: <sip:xyz@b2bua.example.com>
Identity: "TODO"
Identity-Info: <https://example.com/cert>;alg=rsa-sha1



Elwell                  Expires February 9, 2007               [Page 19]

Internet-Draft              SIP Connected ID                 August 2006


Content-Length: 0

200 (5)

SIP/2.0 200 OK
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdt1;received=192.0.2.2
From: Bob <sip:Bob@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 2 UPDATE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 0

re-INVITE (6)

INVITE sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:03:20 GMT
Contact: <sip:xyz@b2bua.example.com>
Identity: "TODO"
Identity-Info: <https://example.com/cert>;alg=rsa-sha1
Content-Length: 0

200 (7)

SIP/2.0 200 OK
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxy;received=192.0.2.2
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 INVITE
Contact: <sip:Alice@ua1.example.com>
Content-Length: 154

v=0
o=UserA 2890844526 2890844526 IN IP4 ua1.example.com
s=Session SDP
c=IN IP4 ua1.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000

ACK (8)



Elwell                  Expires February 9, 2007               [Page 20]

Internet-Draft              SIP Connected ID                 August 2006


ACK sip:alice@ua1.example.com SIP/2.0
Via: SIP/2.0/TLS b2bua.example.com;branch=z9hG4bKnashdxz
From: Carol <sip:Carol@example.com>;tag=2ge46ab5
To: Alice <sip:Alice@example.com>;tag=13adc987
Call-ID: 12345600@ua1.example.com
CSeq: 3 ACK
Max-Forwards: 70
Content-Length: 154

v=0
o=UserC 2890844546 2890844546 IN IP4 ua3.example.com
s=Session SDP
c=IN IP4 ua3.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000



8.  IANA considerations

   This specification registers a new SIP option tag, as per the
   guidelines in Section 27.1 of RFC 3261.

   Name: id-change

   Description: This option tag is used to indicate that a UA supports
   changes to URIs in From and To header fields during a dialog.


9.  Security considerations

   [3] discusses security considerations relating to the Identity header
   field in some detail.  Those same considerations apply when using the
   Identity header field to authenticate a connected identity in the
   From header field URI of a mid-dialog request.

   A received From header field URI in a mid-dialog request for which no
   valid Identity header field (or other means of authentication) has
   been receivd either in this request or in an an earlier request on
   this dialog cannot be trusted (except in very closed environments)
   and should be treated in a similar way to a From header field in a
   dialog-initiating request that is not backed up by a valid Identity
   header field.

   A signed connected identity in a mid-dialog request (URI in the From
   header field accompanied by a valid Identity header field) provides
   information about the peer UA in a dialog.  In the case of the UA



Elwell                  Expires February 9, 2007               [Page 21]

Internet-Draft              SIP Connected ID                 August 2006


   that was the UAS in the dialog-forming request, this identity is not
   necessarily the same as that in the To header field of the dialog-
   forming request.  This is because of retargeting during the routing
   of the dialog-forming request.  A signed connected identity says
   nothing about the legitimacy of such retargeting, but merely reflects
   the result of that retargeting.

   Likewise, when a signed connected identity indicates a change of
   identity during a dialog, it conveys no information about the reason
   for such change of identity or its legitimacy.

   Use of the sips URI scheme can minimise the chances of attacks in
   which inappropriate connected identity information is sent, either at
   call establishment time or during a call.

   Anonymity may be required by the user of a connected UA.  For
   anonymity the UA must populate the URI in the From header field of a
   mid-dialog request in the way described in [3].


10.  Acknowledgments

   Thanks to Francois Audet, Frank Derks, Steffen Fries, Vijay Gurbani,
   Cullen Jennings, Hans Persson, Jon Peterson, Eric Rescorla, Schida
   Schubert, Ya-Ching Tan and Dan Wing for providing valuable comments.


11.  References

11.1.  Normative References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
        Identity Management in the Session Initiation Protocol (SIP)",
        draft-ietf-sip-identity-06 (work in progress), October 2005.

   [4]  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
        Method", RFC 3311, September 2002.







Elwell                  Expires February 9, 2007               [Page 22]

Internet-Draft              SIP Connected ID                 August 2006


11.2.  Informative References

   [5]  Peterson, J., "Session Initiation Protocol (SIP) Authenticated
        Identity Body (AIB) Format", RFC 3893, September 2004.

   [6]  Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
        "SIP: Session Initiation Protocol", RFC 2543, March 1999.

   [7]  Barnes, M., "An Extension to the Session Initiation Protocol
        (SIP) for Request History Information", RFC 4244, November 2005.

   [8]  Rosenberg, J., "Obtaining and Using Globally Routable User Agent
        (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)",
        draft-ietf-sip-gruu-07 (work in progress), March 2006.


Author's Address

   John Elwell
   Siemens plc
   Technology Drive
   Beeston, Nottingham  NG9 1LA
   UK

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

























Elwell                  Expires February 9, 2007               [Page 23]

Internet-Draft              SIP Connected ID                 August 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Elwell                  Expires February 9, 2007               [Page 24]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/