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 ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.com Supported: dialog Contact: 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 ;tag=8672349 To: Call-ID: xt4653gs2ham@biloxi.com Contact: 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 ;tag=8672349 From: ;tag=1234567 Call-ID: xt4653gs2ham@biloxi.com Contact: Event: dialog Subscription-State: terminated;reason=timeout Content-Type: application/dialog-info+xml Content-Length: ... Proceeding 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 ;tag=9fxced76sl To: Bob Call-ID: 3848276298220188511@atlanta.com Contact: 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]