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. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
