Approval announcement
Draft of message to be sent after approval:
Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>,
behave mailing list <behave@ietf.org>,
behave chair <behave-chairs@tools.ietf.org>
Subject: Protocol Action: 'Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)' to Proposed Standard
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
Ballot Text
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.