Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)
RFC 4538
Document | Type | RFC - Proposed Standard (June 2006; No errata) | |
---|---|---|---|
Author | Jonathan Rosenberg | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4538 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
Send notices to | fluffy@cisco.com, rohan@ekabal.com |
Network Working Group J. Rosenberg Request for Comments: 4538 Cisco Systems Category: Standards Track June 2006 Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. 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 Standards Track [Page 1] RFC 4538 Target Dialog June 2006 Table of Contents 1. Introduction ....................................................3 1.1. Terminology ................................................4 2. Overview of Operation ...........................................4 3. User Agent Client (UAC) Behavior ................................5 4. User Agent Server Behavior ......................................7 5. Proxy Behavior ..................................................8 6. Extensibility Considerations ....................................8 7. Header Field Definition .........................................9 8. Security Considerations .........................................9 9. Relationship with In-Reply-To ..................................10 10. Example Call Flow .............................................10 11. IANA Considerations ...........................................13 11.1. Header Field .............................................13 11.2. Header Field Parameters ..................................13 11.2.1. local-tag .........................................13 11.2.2. remote-tag ........................................13 11.3. SIP Option Tag ...........................................14 12. Acknowledgements ..............................................14 13. References ....................................................14 13.1. Normative References .....................................14 13.2. Informative References ...................................15 Rosenberg Standards Track [Page 2] RFC 4538 Target Dialog June 2006 1. Introduction The Session Initiation Protocol (SIP) [2] 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, REFER [8], and SUBSCRIBE [3] 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 a user agent's authorization decision depends on whether the sender of the request is currently in a dialog with that user agent, or whether the sender of the request is aware of a dialog the user agent has with another entity. 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 request 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 [12]. These problems include difficulties in determining the lifecycle of the dialog and its usages and in determining whichShow full document text