draft-ietf-tram-stunbis-20.txt   draft-ietf-tram-stunbis-21.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 Cisco
Expires: September 12, 2019 Cisco Expires: September 22, 2019 J. Rosenberg
Five9
D. Wing D. Wing
R. Mahy R. Mahy
Unaffiliated Unaffiliated
P. Matthews P. Matthews
Nokia Nokia
March 11, 2019 March 21, 2019
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-20 draft-ietf-tram-stunbis-21
Abstract Abstract
Session Traversal Utilities for NAT (STUN) is a protocol that serves Session Traversal Utilities for NAT (STUN) is a protocol that serves
as a tool for other protocols in dealing with Network Address as a tool for other protocols in dealing with Network Address
Translator (NAT) traversal. It can be used by an endpoint to Translator (NAT) traversal. It can be used by an endpoint to
determine the IP address and port allocated to it by a NAT. It can determine the IP address and port allocated to it by a NAT. It can
also be used to check connectivity between two endpoints, and as a also be used to check connectivity between two endpoints, and as a
keep-alive protocol to maintain NAT bindings. STUN works with many keep-alive protocol to maintain NAT bindings. STUN works with many
existing NATs, and does not require any special behavior from them. existing NATs, and does not require any special behavior from them.
skipping to change at page 1, line 48 skipping to change at page 2, line 4
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 September 22, 2019.
This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. STUN Message Structure . . . . . . . . . . . . . . . . . . . 10 5. STUN Message Structure . . . . . . . . . . . . . . . . . . . 10
6. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 12 6. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 12
6.1. Forming a Request or an Indication . . . . . . . . . . . 12 6.1. Forming a Request or an Indication . . . . . . . . . . . 12
6.2. Sending the Request or Indication . . . . . . . . . . . . 13 6.2. Sending the Request or Indication . . . . . . . . . . . . 13
6.2.1. Sending over UDP or DTLS-over-UDP . . . . . . . . . . 14 6.2.1. Sending over UDP or DTLS-over-UDP . . . . . . . . . . 14
6.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . 15 6.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . 15
6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP . . . . . 16 6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP . . . . . 16
6.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 17 6.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 36 skipping to change at page 3, line 38
14.13. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 46 14.13. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 46
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 . . . . . . . . . . . . . . 51
16.2.1. Attack I: Distributed DoS (DDoS) against a Target . 51 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 . . . . . . . . . . . 52
16.2.3. Attack III: Assuming the Identity of a Client . . . 51 16.2.3. Attack III: Assuming the Identity of a Client . . . 52
16.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 51 16.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 52
16.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 52 16.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 52
17. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 53 17. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 53
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
18.1. STUN Security Features Registry . . . . . . . . . . . . 53 18.1. STUN Security Features Registry . . . . . . . . . . . . 54
18.2. STUN Methods Registry . . . . . . . . . . . . . . . . . 53 18.2. STUN Methods Registry . . . . . . . . . . . . . . . . . 54
18.3. STUN Attribute Registry . . . . . . . . . . . . . . . . 54 18.3. STUN Attribute Registry . . . . . . . . . . . . . . . . 54
18.3.1. Updated Attributes . . . . . . . . . . . . . . . . . 54 18.3.1. Updated Attributes . . . . . . . . . . . . . . . . . 54
18.3.2. New Attributes . . . . . . . . . . . . . . . . . . . 54 18.3.2. New Attributes . . . . . . . . . . . . . . . . . . . 55
18.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 54 18.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 55
18.5. STUN Password Algorithm Registry . . . . . . . . . . . . 55 18.5. STUN Password Algorithm Registry . . . . . . . . . . . . 55
18.5.1. Password Algorithms . . . . . . . . . . . . . . . . 55 18.5.1. Password Algorithms . . . . . . . . . . . . . . . . 56
18.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 55 18.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 56
18.5.1.2. SHA-256 . . . . . . . . . . . . . . . . . . . . 55 18.5.1.2. SHA-256 . . . . . . . . . . . . . . . . . . . . 56
18.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 56 18.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 56
19. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 56 19. Changes Since RFC 5389 . . . . . . . . . . . . . . . . . . . 57
20. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
20.1. Normative References . . . . . . . . . . . . . . . . . . 57 20.1. Normative References . . . . . . . . . . . . . . . . . . 57
20.2. Informative References . . . . . . . . . . . . . . . . . 59 20.2. Informative References . . . . . . . . . . . . . . . . . 60
Appendix A. C Snippet to Determine STUN Message Types . . . . . 61 Appendix A. C Snippet to Determine STUN Message Types . . . . . 62
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 62 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 63
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 . . . . . . . . . . 63
Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 64 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 65
C.1. Modifications between draft-ietf-tram-stunbis-20 and C.1. Modifications between draft-ietf-tram-stunbis-21 and
draft-ietf-tram-stunbis-19 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-20 . . . . . . . . . . . . . . . 65
C.2. Modifications between draft-ietf-tram-stunbis-19 and C.2. Modifications between draft-ietf-tram-stunbis-20 and
draft-ietf-tram-stunbis-18 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-19 . . . . . . . . . . . . . . . 65
C.3. Modifications between draft-ietf-tram-stunbis-18 and C.3. Modifications between draft-ietf-tram-stunbis-19 and
draft-ietf-tram-stunbis-17 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-18 . . . . . . . . . . . . . . . 65
C.4. Modifications between draft-ietf-tram-stunbis-17 and C.4. Modifications between draft-ietf-tram-stunbis-18 and
draft-ietf-tram-stunbis-16 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-17 . . . . . . . . . . . . . . . 65
C.5. Modifications between draft-ietf-tram-stunbis-16 and C.5. Modifications between draft-ietf-tram-stunbis-17 and
draft-ietf-tram-stunbis-15 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-16 . . . . . . . . . . . . . . . 65
C.6. Modifications between draft-ietf-tram-stunbis-15 and C.6. Modifications between draft-ietf-tram-stunbis-16 and
draft-ietf-tram-stunbis-14 . . . . . . . . . . . . . . . 65 draft-ietf-tram-stunbis-15 . . . . . . . . . . . . . . . 65
C.7. Modifications between draft-ietf-tram-stunbis-14 and C.7. Modifications between draft-ietf-tram-stunbis-15 and
draft-ietf-tram-stunbis-13 . . . . . . . . . . . . . . . 65 draft-ietf-tram-stunbis-14 . . . . . . . . . . . . . . . 66
C.8. Modifications between draft-ietf-tram-stunbis-13 and C.8. Modifications between draft-ietf-tram-stunbis-14 and
draft-ietf-tram-stunbis-12 . . . . . . . . . . . . . . . 66 draft-ietf-tram-stunbis-13 . . . . . . . . . . . . . . . 66
C.9. Modifications between draft-ietf-tram-stunbis-12 and C.9. Modifications between draft-ietf-tram-stunbis-13 and
draft-ietf-tram-stunbis-11 . . . . . . . . . . . . . . . 66 draft-ietf-tram-stunbis-12 . . . . . . . . . . . . . . . 67
C.10. Modifications between draft-ietf-tram-stunbis-11 and C.10. Modifications between draft-ietf-tram-stunbis-12 and
draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 66 draft-ietf-tram-stunbis-11 . . . . . . . . . . . . . . . 67
C.11. Modifications between draft-ietf-tram-stunbis-10 and C.11. Modifications between draft-ietf-tram-stunbis-11 and
draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 66 draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 67
C.12. Modifications between draft-ietf-tram-stunbis-09 and C.12. Modifications between draft-ietf-tram-stunbis-10 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 67 draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 68
C.13. Modifications between draft-ietf-tram-stunbis-08 and C.13. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 67 draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 68
C.14. Modifications between draft-ietf-tram-stunbis-07 and C.14. Modifications between draft-ietf-tram-stunbis-08 and
draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 68 draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 69
C.15. Modifications between draft-ietf-tram-stunbis-06 and C.15. Modifications between draft-ietf-tram-stunbis-07 and
draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 68 draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 69
C.16. Modifications between draft-ietf-tram-stunbis-05 and C.16. Modifications between draft-ietf-tram-stunbis-06 and
draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 68 draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 69
C.17. Modifications between draft-ietf-tram-stunbis-04 and C.17. Modifications between draft-ietf-tram-stunbis-05 and
draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 68 draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 69
C.18. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 69
C.19. Modifications between draft-ietf-tram-stunbis-02 and C.18. Modifications between draft-ietf-tram-stunbis-04 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 69 draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 70
C.20. Modifications between draft-ietf-tram-stunbis-01 and C.19. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 70 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 70
C.21. Modifications between draft-salgueiro-tram-stunbis-02 and C.20. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 70 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 70
C.21. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 71
C.22. Modifications between draft-salgueiro-tram-stunbis-02 and C.22. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 70 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 72
C.23. Modifications between draft-salgueiro-tram-stunbis-01 and C.23. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 71 draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 72
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71 C.24. Modifications between draft-salgueiro-tram-stunbis-01 and
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 72 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 72
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
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 [RFC8445], or to relay connectivity checks between two endpoints [RFC8445], or to relay
skipping to change at page 50, line 13 skipping to change at page 50, line 13
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 Note that the bid-down protection mechanism introduced in this
document is inherently limited by the fact that it is not possible to document is inherently limited by the fact that it is not possible to
detect an attack until the server receives the second request after detect an attack until the server receives the second request after
the 401 response. SHA-256 was chosen as the new default for password the 401 response.
hashing for its compability with RFC 7616 but because SHA-256 (like
MD5) is a comparatively fast algorithm, the password can be passively SHA-256 was chosen as the new default for password hashing for its
found through brute-force mechanisms, using the MESSAGE-INTEGRITY or compatibility with [RFC7616] but because SHA-256 (like MD5) is a
MESSAGE-INTEGRITY-SHA256 from the second request. A much stronger comparatively fast algorithm, it does little to deter brute force
algorithm, like Argon2 [I-D.irtf-cfrg-argon2], would help but not attacks. Specifically, this means that if the user has a weak
until the database entry for this user is updated to exclusively use password:
that stronger mechanism. Similarly, an attack against the USERHASH
mechanism will not succeed in establishing a session as the server o An attacker who captures the server's password file can often
will detect that the feature was discarded on-path, but the client determine the user's password and thus impersonate the user to
would still have been convinced to send its username in clear in the other servers where they have used that password. Note that such
USERNAME attribute, thus disclosing it to the attacker. Finally, an attacker can impersonate the user to the server itself without
when the bid-down protection mechanism is employed for a future any brute force attack.
upgrade of the HMAC algorithm used to protect message, it will offer
only a limited protection if the current HMAC algorithm is already o An attacker who captures a single exchange can brute force the
compromised. user's password and thus potentially impersonate the user to the
server and other servers where they have used the same password.
A stronger (which is to say slower) algorithm, like Argon2
[I-D.irtf-cfrg-argon2], would help both of these cases, but in the
case of the first attack, only after until the database entry for
this user is updated to exclusively use that stronger mechanism.
The bid-down defenses in this protocol prevent an attacker from
forcing the client and server to complete a handshake using weaker
algorithms than they jointly support, but only if the weakest joint
algorithm is strong enough that it cannot be brute-forced. However,
this does not defend against many attacks on those algorithms;
specifically, an on-path attacker might perform a bid-down attack on
a client which supported both Argon2 [I-D.irtf-cfrg-argon2] and
SHA-256 for password hashing and use that to collect a MESSAGE-
INTEGRITY-SHA256 value which it uses for an offline brute-force
attack. This would be detected when the server receives the second
request, but that does not prevent the attacker from obtaining the
MESSAGE-INTEGRITY-SHA256 value.
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
skipping to change at page 56, line 15 skipping to change at page 57, line 5
18.6. STUN UDP and TCP Port Numbers 18.6. STUN UDP and TCP Port Numbers
IANA is requested to update the reference from RFC 5389 to RFC-to-be IANA is requested to update the reference from RFC 5389 to RFC-to-be
for the following ports in the Service Name and Transport Protocol for the following ports in the Service Name and Transport Protocol
Port Number Registry. Port Number Registry.
stun 3478/tcp Session Traversal Utilities for NAT (STUN) port stun 3478/tcp Session Traversal Utilities for NAT (STUN) port
stun 3478/udp Session Traversal Utilities for NAT (STUN) port stun 3478/udp Session Traversal Utilities for NAT (STUN) port
stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port
19. Changes since RFC 5389 19. Changes Since RFC 5389
This specification obsoletes [RFC5389]. This specification differs This specification obsoletes [RFC5389]. This specification differs
from RFC 5389 in the following ways: from RFC 5389 in the following ways:
o Added support for DTLS-over-UDP [RFC6347]. o Added support for DTLS-over-UDP [RFC6347].
o Made clear that the RTO is considered stale if there is no o Made clear that the RTO is considered stale if there is no
transactions with the server. transactions with the server.
o Aligned the RTO calculation with [RFC6298]. o Aligned the RTO calculation with [RFC6298].
skipping to change at page 64, line 9 skipping to change at page 65, 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-20 and draft-ietf- C.1. Modifications between draft-ietf-tram-stunbis-21 and draft-ietf-
tram-stunbis-20
o Final edits to clean up bid down protection text to address Eric
Rescorla's DISCUSS and comments.
C.2. Modifications between draft-ietf-tram-stunbis-20 and draft-ietf-
tram-stunbis-19 tram-stunbis-19
o Updates to address Eric Rescorla's DISCUSS and comments. o Updates to address Eric Rescorla's DISCUSS and comments.
o Addressed nits raised by Noriyuki Torii o Addressed nits raised by Noriyuki Torii
C.2. Modifications between draft-ietf-tram-stunbis-19 and draft-ietf- C.3. 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.3. Modifications between draft-ietf-tram-stunbis-18 and draft-ietf- C.4. Modifications between draft-ietf-tram-stunbis-18 and draft-ietf-
tram-stunbis-17 tram-stunbis-17
o Nits. o Nits.
C.4. Modifications between draft-ietf-tram-stunbis-17 and draft-ietf- C.5. 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.5. Modifications between draft-ietf-tram-stunbis-16 and draft-ietf- C.6. 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 28 skipping to change at page 66, line 33
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.6. Modifications between draft-ietf-tram-stunbis-15 and draft-ietf- C.7. 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.7. Modifications between draft-ietf-tram-stunbis-14 and draft-ietf- C.8. 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.8. Modifications between draft-ietf-tram-stunbis-13 and draft-ietf- C.9. 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.9. Modifications between draft-ietf-tram-stunbis-12 and draft-ietf- C.10. 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.10. Modifications between draft-ietf-tram-stunbis-11 and draft-ietf- C.11. 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.11. Modifications between draft-ietf-tram-stunbis-10 and draft-ietf- C.12. 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 20 skipping to change at page 68, line 28
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.12. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- C.13. 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 45 skipping to change at page 69, line 5
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.13. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf- C.14. 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.14. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf- C.15. 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.15. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf- C.16. 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.16. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- C.17. 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.17. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- C.18. 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.18. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- C.19. 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.19. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- C.20. 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 70, line 5 skipping to change at page 71, line 13
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.20. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- C.21. 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 40 skipping to change at page 72, line 5
* DNS discovery is done from the URI. * DNS discovery is done from the URI.
* Reorganized the text about default ports. * Reorganized the text about default ports.
o Add more C snippets. o Add more C snippets.
o Make clear that the cached RTO is discarded only if there is no o Make clear that the cached RTO is discarded only if there is no
new translations for 10 minutes. new translations for 10 minutes.
C.21. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.22. 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.22. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.23. 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 25 skipping to change at page 72, line 39
o Update text and reference from RFC 2988 to RFC 6298. o Update text and reference from RFC 2988 to RFC 6298.
o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o s/The IAB has mandated/The IAB has suggested/ (Errata #3737).
o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972).
o Fix section number and make clear that the original domain name is o Fix section number and make clear that the original domain name is
used for the server certificate verification. This is consistent used for the server certificate verification. This is consistent
with what RFC 5922 (section 4) is doing. (Errata #2010) with what RFC 5922 (section 4) is doing. (Errata #2010)
C.23. Modifications between draft-salgueiro-tram-stunbis-01 and draft- C.24. 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,
skipping to change at page 72, line 26 skipping to change at page 73, line 37
Gonzalo Salgueiro Gonzalo Salgueiro
Cisco Cisco
7200-12 Kit Creek Road 7200-12 Kit Creek Road
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
US US
Email: gsalguei@cisco.com Email: gsalguei@cisco.com
Jonathan Rosenberg Jonathan Rosenberg
Cisco Five9
Edison, NJ Edison, NJ
US US
Email: jdrosen@cisco.com Email: jdrosen@jdrosen.net
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Dan Wing Dan Wing
Email: dwing-ietf@fuggles.com Email: dwing-ietf@fuggles.com
Rohan Mahy Rohan Mahy
Unaffiliated Unaffiliated
Email: rohan.ietf@gmail.com Email: rohan.ietf@gmail.com
Philip Matthews Philip Matthews
Nokia Nokia
600 March Road 600 March Road
Ottawa, Ontario K2K 2T6 Ottawa, Ontario K2K 2T6
Canada Canada
Phone: 613-784-3139 Phone: 613-784-3139
Email: philip_matthews@magma.ca Email: philip_matthews@magma.ca
 End of changes. 45 change blocks. 
117 lines changed or deleted 156 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/