draft-ietf-tram-stunbis-02.txt   draft-ietf-tram-stunbis-03.txt 
TRAM M. Petit-Huguenin TRAM M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Obsoletes: 5389 (if approved) G. Salgueiro Obsoletes: 5389 (if approved) G. Salgueiro
Intended status: Standards Track J. Rosenberg Intended status: Standards Track J. Rosenberg
Expires: September 10, 2015 D. Wing Expires: September 27, 2015 D. Wing
Cisco Cisco
R. Mahy R. Mahy
Plantronics Plantronics
P. Matthews P. Matthews
Avaya Avaya
March 09, 2015 March 26, 2015
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-02 draft-ietf-tram-stunbis-03
Abstract Abstract
Session Traversal Utilities for NAT (STUN) is a protocol that serves Session Traversal Utilities for NAT (STUN) is a protocol that serves
as a tool for other protocols in dealing with Network Address as a tool for other protocols in dealing with Network Address
Translator (NAT) traversal. It can be used by an endpoint to Translator (NAT) traversal. It can be used by an endpoint to
determine the IP address and port allocated to it by a NAT. It can determine the IP address and port allocated to it by a NAT. It can
also be used to check connectivity between two endpoints, and as a also be used to check connectivity between two endpoints, and as a
keep-alive protocol to maintain NAT bindings. STUN works with many keep-alive protocol to maintain NAT bindings. STUN works with many
existing NATs, and does not require any special behavior from them. existing NATs, and does not require any special behavior from them.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015. This Internet-Draft will expire on September 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 44 skipping to change at page 3, line 44
15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 44 15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 44
15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 45 15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 45
15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 45 15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 45
15.2.3. Attack III: Assuming the Identity of a Client . . . 46 15.2.3. Attack III: Assuming the Identity of a Client . . . 46
15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 46 15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 46
15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 46 15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 46
16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 46 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 46
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . 47 17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . 47
17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . 47 17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . 47
17.2.1. Updated Attributes . . . . . . . . . . . . . . . . . 47
17.2.2. New Attributes . . . . . . . . . . . . . . . . . . . 48
17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 48 17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 48
17.4. Password Algorithm Registry . . . . . . . . . . . . . . 49 17.4. Password Algorithm Registry . . . . . . . . . . . . . . 48
17.4.1. Password Algorithms . . . . . . . . . . . . . . . . 49 17.4.1. Password Algorithms . . . . . . . . . . . . . . . . 49
17.4.1.1. Salted SHA256 . . . . . . . . . . . . . . . . . 49 17.4.1.1. SHA256 . . . . . . . . . . . . . . . . . . . . . 49
17.4.1.2. Salted SHA256 . . . . . . . . . . . . . . . . . 49
17.5. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 49 17.5. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 49
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 50
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 49
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
19.1. Normative References . . . . . . . . . . . . . . . . . . 50 19.1. Normative References . . . . . . . . . . . . . . . . . . 50
19.2. Informational References . . . . . . . . . . . . . . . . 52 19.2. Informational References . . . . . . . . . . . . . . . . 52
Appendix A. C Snippet to Determine STUN Message Types . . . . . 53 Appendix A. C Snippet to Determine STUN Message Types . . . . . 53
Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 54 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 54
B.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 54 B.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 54
B.2. Modifications between draft-ietf-tram-stunbis-02 and B.2. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 54 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 54
B.3. Modifications between draft-ietf-tram-stunbis-01 and B.3. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 55 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 55
B.4. Modifications between draft-salgueiro-tram-stunbis-02 and B.4. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 55 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 55
B.5. Modifications between draft-salgueiro-tram-stunbis-02 and B.5. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 56
B.6. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 56 draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 56
B.6. Modifications between draft-salgueiro-tram-stunbis-01 and B.7. Modifications between draft-salgueiro-tram-stunbis-01 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 56 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 57
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 56 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
The protocol defined in this specification, Session Traversal The protocol defined in this specification, Session Traversal
Utilities for NAT, provides a tool for dealing with NATs. It Utilities for NAT, provides a tool for dealing with NATs. It
provides a means for an endpoint to determine the IP address and port provides a means for an endpoint to determine the IP address and port
allocated by a NAT that corresponds to its private IP address and allocated by a NAT that corresponds to its private IP address and
port. It also provides a way for an endpoint to keep a NAT binding port. It also provides a way for an endpoint to keep a NAT binding
alive. With some extensions, the protocol can be used to do alive. With some extensions, the protocol can be used to do
connectivity checks between two endpoints [RFC5245], or to relay connectivity checks between two endpoints
packets between two endpoints [RFC5766]. [I-D.ietf-mmusic-rfc5245bis], or to relay packets between two
endpoints [RFC5766].
In keeping with its tool nature, this specification defines an In keeping with its tool nature, this specification defines an
extensible packet format, defines operation over several transport extensible packet format, defines operation over several transport
protocols, and provides for two forms of authentication. protocols, and provides for two forms of authentication.
STUN is intended to be used in context of one or more NAT traversal STUN is intended to be used in context of one or more NAT traversal
solutions. These solutions are known as STUN usages. Each usage solutions. These solutions are known as STUN usages. Each usage
describes how STUN is utilized to achieve the NAT traversal solution. describes how STUN is utilized to achieve the NAT traversal solution.
Typically, a usage indicates when STUN messages get sent, which Typically, a usage indicates when STUN messages get sent, which
optional attributes to include, what server is used, and what optional attributes to include, what server is used, and what
authentication mechanism is to be used. Interactive Connectivity authentication mechanism is to be used. Interactive Connectivity
Establishment (ICE) [RFC5245] is one usage of STUN. SIP Outbound Establishment (ICE) [I-D.ietf-mmusic-rfc5245bis] is one usage of
[RFC5626] is another usage of STUN. In some cases, a usage will STUN. SIP Outbound [RFC5626] is another usage of STUN. In some
require extensions to STUN. A STUN extension can be in the form of cases, a usage will require extensions to STUN. A STUN extension can
new methods, attributes, or error response codes. More information be in the form of new methods, attributes, or error response codes.
on STUN usages can be found in Section 13. More information on STUN usages can be found in Section 13.
Implementations and deployments of a STUN usage should follow the Implementations and deployments of a STUN usage using TLS or DTLS
recommendations in [I-D.ietf-uta-tls-bcp]. should follow the recommendations in [I-D.ietf-uta-tls-bcp].
2. Overview of Operation 2. Overview of Operation
This section is descriptive only. This section is descriptive only.
/-----\ /-----\
// STUN \\ // STUN \\
| Server | | Server |
\\ // \\ //
\-----/ \-----/
+--------------+ Public Internet +--------------+ Public Internet
................| NAT 2 |....................... ................| NAT 2 |.......................
+--------------+ +--------------+
+--------------+ Private NET 2 +--------------+ Private NET 2
................| NAT 1 |....................... ................| NAT 1 |.......................
+--------------+ +--------------+
/-----\ /-----\
// STUN \\ // STUN \\
| Client | | Client |
\\ // Private NET 1 \\ // Private NET 1
\-----/ \-----/
Figure 1: One Possible STUN Configuration Figure 1: One Possible STUN Configuration
One possible STUN configuration is shown in Figure 1. In this One possible STUN configuration is shown in Figure 1. In this
configuration, there are two entities (called STUN agents) that configuration, there are two entities (called STUN agents) that
implement the STUN protocol. The lower agent in the figure is the implement the STUN protocol. The lower agent in the figure is the
client, and is connected to private network 1. This network connects client, and is connected to private network 1. This network connects
to private network 2 through NAT 1. Private network 2 connects to to private network 2 through NAT 1. Private network 2 connects to
the public Internet through NAT 2. The upper agent in the figure is the public Internet through NAT 2. The upper agent in the figure is
the server, and resides on the public Internet. the server, and resides on the public Internet.
skipping to change at page 6, line 47 skipping to change at page 7, line 6
server copies that source transport address into an XOR-MAPPED- server copies that source transport address into an XOR-MAPPED-
ADDRESS attribute in the STUN Binding response and sends the Binding ADDRESS attribute in the STUN Binding response and sends the Binding
response back to the STUN client. As this packet passes back through response back to the STUN client. As this packet passes back through
a NAT, the NAT will modify the destination transport address in the a NAT, the NAT will modify the destination transport address in the
IP header, but the transport address in the XOR-MAPPED-ADDRESS IP header, but the transport address in the XOR-MAPPED-ADDRESS
attribute within the body of the STUN response will remain untouched. attribute within the body of the STUN response will remain untouched.
In this way, the client can learn its reflexive transport address In this way, the client can learn its reflexive transport address
allocated by the outermost NAT with respect to the STUN server. allocated by the outermost NAT with respect to the STUN server.
In some usages, STUN must be multiplexed with other protocols (e.g., In some usages, STUN must be multiplexed with other protocols (e.g.,
[RFC5245], [RFC5626]). In these usages, there must be a way to [I-D.ietf-mmusic-rfc5245bis], [RFC5626]). In these usages, there
inspect a packet and determine if it is a STUN packet or not. STUN must be a way to inspect a packet and determine if it is a STUN
provides three fields in the STUN header with fixed values that can packet or not. STUN provides three fields in the STUN header with
be used for this purpose. If this is not sufficient, then STUN fixed values that can be used for this purpose. If this is not
packets can also contain a FINGERPRINT value, which can further be sufficient, then STUN packets can also contain a FINGERPRINT value,
used to distinguish the packets. which can further be used to distinguish the packets.
STUN defines a set of optional procedures that a usage can decide to STUN defines a set of optional procedures that a usage can decide to
use, called mechanisms. These mechanisms include DNS discovery, a use, called mechanisms. These mechanisms include DNS discovery, a
redirection technique to an alternate server, a fingerprint attribute redirection technique to an alternate server, a fingerprint attribute
for demultiplexing, and two authentication and message-integrity for demultiplexing, and two authentication and message-integrity
exchanges. The authentication mechanisms revolve around the use of a exchanges. The authentication mechanisms revolve around the use of a
username, password, and message-integrity value. Two authentication username, password, and message-integrity value. Two authentication
mechanisms, the long-term credential mechanism and the short-term mechanisms, the long-term credential mechanism and the short-term
credential mechanism, are defined in this specification. Each usage credential mechanism, are defined in this specification. Each usage
specifies the mechanisms allowed with that usage. specifies the mechanisms allowed with that usage.
In the long-term credential mechanism, the client and server share a In the long-term credential mechanism, the client and server share a
pre-provisioned username and password and perform a digest challenge/ pre-provisioned username and password and perform a digest challenge/
response exchange inspired by (but differing in details) to the one response exchange inspired by (but differing in details) to the one
defined for HTTP [RFC2617]. In the short-term credential mechanism, defined for HTTP [RFC2617]. In the short-term credential mechanism,
the client and the server exchange a username and password through the client and the server exchange a username and password through
some out-of-band method prior to the STUN exchange. For example, in some out-of-band method prior to the STUN exchange. For example, in
the ICE usage [RFC5245] the two endpoints use out-of-band signaling the ICE usage [I-D.ietf-mmusic-rfc5245bis] the two endpoints use out-
to exchange a username and password. These are used to integrity of-band signaling to exchange a username and password. These are
protect and authenticate the request and response. There is no used to integrity protect and authenticate the request and response.
challenge or nonce used. There is no challenge or nonce used.
3. Terminology 3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant STUN [RFC2119] and indicate requirement levels for compliant STUN
implementations. implementations.
4. Definitions 4. Definitions
skipping to change at page 15, line 48 skipping to change at page 15, line 48
For SCTP-over-UDP [RFC6951] and SCTP-over-DTLS-over-UDP For SCTP-over-UDP [RFC6951] and SCTP-over-DTLS-over-UDP
[I-D.ietf-tsvwg-sctp-dtls-encaps], the client opens a Stream Control [I-D.ietf-tsvwg-sctp-dtls-encaps], the client opens a Stream Control
Transmission Protocol (SCTP) connection to the server. Transmission Protocol (SCTP) connection to the server.
For some STUN usages, STUN is sent over SCTP as the only protocol For some STUN usages, STUN is sent over SCTP as the only protocol
over the UDP association. In this case, it can be sent without the over the UDP association. In this case, it can be sent without the
aid of any additional demultiplexing. In other usages, or with other aid of any additional demultiplexing. In other usages, or with other
extensions, it may be multiplexed with other data over a UDP extensions, it may be multiplexed with other data over a UDP
association. In that case, the SCTP source and destination ports association. In that case, the SCTP source and destination ports
MUST be chosen so the two most significant bits are 0b11. MUST be chosen so the eight most significant bits are 0b00000101 (5).
Reliability of STUN over SCTP-over-UDP and STUN over SCTP-over-DTLS- Reliability of STUN over SCTP-over-UDP and STUN over SCTP-over-DTLS-
over-UDP is handled by SCTP itself and there are no retransmissions over-UDP is handled by SCTP itself and there are no retransmissions
at the STUN protocol level. However, for a request/response at the STUN protocol level. However, for a request/response
transaction, if the client has not received a response by Ti seconds transaction, if the client has not received a response by Ti seconds
after it sent the INIT to establish the connection, it considers the after it sent the INIT to establish the connection, it considers the
transaction to have timed out. Ti SHOULD be configurable and SHOULD transaction to have timed out. Ti SHOULD be configurable and SHOULD
have a default of 39.5s. This value has been chosen to equalize the have a default of 39.5s. This value has been chosen to equalize the
SCTP-over-UDP, TCP, and UDP timeouts for the default initial RTO. SCTP-over-UDP, TCP, and UDP timeouts for the default initial RTO.
skipping to change at page 16, line 33 skipping to change at page 16, line 33
o has no plans to use any resources (such as a mapped address o has no plans to use any resources (such as a mapped address
(MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) or relayed address (MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) or relayed address
[RFC5766]) that were learned through STUN requests sent over that [RFC5766]) that were learned through STUN requests sent over that
connection, and connection, and
o has finished using all corresponding applications if multiplexing o has finished using all corresponding applications if multiplexing
other application protocols over that port other application protocols over that port
When using SCTP-over-UDP, the SCTP source port and destination port When using SCTP-over-UDP, the SCTP source port and destination port
MUST be selected so the two most significant bits are set to "1". MUST be selected so the eight most significant bits are set to
This permits multiplexing of STUN-over-UDP, STUN-over-SCTP-over-UDP, 0b00000101. This permits multiplexing of STUN-over-UDP, STUN-over-
DTLS, and RTP/RTCP on the same socket. SCTP-over-UDP, DTLS, TURN channels and RTP/RTCP on the same socket as
specified in [I-D.ietf-avtcore-rfc5764-mux-fixes].
STUN indications MAY be sent unreliably by using the SCTP extension STUN indications MAY be sent unreliably by using the SCTP extension
in [RFC3758], augmented with the policies of in [RFC3758], augmented with the policies of
[I-D.ietf-tsvwg-sctp-prpolicies]. Each STUN usage MUST specify the [I-D.ietf-tsvwg-sctp-prpolicies]. Each STUN usage MUST specify the
conditions under which STUN indications are sent reliably or not, and conditions under which STUN indications are sent reliably or not, and
MUST specify the policy for allocating an SCTP stream ID. The NAT MUST specify the policy for allocating an SCTP stream ID. The NAT
Discovery usage described in this document does not use STUN Discovery usage described in this document does not use STUN
indications. indications.
At the server end, the server SHOULD keep the connection open and let At the server end, the server SHOULD keep the connection open and let
skipping to change at page 20, line 17 skipping to change at page 20, line 17
attributes to the response (see Section 9). attributes to the response (see Section 9).
The server also adds any attributes required by the specific method The server also adds any attributes required by the specific method
or usage. In addition, the server SHOULD add a SOFTWARE attribute to or usage. In addition, the server SHOULD add a SOFTWARE attribute to
the message. the message.
For the Binding method, no additional checking is required unless the For the Binding method, no additional checking is required unless the
usage specifies otherwise. When forming the success response, the usage specifies otherwise. When forming the success response, the
server adds a XOR-MAPPED-ADDRESS attribute to the response, where the server adds a XOR-MAPPED-ADDRESS attribute to the response, where the
contents of the attribute are the source transport address of the contents of the attribute are the source transport address of the
request message. For UDP and DTLS-over-UDP, this is the source IP request message. For UDP, DTLS-over-UDP, SCTP-over-UDP and SCTP-
address and source UDP port of the request message. For TCP and TLS- over-DTLS-over-UDP, this is the source IP address and source UDP port
over-TCP, this is the source IP address and source TCP port of the of the request message. For TCP and TLS-over-TCP, this is the source
TCP connection as seen by the server. IP address and source TCP port of the TCP connection as seen by the
server.
6.3.1.2. Sending the Success or Error Response 6.3.1.2. Sending the Success or Error Response
The response (success or error) is sent over the same transport as The response (success or error) is sent over the same transport as
the request was received on. If the request was received over UDP or the request was received on. If the request was received over UDP,
DTLS-over-UDP, the destination IP address and port of the response DTLS-over-UDP, SCTP-over-UDP and SCTP-over-DTLS-over-UDP, the
are the source IP address and port of the received request message, destination IP address and port of the response are the source IP
and the source IP address and port of the response are equal to the address and port of the received request message, and the source IP
destination IP address and port of the received request message. If address and port of the response are equal to the destination IP
the request was received over TCP or TLS-over-TCP, the response is address and port of the received request message. If the request was
sent back on the same TCP connection as the request was received on. received over TCP or TLS-over-TCP, the response is sent back on the
same TCP connection as the request was received on.
6.3.2. Processing an Indication 6.3.2. Processing an Indication
If the indication contains unknown comprehension-required attributes, If the indication contains unknown comprehension-required attributes,
the indication is discarded and processing ceases. the indication is discarded and processing ceases.
The agent then does any additional checking that the method or the The agent then does any additional checking that the method or the
specific usage requires. If all the checks succeed, the agent then specific usage requires. If all the checks succeed, the agent then
processes the indication. No response is generated for an processes the indication. No response is generated for an
indication. indication.
skipping to change at page 24, line 33 skipping to change at page 24, line 33
a message, when receiving a message immediately after the basic a message, when receiving a message immediately after the basic
checks have been performed, and when doing the detailed processing of checks have been performed, and when doing the detailed processing of
error responses. error responses.
9.1. Short-Term Credential Mechanism 9.1. Short-Term Credential Mechanism
The short-term credential mechanism assumes that, prior to the STUN The short-term credential mechanism assumes that, prior to the STUN
transaction, the client and server have used some other protocol to transaction, the client and server have used some other protocol to
exchange a credential in the form of a username and password. This exchange a credential in the form of a username and password. This
credential is time-limited. The time limit is defined by the usage. credential is time-limited. The time limit is defined by the usage.
As an example, in the ICE usage [RFC5245], the two endpoints use out- As an example, in the ICE usage [I-D.ietf-mmusic-rfc5245bis], the two
of-band signaling to agree on a username and password, and this endpoints use out-of-band signaling to agree on a username and
username and password are applicable for the duration of the media password, and this username and password are applicable for the
session. duration of the media session.
This credential is used to form a message-integrity check in each This credential is used to form a message-integrity check in each
request and in many responses. There is no challenge and response as request and in many responses. There is no challenge and response as
in the long-term mechanism; consequently, replay is prevented by in the long-term mechanism; consequently, replay is prevented by
virtue of the time-limited nature of the credential. virtue of the time-limited nature of the credential.
9.1.1. HMAC Key 9.1.1. HMAC Key
For short-term credentials the HMAC key is defined as follow: For short-term credentials the HMAC key is defined as follow:
key = SASLprep(password) key = OpaqueString(password)
where SASLprep() is defined in RFC 4013 [RFC4013]. where the OpaqueString profile is defined in
[I-D.ietf-precis-saslprepbis].
9.1.2. Forming a Request or Indication 9.1.2. Forming a Request or Indication
For a request or indication message, the agent MUST include the For a request or indication message, the agent MUST include the
USERNAME, MESSAGE-INTEGRITY2, and MESSAGE-INTEGRITY attributes in the USERNAME, MESSAGE-INTEGRITY2, and MESSAGE-INTEGRITY attributes in the
message. The HMAC for the MESSAGE-INTEGRITY attribute is computed as message. The HMAC for the MESSAGE-INTEGRITY attribute is computed as
described in Section 14.4 and the HMAC for the MESSAGE-INTEGRITY2 described in Section 14.4 and the HMAC for the MESSAGE-INTEGRITY2
attributes is computed as described in Section 14.5. Note that the attributes is computed as described in Section 14.5. Note that the
password is never included in the request or indication. password is never included in the request or indication.
skipping to change at page 27, line 43 skipping to change at page 27, line 43
by the user, but are rather placed on a client device during device by the user, but are rather placed on a client device during device
provisioning, the password SHOULD have at least 128 bits of provisioning, the password SHOULD have at least 128 bits of
randomness. In cases where the credentials are entered by the user, randomness. In cases where the credentials are entered by the user,
they should follow best current practices around password structure. they should follow best current practices around password structure.
9.2.1. HMAC Key 9.2.1. HMAC Key
For long-term credentials that do not use a different algorithm, as For long-term credentials that do not use a different algorithm, as
specified by the PASSWORD-ALGORITHM attribute, the key is 16 bytes: specified by the PASSWORD-ALGORITHM attribute, the key is 16 bytes:
key = MD5(username ":" realm ":" SASLprep(password)) key = MD5(username ":" realm ":" OpaqueString(password))
Where MD5 is defined in RFC 1321 [RFC1321] and SASLprep() is defined Where MD5 is defined in RFC 1321 [RFC1321] and the OpaqueString
in RFC 4013 [RFC4013]. profile is defined in [I-D.ietf-precis-saslprepbis].
The 16-byte key is formed by taking the MD5 hash of the result of The 16-byte key is formed by taking the MD5 hash of the result of
concatenating the following five fields: (1) the username, with any concatenating the following five fields: (1) the username, with any
quotes and trailing nulls removed, as taken from the USERNAME quotes and trailing nulls removed, as taken from the USERNAME
attribute (in which case SASLprep has already been applied); (2) a attribute (in which case OpaqueString has already been applied); (2)
single colon; (3) the realm, with any quotes and trailing nulls a single colon; (3) the realm, with any quotes and trailing nulls
removed; (4) a single colon; and (5) the password, with any trailing removed; (4) a single colon; and (5) the password, with any trailing
nulls removed and after processing using SASLprep. For example, if nulls removed and after processing using OpaqueString. For example,
the username was 'user', the realm was 'realm', and the password was if the username was 'user', the realm was 'realm', and the password
'pass', then the 16-byte HMAC key would be the result of performing was 'pass', then the 16-byte HMAC key would be the result of
an MD5 hash on the string 'user:realm:pass', the resulting hash being performing an MD5 hash on the string 'user:realm:pass', the resulting
0x8493fbc53ba582fb4c044c456bdc40eb. hash being 0x8493fbc53ba582fb4c044c456bdc40eb.
The structure of the key when used with long-term credentials The structure of the key when used with long-term credentials
facilitates deployment in systems that also utilize SIP. Typically, facilitates deployment in systems that also utilize SIP. Typically,
SIP systems utilizing SIP's digest authentication mechanism do not SIP systems utilizing SIP's digest authentication mechanism do not
actually store the password in the database. Rather, they store a actually store the password in the database. Rather, they store a
value called H(A1), which is equal to the key defined above. value called H(A1), which is equal to the key defined above.
When a PASSWORD-ALGORITHM is used, the key length and algorithm to When a PASSWORD-ALGORITHM is used, the key length and algorithm to
use are described in Section 17.4.1. use are described in Section 17.4.1.
skipping to change at page 29, line 27 skipping to change at page 29, line 27
include a REALM value. It is RECOMMENDED that the REALM value be include a REALM value. It is RECOMMENDED that the REALM value be
the domain name of the provider of the STUN server. The response the domain name of the provider of the STUN server. The response
MUST include a NONCE, selected by the server. The server MUST MUST include a NONCE, selected by the server. The server MUST
ensure that the same NONCE cannot be selected for clients that use ensure that the same NONCE cannot be selected for clients that use
different IP addresses and/or different ports. The server MAY different IP addresses and/or different ports. The server MAY
support alternate password algorithms, in which case it can list support alternate password algorithms, in which case it can list
them in preferential order in a PASSWORD-ALGORITHMS attribute. If them in preferential order in a PASSWORD-ALGORITHMS attribute. If
the server adds a PASSWORD-ALGORITHMS attribute it MUST prepend the server adds a PASSWORD-ALGORITHMS attribute it MUST prepend
the NONCE attribute value with the character string "obMatJos2". the NONCE attribute value with the character string "obMatJos2".
The response SHOULD NOT contain a USERNAME, MESSAGE-INTEGRITY or The response SHOULD NOT contain a USERNAME, MESSAGE-INTEGRITY or
MESSAGE-INTEGRITY2 attribute. MESSAGE-INTEGRITY2 attribute. The "obMatJos2" prefix is used to
prevent bid down attacks on the password algorithm's negotiation.
o If the message contains a MESSAGE-INTEGRITY or a MESSAGE- o If the message contains a MESSAGE-INTEGRITY or a MESSAGE-
INTEGRITY2 attribute, but is missing the USERNAME, REALM, or NONCE INTEGRITY2 attribute, but is missing the USERNAME, REALM, or NONCE
attribute, the server MUST generate an error response with an attribute, the server MUST generate an error response with an
error code of 400 (Bad Request). This response SHOULD NOT include error code of 400 (Bad Request). This response SHOULD NOT include
a USERNAME, NONCE, REALM, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY2 a USERNAME, NONCE, REALM, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY2
attribute. attribute.
o If the NONCE attribute starts with the value "obMatJos2" but the o If the NONCE attribute starts with the value "obMatJos2" but the
PASSWORD-ALGORITHMS attribute is not present or is not identical PASSWORD-ALGORITHMS attribute is not present or is not identical
skipping to change at page 33, line 13 skipping to change at page 33, line 17
usages. This is discussed further in Section 13. usages. This is discussed further in Section 13.
13. STUN Usages 13. STUN Usages
STUN by itself is not a solution to the NAT traversal problem. STUN by itself is not a solution to the NAT traversal problem.
Rather, STUN defines a tool that can be used inside a larger Rather, STUN defines a tool that can be used inside a larger
solution. The term "STUN usage" is used for any solution that uses solution. The term "STUN usage" is used for any solution that uses
STUN as a component. STUN as a component.
At the time of writing, three STUN usages are defined: Interactive At the time of writing, three STUN usages are defined: Interactive
Connectivity Establishment (ICE) [RFC5245], Client-initiated Connectivity Establishment (ICE) [I-D.ietf-mmusic-rfc5245bis],
connections for SIP [RFC5626], and NAT Behavior Discovery [RFC5780]. Client-initiated connections for SIP [RFC5626], and NAT Behavior
Other STUN usages may be defined in the future. Discovery [RFC5780]. Other STUN usages may be defined in the future.
A STUN usage defines how STUN is actually utilized -- when to send A STUN usage defines how STUN is actually utilized -- when to send
requests, what to do with the responses, and which optional requests, what to do with the responses, and which optional
procedures defined here (or in an extension to STUN) are to be used. procedures defined here (or in an extension to STUN) are to be used.
A usage would also define: A usage would also define:
o Which STUN methods are used. o Which STUN methods are used.
o What transports are used. If DTLS-over-UDP is used then o What transports are used. If DTLS-over-UDP is used then
implementing the denial-of-service countermeasure described in implementing the denial-of-service countermeasure described in
skipping to change at page 36, line 10 skipping to change at page 36, line 10
The XOR-MAPPED-ADDRESS attribute is identical to the MAPPED-ADDRESS The XOR-MAPPED-ADDRESS attribute is identical to the MAPPED-ADDRESS
attribute, except that the reflexive transport address is obfuscated attribute, except that the reflexive transport address is obfuscated
through the XOR function. through the XOR function.
The format of the XOR-MAPPED-ADDRESS is: The format of the XOR-MAPPED-ADDRESS is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x x x x x| Family | X-Port | |0 0 0 0 0 0 0 0| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (Variable) | X-Address (Variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of XOR-MAPPED-ADDRESS Attribute Figure 6: Format of XOR-MAPPED-ADDRESS Attribute
The Family represents the IP address family, and is encoded The Family represents the IP address family, and is encoded
identically to the Family in MAPPED-ADDRESS. identically to the Family in MAPPED-ADDRESS.
X-Port is computed by taking the mapped port in host byte order, X-Port is computed by taking the mapped port in host byte order,
skipping to change at page 37, line 7 skipping to change at page 37, line 7
failure of STUN's message-integrity checking. failure of STUN's message-integrity checking.
14.3. USERNAME 14.3. USERNAME
The USERNAME attribute is used for message integrity. It identifies The USERNAME attribute is used for message integrity. It identifies
the username and password combination used in the message-integrity the username and password combination used in the message-integrity
check. check.
The value of USERNAME is a variable-length value. It MUST contain a The value of USERNAME is a variable-length value. It MUST contain a
UTF-8 [RFC3629] encoded sequence of less than 513 bytes, and MUST UTF-8 [RFC3629] encoded sequence of less than 513 bytes, and MUST
have been processed using SASLprep [RFC4013]. have been processed using the OpaqueString profile
[I-D.ietf-precis-saslprepbis].
14.4. MESSAGE-INTEGRITY 14.4. MESSAGE-INTEGRITY
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of
the STUN message. The MESSAGE-INTEGRITY attribute can be present in the STUN message. The MESSAGE-INTEGRITY attribute can be present in
any STUN message type. Since it uses the SHA1 hash, the HMAC will be any STUN message type. Since it uses the SHA1 hash, the HMAC will be
20 bytes. The text used as input to HMAC is the STUN message, 20 bytes. The text used as input to HMAC is the STUN message,
including the header, up to and including the attribute preceding the including the header, up to and including the attribute preceding the
MESSAGE-INTEGRITY attribute. With the exception of the MESSAGE- MESSAGE-INTEGRITY attribute. With the exception of the MESSAGE-
INTEGRITY2 and FINGERPRINT attributes, which appear after MESSAGE- INTEGRITY2 and FINGERPRINT attributes, which appear after MESSAGE-
skipping to change at page 40, line 37 skipping to change at page 40, line 40
client should try again. client should try again.
14.8. REALM 14.8. REALM
The REALM attribute may be present in requests and responses. It The REALM attribute may be present in requests and responses. It
contains text that meets the grammar for "realm-value" as described contains text that meets the grammar for "realm-value" as described
in RFC 3261 [RFC3261] but without the double quotes and their in RFC 3261 [RFC3261] but without the double quotes and their
surrounding whitespace. That is, it is an unquoted realm-value (and surrounding whitespace. That is, it is an unquoted realm-value (and
is therefore a sequence of qdtext or quoted-pair). It MUST be a is therefore a sequence of qdtext or quoted-pair). It MUST be a
UTF-8 [RFC3629] encoded sequence of less than 128 characters (which UTF-8 [RFC3629] encoded sequence of less than 128 characters (which
can be as long as 763 bytes), and MUST have been processed using can be as long as 763 bytes), and MUST have been processed using the
SASLprep [RFC4013]. OpaqueString profile [I-D.ietf-precis-saslprepbis].
Presence of the REALM attribute in a request indicates that long-term Presence of the REALM attribute in a request indicates that long-term
credentials are being used for authentication. Presence in certain credentials are being used for authentication. Presence in certain
error responses indicates that the server wishes the client to use a error responses indicates that the server wishes the client to use a
long-term credential for authentication. long-term credential for authentication.
14.9. NONCE 14.9. NONCE
The NONCE attribute may be present in requests and responses. It The NONCE attribute may be present in requests and responses. It
contains a sequence of qdtext or quoted-pair, which are defined in contains a sequence of qdtext or quoted-pair, which are defined in
skipping to change at page 44, line 17 skipping to change at page 44, line 17
message integrity are not required since these attacks are detected message integrity are not required since these attacks are detected
during the connectivity check phase. The connectivity checks during the connectivity check phase. The connectivity checks
themselves, however, require protection for proper operation of ICE themselves, however, require protection for proper operation of ICE
overall. As described in Section 13, STUN usages describe when overall. As described in Section 13, STUN usages describe when
authentication and message integrity are needed. authentication and message integrity are needed.
Since STUN uses the HMAC of a shared secret for authentication and Since STUN uses the HMAC of a shared secret for authentication and
integrity protection, it is subject to offline dictionary attacks. integrity protection, it is subject to offline dictionary attacks.
When authentication is utilized, it SHOULD be with a strong password When authentication is utilized, it SHOULD be with a strong password
that is not readily subject to offline dictionary attacks. that is not readily subject to offline dictionary attacks.
Protection of the channel itself, using TLS, mitigates these attacks. Protection of the channel itself, using TLS or DTLS, mitigates these
However, STUN is most often run over UDP and in those cases, strong attacks.
passwords are the only way to protect against these attacks.
STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY2, which is
subject to bid down attacks by an on-path attacker. Protection of
the channel itself, using TLS or DTLS, mitigates these attacks.
Timely removal of the support of MESSAGE-INTEGRITY in a future
version of STUN is necessary.
15.1.2. Inside Attacks 15.1.2. Inside Attacks
A rogue client may try to launch a DoS attack against a server by A rogue client may try to launch a DoS attack against a server by
sending it a large number of STUN requests. Fortunately, STUN sending it a large number of STUN requests. Fortunately, STUN
requests can be processed statelessly by a server, making such requests can be processed statelessly by a server, making such
attacks hard to launch. attacks hard to launch.
A rogue client may use a STUN server as a reflector, sending it A rogue client may use a STUN server as a reflector, sending it
requests with a falsified source IP address and port. In such a requests with a falsified source IP address and port. In such a
skipping to change at page 45, line 18 skipping to change at page 45, line 23
attacker can modify the source IP address of the Binding request attacker can modify the source IP address of the Binding request
before it arrives at the STUN server. The STUN server will then before it arrives at the STUN server. The STUN server will then
return this IP address in the XOR-MAPPED-ADDRESS attribute to the return this IP address in the XOR-MAPPED-ADDRESS attribute to the
client, and send the response back to that (falsified) IP address and client, and send the response back to that (falsified) IP address and
port. If the attacker can also intercept this response, it can port. If the attacker can also intercept this response, it can
direct it back towards the client. Protecting against this attack by direct it back towards the client. Protecting against this attack by
using a message-integrity check is impossible, since a message- using a message-integrity check is impossible, since a message-
integrity value cannot cover the source IP address, since the integrity value cannot cover the source IP address, since the
intervening NAT must be able to modify this value. Instead, one intervening NAT must be able to modify this value. Instead, one
solution to preventing the attacks listed below is for the client to solution to preventing the attacks listed below is for the client to
verify the reflexive address learned, as is done in ICE [RFC5245]. verify the reflexive address learned, as is done in ICE
Other usages may use other means to prevent these attacks. [I-D.ietf-mmusic-rfc5245bis]. Other usages may use other means to
prevent these attacks.
15.2.1. Attack I: Distributed DoS (DDoS) against a Target 15.2.1. Attack I: Distributed DoS (DDoS) against a Target
In this attack, the attacker provides one or more clients with the In this attack, the attacker provides one or more clients with the
same faked reflexive address that points to the intended target. same faked reflexive address that points to the intended target.
This will trick the STUN clients into thinking that their reflexive This will trick the STUN clients into thinking that their reflexive
addresses are equal to that of the target. If the clients hand out addresses are equal to that of the target. If the clients hand out
that reflexive address in order to receive traffic on it (for that reflexive address in order to receive traffic on it (for
example, in SIP messages), the traffic will instead be sent to the example, in SIP messages), the traffic will instead be sent to the
target. This attack can provide substantial amplification, target. This attack can provide substantial amplification,
skipping to change at page 46, line 27 skipping to change at page 46, line 29
the attack, the attacker must have already been able to observe the attack, the attacker must have already been able to observe
packets from the client to the STUN server. In most cases (such as packets from the client to the STUN server. In most cases (such as
when the attack is launched from an access network), this means that when the attack is launched from an access network), this means that
the attacker could already observe packets sent to the client. This the attacker could already observe packets sent to the client. This
attack is, as a result, only useful for observing traffic by attack is, as a result, only useful for observing traffic by
attackers on the path from the client to the STUN server, but not attackers on the path from the client to the STUN server, but not
generally on the path of packets being routed towards the client. generally on the path of packets being routed towards the client.
15.3. Hash Agility Plan 15.3. Hash Agility Plan
This specification uses HMAC-SHA-1 for computation of the message This specification uses both HMAC-SHA-1 and HMAC-SHA-256 for
integrity. If, at a later time, HMAC-SHA-1 is found to be computation of the message integrity. If, at a later time, HMAC-
compromised, the following is the remedy that will be applied. SHA-256 is found to be compromised, the following is the remedy that
will be applied.
We will define a STUN extension that introduces a new message- We will define a STUN extension that introduces a new message-
integrity attribute, computed using a new hash. Clients would be integrity attribute, computed using a new hash. Clients would be
required to include both the new and old message-integrity attributes required to include both the new and old message-integrity attributes
in their requests or indications. A new server will utilize the new in their requests or indications. A new server will utilize the new
message-integrity attribute, and an old one, the old. After a message-integrity attribute, and an old one, the old. After a
transition period where mixed implementations are in deployment, the transition period where mixed implementations are in deployment, the
old message-integrity attribute will be deprecated by another old message-integrity attribute will be deprecated by another
specification, and clients will cease including it in requests. specification, and clients will cease including it in requests.
It is also important to note that the HMAC is done using a key that After a transition period, a new document updating this document will
is itself computed using an MD5 of the user's password. The choice remove the usage of HMAC-SHA-1 for computation of the message-
of the MD5 hash was made because of the existence of legacy databases integrity.
that store passwords in that form. If future work finds that an HMAC
of an MD5 input is not secure, and a different hash is needed, it can
also be changed using this plan. However, this would require
administrators to repopulate their databases.
16. IAB Considerations 16. IAB Considerations
The IAB has studied the problem of Unilateral Self-Address Fixing The IAB has studied the problem of Unilateral Self-Address Fixing
(UNSAF), which is the general process by which a client attempts to (UNSAF), which is the general process by which a client attempts to
determine its address in another realm on the other side of a NAT determine its address in another realm on the other side of a NAT
through a collaborative protocol reflection mechanism (RFC3424 through a collaborative protocol reflection mechanism (RFC3424
[RFC3424]). STUN can be used to perform this function using a [RFC3424]). STUN can be used to perform this function using a
Binding request/response transaction if one agent is behind a NAT and Binding request/response transaction if one agent is behind a NAT and
the other is on the public side of the NAT. the other is on the public side of the NAT.
The IAB has suggested that protocols developed for this purpose The IAB has suggested that protocols developed for this purpose
document a specific set of considerations. Because some STUN usages document a specific set of considerations. Because some STUN usages
provide UNSAF functions (such as ICE [RFC5245] ), and others do not provide UNSAF functions (such as ICE [I-D.ietf-mmusic-rfc5245bis] ),
(such as SIP Outbound [RFC5626]), answers to these considerations and others do not (such as SIP Outbound [RFC5626]), answers to these
need to be addressed by the usages themselves. considerations need to be addressed by the usages themselves.
17. IANA Considerations 17. IANA Considerations
IANA has created three new registries: a "STUN Methods Registry", a
"STUN Attributes Registry", and a "STUN Error Codes Registry". IANA
has also changed the name of the assigned IANA port for STUN from
"nat-stun-port" to "stun".
17.1. STUN Methods Registry 17.1. STUN Methods Registry
A STUN method is a hex number in the range 0x000 - 0xFFF. The IANA is requested to update the reference from RFC 5389 to RFC-to-be
encoding of STUN method into a STUN message is described in for the following STUN methods:
Section 5.
The initial STUN methods are:
0x000: (Reserved) 0x000: (Reserved)
0x001: Binding 0x001: Binding
0x002: (Reserved; was SharedSecret) 0x002: (Reserved; was SharedSecret)
STUN methods in the range 0x000 - 0x7FF are assigned by IETF Review
[RFC5226]. STUN methods in the range 0x800 - 0xFFF are assigned by
Designated Expert [RFC5226]. The responsibility of the expert is to
verify that the selected codepoint(s) are not in use and that the
request is not for an abnormally large number of codepoints.
Technical review of the extension itself is outside the scope of the
designated expert responsibility.
17.2. STUN Attribute Registry 17.2. STUN Attribute Registry
A STUN Attribute type is a hex number in the range 0x0000 - 0xFFFF. 17.2.1. Updated Attributes
STUN attribute types in the range 0x0000 - 0x7FFF are considered
comprehension-required; STUN attribute types in the range 0x8000 -
0xFFFF are considered comprehension-optional. A STUN agent handles
unknown comprehension-required and comprehension-optional attributes
differently.
The initial STUN Attributes types are: IANA is requested to update the reference from RFC 5389 to RFC-to-be
for the following STUN methods:
Comprehension-required range (0x0000-0x7FFF): Comprehension-required range (0x0000-0x7FFF):
0x0000: (Reserved) 0x0000: (Reserved)
0x0001: MAPPED-ADDRESS 0x0001: MAPPED-ADDRESS
0x0002: (Reserved; was RESPONSE-ADDRESS) 0x0002: (Reserved; was RESPONSE-ADDRESS)
0x0003: (Reserved; was CHANGE-ADDRESS) 0x0003: (Reserved; was CHANGE-ADDRESS)
0x0004: (Reserved; was SOURCE-ADDRESS) 0x0004: (Reserved; was SOURCE-ADDRESS)
0x0005: (Reserved; was CHANGED-ADDRESS) 0x0005: (Reserved; was CHANGED-ADDRESS)
0x0006: USERNAME 0x0006: USERNAME
0x0007: (Reserved; was PASSWORD) 0x0007: (Reserved; was PASSWORD)
0x0008: MESSAGE-INTEGRITY 0x0008: MESSAGE-INTEGRITY
0x0009: ERROR-CODE 0x0009: ERROR-CODE
0x000A: UNKNOWN-ATTRIBUTES 0x000A: UNKNOWN-ATTRIBUTES
0x000B: (Reserved; was REFLECTED-FROM) 0x000B: (Reserved; was REFLECTED-FROM)
0x0014: REALM 0x0014: REALM
0x0015: NONCE 0x0015: NONCE
0x0020: XOR-MAPPED-ADDRESS 0x0020: XOR-MAPPED-ADDRESS
0xXXXX: PASSWORD-ALGORITHM
Comprehension-optional range (0x8000-0xFFFF) Comprehension-optional range (0x8000-0xFFFF)
0x8022: SOFTWARE 0x8022: SOFTWARE
0x8023: ALTERNATE-SERVER 0x8023: ALTERNATE-SERVER
0x8028: FINGERPRINT 0x8028: FINGERPRINT
0xXXXX: PASSSORD-ALGORITHMS
0xXXXX: ALTERNATE-DOMAIN
STUN Attribute types in the first half of the comprehension-required 17.2.2. New Attributes
range (0x0000 - 0x3FFF) and in the first half of the comprehension-
optional range (0x8000 - 0xBFFF) are assigned by IETF Review
[RFC5226]. STUN Attribute types in the second half of the
comprehension-required range (0x4000 - 0x7FFF) and in the second half
of the comprehension-optional range (0xC000 - 0xFFFF) are assigned by
Designated Expert [RFC5226]. The responsibility of the expert is to
verify that the selected codepoint(s) are not in use, and that the
request is not for an abnormally large number of codepoints.
Technical review of the extension itself is outside the scope of the
designated expert responsibility.
17.3. STUN Error Code Registry IANA is requested to add the following attribute to the STUN
Attribute Registry:
A STUN error code is a number in the range 0 - 699. STUN error codes Comprehension-required range (0x0000-0x7FFF):
are accompanied by a textual reason phrase in UTF-8 [RFC3629] that is 0xXXXX: MESSAGE-INTEGRITY2
intended only for human consumption and can be anything appropriate; 0xXXXX: PASSWORD-ALGORITHM
this document proposes only suggested values.
STUN error codes are consistent in codepoint assignments and Comprehension-optional range (0x8000-0xFFFF)
semantics with SIP [RFC3261] and HTTP [RFC2616]. 0xXXXX: PASSSORD-ALGORITHMS
0xXXXX: ALTERNATE-DOMAIN
The initial values in this registry are given in Section 14.7. 17.3. STUN Error Code Registry
New STUN error codes are assigned based on IETF Review [RFC5226]. IANA is requested to update the reference from RFC 5389 to RFC-to-be
The specification must carefully consider how clients that do not for the Error Codes given in Section 14.7.
understand this error code will process it before granting the
request. See the rules in Section 6.3.4.
17.4. Password Algorithm Registry 17.4. Password Algorithm Registry
IANA is requested to create a new registry for Password Algorithm.
A Password Algorithm is a hex number in the range 0x0000 - 0xFFFF. A Password Algorithm is a hex number in the range 0x0000 - 0xFFFF.
The initial Password Algorithms are: The initial Password Algorithms are:
0x0001: Salted SHA256 0x0001: Salted SHA256
0x0002: SHA256
Password Algorithms in the first half of the range (0x0000 - 0x7FFF) Password Algorithms in the first half of the range (0x0000 - 0x7FFF)
are assigned by IETF Review [RFC5226]. Password Algorithms in the are assigned by IETF Review [RFC5226]. Password Algorithms in the
second half of the range (0x8000 - 0xFFFF) are assigned by Designated second half of the range (0x8000 - 0xFFFF) are assigned by Designated
Expert [RFC5226]. Expert [RFC5226].
17.4.1. Password Algorithms 17.4.1. Password Algorithms
The initial list of password algorithms is taken from The default algorithm is "SHA256".
[I-D.veltri-sip-alt-auth].
17.4.1.1. Salted SHA256 17.4.1.1. SHA256
This password algorithms is taken from [I-D.ietf-httpauth-digest].
The key length is 32 bytes and the parameters value is empty.
key = SHA256(username ":" realm ":" OpaqueString(password))
17.4.1.2. Salted SHA256
This password algorithms is taken from [I-D.veltri-sip-alt-auth].
The key length is 32 bytes and the parameters contains the salt. The key length is 32 bytes and the parameters contains the salt.
key = SHA256(username ":" realm ":" SASLprep(password) ":" salt) key = SHA256(username ":" realm ":" OpaqueString(password) ":" salt)
17.5. STUN UDP and TCP Port Numbers 17.5. STUN UDP and TCP Port Numbers
IANA has previously assigned port 3478 for STUN. This port appears IANA is requested to update the reference from RFC 5389 to RFC-to-be
in the IANA registry under the moniker "nat-stun-port". In order to for the following ports:
align the DNS SRV procedures with the registered protocol service,
IANA is requested to change the name of protocol assigned to port
3478 from "nat-stun-port" to "stun", and the textual name from
"Simple Traversal of UDP Through NAT (STUN)" to "Session Traversal
Utilities for NAT", so that the IANA port registry would read:
stun 3478/tcp Session Traversal Utilities for NAT (STUN) port stun 3478/tcp Session Traversal Utilities for NAT (STUN) port
stun 3478/udp Session Traversal Utilities for NAT (STUN) port stun 3478/udp Session Traversal Utilities for NAT (STUN) port
stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port
In addition, IANA has assigned port number 5349 for the "stuns"
service, defined over TCP and UDP. The UDP port is not currently
defined; however, it is reserved for future use.
18. Changes since RFC 5389 18. Changes since RFC 5389
This specification obsoletes RFC 5389 [RFC5389]. This specification This specification obsoletes RFC 5389 [RFC5389]. This specification
differs from RFC 5389 in the following ways: differs from RFC 5389 in the following ways:
o o
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-avtcore-rfc5764-mux-fixes]
Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme
Updates for Secure Real-time Transport Protocol (SRTP)
Extension for Datagram Transport Layer Security (DTLS)",
draft-ietf-avtcore-rfc5764-mux-fixes-02 (work in
progress), March 2015.
[I-D.ietf-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", draft-ietf-precis-
saslprepbis-14 (work in progress), March 2015.
[I-D.ietf-tsvwg-sctp-dtls-encaps] [I-D.ietf-tsvwg-sctp-dtls-encaps]
Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets for RTCWEB", draft-ietf- Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
tsvwg-sctp-dtls-encaps-00 (work in progress), February dtls-encaps-09 (work in progress), January 2015.
2013.
[I-D.ietf-tsvwg-sctp-prpolicies] [I-D.ietf-tsvwg-sctp-prpolicies]
Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
"Additional Policies for the Partial Reliability Extension "Additional Policies for the Partial Reliability Extension
of the Stream Control Transmission Protocol", draft-ietf- of the Stream Control Transmission Protocol", draft-ietf-
tsvwg-sctp-prpolicies-05 (work in progress), November tsvwg-sctp-prpolicies-07 (work in progress), February
2014. 2015.
[ITU.V42.2002] [ITU.V42.2002]
International Telecommunications Union, "Error-correcting International Telecommunications Union, "Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous Procedures for DCEs Using Asynchronous-to-Synchronous
Conversion", ITU-T Recommendation V.42, 2002. Conversion", ITU-T Recommendation V.42, 2002.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981. 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
skipping to change at page 51, line 23 skipping to change at page 51, line 29
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP) Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004. Partial Reliability Extension", RFC 3758, May 2004.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005. 4033, March 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, June "Computing TCP's Retransmission Timer", RFC 6298, June
2011. 2011.
skipping to change at page 52, line 11 skipping to change at page 52, line 15
[RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- [RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit-
Huguenin, "URI Scheme for the Session Traversal Utilities Huguenin, "URI Scheme for the Session Traversal Utilities
for NAT (STUN) Protocol", RFC 7064, November 2013. for NAT (STUN) Protocol", RFC 7064, November 2013.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Session Traversal Layer Security (DTLS) as Transport for Session Traversal
Utilities for NAT (STUN)", RFC 7350, August 2014. Utilities for NAT (STUN)", RFC 7350, August 2014.
19.2. Informational References 19.2. Informational References
[I-D.ietf-httpauth-digest]
Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest
Access Authentication", draft-ietf-httpauth-digest-15
(work in progress), March 2015.
[I-D.ietf-mmusic-rfc5245bis]
Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-rfc5245bis-04 (work in progress), March
2015.
[I-D.ietf-tram-stun-origin] [I-D.ietf-tram-stun-origin]
Johnston, A., Uberti, J., Yoakum, J., and K. Singh, "An Johnston, A., Uberti, J., Yoakum, J., and K. Singh, "An
Origin Attribute for the STUN Protocol", draft-ietf-tram- Origin Attribute for the STUN Protocol", draft-ietf-tram-
stun-origin-05 (work in progress), February 2015. stun-origin-05 (work in progress), February 2015.
[I-D.ietf-uta-tls-bcp] [I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre, Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft- "Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-11 (work in progress), February 2015. ietf-uta-tls-bcp-11 (work in progress), February 2015.
skipping to change at page 53, line 9 skipping to change at page 53, line 26
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005. Key Management", BCP 107, RFC 4107, June 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
skipping to change at page 54, line 26 skipping to change at page 54, line 41
} }
Appendix B. Release notes Appendix B. Release notes
This section must be removed before publication as an RFC. This section must be removed before publication as an RFC.
B.1. Open Issues B.1. Open Issues
1. Integrate RFC 5769 (stun vectors) as examples 1. Integrate RFC 5769 (stun vectors) as examples
B.2. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- B.2. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf-
tram-stunbis-02
o SCTP prefix is now 0b00000101 instead of 0x11.
o Add SCTP at various places it was needed.
o Update the hash agility plan to take in account HMAC-SHA-256.
o Adds the bid down attack on message-integrity in the security
section.
B.3. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf-
tram-stunbis-01 tram-stunbis-01
o Prevent the server to allocate the same NONCE to clients with o Prevent the server to allocate the same NONCE to clients with
different IP address and/or different port. This prevent sharing different IP address and/or different port. This prevent sharing
the nonce between TURN allocations in TURN. the nonce between TURN allocations in TURN.
o Add reference to draft-ietf-uta-tls-bcp o Add reference to draft-ietf-uta-tls-bcp
o Add a new attribute ALTERNATE-DOMAIN to verify the certificate of o Add a new attribute ALTERNATE-DOMAIN to verify the certificate of
the ALTERNATE-SERVER after a 300 over (D)TLS. the ALTERNATE-SERVER after a 300 over (D)TLS.
o The RTP delay between transactions applies only to parallel o The RTP delay between transactions applies only to parallel
transactions, not to serial transactions. That prevents a 3RTT transactions, not to serial transactions. That prevents a 3RTT
delay between the first transaction and the second transaction delay between the first transaction and the second transaction
with long term authentication. with long term authentication.
o Add text saying ORIGIN can increase a request size beyond the MTU o Add text saying ORIGIN can increase a request size beyond the MTU
and so require an SCTPoUDP transport. and so require an SCTPoUDP transport.
o Add a new attribute ALTERNATE-DOMAIN to verify the certificate of
the ALTERNATE-SERVER after a 300 over (D)TLS.
o The RTP delay between transactions applies only to parallel
transactions, not to serial transactions. That prevents a 3RTT
delay between the first transaction and the second transaction
with long term authentication.
o Add text saying ORIGIN can increase a request size beyond the MTU
and so require an SCTPoUDP transport.
o Move the Acknowledgments and Contributor sections to the end of o Move the Acknowledgments and Contributor sections to the end of
the document, in accordance with RFC 7322 section 4. the document, in accordance with RFC 7322 section 4.
B.3. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- B.4. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf-
tram-stunbis-00 tram-stunbis-00
o Add negotiation mechanism for new password algorithms. o Add negotiation mechanism for new password algorithms.
o Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol. o Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol.
o Add support for SCTP to solve the fragmentation problem. o Add support for SCTP to solve the fragmentation problem.
o Merge RFC 7350: o Merge RFC 7350:
skipping to change at page 55, line 46 skipping to change at page 56, line 14
* DNS discovery is done from the URI. * DNS discovery is done from the URI.
* Reorganized the text about default ports. * Reorganized the text about default ports.
o Add more C snippets. o Add more C snippets.
o Make clear that the cached RTO is discarded only if there is no o Make clear that the cached RTO is discarded only if there is no
new transations for 10 minutes. new transations for 10 minutes.
B.4. Modifications between draft-salgueiro-tram-stunbis-02 and draft- B.5. Modifications between draft-salgueiro-tram-stunbis-02 and draft-
ietf-tram-stunbis-00 ietf-tram-stunbis-00
o Draft adopted as WG item. o Draft adopted as WG item.
B.5. Modifications between draft-salgueiro-tram-stunbis-02 and draft- B.6. Modifications between draft-salgueiro-tram-stunbis-02 and draft-
salgueiro-tram-stunbis-01 salgueiro-tram-stunbis-01
o Add definition of MESSAGE-INTEGRITY2. o Add definition of MESSAGE-INTEGRITY2.
o Update text and reference from RFC 2988 to RFC 6298. o Update text and reference from RFC 2988 to RFC 6298.
o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o s/The IAB has mandated/The IAB has suggested/ (Errata #3737).
o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972).
skipping to change at page 56, line 34 skipping to change at page 57, line 5
o Update text and reference from RFC 2988 to RFC 6298. o Update text and reference from RFC 2988 to RFC 6298.
o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o s/The IAB has mandated/The IAB has suggested/ (Errata #3737).
o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972).
o Fix section number and make clear that the original domain name is o Fix section number and make clear that the original domain name is
used for the server certificate verification. This is consistent used for the server certificate verification. This is consistent
with what RFC 5922 (section 4) is doing. (Errata #2010) with what RFC 5922 (section 4) is doing. (Errata #2010)
B.6. Modifications between draft-salgueiro-tram-stunbis-01 and draft- B.7. Modifications between draft-salgueiro-tram-stunbis-01 and draft-
salgueiro-tram-stunbis-00 salgueiro-tram-stunbis-00
o Restore the RFC 5389 text. o Restore the RFC 5389 text.
o Add list of open issues. o Add list of open issues.
Acknowledgements Acknowledgements
Thanks to Michael Tuexen, Tirumaleswar Reddy, Oleg Moskalenko, Simon Thanks to Michael Tuexen, Tirumaleswar Reddy, Oleg Moskalenko, Simon
Perreault, and Benjamin Schwartz for the comments, suggestions, and Perreault, Benjamin Schwartz, Rifaat Shekh-Yusef, and Alan Johnston
questions that helped improve this document. for the comments, suggestions, and questions that helped improve this
document.
The authors of RFC 5389 would like to thank Cedric Aoun, Pete The authors of RFC 5389 would like to thank Cedric Aoun, Pete
Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus
Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for
their comments, and Baruch Sterman and Alan Hawrylyshen for initial their comments, and Baruch Sterman and Alan Hawrylyshen for initial
implementations. Thanks for Leslie Daigle, Allison Mankin, Eric implementations. Thanks for Leslie Daigle, Allison Mankin, Eric
Rescorla, and Henning Schulzrinne for IESG and IAB input on this Rescorla, and Henning Schulzrinne for IESG and IAB input on this
work. work.
Contributors Contributors
 End of changes. 71 change blocks. 
194 lines changed or deleted 198 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/