draft-ietf-tram-stunbis-09.txt   draft-ietf-tram-stunbis-10.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: June 17, 2017 D. Wing Expires: August 20, 2017 D. Wing
Cisco Cisco
R. Mahy R. Mahy
Plantronics Plantronics
P. Matthews P. Matthews
Avaya Avaya
December 14, 2016 February 16, 2017
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-09 draft-ietf-tram-stunbis-10
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 June 17, 2017. This Internet-Draft will expire on August 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 11 skipping to change at page 4, line 11
17.5.1. Password Algorithms . . . . . . . . . . . . . . . . 52 17.5.1. Password Algorithms . . . . . . . . . . . . . . . . 52
17.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 52 17.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 52
17.5.1.2. SHA256 . . . . . . . . . . . . . . . . . . . . . 52 17.5.1.2. SHA256 . . . . . . . . . . . . . . . . . . . . . 52
17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 52 17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 52
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 52 18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 52
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
19.1. Normative References . . . . . . . . . . . . . . . . . . 53 19.1. Normative References . . . . . . . . . . . . . . . . . . 53
19.2. Informative References . . . . . . . . . . . . . . . . . 55 19.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. C Snippet to Determine STUN Message Types . . . . . 57 Appendix A. C Snippet to Determine STUN Message Types . . . . . 57
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 57 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 58
B.1. Sample Request with Long-Term Authentication with B.1. Sample Request with Long-Term Authentication with
MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 58 MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 58
Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 60 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 60
C.1. Modifications between draft-ietf-tram-stunbis-09 and C.1. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 60
C.2. Modifications between draft-ietf-tram-stunbis-08 and C.2. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 60
C.3. Modifications between draft-ietf-tram-stunbis-07 and C.3. Modifications between draft-ietf-tram-stunbis-08 and
draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 61
C.4. Modifications between draft-ietf-tram-stunbis-06 and C.4. Modifications between draft-ietf-tram-stunbis-07 and
draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 61
C.5. Modifications between draft-ietf-tram-stunbis-06 and
draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 61
C.5. Modifications between draft-ietf-tram-stunbis-05 and C.6. Modifications between draft-ietf-tram-stunbis-05 and
draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 62
C.6. Modifications between draft-ietf-tram-stunbis-04 and C.7. Modifications between draft-ietf-tram-stunbis-04 and
draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 62
C.7. Modifications between draft-ietf-tram-stunbis-03 and C.8. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 62
C.8. Modifications between draft-ietf-tram-stunbis-02 and C.9. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 62
C.9. Modifications between draft-ietf-tram-stunbis-01 and C.10. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 62
C.10. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 63
C.11. Modifications between draft-salgueiro-tram-stunbis-02 and C.11. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 64
C.12. Modifications between draft-salgueiro-tram-stunbis-01 and C.12. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 64
C.13. Modifications between draft-salgueiro-tram-stunbis-01 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 64 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 64
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 64 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 64
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65
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 [I-D.ietf-ice-rfc5245bis], connectivity checks between two endpoints [I-D.ietf-ice-rfc5245bis],
skipping to change at page 8, line 26 skipping to change at page 8, line 26
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 [I-D.ietf-ice-rfc5245bis] the two endpoints use out-of- the ICE usage [I-D.ietf-ice-rfc5245bis] the two endpoints use out-of-
band signaling to exchange a username and password. These are used band signaling to exchange a username and password. These are used
to integrity protect and authenticate the request and response. to integrity protect and authenticate the request and response.
There is no 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 [RFC2119] and
[RFC2119] and indicate requirement levels for compliant STUN indicate requirement levels for compliant STUN implementations.
implementations.
4. Definitions 4. Definitions
STUN Agent: A STUN agent is an entity that implements the STUN STUN Agent: A STUN agent is an entity that implements the STUN
protocol. The entity can be either a STUN client or a STUN protocol. The entity can be either a STUN client or a STUN
server. server.
STUN Client: A STUN client is an entity that sends STUN requests and STUN Client: A STUN client is an entity that sends STUN requests and
receives STUN responses. A STUN client can also send indications. receives STUN responses. A STUN client can also send indications.
In this specification, the terms STUN client and client are In this specification, the terms STUN client and client are
skipping to change at page 10, line 10 skipping to change at page 10, line 10
RTO: Retransmission TimeOut, which defines the initial period of RTO: Retransmission TimeOut, which defines the initial period of
time between transmission of a request and the first retransmit of time between transmission of a request and the first retransmit of
that request. that request.
5. STUN Message Structure 5. STUN Message Structure
STUN messages are encoded in binary using network-oriented format STUN messages are encoded in binary using network-oriented format
(most significant byte or octet first, also commonly known as big- (most significant byte or octet first, also commonly known as big-
endian). The transmission order is described in detail in Appendix B endian). The transmission order is described in detail in Appendix B
of RFC 791 [RFC0791]. Unless otherwise noted, numeric constants are of [RFC0791]. Unless otherwise noted, numeric constants are in
in decimal (base 10). decimal (base 10).
All STUN messages MUST start with a 20-byte header followed by zero All STUN messages MUST start with a 20-byte header followed by zero
or more Attributes. The STUN header contains a STUN message type, or more Attributes. The STUN header contains a STUN message type,
magic cookie, transaction ID, and message length. magic cookie, transaction ID, and message length.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0| STUN Message Type | Message Length | |0 0| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 36 skipping to change at page 11, line 36
method=0b000000000001 (Binding) and is encoded into the first 16 bits method=0b000000000001 (Binding) and is encoded into the first 16 bits
as 0x0001. A Binding response has class=0b10 (success response) and as 0x0001. A Binding response has class=0b10 (success response) and
method=0b000000000001, and is encoded into the first 16 bits as method=0b000000000001, and is encoded into the first 16 bits as
0x0101. 0x0101.
Note: This unfortunate encoding is due to assignment of values in Note: This unfortunate encoding is due to assignment of values in
[RFC3489] that did not consider encoding Indications, Success, and [RFC3489] that did not consider encoding Indications, Success, and
Errors using bit fields. Errors using bit fields.
The magic cookie field MUST contain the fixed value 0x2112A442 in The magic cookie field MUST contain the fixed value 0x2112A442 in
network byte order. In RFC 3489 [RFC3489], this field was part of network byte order. In [RFC3489], this field was part of the
the transaction ID; placing the magic cookie in this location allows transaction ID; placing the magic cookie in this location allows a
a server to detect if the client will understand certain attributes server to detect if the client will understand certain attributes
that were added in this revised specification. In addition, it aids that were added in this revised specification. In addition, it aids
in distinguishing STUN packets from packets of other protocols when in distinguishing STUN packets from packets of other protocols when
STUN is multiplexed with those other protocols on the same port. STUN is multiplexed with those other protocols on the same port.
The transaction ID is a 96-bit identifier, used to uniquely identify The transaction ID is a 96-bit identifier, used to uniquely identify
STUN transactions. For request/response transactions, the STUN transactions. For request/response transactions, the
transaction ID is chosen by the STUN client for the request and transaction ID is chosen by the STUN client for the request and
echoed by the server in the response. For indications, it is chosen echoed by the server in the response. For indications, it is chosen
by the agent sending the indication. It primarily serves to by the agent sending the indication. It primarily serves to
correlate requests with responses, though it also plays a small role correlate requests with responses, though it also plays a small role
skipping to change at page 14, line 17 skipping to change at page 14, line 17
When running STUN over UDP or STUN over DTLS-over-UDP [RFC7350], it When running STUN over UDP or STUN over DTLS-over-UDP [RFC7350], it
is possible that the STUN message might be dropped by the network. is possible that the STUN message might be dropped by the network.
Reliability of STUN request/response transactions is accomplished Reliability of STUN request/response transactions is accomplished
through retransmissions of the request message by the client through retransmissions of the request message by the client
application itself. STUN indications are not retransmitted; thus, application itself. STUN indications are not retransmitted; thus,
indication transactions over UDP or DTLS-over-UDP are not reliable. indication transactions over UDP or DTLS-over-UDP are not reliable.
A client SHOULD retransmit a STUN request message starting with an A client SHOULD retransmit a STUN request message starting with an
interval of RTO ("Retransmission TimeOut"), doubling after each interval of RTO ("Retransmission TimeOut"), doubling after each
retransmission. The RTO is an estimate of the round-trip time (RTT), retransmission. The RTO is an estimate of the round-trip time (RTT),
and is computed as described in RFC 6298 [RFC6298], with two and is computed as described in [RFC6298], with two exceptions.
exceptions. First, the initial value for RTO SHOULD be greater than First, the initial value for RTO SHOULD be greater than 500 ms. The
500 ms. The exception cases for this "SHOULD" are when other exception cases for this "SHOULD" are when other mechanisms are used
mechanisms are used to derive congestion thresholds (such as the ones to derive congestion thresholds (such as the ones defined in ICE for
defined in ICE for fixed rate streams), or when STUN is used in non- fixed rate streams), or when STUN is used in non-Internet
Internet environments with known network capacities. In fixed-line environments with known network capacities. In fixed-line access
access links, a value of 500 ms is RECOMMENDED. Second, the value of links, a value of 500 ms is RECOMMENDED. Second, the value of RTO
RTO SHOULD NOT be rounded up to the nearest second. Rather, a 1 ms SHOULD NOT be rounded up to the nearest second. Rather, a 1 ms
accuracy SHOULD be maintained. As with TCP, the usage of Karn's accuracy SHOULD be maintained. As with TCP, the usage of Karn's
algorithm is RECOMMENDED [KARN87]. When applied to STUN, it means algorithm is RECOMMENDED [KARN87]. When applied to STUN, it means
that RTT estimates SHOULD NOT be computed from STUN transactions that that RTT estimates SHOULD NOT be computed from STUN transactions that
result in the retransmission of a request. result in the retransmission of a request.
The value for RTO SHOULD be cached by a client after the completion The value for RTO SHOULD be cached by a client after the completion
of the transaction, and used as the starting value for RTO for the of the transaction, and used as the starting value for RTO for the
next transaction to the same server (based on equality of IP next transaction to the same server (based on equality of IP
address). The value SHOULD be considered stale and discarded after address). The value SHOULD be considered stale and discarded after
10 minutes without any transactions to the same server. 10 minutes without any transactions to the same server.
skipping to change at page 16, line 41 skipping to change at page 16, line 41
cipher suites. Cipher suites with known weaknesses, such as those cipher suites. Cipher suites with known weaknesses, such as those
based on (single) DES and RC4, MUST NOT be used. Implementations based on (single) DES and RC4, MUST NOT be used. Implementations
MUST disable TLS-level compression. MUST disable TLS-level compression.
When it receives the TLS Certificate message, the client SHOULD When it receives the TLS Certificate message, the client SHOULD
verify the certificate and inspect the site identified by the verify the certificate and inspect the site identified by the
certificate. If the certificate is invalid or revoked, or if it does certificate. If the certificate is invalid or revoked, or if it does
not identify the appropriate party, the client MUST NOT send the STUN not identify the appropriate party, the client MUST NOT send the STUN
message or otherwise proceed with the STUN transaction. The client message or otherwise proceed with the STUN transaction. The client
MUST verify the identity of the server. To do that, it follows the MUST verify the identity of the server. To do that, it follows the
identification procedures defined in Section 3.1 of RFC 2818 identification procedures defined in [RFC6125]. Alternatively, a
[RFC2818]. Alternatively, a client MAY be configured with a set of client MAY be configured with a set of domains or IP addresses that
domains or IP addresses that are trusted; if a certificate is are trusted; if a certificate is received that identifies one of
received that identifies one of those domains or IP addresses, the those domains or IP addresses, the client considers the identity of
client considers the identity of the server to be verified. the server to be verified.
When STUN is run multiplexed with other protocols over a TLS-over-TCP When STUN is run multiplexed with other protocols over a TLS-over-TCP
connection or a DTLS-over-UDP association, the mandatory ciphersuites connection or a DTLS-over-UDP association, the mandatory ciphersuites
and TLS handling procedures operate as defined by those protocols. and TLS handling procedures operate as defined by those protocols.
6.3. Receiving a STUN Message 6.3. Receiving a STUN Message
This section specifies the processing of a STUN message. The This section specifies the processing of a STUN message. The
processing specified here is for STUN messages as defined in this processing specified here is for STUN messages as defined in this
specification; additional rules for backwards compatibility are specification; additional rules for backwards compatibility are
skipping to change at page 28, line 7 skipping to change at page 28, line 7
security feature, it is implied that the "Password algorithms" bit, security feature, it is implied that the "Password algorithms" bit,
as defined in Section 17.1, is set to 1 in the "nonce cookie". as defined in Section 17.1, is set to 1 in the "nonce cookie".
9.2.2. HMAC Key 9.2.2. 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 ":" OpaqueString(password)) key = MD5(username ":" realm ":" OpaqueString(password))
Where MD5 is defined in RFC 1321 [RFC1321] and the OpaqueString Where MD5 is defined in [RFC1321] and the OpaqueString profile is
profile is defined in [RFC7613]. defined in [RFC7613].
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 OpaqueString has already been applied); (2) attribute (in which case OpaqueString has already been applied); (2)
a 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 OpaqueString. For example, nulls removed and after processing using OpaqueString. For example,
if the username was 'user', the realm was 'realm', and the password if the username was 'user', the realm was 'realm', and the password
was 'pass', then the 16-byte HMAC key would be the result of was 'pass', then the 16-byte HMAC key would be the result of
skipping to change at page 29, line 39 skipping to change at page 29, line 39
response with an error code of 401 (Unauthenticated). This response with an error code of 401 (Unauthenticated). This
response MUST include a REALM value. It is RECOMMENDED that the response MUST include a REALM value. It is RECOMMENDED that the
REALM value be the domain name of the provider of the STUN server. REALM value be the domain name of the provider of the STUN server.
The response MUST include a NONCE, selected by the server. The The response MUST include a NONCE, selected by the server. The
server MUST ensure that the same NONCE cannot be selected for server MUST ensure that the same NONCE cannot be selected for
clients that use different IP addresses and/or different ports. clients that use different IP addresses and/or different ports.
The server MAY support alternate password algorithms, in which The server MAY support alternate password algorithms, in which
case it can list them in preferential order in a PASSWORD- case it can list them in preferential order in a PASSWORD-
ALGORITHMS attribute. If the server adds a PASSWORD-ALGORITHMS ALGORITHMS attribute. If the server adds a PASSWORD-ALGORITHMS
attribute it MUST prepend the NONCE attribute value with the attribute it MUST prepend the NONCE attribute value with the
"nonce cookie". The server MAY support anonymous username, in "nonce cookie" that has the STUN Security Feature "Password
which case it can prepend the NONCE attribute value with the algorithms" bit set to 1. The server MAY support anonymous
"nonce cookie" that has the STUN Security Feature "Anonymous username, in which case it can prepend the NONCE attribute value
username" bit set to 1. The response SHOULD NOT contain a with the "nonce cookie" that has the STUN Security Feature
USERNAME, USERHASH, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 "Anonymous username" bit set to 1. The response SHOULD NOT
attribute. contain a USERNAME, USERHASH, MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY-SHA256 attribute.
Note: Sharing a NONCE is no longer permitted, so trying to share one Note: Sharing a NONCE is no longer permitted, so trying to share one
will result in a wasted transaction. will result in a wasted transaction.
o If the message contains a MESSAGE-INTEGRITY or a MESSAGE- o If the message contains a MESSAGE-INTEGRITY or a MESSAGE-
INTEGRITY-SHA256 attribute, but is missing either the USERNAME or INTEGRITY-SHA256 attribute, but is missing either the USERNAME or
USERHASH, REALM, or NONCE attribute, the server MUST generate an USERHASH, REALM, or NONCE attribute, the server MUST generate an
error response with an error code of 400 (Bad Request). This error response with an error code of 400 (Bad Request). This
response SHOULD NOT include a USERNAME, USERHASH, NONCE, or REALM. response SHOULD NOT include a USERNAME, USERHASH, NONCE, or REALM.
The response cannot contain a MESSAGE-INTEGRITY or MESSAGE- The response cannot contain a MESSAGE-INTEGRITY or MESSAGE-
skipping to change at page 34, line 8 skipping to change at page 34, line 8
A client using this extension handles a 300 (Try Alternate) error A client using this extension handles a 300 (Try Alternate) error
code as follows. The client looks for an ALTERNATE-SERVER attribute code as follows. The client looks for an ALTERNATE-SERVER attribute
in the error response. If one is found, then the client considers in the error response. If one is found, then the client considers
the current transaction as failed, and reattempts the request with the current transaction as failed, and reattempts the request with
the server specified in the attribute, using the same transport the server specified in the attribute, using the same transport
protocol used for the previous request. That request, if protocol used for the previous request. That request, if
authenticated, MUST utilize the same credentials that the client authenticated, MUST utilize the same credentials that the client
would have used in the request to the server that performed the would have used in the request to the server that performed the
redirection. If the transport protocol uses TLS or DTLS, then the redirection. If the transport protocol uses TLS or DTLS, then the
client looks for an ALTERNATE-DOMAIN attribute. If the attribute is client looks for an ALTERNATE-DOMAIN attribute. If the attribute is
found, the domain MUST be used to validate the cartificate. If the found, the domain MUST be used to validate the certificate using the
attribute is not found, the same domain that was used for the recommendations in [RFC6125]. If the attribute is not found, the
original request MUST be used to validate the certificate. If the same domain that was used for the original request MUST be used to
client has been redirected to a server on which it has already tried validate the certificate. If the client has been redirected to a
this request within the last five minutes, it MUST ignore the server on which it has already tried this request within the last
redirection and consider the transaction to have failed. This five minutes, it MUST ignore the redirection and consider the
prevents infinite ping-ponging between servers in case of redirection transaction to have failed. This prevents infinite ping-ponging
loops. between servers in case of redirection loops.
11. Backwards Compatibility with RFC 3489 11. Backwards Compatibility with RFC 3489
In addition to the backward compatibility already described in In addition to the backward compatibility already described in
Section 12 of [RFC5389], DTLS MUST NOT be used with RFC 3489 STUN Section 12 of [RFC5389], DTLS MUST NOT be used with STUN [RFC3489]
[RFC3489] (also referred to as "classic STUN"). Any STUN request or (also referred to as "classic STUN"). Any STUN request or indication
indication without the magic cookie (see Section 6 of [RFC5389]) over without the magic cookie (see Section 6 of [RFC5389]) over DTLS MUST
DTLS MUST always result in an error. always result in an error.
12. Basic Server Behavior 12. Basic Server Behavior
This section defines the behavior of a basic, stand-alone STUN This section defines the behavior of a basic, stand-alone STUN
server. A basic STUN server provides clients with server reflexive server. A basic STUN server provides clients with server reflexive
transport addresses by receiving and replying to STUN Binding transport addresses by receiving and replying to STUN Binding
requests. requests.
The STUN server MUST support the Binding method. It SHOULD NOT The STUN server MUST support the Binding method. It SHOULD NOT
utilize the short-term or long-term credential mechanism. This is utilize the short-term or long-term credential mechanism. This is
skipping to change at page 35, line 44 skipping to change at page 35, line 44
required. required.
o How a STUN client determines the IP address and port of the STUN o How a STUN client determines the IP address and port of the STUN
server. server.
o Whether backwards compatibility to RFC 3489 is required. o Whether backwards compatibility to RFC 3489 is required.
o What optional attributes defined here (such as FINGERPRINT and o What optional attributes defined here (such as FINGERPRINT and
ALTERNATE-SERVER) or in other extensions are required. ALTERNATE-SERVER) or in other extensions are required.
o If MESSAGE-INTEGRITY-256 truncation is permitted, and the limits
permitted for truncation.
In addition, any STUN usage must consider the security implications In addition, any STUN usage must consider the security implications
of using STUN in that usage. A number of attacks against STUN are of using STUN in that usage. A number of attacks against STUN are
known (see the Security Considerations section in this document), and known (see the Security Considerations section in this document), and
any usage must consider how these attacks can be thwarted or any usage must consider how these attacks can be thwarted or
mitigated. mitigated.
Finally, a usage must consider whether its usage of STUN is an Finally, a usage must consider whether its usage of STUN is an
example of the Unilateral Self-Address Fixing approach to NAT example of the Unilateral Self-Address Fixing approach to NAT
traversal, and if so, address the questions raised in RFC 3424 traversal, and if so, address the questions raised in RFC 3424
[RFC3424]. [RFC3424].
skipping to change at page 37, line 38 skipping to change at page 37, line 41
The address family can take on the following values: The address family can take on the following values:
0x01:IPv4 0x01:IPv4
0x02:IPv6 0x02:IPv6
The first 8 bits of the MAPPED-ADDRESS MUST be set to 0 and MUST be The first 8 bits of the MAPPED-ADDRESS MUST be set to 0 and MUST be
ignored by receivers. These bits are present for aligning parameters ignored by receivers. These bits are present for aligning parameters
on natural 32-bit boundaries. on natural 32-bit boundaries.
This attribute is used only by servers for achieving backwards This attribute is used only by servers for achieving backwards
compatibility with RFC 3489 [RFC3489] clients. compatibility with [RFC3489] clients.
14.2. XOR-MAPPED-ADDRESS 14.2. XOR-MAPPED-ADDRESS
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
skipping to change at page 39, line 28 skipping to change at page 39, line 28
The following is the operation that the client will perform to hash The following is the operation that the client will perform to hash
the username: the username:
userhash = SHA256(username ":" realm) userhash = SHA256(username ":" realm)
14.5. MESSAGE-INTEGRITY 14.5. 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
at most 20 bytes. The HMAC MUST NOT be truncated below a minimum at 20 bytes.
size of 4. If truncation is employed then the HMAC size MUST be a
multiple of XX. Truncation MUST be done from the most significant
byte to the least significant byte. STUN Usages can define their own
truncation limits, as long as they adhere to the guidelines
specificed above.
Note: We don't know what we're doing, we need a cryptographer to
weigh in on the above text.
The text used as input to HMAC is the STUN message, including the The text used as input to HMAC is the STUN message, including the
header, up to and including the attribute preceding the MESSAGE- header, up to and including the attribute preceding the MESSAGE-
INTEGRITY attribute. With the exception of the MESSAGE-INTEGRITY- INTEGRITY attribute. With the exception of the MESSAGE-INTEGRITY-
SHA256 and FINGERPRINT attributes, which appear after MESSAGE- SHA256 and FINGERPRINT attributes, which appear after MESSAGE-
INTEGRITY, agents MUST ignore all other attributes that follow INTEGRITY, agents MUST ignore all other attributes that follow
MESSAGE-INTEGRITY. MESSAGE-INTEGRITY.
The key for the HMAC depends on which credential mechanism is in use. The key for the HMAC depends on which credential mechanism is in use.
Section 9.1.1 defines the key for the short-term credential mechanism Section 9.1.1 defines the key for the short-term credential mechanism
skipping to change at page 40, line 24 skipping to change at page 40, line 15
the end of the MESSAGE-INTEGRITY attribute prior to calculating the the end of the MESSAGE-INTEGRITY attribute prior to calculating the
HMAC. Such adjustment is necessary when attributes, such as HMAC. Such adjustment is necessary when attributes, such as
FINGERPRINT, appear after MESSAGE-INTEGRITY. FINGERPRINT, appear after MESSAGE-INTEGRITY.
14.6. MESSAGE-INTEGRITY-SHA256 14.6. MESSAGE-INTEGRITY-SHA256
The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA-256 The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA-256
[RFC2104] of the STUN message. The MESSAGE-INTEGRITY-SHA256 [RFC2104] of the STUN message. The MESSAGE-INTEGRITY-SHA256
attribute can be present in any STUN message type. Since it uses the attribute can be present in any STUN message type. Since it uses the
SHA1 hash, the HMAC will be at most 32 bytes. The HMAC MUST NOT be SHA1 hash, the HMAC will be at most 32 bytes. The HMAC MUST NOT be
truncated below a minimum size of 4. If truncation is employed then truncated below a minimum size of 16 bytes. If truncation is
the HMAC size MUST be a multiple of XX. Truncation MUST be done from employed then the HMAC size MUST be a multiple of 4. Truncation MUST
the most significant byte to the least significant byte. STUN Usages be done by stripping off the final bytes. STUN Usages can define
can define their own truncation limits, as long as they adhere to the their own truncation limits, as long as they adhere to the guidelines
guidelines specificed above. specificed above. STUN Usages that do not define truncation limits
MUST NOT use truncation at all.
Note: We don't know what we're doing, we need a cryptographer to
weigh in on the above text.
The text used as input to HMAC is the STUN message, including the The text used as input to HMAC is the STUN message, including the
header, up to and including the attribute preceding the MESSAGE- header, up to and including the attribute preceding the MESSAGE-
INTEGRITY-SHA256 attribute. With the exception of the FINGERPRINT INTEGRITY-SHA256 attribute. With the exception of the FINGERPRINT
attribute, which appears after MESSAGE-INTEGRITY-SHA256, agents MUST attribute, which appears after MESSAGE-INTEGRITY-SHA256, agents MUST
ignore all other attributes that follow MESSAGE-INTEGRITY-SHA256. ignore all other attributes that follow MESSAGE-INTEGRITY-SHA256.
The key for the HMAC depends on which credential mechanism is in use. The key for the HMAC depends on which credential mechanism is in use.
Section 9.1.1 defines the key for the short-term credential mechanism Section 9.1.1 defines the key for the short-term credential mechanism
and Section 9.2.2 defines the key for the long-term credential and Section 9.2.2 defines the key for the long-term credential
skipping to change at page 41, line 21 skipping to change at page 41, line 14
14.7. FINGERPRINT 14.7. FINGERPRINT
The FINGERPRINT attribute MAY be present in all STUN messages. The The FINGERPRINT attribute MAY be present in all STUN messages. The
value of the attribute is computed as the CRC-32 of the STUN message value of the attribute is computed as the CRC-32 of the STUN message
up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with
the 32-bit value 0x5354554e (the XOR helps in cases where an the 32-bit value 0x5354554e (the XOR helps in cases where an
application packet is also using CRC-32 in it). The 32-bit CRC is application packet is also using CRC-32 in it). The 32-bit CRC is
the one defined in ITU V.42 [ITU.V42.2002], which has a generator the one defined in ITU V.42 [ITU.V42.2002], which has a generator
polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1.
See the sample code for the CRC-32 in Section 8 of [RFC1952].
When present, the FINGERPRINT attribute MUST be the last attribute in When present, the FINGERPRINT attribute MUST be the last attribute in
the message, and thus will appear after MESSAGE-INTEGRITY. the message, and thus will appear after MESSAGE-INTEGRITY.
The FINGERPRINT attribute can aid in distinguishing STUN packets from The FINGERPRINT attribute can aid in distinguishing STUN packets from
packets of other protocols. See Section 7. packets of other protocols. See Section 7.
As with MESSAGE-INTEGRITY, the CRC used in the FINGERPRINT attribute As with MESSAGE-INTEGRITY, the CRC used in the FINGERPRINT attribute
covers the length field from the STUN message header. Therefore, covers the length field from the STUN message header. Therefore,
this value must be correct and include the CRC attribute as part of this value must be correct and include the CRC attribute as part of
the message length, prior to computation of the CRC. When using the the message length, prior to computation of the CRC. When using the
skipping to change at page 43, line 18 skipping to change at page 43, line 18
438 Stale Nonce: The NONCE used by the client was no longer valid. 438 Stale Nonce: The NONCE used by the client was no longer valid.
The client should retry, using the NONCE provided in the response. The client should retry, using the NONCE provided in the response.
500 Server Error: The server has suffered a temporary error. The 500 Server Error: The server has suffered a temporary error. The
client should try again. client should try again.
14.9. REALM 14.9. 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 [RFC3261] but without the double quotes and their surrounding
surrounding whitespace. That is, it is an unquoted realm-value (and whitespace. That is, it is an unquoted realm-value (and is therefore
is therefore a sequence of qdtext or quoted-pair). It MUST be a a sequence of qdtext or quoted-pair). It MUST be a UTF-8 [RFC3629]
UTF-8 [RFC3629] encoded sequence of less than 128 characters (which encoded sequence of less than 128 characters (which can be as long as
can be as long as 763 bytes), and MUST have been processed using the 763 bytes), and MUST have been processed using the OpaqueString
OpaqueString profile [RFC7613]. profile [RFC7613].
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.10. NONCE 14.10. 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
RFC 3261 [RFC3261]. Note that this means that the NONCE attribute RFC 3261 [RFC3261]. Note that this means that the NONCE attribute
will not contain actual quote characters. See RFC 2617 [RFC2617], will not contain actual quote characters. See [RFC2617],
Section 4.3, for guidance on selection of nonce values in a server. Section 4.3, for guidance on selection of nonce values in a server.
It MUST be less than 128 characters (which can be as long as 763 It MUST be less than 128 characters (which can be as long as 763
bytes). bytes).
14.11. PASSWORD-ALGORITHMS 14.11. PASSWORD-ALGORITHMS
The PASSWORD-ALGORITHMS attribute may be present in requests and The PASSWORD-ALGORITHMS attribute may be present in requests and
responses. It contains the list of algorithms that the server can responses. It contains the list of algorithms that the server can
use to derive the long-term password. use to derive the long-term password.
skipping to change at page 49, line 35 skipping to change at page 49, line 35
After a transition period, a new document updating this document will After a transition period, a new document updating this document will
remove the usage of HMAC-SHA-1 for computation of the message- remove the usage of HMAC-SHA-1 for computation of the message-
integrity. integrity.
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 STUN can be used to perform this function using a Binding request/
Binding request/response transaction if one agent is behind a NAT and response transaction if one agent is behind a NAT and the other is on
the other is on the public side of the NAT. 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 [I-D.ietf-ice-rfc5245bis] ), and provide UNSAF functions (such as ICE [I-D.ietf-ice-rfc5245bis] ), and
others do not (such as SIP Outbound [RFC5626]), answers to these others do not (such as SIP Outbound [RFC5626]), answers to these
considerations need to be addressed by the usages themselves. considerations need to be addressed by the usages themselves.
17. IANA Considerations 17. IANA Considerations
17.1. STUN Security Features Registry 17.1. STUN Security Features Registry
A STUN Security Feature set is a 24 bit value. A STUN Security Feature set is a 24 bit value.
IANA is requested to create a new registry containing the STUN IANA is requested to create a new registry containing the STUN
Security Features that are protected by the bid down attack Security Features that are protected by the bid down attack
prevention mechanism described in section Section 9.2.1. prevention mechanism described in section Section 9.2.1.
The initial STUN Security Features are: The initial STUN Security Features are:
0x000000: Reserved
0x000001: Password algorithms 0x000001: Password algorithms
0x000002: Username anonymity 0x000002: Username anonymity
New Security Features are assigned by a Standard Action [RFC5226]. New Security Features are assigned by a Standard Action [RFC5226].
17.2. STUN Methods Registry 17.2. STUN Methods Registry
IANA is requested to update the reference from RFC 5389 to RFC-to-be IANA is requested to update the reference from RFC 5389 to RFC-to-be
for the following STUN methods: for the following STUN methods:
skipping to change at page 52, line 45 skipping to change at page 52, line 45
IANA is requested to update the reference from RFC 5389 to RFC-to-be IANA is requested to update the reference from RFC 5389 to RFC-to-be
for the following ports: for the following ports:
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 stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port
18. Changes since RFC 5389 18. Changes since RFC 5389
This specification obsoletes RFC 5389 [RFC5389]. This specification This specification obsoletes [RFC5389]. This specification differs
differs from RFC 5389 in the following ways: from RFC 5389 in the following ways:
o Added support for DTLS-over-UDP (RFC 6347). o Added support for DTLS-over-UDP (RFC 6347).
o Made clear that the RTO is considered stale if there is no o Made clear that the RTO is considered stale if there is no
transactions with the server. transactions with the server.
o Aligned the RTO calculation with RFC 6298. o Aligned the RTO calculation with RFC 6298.
o Updated the cipher suites for TLS. o Updated the cipher suites for TLS.
skipping to change at page 53, line 29 skipping to change at page 53, line 29
o Added protocol and registry for preventing biddown attacks. o Added protocol and registry for preventing biddown attacks.
o Sharing a NONCE is no longer permitted. o Sharing a NONCE is no longer permitted.
o Added the possibility of using a domain name in the alternate o Added the possibility of using a domain name in the alternate
server mechanism. server mechanism.
o Added more C snippets. o Added more C snippets.
o Added test vector.
19. References 19. References
19.1. Normative References 19.1. Normative References
[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, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
skipping to change at page 54, line 30 skipping to change at page 54, line 30
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, DOI 10.17487/RFC2617, June 1999, RFC 2617, DOI 10.17487/RFC2617, June 1999,
<http://www.rfc-editor.org/info/rfc2617>. <http://www.rfc-editor.org/info/rfc2617>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>. <http://www.rfc-editor.org/info/rfc2782>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[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, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <http://www.rfc-editor.org/info/rfc3629>.
[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, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>.
[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, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, DOI 10.17487/RFC6298, June 2011,
<http://www.rfc-editor.org/info/rfc6298>. <http://www.rfc-editor.org/info/rfc6298>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- [RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit-
skipping to change at page 55, line 33 skipping to change at page 55, line 37
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A. and J. Rosenberg, "Interactive Connectivity Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal", draft-ietf-ice-rfc5245bis-01 Translator (NAT) Traversal", draft-ietf-ice-rfc5245bis-01
(work in progress), December 2015. (work in progress), December 2015.
[KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time [KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", SIGCOMM 1987, Estimates in Reliable Transport Protocols", SIGCOMM 1987,
August 1987. August 1987.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, DOI 10.17487/RFC1952, May 1996,
<http://www.rfc-editor.org/info/rfc1952>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>. <http://www.rfc-editor.org/info/rfc2616>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
skipping to change at page 57, line 21 skipping to change at page 57, line 26
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616, Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015, DOI 10.17487/RFC7616, September 2015,
<http://www.rfc-editor.org/info/rfc7616>. <http://www.rfc-editor.org/info/rfc7616>.
Appendix A. C Snippet to Determine STUN Message Types Appendix A. C Snippet to Determine STUN Message Types
Given a 16-bit STUN message type value in host byte order in msg_type Given a 16-bit STUN message type value in host byte order in msg_type
parameter, below are C macros to determine the STUN message types: parameter, below are C macros to determine the STUN message types:
<CODE BEGINS>
#define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000) #define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000)
#define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010) #define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010)
#define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100) #define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100)
#define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110) #define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110)
<CODE ENDS>
A function to convert method and class into a message type: A function to convert method and class into a message type:
<CODE BEGINS>
int type(int method, int cls) { int type(int method, int cls) {
return (method & 0x0F80) << 9 | (method & 0x0070) << 5 return (method & 0x0F80) << 9 | (method & 0x0070) << 5
| (method & 0x000F) | (cls & 0x0002) << 8 | (method & 0x000F) | (cls & 0x0002) << 8
| (cls & 0x0001) << 4; | (cls & 0x0001) << 4;
} }
<CODE ENDS>
A function to extract the method from the message type: A function to extract the method from the message type:
<CODE BEGINS>
int method(int type) { int method(int type) {
return (type & 0x3E00) >> 2 | (type & 0x00E0) >> 1 return (type & 0x3E00) >> 2 | (type & 0x00E0) >> 1
| (type & 0x000F); | (type & 0x000F);
} }
<CODE ENDS>
A function to extract the class from the message type: A function to extract the class from the message type:
<CODE BEGINS>
int cls(int type) { int cls(int type) {
return (type & 0x0100) >> 7 | (type & 0x0010) >> 4; return (type & 0x0100) >> 7 | (type & 0x0010) >> 4;
} }
<CODE ENDS>
Appendix B. Test Vectors Appendix B. Test Vectors
This section augments the list of test vectors defined in [RFC5769] This section augments the list of test vectors defined in [RFC5769]
with MESSAGE-INTEGRITY-SHA256. All the formats and definitions with MESSAGE-INTEGRITY-SHA256. All the formats and definitions
listed in Section 2 of [RFC5769] apply here. listed in Section 2 of [RFC5769] apply here.
B.1. Sample Request with Long-Term Authentication with MESSAGE- B.1. Sample Request with Long-Term Authentication with MESSAGE-
INTEGRITY-SHA256 and USERHASH INTEGRITY-SHA256 and USERHASH
skipping to change at page 60, line 12 skipping to change at page 60, line 12
IANA. The MESSAGE-INTEGRITY-SHA256 attribute value will need to IANA. The MESSAGE-INTEGRITY-SHA256 attribute value will need to
be updated after this. be updated after this.
Appendix C. Release notes Appendix C. Release notes
This section must be removed before publication as an RFC. This section must be removed before publication as an RFC.
C.1. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- C.1. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf-
tram-stunbis-08 tram-stunbis-08
o Removed the reserved value in the security registry, as it does
not make sense in a bitset.
o Updated change list.
o Updated the minimum trancation size for M-I-256 to 16 bytes.
o Changed the truncation order to match RFC 7518.
o Fixed bugs in truncation boundary text.
o Stated that STUN Usages have to explicitly state that they can use
truncation.
o Removed truncation from the MESSAGE-INTEGRITY attrbute.
o Add reference to C code in RFC 1952.
o Replaced RFC 2818 reference to RFC 6125.
C.2. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf-
tram-stunbis-08
o Packets discarded in a reliable or unreliable transaction triggers o Packets discarded in a reliable or unreliable transaction triggers
an attack error instead of a timeout error. An attack error on a an attack error instead of a timeout error. An attack error on a
reliable transport is signalled immediately instead of waiting for reliable transport is signaled immediately instead of waiting for
the timeout. the timeout.
o Explicitly state that a received 400 response without o Explicitly state that a received 400 response without
authentication will be dropped until timeout. authentication will be dropped until timeout.
o Clarify the SHOULD omit/include rule sin LTCM. o Clarify the SHOULD omit/include rules in LTCM.
o If the nonce and the hmac are both invlid, then a 401 is sent o If the nonce and the hmac are both invalid, then a 401 is sent
instead of a 438. instead of a 438.
o The 401 and 438 error response to subsequent requests may use the o The 401 and 438 error response to subsequent requests may use the
previous NONCE/password to authenticate, if they are still previous NONCE/password to authenticate, if they are still
available. available.
C.2. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf- o Change "401 Unauthorized" to "401 Unauthenticated"
o Make clear that in some cases it is impossible to add a MI or MI2
even if the text says SHOULD NOT.
C.3. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf-
tram-stunbis-07 tram-stunbis-07
o Updated list of changes since RFC 5389. o Updated list of changes since RFC 5389.
o More examples are automatically generated. o More examples are automatically generated.
o Message integrity truncation is fixed at a multiple of 4 bytes, o Message integrity truncation is fixed at a multiple of 4 bytes,
because the padding will not decrease by more than this. because the padding will not decrease by more than this.
o USERHASH contains the 32 bytes of the hash, not a character o USERHASH contains the 32 bytes of the hash, not a character
string. string.
o Updated the example to use the USERHASH attribuet and the modified o Updated the example to use the USERHASH attribuet and the modified
NONCE attribute. NONCE attribute.
o Updated ICEbis reference. o Updated ICEbis reference.
C.3. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf- C.4. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf-
tram-stunbis-06 tram-stunbis-06
o Add USERHASH attribute to carry the hashed version of the o Add USERHASH attribute to carry the hashed version of the
username. username.
o Add IANA registry and nonce encoding for Security Features that o Add IANA registry and nonce encoding for Security Features that
need to be protected from bid down attacks. need to be protected from bid down attacks.
o Modified MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 to support o Modified MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 to support
truncation limits (pending cryptographic review), truncation limits (pending cryptographic review),
C.4. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf- C.5. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf-
tram-stunbis-05 tram-stunbis-05
o Changed I-D references to RFC references. o Changed I-D references to RFC references.
o Changed CHANGE-ADDRESS to CHANGE-REQUEST (Errata #4233). o Changed CHANGE-ADDRESS to CHANGE-REQUEST (Errata #4233).
o Added test vector for MESSAGE-INTEGRITY-SHA256. o Added test vector for MESSAGE-INTEGRITY-SHA256.
o Address additional review comments from Jonathan Lennox and o Address additional review comments from Jonathan Lennox and
Brandon Williams. Brandon Williams.
C.5. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- C.6. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf-
tram-stunbis-04 tram-stunbis-04
o Address review comments from Jonathan Lennox and Brandon Williams. o Address review comments from Jonathan Lennox and Brandon Williams.
C.6. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- C.7. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf-
tram-stunbis-03 tram-stunbis-03
o Remove SCTP. o Remove SCTP.
o Remove DANE. o Remove DANE.
o s/MESSAGE-INTEGRITY2/MESSAGE-INTEGRITY-SHA256/ o s/MESSAGE-INTEGRITY2/MESSAGE-INTEGRITY-SHA256/
o Remove Salted SHA256 password hash. o Remove Salted SHA256 password hash.
o The RTO delay between transactions is removed. o The RTO delay between transactions is removed.
o Make clear that reusing NONCE will trigger a wasted round trip. o Make clear that reusing NONCE will trigger a wasted round trip.
C.7. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- C.8. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf-
tram-stunbis-02 tram-stunbis-02
o SCTP prefix is now 0b00000101 instead of 0x11. o SCTP prefix is now 0b00000101 instead of 0x11.
o Add SCTP at various places it was needed. o Add SCTP at various places it was needed.
o Update the hash agility plan to take in account HMAC-SHA-256. 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 o Adds the bid down attack on message-integrity in the security
section. section.
C.8. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- C.9. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf-
tram-stunbis-01 tram-stunbis-01
o STUN hash algorithm agility (currently only SHA-1 is allowed). o STUN hash algorithm agility (currently only SHA-1 is allowed).
o Clarify terminology, text and guidance for STUN fragmentation. o Clarify terminology, text and guidance for STUN fragmentation.
o Clarify whether it's valid to share nonces across TURN o Clarify whether it's valid to share nonces across TURN
allocations. allocations.
o Prevent the server to allocate the same NONCE to clients with o Prevent the server to allocate the same NONCE to clients with
skipping to change at page 62, line 38 skipping to change at page 63, line 18
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 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.
C.9. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- C.10. 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:
* Split the "Sending over..." sections in 3. * Split the "Sending over..." sections in 3.
skipping to change at page 63, line 25 skipping to change at page 64, line 5
* 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.
C.10. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.11. 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.
C.11. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.12. 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 64, line 11 skipping to change at page 64, line 39
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)
C.12. Modifications between draft-salgueiro-tram-stunbis-01 and draft- C.13. 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, Benjamin Schwartz, Rifaat Shekh-Yusef, Alan Johnston, Perreault, Benjamin Schwartz, Rifaat Shekh-Yusef, Alan Johnston,
Jonathan Lennox and Brandon Williams for the comments, suggestions, Jonathan Lennox, Brandon Williams, Olle Johansson, and Martin Thomson
and 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. 58 change blocks. 
119 lines changed or deleted 160 lines changed or added

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