Protocol Action: 'Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'Traversal Using Relays around NAT (TURN): Relay Extensions to Session 
   Traversal Utilities for NAT (STUN) '
   <draft-ietf-behave-turn-16.txt> as a Proposed Standard


This document is the product of the Behavior Engineering for Hindrance Avoidance Working Group. 

The IESG contact persons are Magnus Westerlund and Lars Eggert.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-16.txt

Technical Summary
 
This specification defines a protocol that allows the host to control the
operation of a relay and to exchange IPv4/UDP packets with its peers 
using the relay.  TURN differs from some other relay control protocols 
in that it allows a client to communicate with multiple peers using a
single relay address.

The TURN protocol was designed to be used as part of the ICE
(Interactive Connectivity Establishment) approach to NAT traversal,
though it can be also used without ICE.

Working Group Summary
 
There is a strong consensus on publishing this document. Some details
have had significant discussion and there has been difficult to find the
right trade-off between maintaining transport functionality and the
desired implementability. 

Protocol Quality
 
This specification is well reviewed. It also includes the experience of
implementations and their deployment. 

Personell

The WG shepherd is Dan Wing and the Responsible AD Magnus Westerlund

Note to RFC Editor

Section 2.2, first paragraph:  

OLD: 

   To create an allocation on the server, the client uses an Allocate
   transaction.  The client sends a Allocate request to the server, and
   the server replies with an Allocate success response containing the
   allocated relayed transport address.  The client can include
   attributes in the Allocate request that describe the type of
   allocation it desires (e.g., the lifetime of the allocation).  Since
   relaying data may require lots of bandwidth, the server typically
   requires that the client authenticate itself using STUN's long-term
   credential mechanism, to show that it is authorized to use the
   server.

NEW:

   To create an allocation on the server, the client uses an Allocate
   transaction.  The client sends a Allocate request to the server, and
   the server replies with an Allocate success response containing the
   allocated relayed transport address.  The client can include
   attributes in the Allocate request that describe the type of
   allocation it desires (e.g., the lifetime of the allocation). Since
   relaying data has security implications, the server requires that the
   client authenticate itself, typically using STUN's long-term
   credential mechanism, to show that it is authorized to use the
   server.


Section 4, paragraph 3 (Page 20-21):

OLD:
   [RFC5389] specifies a Long-Term Credential mechanism for STUN.  TURN
   servers and clients MUST implement this mechanism.  The server SHOULD
   demand that all requests from the client be authenticated using this
   mechanism, and the client MUST be prepared to authenticate requests
   if required.

      In general, it is strongly recommended that servers require
      requests to be authenticated, as the security of TURN can
      otherwise be quite weak.  One reason that a server might not
      require requests to be authenticated is that TURN is being used in
      a carefully controlled environment in which the risks of
      unauthenticated requests by hostile third-parties have been
      mitigated.  See Section 17 for more discussion on this point.


NEW:

   [RFC5389] specifies a Long-Term Credential mechanism for STUN.  TURN
   servers and clients MUST implement this mechanism.  The server MUST 
   demand that all requests from the client be authenticated using this 
   mechanism, or that a equally strong or stronger mechanism for client 
   authentication is used.

   [remove paragraph]

Section 6.2, First bullet point in paragraph 2:

OLD:

1.  The server SHOULD require that the request be authenticated using
       the Long-Term Credential mechanism of [RFC5389].

NEW:

1.  The server MUST require that the request be authenticated. Using
       the Long-Term Credential mechanism of [RFC5389] unless another 
       mechanism is signaled.


Section 16, Third paragraph:

OLD:

   The server follows the recommended practice in this specification of
   requiring all requests to be authenticated.  Thus when the server
   receives the initial Allocate request, it rejects the request because
   the request does not contain the authentication attributes.
   Following the procedures of the Long-Term Credential Mechanism of
   STUN [RFC5389], the server includes an ERROR-CODE attribute with a
   value of 401 (Unauthorized), a REALM attribute that specifies the
   authentication realm used by the server (in this case, the server's
   domain "example.com"), and a nonce value in a NONCE attribute.  The
   server also includes a SOFTWARE attribute that gives information
   about the server's software.


NEW: 

   Servers requires any request to be authenticated. Thus when the 
   server receives the initial Allocate request, it rejects the request 
   because the request does not contain the authentication attributes.
   Following the procedures of the Long-Term Credential Mechanism of
   STUN [RFC5389], the server includes an ERROR-CODE attribute with a
   value of 401 (Unauthorized), a REALM attribute that specifies the
   authentication realm used by the server (in this case, the server's
   domain "example.com"), and a nonce value in a NONCE attribute.  The
   server also includes a SOFTWARE attribute that gives information
   about the server's software.

Section 17, second paragraph:

OLD:

   Note: Most of the attacks on TURN are mitigated by the server
   requiring requests be authenticated using the Long-Term Credential
   mechanism of STUN.  Thus it is strongly recommended that servers
   demand that requests be authenticated.  However, in certain
   deployments, the use of this mechanism may be unnecessary.  An
   example might be a deployment where access to the TURN server is
   available only through a network where their are fairly tight
   controls over what devices can connect to the network (and by whom)
   and what software these devices can use.  Tightly-run corporate
   networks can arguably fall into this category.

NEW:

   Most of the attacks on TURN are mitigated by the server
   requiring requests be authenticated. Thus this specification requires 
   the use of authentication. The mandatory to implement mechanism is the
   Long-Term Credential mechanism of STUN. Other authentication 
   mechanisms of equal or stronger security properties may be used. 
   However, it is important to ensure that they can be invoked in an 
   inter-operable way.