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]