The IESG has approved the following document: - 'Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP) ' <draft-ietf-sip-target-dialog-03.txt> as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact person is Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-target-dialog-03.txt Technical Summary This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. SIP defines the concept of a dialog as a persistent relationship between a pair a of user agents (UA). When a UA receives a request that creates a dialog, it needs 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 whehter 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. Working Group Summary The working group supported the advancement of this specification. Protocol Quality Allison Mankin reviewed this document for the IESG. Dean Willis is the WG Chair shepherd. Notes to RFC Editor: [all of these changes reflect the fact that the GRUU is not essential to target-dialog] Section 1, Introduction, Para 3 OLD: Instead, a better approach is for user agent A to send the REFER request to user agent B outside of the dialog using its Globally Routable User Agent URI (GRUU) [11]. In that case, a means is needed for user agent B to authorize the REFER. NEW: Instead, a better approach is for user agent A to send the REFER request to user agent B outside of the dialog. In that case, a means is needed for user agent B to authorize the REFER. Section 2, Overview of Operation, Para 1 OLD: This 200 OK includes a Supported header field indicating support for both the GRUU specification (through the presence of the gruu option tag) and this specification (through the presence of the tdialog option tag). NEW: This 200 OK includes a Supported header field indicating support for this specification (through the presence of the tdialog option tag). Para #2: OLD: So, the entity acts as a user agent and sends the request to user agent B. This request is addressed to the GRUU of user agent B, which server 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 server A, to reach the specific user agent instance that generated that 200 OK to the INVITE. NEW: So, the entity acts as a user agent and sends the request to user agent B. This request is addressed to the URI of user agent B, which server A learned from inspecting the Contact header field in the 200 OK of the INVITE request. If this URI has the GRUU [11] property (it be used by any element on the Internet, such as server A, to reach the specific user agent instance that generated that 200 OK to the INVITE) then the mechanism will work across NAT boundaries. Section 10, Example Call Flow, Para 1: OLD: To do that, it sends a REFER request to A's GRUU. The flow for this is shown in Figure 5. NEW: To do that, it sends a REFER request to A's URI. The flow for this is shown in Figure 5. Example, Under Figure 5, Legend: "First the caller sends an INVITE, as shown in message 1": OLD: Supported: gruu, tdialog NEW: Supported: tdialog ------ Add the following at the end of Section 1: Section 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [xx]. - Add [xx], a normative reference to RFC 2119. ------- Section 8, Security Considerations OLD: The second condition is that the dialog identifiers be cryptographically random that they cannot be guessed. RFC 3261 requires global uniquess for the Call-ID and 32 bits of cryptographic 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. However, its important to note that this specification truly requires cryptographic randomness, as opposed to just pseudorandom identifiers. Pseudorandom identifiers reduce the probability of collision, but because they are guessable, NEW: The second condition is that the dialog identifiers be sufficiently cryptographically random that they cannot be guessed. RFC 3261 requires global uniqueness for the Call-ID and 32 bits of cryptographic 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. However, it's important to note, that this specification requires true cryptographic randomness as set forth in RFC 4086 [yy]. Weaker pseudorandom identifiers reduce the probability of collision, but because they are guessable, - Add [yy], an Informative reference to RFC 4086 _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
