[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00

SIP WG                                                         J. Kuthan
Internet-Draft                                                D. Sisalem
Intended status: Standards Track                              R. Coeffic
Expires: April 28, 2009                                       V. Pascual
                                                                 Tekelec
                                                        October 25, 2008


                 Dialog Event foR Identity VErification
                       draft-kuthan-sip-derive-00

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on April 28, 2009.

Abstract

   This document provides a simple mechanism to prevent an attacker from
   presenting a forged "From" header field.  It offers an end-to-end
   identity assumption which does not require any previous association
   or trust relationship between administrative domains or the UAs.  The
   UAS verifies the "From" header by subscribing to the Dialog Event
   package [RFC 4235] at the AOR in the "From" header field.  If the
   entity calling is registered under this AOR, it will confirm that it
   is calling by sending some valid dialog state.  In this case, the
   identity of the caller is considered to be verified.




Kuthan, et al.           Expires April 28, 2009                 [Page 1]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview of operation  . . . . . . . . . . . . . . . . . . . .  4
   4.  434 Response Code Definition . . . . . . . . . . . . . . . . .  6
   5.  Behaviour  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Applicaibility . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Protocol compatibility . . . . . . . . . . . . . . . . . .  8
     6.2.  Limitations  . . . . . . . . . . . . . . . . . . . . . . .  8
   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Example 1: Verified call . . . . . . . . . . . . . . . . .  9
     7.2.  Example 2: Unverified call . . . . . . . . . . . . . . . . 12
     7.3.  Example 3: Suspicious call . . . . . . . . . . . . . . . . 14
     7.4.  Example 4: Unverified call . . . . . . . . . . . . . . . . 15
     7.5.  Example 5: Verified call . . . . . . . . . . . . . . . . . 17
     7.6.  Example 6: Verified call . . . . . . . . . . . . . . . . . 18
     7.7.  Example 7: Suspicious call . . . . . . . . . . . . . . . . 20
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 22
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   10. Grammar  . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     12.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 24
























Kuthan, et al.           Expires April 28, 2009                 [Page 2]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


1.  Introduction

   The Session Initiation Protocol (SIP) [RFC3261] [2], creates,
   modifies and terminates sessions but also provides information on the
   identitites of the users involved at both ends of a session.
   Providing a very basic mechanism for identifying users involved in a
   session or call in SIP, the usage of the URI from the "To:" and
   "From:" fields in the original request within subsequent requests is
   done for backwards compatibility with [RFC2543].  The former,
   specifies the desired logical recipient of the request and the later
   represents the logical identity of the initiator of the request.  An
   identifier delivered in a "From:" header field contains a URI (TEL,
   SIP or SIPS URI) and can be optionally accompanied by a "display-
   name" field, which typically gives further information about the
   caller.  In the case of an INVITE-request, the delivered identifier
   is normally presented as "Caller ID" by a human-readable user
   interface (e.g. a phone's display) or used automatically to decide
   whether the call requires special treatment (e.g. black and white
   lists).

   The value that populates the "From:" header field in requests
   generated by a particular UA is usually pre-provisioned by the user
   or by the administrators of the user's local domain.  Outside the
   context of an existing dialog, requests sent by the callee to the
   caller use the callee's address in the "From:" header field [2]; that
   is, the "public address" of the user, also known as address-of-record
   (AOR).

   Although a UAC should place its identity (display-name and AOR) in
   the "From:" header field of a SIP request, the "Caller ID" can be
   easily forged, either by the UAC or by an intermediary, through
   simple modification of the "From:" header field.  So far, in the
   absence of some sort of authentication mechanism, a UAS has no end-
   to-end mechanism to verify that the "From:" header field of a request
   has been populated appropriately.  Therefore the "Caller-ID" cannot
   be relied upon.  Since in SIP there is no built-in assurance that the
   user can legitimately claim this identity, some solutions have been
   proposed.  [I-D.elwell-sip-e2e-identity-important] [4] surveys some
   of these existing solutions.  However, a user is likely to have a SIP
   digest authentication shared secret only with a SIP Server in the
   same administrative domain and only a few SIP UAs support the end-
   user certificates necessary to authenticate themselves.
   Nevertheless, it is desirable for SIP UAs to be able to send and
   receive requests from destinations with which they don't have any
   previous association or trust relationship while having a reasonable
   assurance that the "Caller-ID" is not misleading.

   [RFC3261] [2] describes a Dialog as a peer-to-peer relationship



Kuthan, et al.           Expires April 28, 2009                 [Page 3]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


   between two SIP user agents that persists for some time.  A dialog is
   identified at each UA with a unique dialog-ID, which consists of a
   Call-ID value, a local tag and a remote tag.  When a UA sends a
   request outside of a dialog, it provides only "half" of the dialog
   ID.  The dialog is completed from the responses contributing the
   second "half" of the dialog ID.

   The INVITE-Initiated Dialog Event Package for SIP [RFC4235] [3]
   defines an event package for INVITE-initiated dialog usages.  It
   allows users to subscribe to another user and to receive notification
   of the changes in state of INVITE-initiated dialog usages in which
   the subscribed-to user is involved.

   This document provides a simple mechanism to prevent an attacker from
   presenting a forged "From" header field.  It offers an end-to-end
   identity assumption which does not require any previous association
   or trust relationship between administrative domains or the UAs.  The
   UAS verifies the "From" header by subscribing to the Dialog Event
   package [RFC 4235] at the AOR in the "From" header field.  If the
   entity calling is registered under this AOR, it will confirm that it
   is calling by sending some valid dialog state.  In this case, the
   identity of the caller is considered to be verified.


2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14 [1] and indicate requirement levels for compliant
   implementations.

   The other concepts used in this document are compatible with RFC3261
   [2] and RFC4235 [3].


3.  Overview of operation

   This section provides a brief overview of the operation of the
   mechanism.  It is tutorial in nature and should not be considered
   normative.

   The mechanism proposed in this document is based on the INVITE-
   Initiated Dialog Event Package for SIP [RFC 4235] [3], which defines
   a Dialog event package for the SIP Events architecture [RFC 3856].
   Using the Dialog event package, a Callee can subscribe to a Caller
   and receive notification of the state of an INVITE-initiated "half-
   dialog" (resulting from the generation of an INVITE-request for which



Kuthan, et al.           Expires April 28, 2009                 [Page 4]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


   no final responses or provisional responses with tags has been
   received) in which both the subscriber and the subscribed-to users
   are involved.  A positive response (2xx) and a subsequent
   notification to this subscription indicates the existence of that
   "half-dialog" at the user registered at the AOR present in the
   INVITE's "From" header field.  In that case, the conveyed identity of
   the Caller (From header field) is considered to be verified.


      Caller           Proxy 1          Proxy 2          Callee
        |                |                |                |       --------
        | INVITE F1      |                |                |
        |--------------->| INVITE F2      |                |       INVITE "half-dialog"
        |                |--------------->| INVITE F3      |
        |                |                |--------------->|       --------
        |                |                | SUBSCRIBE F4   |
        |                | SUBSCRIBE F5   |<---------------|
        | SUBSCRIBE F6   |<---------------|                |
        |<---------------|                |                |
        | 200 F7         |                |                |
        |--------------->| 200 F8         |                |       SUBSCRIBE "dialog"
        |                |--------------->| 200 F9         |
        |                |                |--------------->|
        | NOTIFY F10     |                |                |
        |------------------------------------------------->|
        |                |                | 200 F11        |
        |<-------------------------------------------------|       --------
        |                |                | 200 F12        |
        |                | 200 F13        |<---------------|
        | 200 F14        |<---------------|                |
        |<---------------|                |                |       INVITE "dialog"
        | ACK F15        |                |                |
        |------------------------------------------------->|       --------


   Figure 1: Overview of Operation

   Figure 1 shows the basic model of operation.  When the Caller (UAC)
   desires to initiate a session with the Callee (UAS), it forms an
   INVITE-request (F1-F3) indicating its identity (AOR) in the "From:"
   header field.  This request is forwarded traversing some servers,
   Proxy 1 and Proxy 2.  When the UAS receives the INVITE request, it
   needs to decide whether to authorize or reject the call based on the
   identity of the sender (conveyed in the "From:" header field).
   Hence, prior to accepting the call, the Callee desires to verify the
   identity of the potential Caller.  This is done by inspecting the
   "From:" header field and sending a subscription to the dialog event
   package (F4-F6) in the opposite direction to the INVITE request.  The



Kuthan, et al.           Expires April 28, 2009                 [Page 5]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


   SUBSCRIBE request is sent before any 18x or final response to the
   identity specified in the INVITE's "From" header field.  The
   "Expires" header field value is equal to 0 to signal a one time
   subscription.  The "Event" header field is set in conformance to [RFC
   4235] [3] and includes the part of dialog identifier known at this
   point.  As an alternative, the dialog information MAY also be sent in
   a body defining a filter to be applied to the subscription (as
   allowed in [RFC 4235] [3]).

   The SUBSCRIBE request is then forwarded to Proxy 2, from there to
   Proxy 1, and from there (because of retargeting of a dialog-forming
   request) to the Contact address binded to the AOR conveyed in the
   "From:" header field of the original INVITE request.  If the
   subscription is accepted (F7-F9), the notifier sends immediately a
   NOTIFY-request (F10) to communicate the existence and current state
   of that "half-dialog" to the subscriber (Callee).  This NOTIFY
   message is sent on the same dialog as created by the SUBSCRIBE
   response.  The body of the notification contains a dialog information
   document used to report the state of the "half-dialog" being
   monitored.  This information should be formatted into one of the body
   formats specified in the "Accept" header of the corresponding
   SUBSCRIBE request and can contain either the state of the subscribed
   resource or a pointer to such state in the form of a URI.  In case
   the notifier is not aware of the "half-dialog" being monitored, a 481
   (Call/Transaction Does Not Exist) response to the SUBSCRIBE request
   MUST be sent instead.

   The result of the Caller's identity verification SHOULD be provided
   as input to an authorization process (out of the scope of this
   document).  Once this authorization process is completed, if the
   Callee decides to accept the call, the INVITE is accepted and the
   Callee's UAS core generates a 2xx (F12-F14) response which
   establishes a dialog.  Otherwise, when the Callee's UAS is not
   willing to accept the call because the Caller was not aware of the
   monitored "half-dialog", a 434 (Suspicious Call) response MUST be
   returned (F12-F14).


4.  434 Response Code Definition

   This specification introduces the 434 (Suspicious Call) response
   code.  It is generated by a UAS to indicate that the server refused
   to fulfill the request because the requestor could not be verified.
   A UAC compliant to this specification shall try to comply to the
   requirements by, for example, registering the AOR sent in the "From"
   header field.  Its default reason phrase is "Suspicious Call".





Kuthan, et al.           Expires April 28, 2009                 [Page 6]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


5.  Behaviour

   User Agents compliant with this specification MUST support the
   INVITE-Initiated Dialog Event Package for the Session Initiation
   Protocol (SIP) as defined per RFC 4235.

   Some considerations:
      - Subscriber Generation of SUBSCRIBE Request: After receiving an
      INVITE request, the UAS MUST inspect the value conveyed in the
      "From:" header field and MUST issue (before sending any 18x
      alerting the user, or final response to the INVITE request) a
      dialog-forming SUBSCRIBE request with an "Expires" of 0 addressed
      to the AOR conveyed in the "From:" header field of the original
      INVITE request.  The SUBSCRIBE request MUST include an "Event:"
      header field set to "dialog".  This header SHOULD also include the
      "half-dialog" identifier being subscribed-to.  Alternatively, this
      information MAY be sent in a body defining a filter to be applied
      to the subscription.  However, this is NOT RECOMMENDED.  So far,
      [RFC 4660] is the only standard's based work that has been done.
      Some additional ideas were discussed in
      [draft-olson-sipping-dialog-package-extensions] but, to our best
      knowledge, this work has not progressed.
      - Subscriber Processing 2xx responses for the SUBSCRIBE-request: A
      positive response (2xx) and a subsequent notification to the
      subscription indicates the Caller's awareness of the "half-dialog"
      being monitored by the Callee.  In that case, the conveyed
      identity of the Caller is considered to be verified and the call
      SHOULD be accepted.
      - Subscriber Processing non-2xx responses for the SUBSCRIBE-
      request:
         - A 480 (Temporarily Unavailable) response indicates the proxy
         server does not currently have a valid forwarding location for
         the user identified by the Request-URI.  In that case, the UAS
         SHOULD reject the call with a 434 (Suspicious call) response
         code to indicate to the UAC that it SHOULD get registered
         before re-sending the INVITE request.
         - A 481 (Call/Transaction Does Not Exist) response indicates
         the notifier is not aware of the subscribed dialog.  In that
         case, the UAS MUST reject the call with a 434 (Suspicious call)
         response code.
         - A 489 Bad Event response indicates the Dialog event package
         was not supported by the potential caller.  In that case, the
         UAS SHOULD accept the call and MAY use a common visual
         identifier to indicate that the user is communicating with
         someone whose identity has not been verified.






Kuthan, et al.           Expires April 28, 2009                 [Page 7]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


         - Other non-2xx responses (e.g. 408 Request Timeout): the UAS
         SHOULD accept the call and MAY use a common visual identifier
         to indicate that the user is communicating with someone whose
         identity has not been verified.


6.  Applicaibility

6.1.  Protocol compatibility

   This mechanism is backward compatible with SIP RFCs and re-uses
   existing specifications.  A new response code code (434) is defined,
   and it indicates that the server refused to fulfill the request
   because the requestor was untrusted.

   The requirements described by this specification mandates the
   compliance to following RFCs:
      - RFC 3261: Session Initiation Protocol (SIP)
      - RFC 3265: Session Initiation Protocol (SIP)-Specific Event
      Notification
      - RFC 4235: An INVITE-Initiated Dialog Event Package for the
      Session Initiation Protocol (SIP)

6.2.  Limitations
      - The mechanism described in this document can provide a
      reasonably good assertion about the positive case, but it can't
      make a qualified assertion for failure (because of unregistered
      caller, caller in DnD mode, caller without SUB-NOT, TEL URIs,
      caller with permanent request forwarding turned on, etc.)
      - Call setup delay: a delayed or missing final response will
      dominate the processing at UAS that receives no response to a
      SUBSCRIBE request.


7.  Examples

   This section describes the caller's identity verification and session
   establishment between two SIP User Agents (UAs) which belong to two
   different service providers (atlanta.com and biloxi.com).

   Considerations:
      - Alice and Bob (UAs) register and authenticate with their
      respective domains (F1-F4) to be able to receive the requests via
      their home proxy.  In some cases, caller registration is triggered
      upon receipt of a 434 Response (see Example 5).






Kuthan, et al.           Expires April 28, 2009                 [Page 8]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


      - Proxy 1 and Proxy 2 belong to two different Service Providers
      which wish to be present in all message exchanges.  Hence, they
      will record-route any dialog-establishing requests.  In that case,
      UAs may elect to use S/MIME encryption of requests; consequently,
      proxies cannot rely on being able to access any information that
      is not explicitly required to be proxy-readable by SIP.

   The examples shown below are for informational purposes only.  For a
   normative description of the dialog event package, please see RFC4235
   [3]

7.1.  Example 1: Verified call

   In this scenario, Alice completes a call to Bob using two proxies
   (Proxy 1 and Proxy 2) from different service providers.  In order to
   verify Alice's identity, Bob's UA subscribes to the status of Alice's
   "half-dialog".


































Kuthan, et al.           Expires April 28, 2009                 [Page 9]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


      Alice   Proxy 1 (atlanta.com) Proxy 2 (biloxi.com)   Bob
        |                |                |                |       --------
        | REGISTER F1    |                | REGISTER F1    |
        |--------------->|                |<---------------|
        | 401 F2         |                | 401 F2         |
        |<---------------|                |--------------->|
        | REGISTER F3    |                | REGISTER F3    |       Registration
        |--------------->|                |<---------------|
        | 200 F4         |                | 200 F4         |
        |<---------------|                |--------------->|
        |                |                |                |       --------
        | INVITE F5      |                |                |
        |--------------->| INVITE F7      |                |
        | 100 F6         |--------------->| INVITE F9      |       INVITE "half-dialog"
        |<---------------| 100 F8         |--------------->|
        |                |<---------------| 100 F10        |
        |                |                |<---------------|       --------
        |                |                | SUBSCRIBE F11  |
        |                | SUBSCRIBE F12  |<---------------|
        | SUBSCRIBE F13  |<---------------|                |
        |<---------------|                |                |
        | 200 F14        |                |                |
        |--------------->| 200 F15        |                |
        |                |--------------->| 200 F16        |       SUBSCRIBE "dialog"
        |                |                |--------------->|
        | NOTIFY F17     |                |                |
        |--------------->| NOTIFY F18     |                |
        |                |--------------->| NOTIFY F19     |
        |                |                |--------------->|
        |                |                | 200 F20        |
        |                | 200 F21        |<---------------|
        | 200 F22        |<---------------|                |
        |<---------------|                |                |       --------
        |                |                | 180 F23        |
        |                | 180 F24        |<---------------|
        | 180 F25        |<---------------|                |
        |<---------------|                |                |
        |                |                | 200 F26        |
        |                | 200 F27        |<---------------|       INVITE "dialog"
        | 200 F28        |<---------------|                |
        |<---------------|                |                |
        | ACK F29        |                |                |
        |--------------->| ACK F30        |                |
        |                |--------------->| ACK F31        |
        |                |                |--------------->|       --------

   Figure 2: Verified call




Kuthan, et al.           Expires April 28, 2009                [Page 10]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


   Note: Via, Route and other headers are omitted from the message
   illustrations for clarity.

   Alice's UAC sends an INVITE request to Bob's UAS that looks, in part,
   like:


           F5 INVITE Alice -> Proxy 1 (atlanta.com)

              INVITE sip:bob@biloxi.com SIP/2.0
              From: Alice <sip:alice@atlanta.com>;tag=9fxced76sl
              To: Bob <sip:bob@biloxi.com>
              Call-ID: 3848276298220188511@atlanta.com
              Supported: dialog
              Contact: <sip:alice@client.atlanta.com>
              Content-Type: application/sdp
              Content-Length: ...

              [SDP not shown]

   After receiving Alice's INVITE request, Bob's UAS sends a dialog-
   forming SUBSCRIBE request with an "Expires" of 0 to the AOR conveyed
   in the "From:" header field of the original INVITE-request.


    F11 SUBSCRIBE Bob -> Proxy 2 (biloxi.com)     "Fetch Operation"

      SUBSCRIBE sip:alice@atlanta.com SIP/2.0
      From: Bob <sip:Bob@biloxi.com>;tag=8672349
      To: <sip:alice@atlanta.com>
      Call-ID: xt4653gs2ham@biloxi.com
      Contact: <sip:bob@client.biloxy.com>
      Event: dialog;call-id=3848276298220188511@atlanta.com;to-tag=9fxced76sl
      Expires=0
      Accept: application/dialog-info+xml
      Content-Length: 0

   This SUBSCRIBE request contains an "Event:" header field that
   identify the "half-dialog" being subscribed to.

   The SUBSCRIBE is forwarded to Proxy 2, from there to Proxy 1, and
   from there it is re-targeted to Alice (F13).  Upon receipt of this
   SUBSCRIBE request, the notifier will send a single NOTIFY (F17)
   request in the same dialog.

   The NOTIFY (F17) body is used to report state on the resource being
   monitored and it indicates to the recipient that the sender is aware
   of an existing "half-dialog" with the recipient.  It is formatted



Kuthan, et al.           Expires April 28, 2009                [Page 11]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


   into the body format specified in the "Accept" header of the
   corresponding SUBSCRIBE (F11) request (dialog-info+xml).  This body
   contains the state of the subscribed "half-dialog".


    F17 NOTIFY Alice -> Proxy 1

      NOTIFY sip:bob@client.biloxy.com SIP/2.0
      To: Bob <sip:bob@biloxy.com>;tag=8672349
      From: <sip:alice@atlanta.com>;tag=1234567
      Call-ID: xt4653gs2ham@biloxi.com
      Contact: <sip:alice@client.atlanta.com>
      Event: dialog
      Subscription-State: terminated;reason=timeout
      Content-Type: application/dialog-info+xml
      Content-Length: ...

         <?xml version="1.0"?>
           <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
           version="0" state="full" entity="sip:alice@atlanta.com">
                   <dialog id="as7d900as8" call-id="3848276298220188511@atlanta.com"
                   local-tag="9fxced76sl" direction="initiator">
                           <state>Proceeding</state>
                   </dialog>
         </dialog-info>

   Note that the NOTIFY messages triggered by SUBSCRIBE messages with
   "Expires" headers of 0 will contain a "Subscription-State" value of
   "terminated", and a "reason" parameter of "timeout".

7.2.  Example 2: Unverified call




















Kuthan, et al.           Expires April 28, 2009                [Page 12]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


   In the example call flow below, Alice completes a call to Bob using
   two proxies (Proxy 1 and Proxy 2) from different service providers.
   In order to verify Alice's identity, Bob's UA subscribes to the
   status of Alice's dialog but Alice's UA does not support the Dialog
   event package.  Hence, Aice issues a 489 Bad Event response to
   indicate that she did not understand the dialog event package.
   Alice's identity could not be verified and this information is
   displayed to Bob. Anyhow, he decides to proceed with the unverified
   call

            Alice   Proxy 1 (atlanta.com) Proxy 2 (biloxi.com)   Bob
              |                |                |                |
              | REGISTER F1    |                | REGISTER F1    |
              |--------------->|                |<---------------|
              | 401 F2         |                | 401 F2         |
              |<---------------|                |--------------->|
              | REGISTER F3    |                | REGISTER F3    |
              |--------------->|                |<---------------|
              | 200 F4         |                | 200 F4         |
              |<---------------|                |--------------->|
              | INVITE F5      |                |                |
              |--------------->| INVITE F7      |                |
              | 100 F6         |--------------->| INVITE F9      |
              |<---------------| 100 F8         |--------------->|
              |                |<---------------| 100 F10        |
              |                |                |<---------------|
              |                |                | SUBSCRIBE F11  |
              |                | SUBSCRIBE F12  |<---------------|
              | SUBSCRIBE F13  |<---------------|                |
              |<---------------|                |                |
              | 489 F14        |                |                |
              |--------------->| 489 F15        |                |
              |                |--------------->| 489 F16        |
              |                |                |--------------->|
         /* Alice's identity could not be verified because Alice's
         UA does not support the Dialog event package. */
              |                |                | 180 F17        |
              |                | 180 F18        |<---------------|
              |  180 F19       |<---------------|                |
              |<---------------|                |                |
              |                |                | 200 F20        |
              |                | 200 F21        |<---------------|
              | 200 F22        |<---------------|                |
              |<---------------|                |                |
              | ACK F23        |                |                |
              |--------------->| ACK F24        |                |
              |                |--------------->| ACK F25        |
              |                |                |--------------->|



Kuthan, et al.           Expires April 28, 2009                [Page 13]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


   Figure 3: Unverified call

7.3.  Example 3: Suspicious call

   In the example call flow below, an Attacker issues an INVITE-request
   using a forged From URI, impersonating Alice's AOR
   (alice@atlanta.com).


           F5 INVITE Attacker -> Proxy 2

              INVITE sip:bob@biloxi.com SIP/2.0
              From: Alice <sip:alice@atlanta.com>;tag=9fxced76sl
              To: Bob <sip:bob@biloxi.com>
              Call-ID: 3848276298220188511@atlanta.com
              Contact: <sip:attacker@pc1.attacker.com>
              Content-Type: application/sdp
              Content-Length: ...

              [SDP not shown]


   In order to verify Alice's identity, Bob's UA subscribes to the
   status of Alice's dialog.  Alice's UA issues a 481 Call/Transaction
   Does Not Exist response to indicate that she is not aware of the
   requested dialog.  Caller's identity is identified to be suspicious
   and this information is displayed to Bob. Bob decides to reject the
   call and a 434 Suspicious Call response is sent.























Kuthan, et al.           Expires April 28, 2009                [Page 14]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


    Attacker        Alice   Proxy 1 (atlanta.com) Proxy 2 (biloxi.com) Bob
    |               |                |                |                |
    |               | REGISTER F1    |                | REGISTER F1    |
    |               |--------------->|                |<---------------|
    |               | 401 F2         |                | 401 F2         |
    |               |<---------------|                |--------------->|
    |               | REGISTER F3    |                | REGISTER F3    |
    |               |--------------->|                |<---------------|
    |               | 200 F4         |                | 200 F4         |
    |               |<---------------|                |--------------->|
    |               | INVITE F5      |                |                |
    |------------------------------------------------>|                |
    |               | 100 F6         |                |                |
    |<------------------------------------------------| INVITE F7      |
    |               |                |                |--------------->|
    |               |                |                | 100 F8         |
    |               |                |                |<---------------|
    |               |                |                | SUBSCRIBE F9   |
    |               |                | SUBSCRIBE F10  |<---------------|
    |               | SUBSCRIBE F11  |<---------------|                |
    |               |<---------------|                |                |
    |               | 481 F12        |                |                |
    |               |--------------->| 481 F13        |                |
    |               |                |--------------->| 481 F14        |
    |               |                |                |--------------->|
    |               |                |                | 434 F15        |
    |               | 434 F16        |                |<---------------|
    |<------------------------------------------------|                |
    |               | ACK F17        |                |                |
    |------------------------------------------------>|                |
    |               |                |                | ACK F18        |
    |               |                |                |--------------->|


   Figure 4: Suspicious call

7.4.  Example 4: Unverified call














Kuthan, et al.           Expires April 28, 2009                [Page 15]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


   In the example call flow below, an Attacker issues an INVITE request
   using a forged From URI, impersonating Alice.  In order to verify
   Alice's identity, Bob's UA subscribes to the status of Alice's dialog
   but Alice's UA does not support the Dialog event package.  Hence,
   Aice issues a 489 Bad Event response to indicate that she did not
   understand the dialog event package.  Alice's identity could not be
   verified and this information is displayed to Bob. Anyhow, he decides
   to proceed with the unverified call.

    Attacker        Alice   Proxy 1 (atlanta.com) Proxy 2 (biloxi.com) Bob
    |               |                |                |                |
    |               | REGISTER F1    |                | REGISTER F1    |
    |               |--------------->|                |<---------------|
    |               | 401 F2         |                | 401 F2         |
    |               |<---------------|                |--------------->|
    |               | REGISTER F3    |                | REGISTER F3    |
    |               |--------------->|                |<---------------|
    |               | 200 F4         |                | 200 F4         |
    |               |<---------------|                |--------------->|
    |               | INVITE F5      |                |                |
    |------------------------------------------------>|                |
    |               | 100 F6         |                |                |
    |<------------------------------------------------| INVITE F7      |
    |               |                |                |--------------->|
    |               |                |                | 100 F8         |
    |               |                |                |<---------------|
    |               |                |                | SUBSCRIBE F9   |
    |               |                | SUBSCRIBE F10  |<---------------|
    |               | SUBSCRIBE F11  |<---------------|                |
    |               |<---------------|                |                |
    |               | 489 F12        |                |                |
    |               |--------------->| 489 F13        |                |
    |               |                |--------------->| 489 F14        |
    |               |                |                |--------------->|
    /* Alice's identity could not be verified because Alice's
    UA does not support the Dialog event package. */
    |               |                |                | 180 F15        |
    |               | 180 F16        |                |<---------------|
    |<------------------------------------------------|                |
    |               |                |                | 200 F17        |
    |               | 200 F18        |                |<---------------|
    |<------------------------------------------------|                |
    |               | ACK F19        |                |                |
    |------------------------------------------------>| ACK F20        |
    |               |                |                |--------------->|


   Figure 5: Unverified call



Kuthan, et al.           Expires April 28, 2009                [Page 16]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


7.5.  Example 5: Verified call

   In the example call flow below, Alice completes a call to Bob using
   two proxies (Proxy 1 and Proxy 2) from different service providers.
   In order to verify Alice's identity, Bob's UA subscribes to the
   status of Alice's dialog but since Alice is not registered, her home
   proxy does not currently have a valid forwarding location for her
   (F13).  Then, Bob decides to reject the call and a 434 Suspicious
   Call is sent.  After receiving a 434 response, Alice's UA decides to
   register and authenticate with her service provider.  Once she is
   registered, the original INVITE-request is re-sent.  Alice's AOR can
   now be verified and the call is successfully established.

            Alice   Proxy 1(atlanta.com) Proxy 2 (biloxi.com)   Bob
              |                |                |                |
              |                |                | REGISTER F1    |
              |                |                |<---------------|
              |                |                | 401 F2         |
              |                |                |--------------->|
              |                |                | REGISTER F3    |
              |                |                |<---------------|
              |                |                | 200 F4         |
              |                |                |--------------->|
              | INVITE F5      |                |                |
              |--------------->| INVITE F7      |                |
              | 100 F6         |--------------->| INVITE F9      |
              |<---------------| 100 F8         |--------------->|
              |                |<---------------| 100 F10        |
              |                |                |<---------------|
              |                |                | SUBSCRIBE F11  |
              |                | SUBSCRIBE F12  |<---------------|
              |                |<---------------|                |
              |                | 480 F13        |                |
              |                |--------------->| 480 F14        |
              |                |                |--------------->|
              |                |                | 434 F15        |
              |                | 434 F16        |<---------------|
              | 434 F17        |<---------------|                |
              |<---------------|                |                |
              | ACK F18        |                |                |
              |--------------->| ACK F19        |                |
              |                |--------------->| ACK F20        |
              |                |                |--------------->|
              | REGISTER F21   |                |                |
              |--------------->|                |                |
              | 401 F22        |                |                |
              |<---------------|                |                |
              | REGISTER F23   |                |                |



Kuthan, et al.           Expires April 28, 2009                [Page 17]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


              |--------------->|                |                |
              | 200 F24        |                |                |
              |<---------------|                |                |
              | INVITE F25     |                |                |
              |--------------->| INVITE F27     |                |
              | 100 F26        |--------------->| INVITE F29     |
              |<---------------| 100 F28        |--------------->|
              |                |<---------------| 100 F30        |
              |                |                |<---------------|
              |                |                | SUBSCRIBE F31  |
              |                | SUBSCRIBE F32  |<---------------|
              | SUBSCRIBE F33  |<---------------|                |
              |<---------------|                |                |
              | 200 F34        |                |                |
              |--------------->| 200 F35        |                |
              |                |--------------->| 200 F36        |
              |                |                |--------------->|
              | NOTIFY F37     |                |                |
              |--------------->| NOTIFY F38     |                |
              |                |--------------->| NOTIFY F39     |
              |                |                |--------------->|
              |                |                | 200 F40        |
              |                | 200 F41        |<---------------|
              | 200 F42        |<---------------|                |
              |<---------------|                |                |
              |                |                | 180 F43        |
              |                | 180 F44        |<---------------|
              | 180 F45        |<---------------|                |
              |<---------------|                |                |
              |                |                | 200 F46        |
              |                | 200 F47        |<---------------|
              | 200 F48        |<---------------|                |
              |<---------------|                |                |
              | ACK F49        |                |                |
              |--------------->| ACK F50        |                |
              |                |--------------->| ACK F51        |
              |                |                |--------------->|

   Figure 6: Verified call

7.6.  Example 6: Verified call

   In the example call flow below, Alice completes a call to Bob using
   two proxies (Proxy 1 and Proxy 2) from different service providers.
   In order to verify Alice's identity, Bob's UA subscribes to the
   status of Alice's dialog.  Since Alice is registered from multiple
   locations, Proxy 1 (a stateful proxy) chooses to route the SUBSCRIBE
   to multiple destinations (forking).  Note that since only one of



Kuthan, et al.           Expires April 28, 2009                [Page 18]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


   Alice's devices is involved in the INVITE-initiated dialog, a forked
   SUBSCRIBE will only result in a single 2xx (F18) response.  Once
   Alice's identity is verified the call is established successfully.

   Alice@pda    Alice@pc  Proxy 1 (atlanta.com) Proxy 2 (biloxi.com) Bob
   |               |                |                |                |
   |               | REGISTER F1    |                | REGISTER F1    |
   |               |--------------->|                |<---------------|
   |               | 401 F2         |                | 401 F2         |
   |               |<---------------|                |--------------->|
   |               | REGISTER F3    |                | REGISTER F3    |
   |               |--------------->|                |<---------------|
   |               | 200 F4         |                | 200 F4         |
   |               |<---------------|                |--------------->|
   |               | REGISTER F5    |                |                |
   |------------------------------->|                |                |
   |               | 401 F6         |                |                |
   |<-------------------------------|                |                |
   |               | REGISTER F7    |                |                |
   |------------------------------->|                |                |
   |               | 200 F8         |                |                |
   |<-------------------------------|                |                |
   |               | INVITE F9      |                |                |
   |------------------------------->| INVITE F11     |                |
   |               | 100 F10        |--------------->|                |
   |<-------------------------------| 100 F12        | INVITE F13     |
   |               |                |--------------->|--------------->|
   |               |                |                | 100 F14        |
   |               |                |                |<---------------|
   |               |                |                | SUBSCRIBE F15  |
   |               |                | SUBSCRIBE F16  |<---------------|
   |               | SUBSCRIBE F17  |<---------------|                |
   |<-------------------------------|                |                |
   |               | SUBSCRIBE F17  |                |                |
   |               |<---------------|                |                |
   |               | 481 F18        |                |                |
   |               |--------------->|                |                |
   |               | 200 F18        |                |                |
   |------------------------------->| 200 F19        |                |
   |               |                |--------------->| 200 F20        |
   |               |                |                |--------------->|
   |               | NOTIFY F21     |                |                |
   |------------------------------->| NOTIFY F22     |                |
   |               |                |--------------->| NOTIFY F23     |
   |               |                |                |--------------->|
   |               |                |                | 200 F24        |
   |               |                | 200 F25        |<---------------|
   |               | 200 F26        |<---------------|                |



Kuthan, et al.           Expires April 28, 2009                [Page 19]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


   |<-------------------------------|                |                |
   |               |                |                | 180 F27        |
   |               |                | 180 F28        |<---------------|
   |               | 180 F29        |<---------------|                |
   |<-------------------------------|                |                |
   |               |                |                | 200 F30        |
   |               |                | 200 F31        |<---------------|
   |               | 200 F32        |<---------------|                |
   |<-------------------------------|                |                |
   |               | ACK F33        |                |                |
   |------------------------------->| ACK F34        |                |
   |               |                |--------------->| ACK F35        |
   |               |                |                |--------------->|

   Figure 7: Verified call

7.7.  Example 7: Suspicious call

   In the example call flow below, an Attacker issues an INVITE request
   using a forged From URI, impersonating Alice.  In order to verify
   Alice's identity, Bob's UA subscribes to the status of Alice's
   dialog.  Since Alice is registered from multiple locations, Proxy 1
   (a stateful proxy) chooses to route the SUBSCRIBE to multiple
   destinations (forking).  While Alice's UA on her PDA does not support
   the Dialog event package, Alice's UA on her PC does support it and
   issues a 481 Call/Transaction Does Not Exist response to indicate
   that it is not aware of the requested dialog.  In this case, Proxy 1
   chooses one of the responses among those received and stored in the
   response context; preference should be given to 481 Responses.
   Caller's identity is identified to be suspicious and this information
   is displayed to Bob. Bob decides to reject the call and a 434
   Suspicious Call is sent.



















Kuthan, et al.           Expires April 28, 2009                [Page 20]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


   Attacker      Alice@pda      Alice@pc  Proxy 1 (atlanta.com) Proxy 2 (biloxi.com) Bob
   |               |               |                |                |                |
   |               |               | REGISTER F1    |                | REGISTER F1    |
   |               |               |--------------->|                |<---------------|
   |               |               | 401 F2         |                | 401 F2         |
   |               |               |<---------------|                |--------------->|
   |               |               | REGISTER F3    |                | REGISTER F3    |
   |               |               |--------------->|                |<---------------|
   |               |               | 200 F4         |                | 200 F4         |
   |               |               |<---------------|                |--------------->|
   |               |               | REGISTER F5    |                |                |
   |               |------------------------------->|                |                |
   |               |               | 401 F6         |                |                |
   |               |<-------------------------------|                |                |
   |               |               | REGISTER F7    |                |                |
   |               |------------------------------->|                |                |
   |               |               | 200 F8         |                |                |
   |               |<-------------------------------|                |                |
   |               |               | INVITE F9      |                |                |
   |----------------------------------------------->| INVITE F11     |                |
   |               |               | 100 F10        |--------------->|                |
   |<-----------------------------------------------| 100 F12        | INVITE F13     |
   |               |               |                |<---------------|--------------->|
   |               |               |                |                | 100 F14        |
   |               |               |                |                |<---------------|
   |               |               |                |                | SUBSCRIBE F15  |
   |               |               |                | SUBSCRIBE F16  |<---------------|
   |               |               | SUBSCRIBE F17  |<---------------|                |
   |               |<-------------------------------|                |                |
   |               |               | SUBSCRIBE F17  |                |                |
   |               |               |<---------------|                |                |
   |               |               | 481 F18        |                |                |
   |               |               |--------------->|                |                |
   |               |               | 489 F18        |                |                |
   |               |------------------------------->| 481 F19        |                |
   |               |               |                |--------------->| 481 F20        |
   |               |               |                |                |--------------->|
   |               |               |                |                | 434 F21        |
   |               |               |                | 434 F22        |<---------------|
   |               |               | 434 F23        |<---------------|                |
   |<-----------------------------------------------|                |                |
   |               |               | ACK F24        |                |                |
   |----------------------------------------------->| ACK F25        |                |
   |               |               |                |--------------->| ACK F26        |
   |               |               |                |                |--------------->|

   Figure 8: Suspicious call




Kuthan, et al.           Expires April 28, 2009                [Page 21]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


8.  Acknowledgments


9.  Security Considerations

   As pointed out in [RFC 4235] [3], subscriptions to dialog state can
   reveal sensitive information.  Therefore, all subscriptions SHOULD be
   authorized before approval and a caller SHOULD accept subscribe
   requests only from URIs to which it has sent an INVITE-request.

   Since the data in notifications is sensitive as well, end-to-end SIP
   encryption mechanisms using S/MIME MAY be used to protect it.  User
   agents that implement this specification MAY also implement SIP over
   (D)TLS and the sips: scheme.

   The fact that a request was rejected because it was a Suspicious Call
   (434) does reveal that the called party does not accept Suspicious
   Calls.  This information may or may not be sensitive.  If it is, a
   UAS SHOULD reject the INVITE-request with a 403 instead.


10.  Grammar

   This specification does not require any new grammar definition.


11.  IANA Considerations

   The following is the registration for the new SIP 434 (Suspicious
   Call) response code according to the procedures of RFC 3261:

   Response Code Number: 434

   Default Reason Phrase: Suspicious Call

   RFC Number: TBD


12.  References

12.1.  Normative References

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

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



Kuthan, et al.           Expires April 28, 2009                [Page 22]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


   [3]  Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
        Initiated Dialog Event Package for the Session Initiation
        Protocol (SIP)", RFC 4235, November 2005.

12.2.  Informative References

   [4]  Elwell, J., "End-to-End Identity Important in the Session
        Initiation Protocol (SIP)", July 2008.


Authors' Addresses

   Jiri Kuthan
   Tekelec
   Berlin, Am Borsigturm 11  D13507
   Germany

   Phone: sip:jiri@iptel.org
   Email: Jiri.Kuthan@tekelec.com


   Dorgham Sisalem
   Tekelec
   Berlin, Am Borsigturm 11  D13507
   Germany

   Email: Dorgham.Sisalem@tekelec.com


   Raphael Coeffic
   Tekelec
   Berlin, Am Borsigturm 11  D13507
   Germany

   Phone: sip:raf@iptel.org
   Email: Raphael.Coeffic@tekelec.com


   Victor Pascual
   Tekelec
   Berlin, Am Borsigturm 11  D13507
   Germany

   Phone: sip:victor.pascual@iptel.org
   Email: Victor.Pascual@tekelec.com






Kuthan, et al.           Expires April 28, 2009                [Page 23]


Internet-Draft   Dialog Event foR Identity VErification     October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

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

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


Intellectual Property

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

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

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











Kuthan, et al.           Expires April 28, 2009                [Page 24]


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