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