SIPPING J. Rosenberg Internet-Draft Cisco Systems Expires: August 21, 2005 February 20, 2005 Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) draft-rosenberg-sip-target-dialog-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 August 21, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP). This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness. Rosenberg Expires August 21, 2005 [Page 1] Internet-Draft Target Dialog February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of Operation . . . . . . . . . . . . . . . . . . . 4 3. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . 5 4. User Agent Server Behavior . . . . . . . . . . . . . . . . . 6 5. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . 6 6. Header Field Definition . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1 Normative References . . . . . . . . . . . . . . . . . . . 8 10.2 Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . 10 Rosenberg Expires August 21, 2005 [Page 2] Internet-Draft Target Dialog February 2005 1. Introduction The Session Initiation Protocol (SIP) [1] defines the concept of a dialog as a persistent relationship between a pair of user agents. Dialogs provide context including sequence numbers, proxy routes, and dialog identifiers. Dialogs are established through the transmission of SIP requests with particular methods. Specifically, the INVITE request, REFER [7], and SUBSCRIBE and NOTIFY [2] requests all create dialogs. When a user agent receives a request that creates a dialog, it needs to decide whether to authorize that request. For some requests, authorization is a function of the identity of the sender, the request method, and so on. However, many situations have been identified in which authorization depends on whether the sender of the request is currently in a dialog with, or aware of a dialog with, the user agent. One such example is call transfer, accomplished through REFER. If user agents A and B are in an INVITE dialog, and user agent A wishes to transfer user agent B to user agent C, user agent A needs to send a REFER request to user agent B, asking user agent B to send an INVITE to user agent C. User agent B needs to authorize this REFER. The proper authorization decision is that user agent B should accept the request if it came from a user with whom B currently has an INVITE dialog relationship. Current implementations deal with this by sending the REFER on the same dialog as the one in place between user agents A and B. However, this approach has numerous problems [8]. These problems include difficulty in determining the lifecycle of the dialog and its usages, and difficulties in determining which messages are associated with each application usage. Instead, a better approach is for user agent A to send the REFER request to user agent C outside of the dialog using its Globally Routable User Agent URI (GRUU) [9]. In that case, a means is needed for user agent B to authorize the REFER. Another example is the application interaction framework [10]. In that framework, proxy servers on the path of a SIP INVITE request can place user interface components on the user agent that generated or received the request. To do this, the proxy server needs to send a REFER request to the user agent, targeted to their GRUU, asking the user agent to fetch an HTTP resource containing the user interface. In such a case, a means is needed for the user agent to authorize the REFER. Another example is if two user agents share an INVITE dialog, and an element on the path of the INVITE request wishes to track the state of the INVITE. In such a case, it sends a SUBSCRIBE request to the Rosenberg Expires August 21, 2005 [Page 3] Internet-Draft Target Dialog February 2005 GRUU of the user agent, asking for a subscription to the dialog event package. If the SUBSCRIBE request came from an element on the INVITE request path, it should be authorized. 2. Overview of Operation +--------+ +--------+ | | INVITE | | | Proxy |----------->| Proxy | | A | | B | | |...........>| | +--------+ +--------+ ^ REFER . \ / . \ / . \ / . \ / . \ / V V +--------+ +--------+ | | | | | User | | User | | Agent | | Agent | | A | | B | +--------+ +--------+ Figure 1 Figure 1 shows the basic model of operation. User agent A sends an INVITE to user agent B, traversing two proxy servers, proxy A and proxy B. This establishes a dialog between the two user agents. Next, the server that was acting in the role of proxy A for the INVITE dialog wishes to REFER user agent B to fetch an HTTP resource. So, it sends a REFER request to user agent B. This REFER is addressed to the GRUU of user agent B, which proxy A learned from inspecting the Contact header field in the 200 OK of the INVITE request. This GRUU is a URI that can be used by any element on the Internet, such as proxy A, to reach the specific user agent instance that generated that 200 OK to the INVITE. The REFER request generated by proxy A will contain a Target-Dialog header field. This header field contains the dialog identifiers for the INVITE dialog between user agents A and B, composed of the Call-ID, local tag, and remote tag. When the REFER request arrives at user agent B, it needs to make an Rosenberg Expires August 21, 2005 [Page 4] Internet-Draft Target Dialog February 2005 authorization decision. Because the INVITE dialog was established using a sips URI, and because the dialog identifiers are cryptographically random [1], no entity except for user agent A or the proxies on the dialog path can know the dialog identifiers. Thus, because the REFER request contains those dialog identifiers, user agent B can be certain that the REFER request came from either user agent A, the two proxies, or an entity trusted by one of those elements to whom the dialog identifier was given. As such, it authorizes the REFER request, and fetches the HTTP resource identified by the URI of the Refer-To header field in the REFER request. 3. UAC Behavior When a user agent client sends a request that establishes a new dialog, and this request is sent outside of any existing dialog, and the user agent believes that the request will not be authorized by the user agent server unless the user agent can prove that it is aware of the dialog identifiers for some other dialog, the user agent includes the Target-Dialog header field in that request. Typically this is the case when the dialog-initiating request would have otherwise been sent over an existing dialog, but was not since this specification allows the request to be sent on a new dialog instead. In particular, the Target-Dialog header field SHOULD be included in REFER requests sent out a dialog, when the REFER would have otherwise been sent as part of an existing dialog. It SHOULD be included in subscriptions to the dialog event package [11] when that SUBSCRIBE request would have otherwise been sent within an INVITE dialog. It SHOULD be included in subscriptions to the conference event package [12] when that SUBSCRIBE request would have otherwise been sent within an INVITE dialog the user agent already has to the focus. If the user agent client is unsure if the Target-Dialog header field should be included in a request, it SHOULD be included anyway. There is never any harm in including a Target-Dialog header field when it was not actually needed. The value of the call-id production in the Target-Dialog header field MUST be equal to the Call-ID of the target dialog. The "remote-tag" header field parameter MUST be present, and MUST contain the tag that would be viewed as the remote tag from the perspective of the recipient of the new request. The "local-tag" header field parameter MUST be present, and MUST contain the tag that would be viewed as the local tag from the perspective of the recipient of the new request. Rosenberg Expires August 21, 2005 [Page 5] Internet-Draft Target Dialog February 2005 4. User Agent Server Behavior If a user agent server receives a dialog-creating request, and wishes to authorize the request, and that authorization depends on whether or not the sender has knowledge of an existing dialog with the UAS, the UAS SHOULD check the request for the existence of the Target-Dialog header field. If this header field is not present, the UAS MAY still authorize the request based on other means. If the header field is present, and the value of the call-id production, the "remote-tag" and "local-tag" values match the Call-ID, remote tag and local tag of an existing dialog, and the dialog that they match was established using a sips URI, the UAS SHOULD authorize the request if it would authorize any entity on the path of the request that created that dialog, or any entity trusted by an entity on the path of the request that created that dialog. If the dialog identifiers match, but they match a dialog not created with a sips URI, the UAS MAY authorize the request if it would authorize any entity on the path of the request that created that dialog, or any entity trusted by an entity on the path of the request that created that dialog. However, in this case, any eavesdropper on the original dialog path would have access to the dialog identifiers, and thus the authorization strength is reduced to MAY. If the dialog identifiers don't match, or if they don't contain both a "remote-tag" and "local-tag" parameter, the header field MUST be ignored, and authorization MAY be determined by other means. 5. Proxy Behavior Proxy behavior is unaffected by this specification. 6. Header Field Definition The grammar for the Target-Dialog header field is defined as follows: Target-Dialog = "Target-Dialog" HCOLON call-id remote-param local-param *generic-param remote-param = SEMI "remote-tag" EQUAL token local-param = SEMI "local-tag" EQUAL token Figure 3 and Figure 4 are an extension of Tables 2 and 3 in RFC 3261 [1] for the Target-Dialog header field. The column "INF" is for the INFO method [3], "PRA" is for the PRACK method [4], "UPD" is for the UPDATE method [5], "SUB" is for the SUBSCRIBE method [2], "NOT" is for the NOTIFY method [2], "MSG" is for the MESSAGE method [6], and Rosenberg Expires August 21, 2005 [Page 6] Internet-Draft Target Dialog February 2005 "REF" is for the REFER method [7] Header field where proxy ACK BYE CAN INV OPT REG Target-Dialog R ar - - - o - - Figure 3: Allowed Methods for Target-Dialog Header field where proxy PRA UPD SUB NOT INF MSG REF Target-Dialog R ar - o o - - - o Figure 4: Accept-Contact, Reject-Contact and Request-Disposition header fields 7. Security Considerations The Target-Dialog header field is used to authorize requests based on the fact that the sender of the request has access to information that only certain entities have access to. In order for such an authorization decision to be secure, two conditions have to be met. Firstly, no eavesdroppers can have access to this information. That requires the original SIP dialog to be established using a sips URI, which provides TLS on each hop. With a sips URI, only the user agents and proxies on the request path will be able to know the dialog identifiers. The second condition is that the dialog identifiers be sufficiently random that they cannot be guessed. RFC 3261 requires global uniquess for the Call-ID and 32 bits of randomness for each tag (there are two tags for a dialog). Given the short duration over which a typical dialog exists (perhaps as long as a day), this amount of randomness appears adequate to prevent guessing attacks. 8. IANA Considerations This specification registers a new SIP header field according to the process of RFC 3261 [1]. RFC Number: RFC XXXX [Note to IANA: Fill in with the RFC number of this specification.] Header Field Name: Target-Dialog Rosenberg Expires August 21, 2005 [Page 7] Internet-Draft Target Dialog February 2005 Compact Form: none 9. Acknowledgments This specification is based on a header field first proposed by Robert Sparks in the dialog usage draft. 10. References 10.1 Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [3] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. [4] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [6] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [7] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. 10.2 Informative References [8] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", draft-sparks-sipping-dialogusage-00 (work in progress), July 2004. [9] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-02 (work in progress), July 2004. [10] Rosenberg, J., "A Framework for Application Interaction in the Session Initiation Protocol (SIP)", draft-ietf-sipping-app-interaction-framework-03 (work in Rosenberg Expires August 21, 2005 [Page 8] Internet-Draft Target Dialog February 2005 progress), October 2004. [11] Rosenberg, J., "An INVITE Inititiated Dialog Event Package for the Session Initiation Protocol (SIP)", draft-ietf-sipping-dialog-package-05 (work in progress), November 2004. [12] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Conference State", draft-ietf-sipping-conference-package-08 (work in progress), December 2004. Author's Address Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net Rosenberg Expires August 21, 2005 [Page 9] Internet-Draft Target Dialog February 2005 Intellectual Property Statement 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. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg Expires August 21, 2005 [Page 10]