Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)
RFC 4538

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

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 which