Protocol Action: 'Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)' to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux