draft-ietf-tram-stunbis-13.txt   draft-ietf-tram-stunbis-14.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 21, 2018 Cisco Expires: July 18, 2018 Cisco
D. Wing D. Wing
R. Mahy R. Mahy
Unaffiliated Unaffiliated
P. Matthews P. Matthews
Nokia Nokia
December 18, 2017 January 14, 2018
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-13 draft-ietf-tram-stunbis-14
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 49 skipping to change at page 1, line 49
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 21, 2018. This Internet-Draft will expire on July 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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 15 skipping to change at page 4, line 15
17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 52 17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 52
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 53 18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 53
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 . . . . . . . . . . . . . . . . . . . . 58 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-13 and C.1. Modifications between draft-ietf-tram-stunbis-14 and
draft-ietf-tram-stunbis-13 . . . . . . . . . . . . . . . 60
C.2. Modifications between draft-ietf-tram-stunbis-13 and
draft-ietf-tram-stunbis-12 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-12 . . . . . . . . . . . . . . . 60
C.2. Modifications between draft-ietf-tram-stunbis-12 and C.3. Modifications between draft-ietf-tram-stunbis-12 and
draft-ietf-tram-stunbis-11 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-11 . . . . . . . . . . . . . . . 60
C.3. Modifications between draft-ietf-tram-stunbis-11 and C.4. Modifications between draft-ietf-tram-stunbis-11 and
draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 61
C.4. Modifications between draft-ietf-tram-stunbis-10 and C.5. Modifications between draft-ietf-tram-stunbis-10 and
draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 61
C.5. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 61
C.6. Modifications between draft-ietf-tram-stunbis-09 and C.6. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 61
C.7. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 62
C.7. Modifications between draft-ietf-tram-stunbis-08 and C.8. Modifications between draft-ietf-tram-stunbis-08 and
draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 62
C.8. Modifications between draft-ietf-tram-stunbis-07 and C.9. Modifications between draft-ietf-tram-stunbis-07 and
draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 63
C.9. Modifications between draft-ietf-tram-stunbis-06 and C.10. Modifications between draft-ietf-tram-stunbis-06 and
draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 63
C.10. Modifications between draft-ietf-tram-stunbis-05 and C.11. Modifications between draft-ietf-tram-stunbis-05 and
draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 63
C.11. Modifications between draft-ietf-tram-stunbis-04 and C.12. Modifications between draft-ietf-tram-stunbis-04 and
draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 63
C.12. Modifications between draft-ietf-tram-stunbis-03 and C.13. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 64
C.13. Modifications between draft-ietf-tram-stunbis-02 and C.14. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 64
C.14. Modifications between draft-ietf-tram-stunbis-01 and C.15. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 64
C.15. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 65 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 65
C.16. Modifications between draft-salgueiro-tram-stunbis-02 and C.16. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 65
C.17. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 65 draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 65
C.17. Modifications between draft-salgueiro-tram-stunbis-01 and C.18. Modifications between draft-salgueiro-tram-stunbis-01 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 66 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 66
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 66 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 66
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
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 25, line 32 skipping to change at page 25, line 32
If any of the checks fail, a server MUST NOT include a MESSAGE- If any of the checks fail, a server MUST NOT include a MESSAGE-
INTEGRITY-SHA256, MESSAGE-INTEGRITY, or USERNAME attribute in the INTEGRITY-SHA256, MESSAGE-INTEGRITY, or USERNAME attribute in the
error response. This is because, in these failure cases, the server error response. This is because, in these failure cases, the server
cannot determine the shared secret necessary to compute the MESSAGE- cannot determine the shared secret necessary to compute the MESSAGE-
INTEGRITY-SHA256 or MESSAGE-INTEGRITY attributes. INTEGRITY-SHA256 or MESSAGE-INTEGRITY attributes.
9.1.4. Receiving a Response 9.1.4. Receiving a Response
The client looks for the MESSAGE-INTEGRITY or the MESSAGE-INTEGRITY- The client looks for the MESSAGE-INTEGRITY or the MESSAGE-INTEGRITY-
SHA256 attribute in the response. If present, the client computes SHA256 attribute in the response. If present and if the client only
the message integrity over the response as defined in Section 14.5 or sent only one of MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
Section 14.6, respectively, using the same password it utilized for attributes in the request (because of the external indication in
the request. If the resulting value matches the contents of the section Section 9.2.3, or this being a subsequent request as defined
MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, in Section 9.1.5) the algorithm in the response has to match
respectively, the response is considered authenticated. If the value otherwise the response MUST be discarded.
does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-
SHA256 were absent, the processing depends on the request been sent The client then computes the message integrity over the response as
over a reliable or an unreliable transport. defined in Section 14.5 or Section 14.6, respectively, using the same
password it utilized for the request. If the resulting value matches
the contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
attribute, respectively, the response is considered authenticated.
If the value does not match, or if both MESSAGE-INTEGRITY and
MESSAGE-INTEGRITY-SHA256 were absent, the processing depends on the
request been sent over a reliable or an unreliable transport.
If the request was sent over an unreliable transport, the response If the request was sent over an unreliable transport, the response
MUST be discarded, as if it was never received. This means that MUST be discarded, as if it was never received. This means that
retransmits, if applicable, will continue. If all the responses retransmits, if applicable, will continue. If all the responses
received are discarded then instead of signalling a timeout after received are discarded then instead of signalling a timeout after
ending the transaction the layer MUST signal that an attack took ending the transaction the layer MUST signal that an attack took
place. place.
If the request was sent over a reliable transport, the response MUST If the request was sent over a reliable transport, the response MUST
be discarded and the layer MUST immediately end the transaction and be discarded and the layer MUST immediately end the transaction and
signal that an attack took place. signal that an attack took place.
If the client only sent only one of MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY-SHA256 attributes in the request (because of the external
indication in section Section 9.2.3, or this being a subsequent
request as defined in Section 9.1.5) the algorithm in the response
has to match otherwise the response MUST be discarded.
9.1.5. Sending Subsequent Requests 9.1.5. Sending Subsequent Requests
A client sending subsequent requests to the same server MUST send A client sending subsequent requests to the same server MUST send
only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY attribute only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY attribute
that matches the attribute that was received in the response to the that matches the attribute that was received in the response to the
initial request. Here same server means same IP address and port initial request. Here same server means same IP address and port
number, not just the same URI or SRV lookup result. number, not just the same URI or SRV lookup result.
9.2. Long-Term Credential Mechanism 9.2. Long-Term Credential Mechanism
skipping to change at page 28, line 10 skipping to change at page 28, line 10
For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS
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 ":" OpaqueString(realm) ":" OpaqueString(password))
Where MD5 is defined in [RFC1321] and the OpaqueString profile is Where MD5 is defined in [RFC1321] and the OpaqueString 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 and after processing using OpaqueString; (4) a single colon;
nulls removed and after processing using OpaqueString. For example, and (5) the password, with any trailing nulls removed and after
if the username was 'user', the realm was 'realm', and the password processing using OpaqueString. For example, if the username was
was 'pass', then the 16-byte HMAC key would be the result of 'user', the realm was 'realm', and the password was 'pass', then the
performing an MD5 hash on the string 'user:realm:pass', the resulting 16-byte HMAC key would be the result of performing an MD5 hash on the
hash being 0x8493fbc53ba582fb4c044c456bdc40eb. string 'user:realm:pass', the resulting 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.5.1. use are described in Section 17.5.1.
skipping to change at page 29, line 42 skipping to change at page 29, line 42
After the server has done the basic processing of a request, it After the server has done the basic processing of a request, it
performs the checks listed below in the order specified: performs the checks listed below in the order specified:
o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE- o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY-SHA256 attribute, the server MUST generate an error INTEGRITY-SHA256 attribute, the server MUST generate an error
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 source IP addresses, different source
ports, or both different source IP addresses and source 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 set the STUN Security Feature "Password attribute it MUST set the STUN Security Feature "Password
algorithms" bit set to 1. The server MAY support anonymous algorithms" bit set to 1. The server MAY support anonymous
username, in which case it MUST set the STUN Security Feature username, in which case it MUST set the STUN Security Feature
"Anonymous username" bit set to 1. The response SHOULD NOT "Anonymous username" bit set to 1. The response SHOULD NOT
contain a USERNAME, USERHASH, MESSAGE-INTEGRITY or MESSAGE- contain a USERNAME, USERHASH, MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY-SHA256 attribute. INTEGRITY-SHA256 attribute.
Note: Sharing a NONCE is no longer permitted, so trying to share one Note: Reusing a NONCE for different source IP addresses or ports was
will result in a wasted transaction. not explicitly forbidden in [RFC5389].
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-
INTEGRITY-SHA256 attribute, as the attributes required to generate INTEGRITY-SHA256 attribute, as the attributes required to generate
them are missing. them are missing.
skipping to change at page 31, line 14 skipping to change at page 31, line 14
o If the NONCE is no longer valid, the server MUST generate an error o If the NONCE is no longer valid, the server MUST generate an error
response with an error code of 438 (Stale Nonce). This response response with an error code of 438 (Stale Nonce). This response
MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and
SHOULD NOT include the USERNAME, USERHASH attribute, The response SHOULD NOT include the USERNAME, USERHASH attribute, The response
MAY include a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MAY include a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
attribute, using the previous NONCE to calculate it. Servers can attribute, using the previous NONCE to calculate it. Servers can
invalidate nonces in order to provide additional security. See invalidate nonces in order to provide additional security. See
Section 4.3 of [RFC7616] for guidelines. Section 4.3 of [RFC7616] for guidelines.
o If the username in the USERNAME or USERHASH attribute is not o If the value of the USERNAME or USERHASH attribute is not valid,
valid, the server MUST generate an error response with an error the server MUST generate an error response with an error code of
code of 401 (Unauthenticated). This response MUST include a REALM 401 (Unauthenticated). This response MUST include a REALM value.
value. It is RECOMMENDED that the REALM value be the domain name It is RECOMMENDED that the REALM value be the domain name of the
of the provider of the STUN server. The response MUST include a provider of the STUN server. The response MUST include a NONCE,
NONCE, selected by the server. The response MUST include a selected by the server. The response MUST include a PASSWORD-
PASSWORD-ALGORITHMS attribute. The response SHOULD NOT contain a ALGORITHMS attribute. The response SHOULD NOT contain a USERNAME,
USERNAME, USERHASH attribute. The response MAY include a MESSAGE- USERHASH attribute. The response MAY include a MESSAGE-INTEGRITY
INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, using the or MESSAGE-INTEGRITY-SHA256 attribute, using the previous password
previous password to calculate it. to calculate it.
o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the
value for the message integrity as described in Section 14.6, value for the message integrity as described in Section 14.6,
using the password associated with the username. Else, using the using the password associated with the username. Else, using the
same password, compute the value for the message integrity as same password, compute the value for the message integrity as
described in Section 14.5. If the resulting value does not match described in Section 14.5. If the resulting value does not match
the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE- the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE-
INTEGRITY-SHA256 attribute, the server MUST reject the request INTEGRITY-SHA256 attribute, the server MUST reject the request
with an error response. This response MUST use an error code of with an error response. This response MUST use an error code of
401 (Unauthenticated). It MUST include REALM and NONCE attributes 401 (Unauthenticated). It MUST include REALM and NONCE attributes
skipping to change at page 50, line 40 skipping to change at page 50, line 40
The initial STUN Security Features are: The initial STUN Security Features are:
0x000001: Password algorithms 0x000001: Password algorithms
0x000002: Username anonymity 0x000002: Username anonymity
New Security Features are assigned by a Standard Action [RFC8126]. New Security Features are assigned by a Standard Action [RFC8126].
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 name for method 0x002 and the
for the following STUN methods: reference from RFC 5389 to RFC-to-be for the following STUN methods:
0x000: (Reserved) 0x000: (Reserved)
0x001: Binding 0x001: Binding
0x002: (Reserved; was SharedSecret) 0x002: (Reserved; prior to [RFC5389] this was SharedSecret)
17.3. STUN Attribute Registry 17.3. STUN Attribute Registry
17.3.1. Updated Attributes 17.3.1. Updated Attributes
IANA is requested to update the reference from RFC 5389 to RFC-to-be IANA is requested to update the names for attributes 0x0002, 0x0003,
for the following STUN methods: 0x0004, 0x0005, 0x0007, and 0x000B, and 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; prior to [RFC5389] this was RESPONSE-ADDRESS)
0x0003: (Reserved; was CHANGE-REQUEST) 0x0003: (Reserved; prior to [RFC5389] this was CHANGE-REQUEST)
0x0004: (Reserved; was SOURCE-ADDRESS) 0x0004: (Reserved; prior to [RFC5389] this was SOURCE-ADDRESS)
0x0005: (Reserved; was CHANGED-ADDRESS) 0x0005: (Reserved; prior to [RFC5389] this was CHANGED-ADDRESS)
0x0006: USERNAME 0x0006: USERNAME
0x0007: (Reserved; was PASSWORD) 0x0007: (Reserved; prior to [RFC5389] this 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; prior to [RFC5389] this was REFLECTED-FROM)
0x0014: REALM 0x0014: REALM
0x0015: NONCE 0x0015: NONCE
0x0020: XOR-MAPPED-ADDRESS 0x0020: XOR-MAPPED-ADDRESS
Comprehension-optional range (0x8000-0xFFFF) Comprehension-optional range (0x8000-0xFFFF)
0x8022: SOFTWARE 0x8022: SOFTWARE
0x8023: ALTERNATE-SERVER 0x8023: ALTERNATE-SERVER
0x8028: FINGERPRINT 0x8028: FINGERPRINT
17.3.2. New Attributes 17.3.2. New Attributes
skipping to change at page 60, line 9 skipping to change at page 60, line 9
Note: Before publication, the XX XX placeholder must be replaced by Note: Before publication, the XX XX placeholder must be replaced by
the value assigned to MESSAGE-INTEGRITY-SHA256 and USERHASH by the value assigned to MESSAGE-INTEGRITY-SHA256 and USERHASH by
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-13 and draft-ietf- C.1. Modifications between draft-ietf-tram-stunbis-14 and draft-ietf-
tram-stunbis-13
o Reorder the paragraphs in section 9.1.4.
o The realm is now processed through Opaque in section 9.2.2.
o Make clear in section 9.2.4 that it is an exclusive-xor.
o Removed text that implied that nonce sharing was explicitly
permitted in RFC 5389.
o In same section, s/username/value/ for USERCASH.
o Modify the IANA requests to explicitly say that the reserved
codepoints were prior to RFC 5389.
C.2. Modifications between draft-ietf-tram-stunbis-13 and draft-ietf-
tram-stunbis-12 tram-stunbis-12
o Update references. o Update references.
o Fixes some text following Shepherd review. o Fixes some text following Shepherd review.
o Update co-author info. o Update co-author info.
C.2. Modifications between draft-ietf-tram-stunbis-12 and draft-ietf- C.3. Modifications between draft-ietf-tram-stunbis-12 and draft-ietf-
tram-stunbis-11 tram-stunbis-11
o Clarifies the procedure to define a new hash algorithm for o Clarifies the procedure to define a new hash algorithm for
message-integrity. message-integrity.
o Explain the procedure to deprecate SHA1 as message-integrity. o Explain the procedure to deprecate SHA1 as message-integrity.
o Added procedure for Happy Eyeballs (RFC 6555). o Added procedure for Happy Eyeballs (RFC 6555).
o Added verification that Happy Eyeballs works in the STUN Usage o Added verification that Happy Eyeballs works in the STUN Usage
checklist. checklist.
o Add reference to Base64 RFC. o Add reference to Base64 RFC.
o Changed co-author affiliation. o Changed co-author affiliation.
C.3. Modifications between draft-ietf-tram-stunbis-11 and draft-ietf- C.4. Modifications between draft-ietf-tram-stunbis-11 and draft-ietf-
tram-stunbis-10 tram-stunbis-10
o Made clear that the same HMAC than received in response of short o Made clear that the same HMAC than received in response of short
term credential must be used for subsequent transactions. term credential must be used for subsequent transactions.
o s/URL/URI/ o s/URL/URI/
o The "nonce cookie" is now mandatory to signal that SHA256 must be o The "nonce cookie" is now mandatory to signal that SHA256 must be
used in the next transaction. used in the next transaction.
o s/SHA1/SHA256/ o s/SHA1/SHA256/
o Changed co-author affiliation. o Changed co-author affiliation.
C.4. Modifications between draft-ietf-tram-stunbis-10 and draft-ietf- C.5. Modifications between draft-ietf-tram-stunbis-10 and draft-ietf-
tram-stunbis-09 tram-stunbis-09
o Removed the reserved value in the security registry, as it does o Removed the reserved value in the security registry, as it does
not make sense in a bitset. not make sense in a bitset.
o Updated change list. o Updated change list.
o Updated the minimum truncation size for M-I-256 to 16 bytes. o Updated the minimum truncation size for M-I-256 to 16 bytes.
o Changed the truncation order to match RFC 7518. o Changed the truncation order to match RFC 7518.
skipping to change at page 61, line 28 skipping to change at page 61, line 43
o Stated that STUN Usages have to explicitly state that they can use o Stated that STUN Usages have to explicitly state that they can use
truncation. truncation.
o Removed truncation from the MESSAGE-INTEGRITY attribute. o Removed truncation from the MESSAGE-INTEGRITY attribute.
o Add reference to C code in RFC 1952. o Add reference to C code in RFC 1952.
o Replaced RFC 2818 reference to RFC 6125. o Replaced RFC 2818 reference to RFC 6125.
C.5. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- C.6. 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 o Removed the reserved value in the security registry, as it does
not make sense in a bitset. not make sense in a bitset.
o Updated change list. o Updated change list.
o Updated the minimum truncation size for M-I-256 to 16 bytes. o Updated the minimum truncation size for M-I-256 to 16 bytes.
o Changed the truncation order to match RFC 7518. o Changed the truncation order to match RFC 7518.
skipping to change at page 62, line 5 skipping to change at page 62, line 18
o Stated that STUN Usages have to explicitly state that they can use o Stated that STUN Usages have to explicitly state that they can use
truncation. truncation.
o Removed truncation from the MESSAGE-INTEGRITY attribute. o Removed truncation from the MESSAGE-INTEGRITY attribute.
o Add reference to C code in RFC 1952. o Add reference to C code in RFC 1952.
o Replaced RFC 2818 reference to RFC 6125. o Replaced RFC 2818 reference to RFC 6125.
C.6. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- C.7. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf-
tram-stunbis-08 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 signaled 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.
skipping to change at page 62, line 30 skipping to change at page 62, line 43
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.
o Change "401 Unauthorized" to "401 Unauthenticated" o Change "401 Unauthorized" to "401 Unauthenticated"
o Make clear that in some cases it is impossible to add a MI or MI2 o Make clear that in some cases it is impossible to add a MI or MI2
even if the text says SHOULD NOT. even if the text says SHOULD NOT.
C.7. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf- C.8. 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 attribute and the modified o Updated the example to use the USERHASH attribute and the modified
NONCE attribute. NONCE attribute.
o Updated ICEbis reference. o Updated ICEbis reference.
C.8. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf- C.9. 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.9. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf- C.10. 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.10. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- C.11. 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.11. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- C.12. 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.12. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- C.13. 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.13. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- C.14. 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 64, line 47 skipping to change at page 65, line 5
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.14. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- C.15. 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 65, line 33 skipping to change at page 65, line 40
* 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.15. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.16. 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.16. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.17. 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 66, line 19 skipping to change at page 66, line 25
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.17. Modifications between draft-salgueiro-tram-stunbis-01 and draft- C.18. 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,
 End of changes. 51 change blocks. 
88 lines changed or deleted 110 lines changed or added

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