< draft-ietf-tram-stunbis-19.txt   draft-ietf-tram-stunbis-20.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: April 18, 2019 Cisco Expires: September 12, 2019 Cisco
D. Wing D. Wing
R. Mahy R. Mahy
Unaffiliated Unaffiliated
P. Matthews P. Matthews
Nokia Nokia
October 15, 2018 March 11, 2019
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-19 draft-ietf-tram-stunbis-20
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 April 18, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 37 skipping to change at page 3, line 37
14.14. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 46 14.14. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 46
14.15. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 46 14.15. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 46
14.16. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 47 14.16. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 47
15. Operational Considerations . . . . . . . . . . . . . . . . . 47 15. Operational Considerations . . . . . . . . . . . . . . . . . 47
16. Security Considerations . . . . . . . . . . . . . . . . . . . 47 16. Security Considerations . . . . . . . . . . . . . . . . . . . 47
16.1. Attacks against the Protocol . . . . . . . . . . . . . . 47 16.1. Attacks against the Protocol . . . . . . . . . . . . . . 47
16.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 47 16.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 47
16.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 48 16.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 48
16.1.3. Bid-Down Attacks . . . . . . . . . . . . . . . . . . 49 16.1.3. Bid-Down Attacks . . . . . . . . . . . . . . . . . . 49
16.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 50 16.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 50
16.2.1. Attack I: Distributed DoS (DDoS) against a Target . 50 16.2.1. Attack I: Distributed DoS (DDoS) against a Target . 51
16.2.2. Attack II: Silencing a Client . . . . . . . . . . . 51 16.2.2. Attack II: Silencing a Client . . . . . . . . . . . 51
16.2.3. Attack III: Assuming the Identity of a Client . . . 51 16.2.3. Attack III: Assuming the Identity of a Client . . . 51
16.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 51 16.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 51
16.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 52 16.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 52
17. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 52 17. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 53
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
18.1. STUN Security Features Registry . . . . . . . . . . . . 53 18.1. STUN Security Features Registry . . . . . . . . . . . . 53
18.2. STUN Methods Registry . . . . . . . . . . . . . . . . . 53 18.2. STUN Methods Registry . . . . . . . . . . . . . . . . . 53
18.3. STUN Attribute Registry . . . . . . . . . . . . . . . . 53 18.3. STUN Attribute Registry . . . . . . . . . . . . . . . . 54
18.3.1. Updated Attributes . . . . . . . . . . . . . . . . . 53 18.3.1. Updated Attributes . . . . . . . . . . . . . . . . . 54
18.3.2. New Attributes . . . . . . . . . . . . . . . . . . . 54 18.3.2. New Attributes . . . . . . . . . . . . . . . . . . . 54
18.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 54 18.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 54
18.5. STUN Password Algorithm Registry . . . . . . . . . . . . 54 18.5. STUN Password Algorithm Registry . . . . . . . . . . . . 55
18.5.1. Password Algorithms . . . . . . . . . . . . . . . . 55 18.5.1. Password Algorithms . . . . . . . . . . . . . . . . 55
18.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 55 18.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 55
18.5.1.2. SHA-256 . . . . . . . . . . . . . . . . . . . . 55 18.5.1.2. SHA-256 . . . . . . . . . . . . . . . . . . . . 55
18.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 55 18.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 56
19. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 56 19. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 56
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
20.1. Normative References . . . . . . . . . . . . . . . . . . 56 20.1. Normative References . . . . . . . . . . . . . . . . . . 57
20.2. Informative References . . . . . . . . . . . . . . . . . 59 20.2. Informative References . . . . . . . . . . . . . . . . . 59
Appendix A. C Snippet to Determine STUN Message Types . . . . . 61 Appendix A. C Snippet to Determine STUN Message Types . . . . . 61
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 62 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 62
B.1. Sample Request with Long-Term Authentication with B.1. Sample Request with Long-Term Authentication with
MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 62 MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 62
Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 64 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 64
C.1. Modifications between draft-ietf-tram-stunbis-19 and C.1. Modifications between draft-ietf-tram-stunbis-20 and
draft-ietf-tram-stunbis-19 . . . . . . . . . . . . . . . 64
C.2. Modifications between draft-ietf-tram-stunbis-19 and
draft-ietf-tram-stunbis-18 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-18 . . . . . . . . . . . . . . . 64
C.2. Modifications between draft-ietf-tram-stunbis-18 and C.3. Modifications between draft-ietf-tram-stunbis-18 and
draft-ietf-tram-stunbis-17 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-17 . . . . . . . . . . . . . . . 64
C.3. Modifications between draft-ietf-tram-stunbis-17 and C.4. Modifications between draft-ietf-tram-stunbis-17 and
draft-ietf-tram-stunbis-16 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-16 . . . . . . . . . . . . . . . 64
C.4. Modifications between draft-ietf-tram-stunbis-16 and C.5. Modifications between draft-ietf-tram-stunbis-16 and
draft-ietf-tram-stunbis-15 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-15 . . . . . . . . . . . . . . . 64
C.5. Modifications between draft-ietf-tram-stunbis-15 and C.6. Modifications between draft-ietf-tram-stunbis-15 and
draft-ietf-tram-stunbis-14 . . . . . . . . . . . . . . . 65 draft-ietf-tram-stunbis-14 . . . . . . . . . . . . . . . 65
C.6. Modifications between draft-ietf-tram-stunbis-14 and C.7. Modifications between draft-ietf-tram-stunbis-14 and
draft-ietf-tram-stunbis-13 . . . . . . . . . . . . . . . 65 draft-ietf-tram-stunbis-13 . . . . . . . . . . . . . . . 65
C.7. Modifications between draft-ietf-tram-stunbis-13 and C.8. Modifications between draft-ietf-tram-stunbis-13 and
draft-ietf-tram-stunbis-12 . . . . . . . . . . . . . . . 65 draft-ietf-tram-stunbis-12 . . . . . . . . . . . . . . . 66
C.8. Modifications between draft-ietf-tram-stunbis-12 and C.9. Modifications between draft-ietf-tram-stunbis-12 and
draft-ietf-tram-stunbis-11 . . . . . . . . . . . . . . . 66 draft-ietf-tram-stunbis-11 . . . . . . . . . . . . . . . 66
C.9. Modifications between draft-ietf-tram-stunbis-11 and C.10. Modifications between draft-ietf-tram-stunbis-11 and
draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 66 draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 66
C.10. Modifications between draft-ietf-tram-stunbis-10 and C.11. Modifications between draft-ietf-tram-stunbis-10 and
draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 66 draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 66
C.11. Modifications between draft-ietf-tram-stunbis-09 and C.12. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 67 draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 67
C.12. Modifications between draft-ietf-tram-stunbis-08 and C.13. Modifications between draft-ietf-tram-stunbis-08 and
draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 67 draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 67
C.13. Modifications between draft-ietf-tram-stunbis-07 and C.14. Modifications between draft-ietf-tram-stunbis-07 and
draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 68 draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 68
C.14. Modifications between draft-ietf-tram-stunbis-06 and C.15. Modifications between draft-ietf-tram-stunbis-06 and
draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 68 draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 68
C.15. Modifications between draft-ietf-tram-stunbis-05 and C.16. Modifications between draft-ietf-tram-stunbis-05 and
draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 68 draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 68
C.16. Modifications between draft-ietf-tram-stunbis-04 and C.17. Modifications between draft-ietf-tram-stunbis-04 and
draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 68 draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 68
C.17. Modifications between draft-ietf-tram-stunbis-03 and C.18. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 69 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 69
C.18. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 69
C.19. Modifications between draft-ietf-tram-stunbis-01 and C.19. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 69 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 69
C.20. Modifications between draft-salgueiro-tram-stunbis-02 and C.20. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 70 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 70
C.21. Modifications between draft-salgueiro-tram-stunbis-02 and C.21. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 70
C.22. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 70 draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 70
C.22. Modifications between draft-salgueiro-tram-stunbis-01 and C.23. Modifications between draft-salgueiro-tram-stunbis-01 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 71 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 71
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72
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 [RFC8445], or to relay
or to relay packets between two endpoints [RFC5766]. packets between two endpoints [RFC5766].
In keeping with its tool nature, this specification defines an In keeping with its tool nature, this specification defines an
extensible packet format, defines operation over several transport extensible packet format, defines operation over several transport
protocols, and provides for two forms of authentication. protocols, and provides for two forms of authentication.
STUN is intended to be used in the context of one or more NAT STUN is intended to be used in the context of one or more NAT
traversal solutions. These solutions are known as STUN usages. Each traversal solutions. These solutions are known as STUN usages. Each
usage describes how STUN is utilized to achieve the NAT traversal usage describes how STUN is utilized to achieve the NAT traversal
solution. Typically, a usage indicates when STUN messages get sent, solution. Typically, a usage indicates when STUN messages get sent,
which optional attributes to include, what server is used, and what which optional attributes to include, what server is used, and what
authentication mechanism is to be used. Interactive Connectivity authentication mechanism is to be used. Interactive Connectivity
Establishment (ICE) [I-D.ietf-ice-rfc5245bis] is one usage of STUN. Establishment (ICE) [RFC8445] is one usage of STUN. SIP Outbound
SIP Outbound [RFC5626] is another usage of STUN. In some cases, a [RFC5626] is another usage of STUN. In some cases, a usage will
usage will require extensions to STUN. A STUN extension can be in require extensions to STUN. A STUN extension can be in the form of
the form of new methods, attributes, or error response codes. More new methods, attributes, or error response codes. More information
information on STUN usages can be found in Section 13. on STUN usages can be found in Section 13.
2. Overview of Operation 2. Overview of Operation
This section is descriptive only. This section is descriptive only.
/-----\ /-----\
// STUN \\ // STUN \\
| Server | | Server |
\\ // \\ //
\-----/ \-----/
skipping to change at page 7, line 43 skipping to change at page 7, line 43
server copies that source transport address into an XOR-MAPPED- server copies that source transport address into an XOR-MAPPED-
ADDRESS attribute in the STUN Binding response and sends the Binding ADDRESS attribute in the STUN Binding response and sends the Binding
response back to the STUN client. As this packet passes back through response back to the STUN client. As this packet passes back through
a NAT, the NAT will modify the destination transport address in the a NAT, the NAT will modify the destination transport address in the
IP header, but the transport address in the XOR-MAPPED-ADDRESS IP header, but the transport address in the XOR-MAPPED-ADDRESS
attribute within the body of the STUN response will remain untouched. attribute within the body of the STUN response will remain untouched.
In this way, the client can learn its reflexive transport address In this way, the client can learn its reflexive transport address
allocated by the outermost NAT with respect to the STUN server. allocated by the outermost NAT with respect to the STUN server.
In some usages, STUN must be multiplexed with other protocols (e.g., In some usages, STUN must be multiplexed with other protocols (e.g.,
[I-D.ietf-ice-rfc5245bis], [RFC5626]). In these usages, there must [RFC8445], [RFC5626]). In these usages, there must be a way to
be a way to inspect a packet and determine if it is a STUN packet or inspect a packet and determine if it is a STUN packet or not. STUN
not. STUN provides three fields in the STUN header with fixed values provides three fields in the STUN header with fixed values that can
that can be used for this purpose. If this is not sufficient, then be used for this purpose. If this is not sufficient, then STUN
STUN packets can also contain a FINGERPRINT value, which can further packets can also contain a FINGERPRINT value, which can further be
be used to distinguish the packets. used to distinguish the packets.
STUN defines a set of optional procedures that a usage can decide to STUN defines a set of optional procedures that a usage can decide to
use, called mechanisms. These mechanisms include DNS discovery, a use, called mechanisms. These mechanisms include DNS discovery, a
redirection technique to an alternate server, a fingerprint attribute redirection technique to an alternate server, a fingerprint attribute
for demultiplexing, and two authentication and message-integrity for demultiplexing, and two authentication and message-integrity
exchanges. The authentication mechanisms revolve around the use of a exchanges. The authentication mechanisms revolve around the use of a
username, password, and message-integrity value. Two authentication username, password, and message-integrity value. Two authentication
mechanisms, the long-term credential mechanism and the short-term mechanisms, the long-term credential mechanism and the short-term
credential mechanism, are defined in this specification. Each usage credential mechanism, are defined in this specification. Each usage
specifies the mechanisms allowed with that usage. specifies the mechanisms allowed with that usage.
In the long-term credential mechanism, the client and server share a In the long-term credential mechanism, the client and server share a
pre-provisioned username and password and perform a digest challenge/ pre-provisioned username and password and perform a digest challenge/
response exchange inspired by (but differing in details) to the one response exchange inspired by (but differing in details) to the one
defined for HTTP [RFC7616]. In the short-term credential mechanism, defined for HTTP [RFC7616]. In the short-term credential mechanism,
the client and the server exchange a username and password through the client and the server exchange a username and password through
some out-of-band method prior to the STUN exchange. For example, in some out-of-band method prior to the STUN exchange. For example, in
the ICE usage [I-D.ietf-ice-rfc5245bis] the two endpoints use out-of- the ICE usage [RFC8445] the two endpoints use out-of-band signaling
band signaling to exchange a username and password. These are used to exchange a username and password. These are used to integrity
to integrity protect and authenticate the request and response. protect and authenticate the request and response. There is no
There is no challenge or nonce used. challenge or nonce used.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
4. Definitions 4. Definitions
skipping to change at page 17, line 17 skipping to change at page 17, line 17
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
defined in Section 11. Those additional procedures are optional, and defined in Section 11. Those additional procedures are optional, and
usages can elect to utilize them. Fcirst, a set of processing usages can elect to utilize them. First, a set of processing
operations is applied that is independent of the class. This is operations is applied that is independent of the class. This is
followed by class-specific processing, described in the subsections followed by class-specific processing, described in the subsections
that follow. that follow.
When a STUN agent receives a STUN message, it first checks that the When a STUN agent receives a STUN message, it first checks that the
message obeys the rules of Section 5. It checks that the first two message obeys the rules of Section 5. It checks that the first two
bits are 0, that the magic cookie field has the correct value, that bits are 0, that the magic cookie field has the correct value, that
the message length is sensible, and that the method value is a the message length is sensible, and that the method value is a
supported method. It checks that the message class is allowed for supported method. It checks that the message class is allowed for
the particular method. If the message class is "Success Response" or the particular method. If the message class is "Success Response" or
skipping to change at page 24, line 5 skipping to change at page 24, line 5
INTEGRITY attribute is not present, with the exception of the INTEGRITY attribute is not present, with the exception of the
FINGERPRINT attribute. FINGERPRINT attribute.
9.1. Short-Term Credential Mechanism 9.1. Short-Term Credential Mechanism
The short-term credential mechanism assumes that, prior to the STUN The short-term credential mechanism assumes that, prior to the STUN
transaction, the client and server have used some other protocol to transaction, the client and server have used some other protocol to
exchange a credential in the form of a username and password. This exchange a credential in the form of a username and password. This
credential is time-limited. The time limit is defined by the usage. credential is time-limited. The time limit is defined by the usage.
As an example, in the ICE usage [I-D.ietf-ice-rfc5245bis], the two As an example, in the ICE usage [RFC8445], the two endpoints use out-
endpoints use out-of-band signaling to agree on a username and of-band signaling to agree on a username and password, and this
password, and this username and password are applicable for the username and password are applicable for the duration of the media
duration of the media session. session.
This credential is used to form a message-integrity check in each This credential is used to form a message-integrity check in each
request and in many responses. There is no challenge and response as request and in many responses. There is no challenge and response as
in the long-term mechanism; consequently, replay is limited by virtue in the long-term mechanism; consequently, replay is limited by virtue
of the time-limited nature of the credential. of the time-limited nature of the credential.
9.1.1. HMAC Key 9.1.1. HMAC Key
For short-term credentials the HMAC key is defined as follow: For short-term credentials the HMAC key is defined as follow:
skipping to change at page 26, line 21 skipping to change at page 26, line 21
password it utilized for the request. If the resulting value matches password it utilized for the request. If the resulting value matches
the contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 the contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
attribute, respectively, the response is considered authenticated. attribute, respectively, the response is considered authenticated.
If the value does not match, or if both MESSAGE-INTEGRITY and If the value does not match, or if both MESSAGE-INTEGRITY and
MESSAGE-INTEGRITY-SHA256 were absent, the processing depends on the MESSAGE-INTEGRITY-SHA256 were absent, the processing depends on the
request been sent over a reliable or an unreliable transport. 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 signaling a timeout after
ending the transaction the layer MUST signal that the integrity ending the transaction the layer MUST signal that the integrity
protection was violated. protection was violated.
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 the integrity protection was violated. signal that the integrity protection was violated.
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
skipping to change at page 33, line 32 skipping to change at page 33, line 32
as defined in Section 14.5 or Section 14.6, using the same password as defined in Section 14.5 or Section 14.6, using the same password
it utilized for the request. If the resulting value matches the it utilized for the request. If the resulting value matches the
contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
attribute, the response is considered authenticated. If the value attribute, the response is considered authenticated. If the value
does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY- does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-
SHA256 were absent, the processing depends on the request been sent SHA256 were absent, the processing depends on the request been sent
over a reliable or an unreliable transport. 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 reponses 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 signaling a timeout after
ending the transaction the layer MUST signal that the integrity ending the transaction the layer MUST signal that the integrity
protection was violated. protection was violated.
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 the integrity protection was violated. signal that the integrity protection was violated.
If the response contains a PASSWORD-ALGORITHMS attribute, all the If the response contains a PASSWORD-ALGORITHMS attribute, all the
subsequent requests MUST be authenticated using MESSAGE-INTEGRITY- subsequent requests MUST be authenticated using MESSAGE-INTEGRITY-
SHA256 only. SHA256 only.
skipping to change at page 40, line 25 skipping to change at page 40, line 25
implementation MUST be able to parse UTF-8 encoded sequence of 763 or implementation MUST be able to parse UTF-8 encoded sequence of 763 or
less bytes, to be compatible with [RFC5389] that mistakenly assumed less bytes, to be compatible with [RFC5389] that mistakenly assumed
up to 6 bytes per characters encoded. up to 6 bytes per characters encoded.
14.4. USERHASH 14.4. USERHASH
The USERHASH attribute is used as a replacement for the USERNAME The USERHASH attribute is used as a replacement for the USERNAME
attribute when username anonymity is supported. attribute when username anonymity is supported.
The value of USERHASH has a fixed length of 32 bytes. The username The value of USERHASH has a fixed length of 32 bytes. The username
and the realm MUST have been processed using the MUST have been processed using the UsernameCasePreserved profile
UsernameCasePreserved profile [RFC8265] before hashing. [RFC8265] and the realm MUST have been processed using the
OpaqueString profile [RFC8265] before hashing.
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 = SHA-256(UsernameCasePreserved(username) userhash = SHA-256(UsernameCasePreserved(username)
":" OpaqueString(realm)) ":" OpaqueString(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
skipping to change at page 44, line 37 skipping to change at page 44, line 37
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 in that realm for authentication. long-term credential in that realm 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 [RFC3261]. Note that this means that the NONCE attribute will not
will not contain the actual surrounding quote characters. See contain the actual surrounding quote characters. See [RFC7616],
[RFC7616], Section 5.4, for guidance on selection of nonce values in Section 5.4, for guidance on selection of nonce values in a server.
a server. It MUST be less than 128 characters (which can be as long It MUST be less than 128 characters (which can be as long as 509
as 509 bytes when encoding them and a long as 763 bytes when decoding bytes when encoding them and a long as 763 bytes when decoding them).
them).
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.
The set of known algorithms is maintained by IANA. The initial set The set of known algorithms is maintained by IANA. The initial set
defined by this specification is found in Section 18.5. defined by this specification is found in Section 18.5.
skipping to change at page 48, line 30 skipping to change at page 48, line 30
attacks. attacks.
STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256,
which is subject to bid-down attacks by an on-path attacker that which is subject to bid-down attacks by an on-path attacker that
would strip the MESSAGE-INTEGRITY-SHA256 attribute leaving only the would strip the MESSAGE-INTEGRITY-SHA256 attribute leaving only the
MESSAGE-INTEGRITY attribute and exploiting a potential vulnerability. MESSAGE-INTEGRITY attribute and exploiting a potential vulnerability.
Protection of the channel itself, using TLS or DTLS, mitigates these Protection of the channel itself, using TLS or DTLS, mitigates these
attacks. Timely removal of the support of MESSAGE-INTEGRITY in a attacks. Timely removal of the support of MESSAGE-INTEGRITY in a
future version of STUN is necessary. future version of STUN is necessary.
Note: The use of SHA-256 for password hashing does not meet modern
standards, which are aimed at slowing down exhaustive password search
by providing a relatively slow minimum time to compute the hash.
Although better algorithms such as Argon2 [I-D.irtf-cfrg-argon2] are
available, SHA-256 was chosen for consistency with [RFC7616].
16.1.2. Inside Attacks 16.1.2. Inside Attacks
A rogue client may try to launch a DoS attack against a server by A rogue client may try to launch a DoS attack against a server by
sending it a large number of STUN requests. Fortunately, STUN sending it a large number of STUN requests. Fortunately, STUN
requests can be processed statelessly by a server, making such requests can be processed statelessly by a server, making such
attacks hard to launch effectively. attacks hard to launch effectively.
A rogue client may use a STUN server as a reflector, sending it A rogue client may use a STUN server as a reflector, sending it
requests with a falsified source IP address and port. In such a requests with a falsified source IP address and port. In such a
case, the response would be delivered to that source IP and port. case, the response would be delivered to that source IP and port.
skipping to change at page 49, line 11 skipping to change at page 49, line 17
attacks against software that is known to contain security holes. attacks against software that is known to contain security holes.
Implementers SHOULD make usage of the SOFTWARE attribute a Implementers SHOULD make usage of the SOFTWARE attribute a
configurable option. configurable option.
16.1.3. Bid-Down Attacks 16.1.3. Bid-Down Attacks
This document adds the possibility of selecting different algorithms This document adds the possibility of selecting different algorithms
for protecting the confidentiality of the passwords stored on the for protecting the confidentiality of the passwords stored on the
server side when using the Long-Term Credential Mechanism, while server side when using the Long-Term Credential Mechanism, while
still ensuring compatibility with MD5, which was the algorithm used still ensuring compatibility with MD5, which was the algorithm used
in a previous versin of this protocol. It works by having the server in a previous version of this protocol. It works by having the
send back to the client the list of algorithms supported in a server send back to the client the list of algorithms supported in a
PASSWORD-ALGORITHMS attribute, and having the client send back a PASSWORD-ALGORITHMS attribute, and having the client send back a
PASSWORD-ALGORITHM attribute containing the algorithm selected. PASSWORD-ALGORITHM attribute containing the algorithm selected.
Because the PASSWORD-ALGORITHMS attribute has to be sent in an Because the PASSWORD-ALGORITHMS attribute has to be sent in an
unauthenticated response, an on-path attacker wanting to exploit an unauthenticated response, an on-path attacker wanting to exploit an
eventual vulnerability in MD5 can just strip the PASSWORD-ALGORITHMS eventual vulnerability in MD5 can just strip the PASSWORD-ALGORITHMS
attribute from the unprotected response, thus making the server attribute from the unprotected response, thus making the server
subsequently act as if the client was implementing a previous version subsequently act as if the client was implementing a previous version
of this protocol. of this protocol.
skipping to change at page 50, line 5 skipping to change at page 50, line 10
The on-path attack may also try to remove the security bit together The on-path attack may also try to remove the security bit together
with the PASSWORD-ALGORITHMS attribute, but the server will discover with the PASSWORD-ALGORITHMS attribute, but the server will discover
that when the next authenticated transaction contains an invalid that when the next authenticated transaction contains an invalid
nonce. nonce.
An on-path attack that removes some algorithms from the PASSWORD- An on-path attack that removes some algorithms from the PASSWORD-
ALGORITHMS attribute will be equally defeated because that attribute ALGORITHMS attribute will be equally defeated because that attribute
will be different from the original one when the server verifies it will be different from the original one when the server verifies it
in the subsequent authenticated transaction. in the subsequent authenticated transaction.
Note that the bid-down protection mechanism introduced in this
document is inherently limited by the fact that it is not possible to
detect an attack until the server receives the second request after
the 401 response. SHA-256 was chosen as the new default for password
hashing for its compability with RFC 7616 but because SHA-256 (like
MD5) is a comparatively fast algorithm, the password can be passively
found through brute-force mechanisms, using the MESSAGE-INTEGRITY or
MESSAGE-INTEGRITY-SHA256 from the second request. A much stronger
algorithm, like Argon2 [I-D.irtf-cfrg-argon2], would help but not
until the database entry for this user is updated to exclusively use
that stronger mechanism. Similarly, an attack against the USERHASH
mechanism will not succeed in establishing a session as the server
will detect that the feature was discarded on-path, but the client
would still have been convinced to send its username in clear in the
USERNAME attribute, thus disclosing it to the attacker. Finally,
when the bid-down protection mechanism is employed for a future
upgrade of the HMAC algorithm used to protect message, it will offer
only a limited protection if the current HMAC algorithm is already
compromised.
16.2. Attacks Affecting the Usage 16.2. Attacks Affecting the Usage
This section lists attacks that might be launched against a usage of This section lists attacks that might be launched against a usage of
STUN. Each STUN usage must consider whether these attacks are STUN. Each STUN usage must consider whether these attacks are
applicable to it, and if so, discuss counter-measures. applicable to it, and if so, discuss counter-measures.
Most of the attacks in this section revolve around an attacker Most of the attacks in this section revolve around an attacker
modifying the reflexive address learned by a STUN client through a modifying the reflexive address learned by a STUN client through a
Binding request/response transaction. Since the usage of the Binding request/response transaction. Since the usage of the
reflexive address is a function of the usage, the applicability and reflexive address is a function of the usage, the applicability and
skipping to change at page 50, line 29 skipping to change at page 51, line 5
attacker can modify the source IP address of the Binding request attacker can modify the source IP address of the Binding request
before it arrives at the STUN server. The STUN server will then before it arrives at the STUN server. The STUN server will then
return this IP address in the XOR-MAPPED-ADDRESS attribute to the return this IP address in the XOR-MAPPED-ADDRESS attribute to the
client, and send the response back to that (falsified) IP address and client, and send the response back to that (falsified) IP address and
port. If the attacker can also intercept this response, it can port. If the attacker can also intercept this response, it can
direct it back towards the client. Protecting against this attack by direct it back towards the client. Protecting against this attack by
using a message-integrity check is impossible, since a message- using a message-integrity check is impossible, since a message-
integrity value cannot cover the source IP address, since the integrity value cannot cover the source IP address, since the
intervening NAT must be able to modify this value. Instead, one intervening NAT must be able to modify this value. Instead, one
solution to preventing the attacks listed below is for the client to solution to preventing the attacks listed below is for the client to
verify the reflexive address learned, as is done in ICE verify the reflexive address learned, as is done in ICE [RFC8445].
[I-D.ietf-ice-rfc5245bis]. X-Port is computed by taking the mapped
port in host byte order, XOR'ing it with the most significant 16 bits
of the magic cookie, and then the converting the result to network
byte order. If the IP address family is IPv4, X-Address is computed
by taking the mapped IP address in host byte order, XOR'ing it with
the magic cookie, and converting the result to network byte order.
If the IP address family is IPv6, X-Address is computed by taking the
mapped IP address in host byte order, XOR'ing it with the
concatenation of the magic cookie and the 96-bit transaction ID, and
converting the result to network byte order.
Other usages may use other means to prevent these attacks. Other usages may use other means to prevent these attacks.
16.2.1. Attack I: Distributed DoS (DDoS) against a Target 16.2.1. Attack I: Distributed DoS (DDoS) against a Target
In this attack, the attacker provides one or more clients with the In this attack, the attacker provides one or more clients with the
same faked reflexive address that points to the intended target. same faked reflexive address that points to the intended target.
This will trick the STUN clients into thinking that their reflexive This will trick the STUN clients into thinking that their reflexive
addresses are equal to that of the target. If the clients hand out addresses are equal to that of the target. If the clients hand out
that reflexive address in order to receive traffic on it (for that reflexive address in order to receive traffic on it (for
skipping to change at page 53, line 7 skipping to change at page 53, line 17
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]).
STUN can be used to perform this function using a Binding request/ STUN can be used to perform this function using a Binding request/
response transaction if one agent is behind a NAT and the other is on response transaction if one agent is behind a NAT and 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 [RFC8445] ), and others do not
others do not (such as SIP Outbound [RFC5626]), answers to these (such as SIP Outbound [RFC5626]), answers to these considerations
considerations need to be addressed by the usages themselves. need to be addressed by the usages themselves.
18. IANA Considerations 18. IANA Considerations
18.1. STUN Security Features Registry 18.1. STUN Security Features Registry
A STUN Security Feature set defines 24 bit as flags. A STUN Security Feature set defines 24 bit as flags.
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.
skipping to change at page 59, line 24 skipping to change at page 59, line 33
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
20.2. Informative References 20.2. Informative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-20 (work in progress), March 2018.
[I-D.ietf-tram-stun-pmtud] [I-D.ietf-tram-stun-pmtud]
Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery
Using Session Traversal Utilities for NAT (STUN)", draft- Using Session Traversal Utilities for NAT (STUN)", draft-
ietf-tram-stun-pmtud-07 (work in progress), March 2018. ietf-tram-stun-pmtud-10 (work in progress), September
2018.
[I-D.irtf-cfrg-argon2]
Biryukov, A., Dinu, D., Khovratovich, D., and S.
Josefsson, "The memory-hard Argon2 password hash and
proof-of-work function", draft-irtf-cfrg-argon2-04 (work
in progress), November 2018.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, DOI 10.17487/RFC1952, May 1996, RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>. <https://www.rfc-editor.org/info/rfc1952>.
[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,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
skipping to change at page 61, line 15 skipping to change at page 61, line 25
[RFC7231] Fielding, R. and R. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and R. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, May 2008, RFC 8126, DOI 10.17487/RFC8126, May 2008,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
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> <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)
skipping to change at page 64, line 9 skipping to change at page 64, 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-19 and draft-ietf- C.1. Modifications between draft-ietf-tram-stunbis-20 and draft-ietf-
tram-stunbis-19
o Updates to address Eric Rescorla's DISCUSS and comments.
o Addressed nits raised by Noriyuki Torii
C.2. Modifications between draft-ietf-tram-stunbis-19 and draft-ietf-
tram-stunbis-18 tram-stunbis-18
o Updates following Adam Roach DISCUSS and comments. o Updates following Adam Roach DISCUSS and comments.
C.2. Modifications between draft-ietf-tram-stunbis-18 and draft-ietf- C.3. Modifications between draft-ietf-tram-stunbis-18 and draft-ietf-
tram-stunbis-17 tram-stunbis-17
o Nits. o Nits.
C.3. Modifications between draft-ietf-tram-stunbis-17 and draft-ietf- C.4. Modifications between draft-ietf-tram-stunbis-17 and draft-ietf-
tram-stunbis-16 tram-stunbis-16
o Modifications following IESG, GENART and SECDIR reviews. o Modifications following IESG, GENART and SECDIR reviews.
C.4. Modifications between draft-ietf-tram-stunbis-16 and draft-ietf- C.5. Modifications between draft-ietf-tram-stunbis-16 and draft-ietf-
tram-stunbis-15 tram-stunbis-15
o Replace "failure response" with "error response". o Replace "failure response" with "error response".
o Fix wrong section number. o Fix wrong section number.
o Use "Username anonymity" everywhere. o Use "Username anonymity" everywhere.
o Align with UTF-8 deprecation. o Align with UTF-8 deprecation.
skipping to change at page 65, line 21 skipping to change at page 65, line 28
o s/invalidate/revoke/. o s/invalidate/revoke/.
o Removed sentences about checking USERHASH in responses, as this o Removed sentences about checking USERHASH in responses, as this
should not happen. should not happen.
o Specify that ALTERNATE-SERVER carries an IP address. o Specify that ALTERNATE-SERVER carries an IP address.
o More modifications following review... o More modifications following review...
C.5. Modifications between draft-ietf-tram-stunbis-15 and draft-ietf- C.6. Modifications between draft-ietf-tram-stunbis-15 and draft-ietf-
tram-stunbis-14 tram-stunbis-14
o Reverted the RFC 2119 boilerplate to what was in RFC 5389. o Reverted the RFC 2119 boilerplate to what was in RFC 5389.
o Reverted the V.42 reference to the 2002 version. o Reverted the V.42 reference to the 2002 version.
o Updated some references. o Updated some references.
C.6. Modifications between draft-ietf-tram-stunbis-14 and draft-ietf- C.7. Modifications between draft-ietf-tram-stunbis-14 and draft-ietf-
tram-stunbis-13 tram-stunbis-13
o Reorder the paragraphs in section 9.1.4. o Reorder the paragraphs in section 9.1.4.
o The realm is now processed through Opaque in section 9.2.2. 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 Make clear in section 9.2.4 that it is an exclusive-xor.
o Removed text that implied that nonce sharing was explicitly o Removed text that implied that nonce sharing was explicitly
permitted in RFC 5389. permitted in RFC 5389.
o In same section, s/username/value/ for USERCASH. o In same section, s/username/value/ for USERCASH.
o Modify the IANA requests to explicitly say that the reserved o Modify the IANA requests to explicitly say that the reserved
codepoints were prior to RFC 5389. codepoints were prior to RFC 5389.
C.7. Modifications between draft-ietf-tram-stunbis-13 and draft-ietf- C.8. 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.8. Modifications between draft-ietf-tram-stunbis-12 and draft-ietf- C.9. 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.9. Modifications between draft-ietf-tram-stunbis-11 and draft-ietf- C.10. 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.10. Modifications between draft-ietf-tram-stunbis-10 and draft-ietf- C.11. 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 67, line 14 skipping to change at page 67, line 20
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.11. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- C.12. 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 67, line 39 skipping to change at page 67, line 45
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.12. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf- C.13. 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.13. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf- C.14. 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.14. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf- C.15. 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.15. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- C.16. 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.16. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- C.17. 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.17. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- C.18. 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.18. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- C.19. 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 69, line 47 skipping to change at page 70, 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.19. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- C.20. 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 70, line 31 skipping to change at page 70, line 38
o Merge RFC 7064: o Merge RFC 7064:
* 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 translations for 10 minutes.
C.20. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.21. 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.21. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.22. 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 71, line 19 skipping to change at page 71, 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.22. Modifications between draft-salgueiro-tram-stunbis-01 and draft- C.23. 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. 74 change blocks. 
119 lines changed or deleted 150 lines changed or added

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