draft-ietf-tram-stunbis-06.txt   draft-ietf-tram-stunbis-07.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: July 31, 2016 D. Wing Expires: November 27, 2016 D. Wing
Cisco Cisco
R. Mahy R. Mahy
Plantronics Plantronics
P. Matthews P. Matthews
Avaya Avaya
January 28, 2016 May 26, 2016
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-06 draft-ietf-tram-stunbis-07
Abstract Abstract
Session Traversal Utilities for NAT (STUN) is a protocol that serves Session Traversal Utilities for NAT (STUN) is a protocol that serves
as a tool for other protocols in dealing with Network Address as a tool for other protocols in dealing with Network Address
Translator (NAT) traversal. It can be used by an endpoint to Translator (NAT) traversal. It can be used by an endpoint to
determine the IP address and port allocated to it by a NAT. It can determine the IP address and port allocated to it by a NAT. It can
also be used to check connectivity between two endpoints, and as a also be used to check connectivity between two endpoints, and as a
keep-alive protocol to maintain NAT bindings. STUN works with many keep-alive protocol to maintain NAT bindings. STUN works with many
existing NATs, and does not require any special behavior from them. existing NATs, and does not require any special behavior from them.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 31, 2016. This Internet-Draft will expire on November 27, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. STUN Message Structure . . . . . . . . . . . . . . . . . . . 9 5. STUN Message Structure . . . . . . . . . . . . . . . . . . . 10
6. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 11 6. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 12
6.1. Forming a Request or an Indication . . . . . . . . . . . 11 6.1. Forming a Request or an Indication . . . . . . . . . . . 12
6.2. Sending the Request or Indication . . . . . . . . . . . . 12 6.2. Sending the Request or Indication . . . . . . . . . . . . 13
6.2.1. Sending over UDP or DTLS-over-UDP . . . . . . . . . . 13 6.2.1. Sending over UDP or DTLS-over-UDP . . . . . . . . . . 14
6.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . 14 6.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . 15
6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP . . . . . 15 6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP . . . . . 16
6.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 16 6.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 17
6.3.1. Processing a Request . . . . . . . . . . . . . . . . 16 6.3.1. Processing a Request . . . . . . . . . . . . . . . . 17
6.3.1.1. Forming a Success or Error Response . . . . . . . 17 6.3.1.1. Forming a Success or Error Response . . . . . . . 18
6.3.1.2. Sending the Success or Error Response . . . . . . 18 6.3.1.2. Sending the Success or Error Response . . . . . . 19
6.3.2. Processing an Indication . . . . . . . . . . . . . . 18 6.3.2. Processing an Indication . . . . . . . . . . . . . . 19
6.3.3. Processing a Success Response . . . . . . . . . . . . 19 6.3.3. Processing a Success Response . . . . . . . . . . . . 20
6.3.4. Processing an Error Response . . . . . . . . . . . . 19 6.3.4. Processing an Error Response . . . . . . . . . . . . 20
7. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 20 7. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 21
8. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 20 8. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 21
8.1. STUN URI Scheme Semantics . . . . . . . . . . . . . . . . 21 8.1. STUN URI Scheme Semantics . . . . . . . . . . . . . . . . 22
9. Authentication and Message-Integrity Mechanisms . . . . . . . 22 9. Authentication and Message-Integrity Mechanisms . . . . . . . 23
9.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 22 9.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 23
9.1.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 22 9.1.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 23
9.1.2. Forming a Request or Indication . . . . . . . . . . . 23 9.1.2. Forming a Request or Indication . . . . . . . . . . . 24
9.1.3. Receiving a Request or Indication . . . . . . . . . . 23 9.1.3. Receiving a Request or Indication . . . . . . . . . . 24
9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 24 9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 25
9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 24 9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 25
9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 25 9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 26
9.2.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 26 9.2.1. Bid Down Attack Prevention . . . . . . . . . . . . . 27
9.2.2. Forming a Request . . . . . . . . . . . . . . . . . . 26 9.2.2. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 27
9.2.2.1. First Request . . . . . . . . . . . . . . . . . . 26 9.2.3. Forming a Request . . . . . . . . . . . . . . . . . . 28
9.2.2.2. Subsequent Requests . . . . . . . . . . . . . . . 27 9.2.3.1. First Request . . . . . . . . . . . . . . . . . . 28
9.2.3. Receiving a Request . . . . . . . . . . . . . . . . . 27 9.2.3.2. Subsequent Requests . . . . . . . . . . . . . . . 28
9.2.4. Receiving a Response . . . . . . . . . . . . . . . . 29 9.2.4. Receiving a Request . . . . . . . . . . . . . . . . . 29
10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 30 9.2.5. Receiving a Response . . . . . . . . . . . . . . . . 31
11. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 31 10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 32
12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 31 11. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 33
13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 33
14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 33 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 34 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 35
14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 34 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 36
14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 35 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 36
14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 36 14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 37
14.5. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 36 14.4. USERHASH . . . . . . . . . . . . . . . . . . . . . . . . 38
14.6. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 37 14.5. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 38
14.7. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 38 14.6. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 39
14.8. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 39 14.7. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 40
14.9. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 39 14.8. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 40
14.10. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 40 14.9. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 42
14.11. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 40 14.10. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 42
14.12. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 41 14.11. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 42
14.13. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 41 14.12. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 43
14.14. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 42 14.13. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 44
14.15. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 42 14.14. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 44
15. Security Considerations . . . . . . . . . . . . . . . . . . . 42 14.15. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 44
15.1. Attacks against the Protocol . . . . . . . . . . . . . . 42 14.16. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 44
15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 42 15. Security Considerations . . . . . . . . . . . . . . . . . . . 45
15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 43 15.1. Attacks against the Protocol . . . . . . . . . . . . . . 45
15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 43 15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 45
15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 44 15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 46
15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 44 15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 46
15.2.3. Attack III: Assuming the Identity of a Client . . . 45 15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 47
15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 45 15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 47
15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 45 15.2.3. Attack III: Assuming the Identity of a Client . . . 47
16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 45 15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 47
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 48
17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . 46 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 48
17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . 46 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
17.2.1. Updated Attributes . . . . . . . . . . . . . . . . . 46 17.1. STUN Security Features Registry . . . . . . . . . . . . 49
17.2.2. New Attributes . . . . . . . . . . . . . . . . . . . 47 17.2. STUN Methods Registry . . . . . . . . . . . . . . . . . 49
17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 47 17.3. STUN Attribute Registry . . . . . . . . . . . . . . . . 49
17.4. Password Algorithm Registry . . . . . . . . . . . . . . 47 17.3.1. Updated Attributes . . . . . . . . . . . . . . . . . 49
17.4.1. Password Algorithms . . . . . . . . . . . . . . . . 48 17.3.2. New Attributes . . . . . . . . . . . . . . . . . . . 50
17.4.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 48 17.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 50
17.4.1.2. SHA256 . . . . . . . . . . . . . . . . . . . . . 48 17.5. Password Algorithm Registry . . . . . . . . . . . . . . 50
17.5. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 48 17.5.1. Password Algorithms . . . . . . . . . . . . . . . . 51
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 48 17.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 51
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 17.5.1.2. SHA256 . . . . . . . . . . . . . . . . . . . . . 51
19.1. Normative References . . . . . . . . . . . . . . . . . . 49
19.2. Informational References . . . . . . . . . . . . . . . . 50 17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 51
Appendix A. C Snippet to Determine STUN Message Types . . . . . 52 18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 51
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 53 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
19.1. Normative References . . . . . . . . . . . . . . . . . . 52
19.2. Informational References . . . . . . . . . . . . . . . . 53
Appendix A. C Snippet to Determine STUN Message Types . . . . . 55
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 56
B.1. Sample Request with Long-Term Authentication with B.1. Sample Request with Long-Term Authentication with
MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 53 MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 56
Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 54 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 57
C.1. Modifications between draft-ietf-tram-stunbis-06 and C.1. Modifications between draft-ietf-tram-stunbis-07 and
draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 54 draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 57
C.2. Modifications between draft-ietf-tram-stunbis-05 and C.2. Modifications between draft-ietf-tram-stunbis-06 and
draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 55 draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 58
C.3. Modifications between draft-ietf-tram-stunbis-04 and C.3. Modifications between draft-ietf-tram-stunbis-05 and
draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 55 draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 58
C.4. Modifications between draft-ietf-tram-stunbis-03 and C.4. Modifications between draft-ietf-tram-stunbis-04 and
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 55 draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 58
C.5. Modifications between draft-ietf-tram-stunbis-02 and C.5. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 55 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 58
C.6. Modifications between draft-ietf-tram-stunbis-01 and C.6. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 56 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 59
C.7. Modifications between draft-salgueiro-tram-stunbis-02 and C.7. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 57 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 59
C.8. Modifications between draft-salgueiro-tram-stunbis-02 and C.8. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 57 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 60
C.9. Modifications between draft-salgueiro-tram-stunbis-01 and C.9. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 57 draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 60
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 58 C.10. Modifications between draft-salgueiro-tram-stunbis-01 and
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 58 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 61
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61
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 connectivity checks between two endpoints
skipping to change at page 10, line 37 skipping to change at page 11, line 32
each method, a request, success response, error response, and each method, a request, success response, error response, and
indication are possible for that method. Extensions defining new indication are possible for that method. Extensions defining new
methods MUST indicate which classes are permitted for that method. methods MUST indicate which classes are permitted for that method.
For example, a Binding request has class=0b00 (request) and For example, a Binding request has class=0b00 (request) and
method=0b000000000001 (Binding) and is encoded into the first 16 bits method=0b000000000001 (Binding) and is encoded into the first 16 bits
as 0x0001. A Binding response has class=0b10 (success response) and as 0x0001. A Binding response has class=0b10 (success response) and
method=0b000000000001, and is encoded into the first 16 bits as method=0b000000000001, and is encoded into the first 16 bits as
0x0101. 0x0101.
Note: This unfortunate encoding is due to assignment of values in NOTE: This unfortunate encoding is due to assignment of values in
[RFC3489] that did not consider encoding Indications, Success, and [RFC3489] that did not consider encoding Indications, Success, and
Errors using bit fields. Errors using bit fields.
The magic cookie field MUST contain the fixed value 0x2112A442 in The magic cookie field MUST contain the fixed value 0x2112A442 in
network byte order. In RFC 3489 [RFC3489], this field was part of network byte order. In RFC 3489 [RFC3489], this field was part of
the transaction ID; placing the magic cookie in this location allows the transaction ID; placing the magic cookie in this location allows
a server to detect if the client will understand certain attributes a server to detect if the client will understand certain attributes
that were added in this revised specification. In addition, it aids that were added in this revised specification. In addition, it aids
in distinguishing STUN packets from packets of other protocols when in distinguishing STUN packets from packets of other protocols when
STUN is multiplexed with those other protocols on the same port. STUN is multiplexed with those other protocols on the same port.
skipping to change at page 20, line 25 skipping to change at page 21, line 25
address as other protocols, such as the Real Time Transport Protocol address as other protocols, such as the Real Time Transport Protocol
(RTP). In order to apply the processing described in Section 6, STUN (RTP). In order to apply the processing described in Section 6, STUN
messages must first be separated from the application packets. messages must first be separated from the application packets.
Section 5 describes three fixed fields in the STUN header that can be Section 5 describes three fixed fields in the STUN header that can be
used for this purpose. However, in some cases, these three fixed used for this purpose. However, in some cases, these three fixed
fields may not be sufficient. fields may not be sufficient.
When the FINGERPRINT extension is used, an agent includes the When the FINGERPRINT extension is used, an agent includes the
FINGERPRINT attribute in messages it sends to another agent. FINGERPRINT attribute in messages it sends to another agent.
Section 14.6 describes the placement and value of this attribute. Section 14.7 describes the placement and value of this attribute.
When the agent receives what it believes is a STUN message, then, in When the agent receives what it believes is a STUN message, then, in
addition to other basic checks, the agent also checks that the addition to other basic checks, the agent also checks that the
message contains a FINGERPRINT attribute and that the attribute message contains a FINGERPRINT attribute and that the attribute
contains the correct value. Section 6.3 describes when in the contains the correct value. Section 6.3 describes when in the
overall processing of a STUN message the FINGERPRINT check is overall processing of a STUN message the FINGERPRINT check is
performed. This additional check helps the agent detect messages of performed. This additional check helps the agent detect messages of
other protocols that might otherwise seem to be STUN messages. other protocols that might otherwise seem to be STUN messages.
8. DNS Discovery of a Server 8. DNS Discovery of a Server
skipping to change at page 23, line 13 skipping to change at page 24, line 13
where the OpaqueString profile is defined in [RFC7613]. where the OpaqueString profile is defined in [RFC7613].
9.1.2. Forming a Request or Indication 9.1.2. Forming a Request or Indication
For a request or indication message, the agent MUST include the For a request or indication message, the agent MUST include the
USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attributes USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attributes
in the message unless the agent knows from an external indication in the message unless the agent knows from an external indication
which message integrity algorithm is supported by both agents. In which message integrity algorithm is supported by both agents. In
this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST
be included in addition to USERNAME. The HMAC for the MESSAGE- be included in addition to USERNAME. The HMAC for the MESSAGE-
INTEGRITY attribute is computed as described in Section 14.4 and the INTEGRITY attribute is computed as described in Section 14.5 and the
HMAC for the MESSAGE-INTEGRITY-SHA256 attributes is computed as HMAC for the MESSAGE-INTEGRITY-SHA256 attributes is computed as
described in Section 14.5. Note that the password is never included described in Section 14.6. Note that the password is never included
in the request or indication. in the request or indication.
9.1.3. Receiving a Request or Indication 9.1.3. Receiving a Request or Indication
After the agent has done the basic processing of a message, the agent After the agent has done the basic processing of a message, the agent
performs the checks listed below in order specified: performs the checks listed below in order specified:
o If the message does not contain 1) a MESSAGE-INTEGRITY or a o If the message does not contain 1) a MESSAGE-INTEGRITY or a
MESSAGE-INTEGRITY-SHA256 attribute and 2) a USERNAME attribute: MESSAGE-INTEGRITY-SHA256 attribute and 2) a USERNAME attribute:
skipping to change at page 23, line 44 skipping to change at page 24, line 44
within the server: within the server:
* If the message is a request, the server MUST reject the request * If the message is a request, the server MUST reject the request
with an error response. This response MUST use an error code with an error response. This response MUST use an error code
of 401 (Unauthorized). of 401 (Unauthorized).
* If the message is an indication, the agent MUST silently * If the message is an indication, the agent MUST silently
discard the indication. discard the indication.
o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the
value for the message integrity as described in Section 14.5, value for the message integrity as described in Section 14.6,
using the password associated with the username. If the MESSAGE- using the password associated with the username. If the MESSAGE-
INTEGRITY-SHA256 attribute is not present, and using the same INTEGRITY-SHA256 attribute is not present, and using the same
password, compute the value for the message integrity as described password, compute the value for the message integrity as described
in Section 14.4. If the resulting value does not match the in Section 14.5. If the resulting value does not match the
contents of the corresponding attribute (MESSAGE-INTEGRITY-SHA256 contents of the corresponding attribute (MESSAGE-INTEGRITY-SHA256
or MESSAGE-INTEGRITY): or MESSAGE-INTEGRITY):
* If the message is a request, the server MUST reject the request * If the message is a request, the server MUST reject the request
with an error response. This response MUST use an error code with an error response. This response MUST use an error code
of 401 (Unauthorized). of 401 (Unauthorized).
* If the message is an indication, the agent MUST silently * If the message is an indication, the agent MUST silently
discard the indication. discard the indication.
skipping to change at page 24, line 33 skipping to change at page 25, line 33
If any of the checks fail, a server MUST NOT include a MESSAGE- If any of the checks fail, a server MUST NOT include a MESSAGE-
INTEGRITY-SHA256, MESSAGE-INTEGRITY, or USERNAME attribute in the INTEGRITY-SHA256, MESSAGE-INTEGRITY, or USERNAME attribute in the
error response. This is because, in these failure cases, the server error response. This is because, in these failure cases, the server
cannot determine the shared secret necessary to compute the MESSAGE- cannot determine the shared secret necessary to compute the MESSAGE-
INTEGRITY-SHA256 or MESSAGE-INTEGRITY attributes. INTEGRITY-SHA256 or MESSAGE-INTEGRITY attributes.
9.1.4. Receiving a Response 9.1.4. Receiving a Response
The client looks for the MESSAGE-INTEGRITY or the MESSAGE-INTEGRITY- The client looks for the MESSAGE-INTEGRITY or the MESSAGE-INTEGRITY-
SHA256 attribute in the response. If present, the client computes SHA256 attribute in the response. If present, the client computes
the message integrity over the response as defined in Section 14.4 or the message integrity over the response as defined in Section 14.5 or
Section 14.5, respectively, using the same password it utilized for Section 14.6, respectively, using the same password it utilized for
the request. If the resulting value matches the contents of the the request. If the resulting value matches the contents of the
MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute,
respectively, the response is considered authenticated. If the value respectively, 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 response MUST be discarded, as if it was SHA256 were absent, the response MUST be discarded, as if it was
never received. This means that retransmits, if applicable, will never received. This means that retransmits, if applicable, will
continue. continue.
If the client only sent one algorithm in the request (because of the If the client only sent one algorithm in the request (because of the
external indication in section Section 9.2.2, or this being a external indication in section Section 9.2.3, or this being a
subsequent request as defined in Section 9.1.5) the algorithm in the subsequent request as defined in Section 9.1.5) the algorithm in the
response has to match otherwise the response MUST be discarded. response has to match otherwise the response MUST be discarded.
9.1.5. Sending Subsequent Requests 9.1.5. Sending Subsequent Requests
A client sending subsequent requests to the same server MAY choose to A client sending subsequent requests to the same server MAY choose to
send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY
attribute depending upon the attribute that was received in the attribute depending upon the attribute that was received in the
response to the initial request. Here same server means same IP response to the initial request. Here same server means same IP
address and port number, not just the same URL or SRV lookup result. address and port number, not just the same URL or SRV lookup result.
skipping to change at page 26, line 5 skipping to change at page 27, line 5
authentication and message integrity for them. authentication and message integrity for them.
Since the long-term credential mechanism is susceptible to offline Since the long-term credential mechanism is susceptible to offline
dictionary attacks, deployments SHOULD utilize passwords that are dictionary attacks, deployments SHOULD utilize passwords that are
difficult to guess. In cases where the credentials are not entered difficult to guess. In cases where the credentials are not entered
by the user, but are rather placed on a client device during device by the user, but are rather placed on a client device during device
provisioning, the password SHOULD have at least 128 bits of provisioning, the password SHOULD have at least 128 bits of
randomness. In cases where the credentials are entered by the user, randomness. In cases where the credentials are entered by the user,
they should follow best current practices around password structure. they should follow best current practices around password structure.
9.2.1. HMAC Key 9.2.1. Bid Down Attack Prevention
This document introduces two new security features that provide the
ability to choose the algorithm used for password protection as well
as the ability to use an anonymous username. Both of these
capabilities are optional in order to remain backwards compatible
with previous versions of the STUN protocol.
These new capabilities are subject to bid down attacks whereby an
attacker in the message path can remove these capabilities and force
weaker security properties. To prevent these kinds of attacks from
going undetected, the nonce is enhanced with additional information.
If the server uses one of the security features subject to bid down
attack protection it MUST prepend the NONCE attribute value with the
character string composed of "obMatJos2" concatenated with the Base64
encoding of the 24 bit STUN Security Features as defined in
Section 17.1. The 24 bit Security Feature set is encoded as a 24 bit
integer in network order. For the remainder of this document the
term "nonce cookie" will refer to the complete 13 character string
prepended to the NONCE attribute value.
The value of the "nonce cookie" will vary based on the specific STUN
Security Features bit values selected. When this document makes
reference to the "nonce cookie" in a section discussing a specific
STUN Security Feature it is understood that the corresponding STUN
Security Feature bit in the "nonce cookie" is set to 1.
For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS
security feature, it is implied that the "Password algorithms" bit,
as defined in Section 17.1, is set to 1 in the "nonce cookie".
9.2.2. HMAC Key
For long-term credentials that do not use a different algorithm, as For long-term credentials that do not use a different algorithm, as
specified by the PASSWORD-ALGORITHM attribute, the key is 16 bytes: specified by the PASSWORD-ALGORITHM attribute, the key is 16 bytes:
key = MD5(username ":" realm ":" OpaqueString(password)) key = MD5(username ":" realm ":" OpaqueString(password))
Where MD5 is defined in RFC 1321 [RFC1321] and the OpaqueString Where MD5 is defined in RFC 1321 [RFC1321] and the OpaqueString
profile is defined in [RFC7613]. profile is defined in [RFC7613].
The 16-byte key is formed by taking the MD5 hash of the result of The 16-byte key is formed by taking the MD5 hash of the result of
skipping to change at page 26, line 34 skipping to change at page 28, line 17
performing an MD5 hash on the string 'user:realm:pass', the resulting performing an MD5 hash on the string 'user:realm:pass', the resulting
hash being 0x8493fbc53ba582fb4c044c456bdc40eb. hash being 0x8493fbc53ba582fb4c044c456bdc40eb.
The structure of the key when used with long-term credentials The structure of the key when used with long-term credentials
facilitates deployment in systems that also utilize SIP. Typically, facilitates deployment in systems that also utilize SIP. Typically,
SIP systems utilizing SIP's digest authentication mechanism do not SIP systems utilizing SIP's digest authentication mechanism do not
actually store the password in the database. Rather, they store a actually store the password in the database. Rather, they store a
value called H(A1), which is equal to the key defined above. value called H(A1), which is equal to the key defined above.
When a PASSWORD-ALGORITHM is used, the key length and algorithm to When a PASSWORD-ALGORITHM is used, the key length and algorithm to
use are described in Section 17.4.1. use are described in Section 17.5.1.
9.2.2. Forming a Request 9.2.3. Forming a Request
There are two cases when forming a request. In the first case, this There are two cases when forming a request. In the first case, this
is the first request from the client to the server (as identified by is the first request from the client to the server (as identified by
its IP address and port). In the second case, the client is its IP address and port). In the second case, the client is
submitting a subsequent request once a previous request/response submitting a subsequent request once a previous request/response
transaction has completed successfully. Forming a request as a transaction has completed successfully. Forming a request as a
consequence of a 401 or 438 error response is covered in consequence of a 401 or 438 error response is covered in
Section 9.2.4 and is not considered a "subsequent request" and thus Section 9.2.5 and is not considered a "subsequent request" and thus
does not utilize the rules described in Section 9.2.2.2. does not utilize the rules described in Section 9.2.3.2.
9.2.2.1. First Request 9.2.3.1. First Request
If the client has not completed a successful request/response If the client has not completed a successful request/response
transaction with the server (as identified by hostname, if the DNS transaction with the server (as identified by hostname, if the DNS
procedures of Section 8 are used, else IP address if not), it SHOULD procedures of Section 8 are used, else IP address if not), it SHOULD
omit the USERNAME, MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256, omit the USERNAME, USERHASH, MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-
REALM, NONCE, PASSWORD-ALGORITHMS, and PASSWORD-ALGORITHM attributes. SHA256, REALM, NONCE, PASSWORD-ALGORITHMS, and PASSWORD-ALGORITHM
In other words, the very first request is sent as if there were no attributes. In other words, the very first request is sent as if
authentication or message integrity applied. there were no authentication or message integrity applied.
9.2.2.2. Subsequent Requests 9.2.3.2. Subsequent Requests
Once a request/response transaction has completed successfully, the Once a request/response transaction has completed successfully, the
client will have been presented a realm and nonce by the server, and client will have been presented a realm and nonce by the server, and
selected a username and password with which it authenticated. The selected a username and password with which it authenticated. The
client SHOULD cache the username, password, realm, and nonce for client SHOULD cache the username, password, realm, and nonce for
subsequent communications with the server. When the client sends a subsequent communications with the server. When the client sends a
subsequent request, it SHOULD include the USERNAME, REALM, NONCE, and subsequent request, it SHOULD include either the USERNAME or
PASSWORD-ALGORITHM attributes with these cached values. It SHOULD USERHASH, REALM, NONCE, and PASSWORD-ALGORITHM attributes with these
include a MESSAGE-INTEGRITY attribute or a MESSAGE-INTEGRITY-SHA256 cached values. It SHOULD include a MESSAGE-INTEGRITY attribute or a
attribute, computed as described in Section 14.4 and Section 14.5 MESSAGE-INTEGRITY-SHA256 attribute, computed as described in
using the cached password. The choice between the two attributes Section 14.5 and Section 14.6 using the cached password. The choice
depends on the attribute received in the response to the first between the two attributes depends on the attribute received in the
request. response to the first request.
9.2.3. Receiving a Request 9.2.4. Receiving a Request
After the server has done the basic processing of a request, it After the server has done the basic processing of a request, it
performs the checks listed below in the order specified: performs the checks listed below in the order specified:
o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE- o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY-SHA256 attribute, the server MUST generate an error INTEGRITY-SHA256 attribute, the server MUST generate an error
response with an error code of 401 (Unauthorized). This response response with an error code of 401 (Unauthorized). This response
MUST include a REALM value. It is RECOMMENDED that the REALM MUST include a REALM value. It is RECOMMENDED that the REALM
value be the domain name of the provider of the STUN server. The value be the domain name of the provider of the STUN server. The
response MUST include a NONCE, selected by the server. The server response MUST include a NONCE, selected by the server. The server
MUST ensure that the same NONCE cannot be selected for clients MUST ensure that the same NONCE cannot be selected for clients
that use different IP addresses and/or different ports. The that use different IP addresses and/or different ports. The
server MAY support alternate password algorithms, in which case it server MAY support alternate password algorithms, in which case it
can list them in preferential order in a PASSWORD-ALGORITHMS can list them in preferential order in a PASSWORD-ALGORITHMS
attribute. If the server adds a PASSWORD-ALGORITHMS attribute it attribute. If the server adds a PASSWORD-ALGORITHMS attribute it
MUST prepend the NONCE attribute value with the character string MUST prepend the NONCE attribute value with the "nonce cookie".
"obMatJos2". The response SHOULD NOT contain a USERNAME, MESSAGE- The server MAY support anonymous username, in which case it can
INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute. The "obMatJos2" prepend the NONCE attribute value with the "nonce cookie" that has
prefix is used to prevent bid down attacks on the password the STUN Security Feature "Anonymous username" bit set to 1. The
algorithm's negotiation. response SHOULD NOT contain a USERNAME, USERHASH, MESSAGE-
INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute.
Note that sharing a NONCE is no longer permitted, so trying to NOTE: Note that sharing a NONCE is no longer permitted, so trying to
share one will result in a wasted transaction. share one will result in a wasted transaction.
o If the message contains a MESSAGE-INTEGRITY or a MESSAGE- o If the message contains a MESSAGE-INTEGRITY or a MESSAGE-
INTEGRITY-SHA256 attribute, but is missing the USERNAME, REALM, or INTEGRITY-SHA256 attribute, but is missing either the USERNAME or
NONCE attribute, the server MUST generate an error response with USERHASH, REALM, or NONCE attribute, the server MUST generate an
an error code of 400 (Bad Request). This response SHOULD NOT error response with an error code of 400 (Bad Request). This
include a USERNAME, NONCE, REALM, MESSAGE-INTEGRITY or MESSAGE- response SHOULD NOT include a USERNAME, USERHASH, NONCE, REALM,
INTEGRITY-SHA256 attribute. MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute.
o If the NONCE attribute starts with the value "obMatJos2" but o If the NONCE attribute starts with the "nonce cookie" with the
STUN Security Feature "Password algorithm" bit set to 1 but
PASSWORD-ALGORITHMS does not match the value sent in the response PASSWORD-ALGORITHMS does not match the value sent in the response
that sent this NONCE, then the server MUST generate an error that sent this NONCE, then the server MUST generate an error
response with an error code of 400 (Bad Request). response with an error code of 400 (Bad Request).
o If the NONCE attribute starts with the value "obMatJos2" but the o If the NONCE attribute starts with the "nonce cookie" with the
STUN Security Feature "Password algorithm" bit set to 1 but the
request contains neither PASSWORD-ALGORITHMS nor PASSWORD- request contains neither PASSWORD-ALGORITHMS nor PASSWORD-
ALGORITHM, then the request is processed as though PASSWORD- ALGORITHM, then the request is processed as though PASSWORD-
ALGORITHM were MD5 (Note that if the original PASSWORD-ALGORITHMS ALGORITHM were MD5 (Note that if the original PASSWORD-ALGORITHMS
attribute did not contain MD5, this will result in a 400 Bad attribute did not contain MD5, this will result in a 400 Bad
Request in a later step below). Request in a later step below).
o If the NONCE attribute starts with the value "obMatJos2" but only o If the NONCE attribute starts with the "nonce cookie" with the
STUN Security Feature "Password algorithm" bit set to 1 but only
one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is present, then one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is present, then
the server MUST generate an error response with an error code of the server MUST generate an error response with an error code of
400 (Bad Request). 400 (Bad Request).
o If the NONCE attribute starts with the value "obMatJos2" but o If the NONCE attribute starts with the "nonce cookie" with the
STUN Security Feature "Password algorithm" bit set to 1 but
PASSWORD-ALGORITHM does not match one of the entries in PASSWORD- PASSWORD-ALGORITHM does not match one of the entries in PASSWORD-
ALGORITHMS, then the server MUST generate an error response with ALGORITHMS, then the server MUST generate an error response with
an error code of 400 (Bad Request). an error code of 400 (Bad Request).
o If the NONCE is no longer valid, the server MUST generate an error o If the NONCE is no longer valid, the server MUST generate an error
response with an error code of 438 (Stale Nonce). This response response with an error code of 438 (Stale Nonce). This response
MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and
SHOULD NOT include the USERNAME, MESSAGE-INTEGRITY, or MESSAGE- SHOULD NOT include the USERNAME, USERHASH, MESSAGE-INTEGRITY, or
INTEGRITY-SHA256 attribute. Servers can invalidate nonces in MESSAGE-INTEGRITY-SHA256 attribute. Servers can invalidate nonces
order to provide additional security. See Section 4.3 of in order to provide additional security. See Section 4.3 of
[RFC2617] for guidelines. [RFC2617] for guidelines.
o If the username in the USERNAME attribute is not valid, the server o If the username in the USERNAME or USERHASH attribute is not
MUST generate an error response with an error code of 401 valid, the server MUST generate an error response with an error
(Unauthorized). This response MUST include a REALM value. It is code of 401 (Unauthorized). This response MUST include a REALM
RECOMMENDED that the REALM value be the domain name of the value. It is RECOMMENDED that the REALM value be the domain name
provider of the STUN server. The response MUST include a NONCE, of the provider of the STUN server. The response MUST include a
selected by the server. The response MUST include a PASSWORD- NONCE, selected by the server. The response MUST include a
ALGORITHMS attribute. The response SHOULD NOT contain a USERNAME, PASSWORD-ALGORITHMS attribute. The response SHOULD NOT contain a
MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute. USERNAME, USERHASH, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
attribute.
o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the
value for the message integrity as described in Section 14.5, value for the message integrity as described in Section 14.6,
using the password associated with the username. Else, using the using the password associated with the username. Else, using the
same password, compute the value for the message integrity as same password, compute the value for the message integrity as
described in Section 14.4. If the resulting value does not match described in Section 14.5. If the resulting value does not match
the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE- the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE-
INTEGRITY-SHA256 attribute, the server MUST reject the request INTEGRITY-SHA256 attribute, the server MUST reject the request
with an error response. This response MUST use an error code of with an error response. This response MUST use an error code of
401 (Unauthorized). It MUST include REALM and NONCE attributes 401 (Unauthorized). It MUST include REALM and NONCE attributes
and SHOULD NOT include the USERNAME, MESSAGE-INTEGRITY, or and SHOULD NOT include the USERNAME, USERHASH, MESSAGE-INTEGRITY,
MESSAGE-INTEGRITY-SHA256 attribute. or MESSAGE-INTEGRITY-SHA256 attribute.
For the responses sent by the steps above, the MESSAGE-INTEGRITY- For the responses sent by the steps above, the MESSAGE-INTEGRITY-
SHA256 attribute cannot be added. SHA256 attribute cannot be added.
If these checks pass, the server continues to process the request. If these checks pass, the server continues to process the request.
Any response generated by the server MUST include MESSAGE-INTEGRITY- Any response generated by the server MUST include MESSAGE-INTEGRITY-
SHA256 attribute, computed using the username and password utilized SHA256 attribute, computed using the username and password utilized
to authenticate the request, unless the request was processed as to authenticate the request, unless the request was processed as
though PASSWORD-ALGORITHM was MD5 (because the request contained though PASSWORD-ALGORITHM was MD5 (because the request contained
neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM). In that case neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM). In that case
the MESSAGE-INTEGRITY attribute MUST be used instead of the MESSAGE- the MESSAGE-INTEGRITY attribute MUST be used instead of the MESSAGE-
INTEGRITY-SHA256 attribute. The REALM, NONCE, and USERNAME INTEGRITY-SHA256 attribute. The REALM, NONCE, USERNAME and USERHASH
attributes SHOULD NOT be included. attributes SHOULD NOT be included.
9.2.4. Receiving a Response 9.2.5. Receiving a Response
If the response is an error response with an error code of 401 If the response is an error response with an error code of 401
(Unauthorized) or 438 (Stale Nonce), the client MUST test if the (Unauthorized) or 438 (Stale Nonce), the client MUST test if the
NONCE attribute value starts with the character string "obMatJos2". NONCE attribute value starts with the "nonce cookie". If the test
If the test succeeds and no PASSWORD-ALGORITHMS attribute is present, succeeds and the "nonce cookie" has the STUN Security Feature
then the client MUST NOT retry the request with a new transaction. "Password algorithm" bit set to 1 but no PASSWORD-ALGORITHMS
attribute is present, then the client MUST NOT retry the request with
a new transaction. If the test succeeds and the "nonce cookie" has
the STUN Security Feature "Username anonymity" bit set to 1 but no
USERHASH attribute is present, then the client MUST NOT retry the
request with a new transaction.
If the response is an error response with an error code of 401 If the response is an error response with an error code of 401
(Unauthorized), the client SHOULD retry the request with a new (Unauthorized), the client SHOULD retry the request with a new
transaction. This request MUST contain a USERNAME, determined by the transaction. This request MUST contain a USERNAME or a USERHASH,
client as the appropriate username for the REALM from the error determined by the client as the appropriate username for the REALM
response. The request MUST contain the REALM, copied from the error from the error response. If the "nonce cookie" was present and had
the STUN Security Feature "Username anonymity" bit set to 1 then the
USERHASH attribute MUST be used, else the USERNAME attribute MUST be
used. The request MUST contain the REALM, copied from the error
response. The request MUST contain the NONCE, copied from the error response. The request MUST contain the NONCE, copied from the error
response. If the response contains a PASSWORD-ALGORITHMS attribute, response. If the response contains a PASSWORD-ALGORITHMS attribute,
the request MUST contain the PASSWORD-ALGORITHMS attribute with the the request MUST contain the PASSWORD-ALGORITHMS attribute with the
same content. If the response contains a PASSWORD-ALGORITHMS same content. If the response contains a PASSWORD-ALGORITHMS
attribute, and this attribute contains at least one algorithm that is attribute, and this attribute contains at least one algorithm that is
supported by the client then the request MUST contain a PASSWORD- supported by the client then the request MUST contain a PASSWORD-
ALGORITHM attribute with the first algorithm supported on the list. ALGORITHM attribute with the first algorithm supported on the list.
If the response contains a PASSWORD-ALGORITHMS attribute, and this If the response contains a PASSWORD-ALGORITHMS attribute, and this
attribute does not contain any algorithm that is supported by the attribute does not contain any algorithm that is supported by the
client, then the client MUST NOT retry the request with a new client, then the client MUST NOT retry the request with a new
transaction. The client MUST NOT perform this retry if it is not transaction. The client MUST NOT perform this retry if it is not
changing the USERNAME or REALM or its associated password, from the changing the USERNAME or USERHASH or REALM or its associated
previous attempt. password, from the previous attempt.
If the response is an error response with an error code of 438 (Stale If the response is an error response with an error code of 438 (Stale
Nonce), the client MUST retry the request, using the new NONCE Nonce), the client MUST retry the request, using the new NONCE
attribute supplied in the 438 (Stale Nonce) response. This retry attribute supplied in the 438 (Stale Nonce) response. This retry
MUST also include the USERNAME, REALM and either the MESSAGE- MUST also include either the USERNAME or USERHASH, REALM and either
INTEGRITY or MESSAGE-INTEGRITY-SHA256 attributes. the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attributes.
For all other responses, if the NONCE attribute starts with the value For all other responses, if the NONCE attribute starts with the
"obMatJos2" but PASSWORD-ALGORITHMS is not present, the response MUST "nonce cookie" with the STUN Security Feature "Password algorithm"
be ignored. bit set to 1 but PASSWORD-ALGORITHMS is not present, the response
MUST be ignored. For all other responses, if the NONCE attribute
starts with the "nonce cookie" with the STUN Security Feature "User
anonymity" bit set to 1 but USERHASH is not present, the response
MUST be ignored.
The client looks for the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY- The client looks for the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-
SHA256 attribute in the response (either success or failure). If SHA256 attribute in the response (either success or failure). If
present, the client computes the message integrity over the response present, the client computes the message integrity over the response
as defined in Section 14.4 or Section 14.5, 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 response MUST be discarded, as if it was SHA256 were absent, the response MUST be discarded, as if it was
never received. This means that retransmits, if applicable, will never received. This means that retransmits, if applicable, will
continue. continue.
If the response contains a PASSWORD-ALGORITHMS attribute, the If the response contains a PASSWORD-ALGORITHMS attribute, the
subsequent request MUST be authenticated using MESSAGE-INTEGRITY- subsequent request MUST be authenticated using MESSAGE-INTEGRITY-
skipping to change at page 33, line 47 skipping to change at page 35, line 47
To allow future revisions of this specification to add new attributes To allow future revisions of this specification to add new attributes
if needed, the attribute space is divided into two ranges. if needed, the attribute space is divided into two ranges.
Attributes with type values between 0x0000 and 0x7FFF are Attributes with type values between 0x0000 and 0x7FFF are
comprehension-required attributes, which means that the STUN agent comprehension-required attributes, which means that the STUN agent
cannot successfully process the message unless it understands the cannot successfully process the message unless it understands the
attribute. Attributes with type values between 0x8000 and 0xFFFF are attribute. Attributes with type values between 0x8000 and 0xFFFF are
comprehension-optional attributes, which means that those attributes comprehension-optional attributes, which means that those attributes
can be ignored by the STUN agent if it does not understand them. can be ignored by the STUN agent if it does not understand them.
The set of STUN attribute types is maintained by IANA. The initial The set of STUN attribute types is maintained by IANA. The initial
set defined by this specification is found in Section 17.2. set defined by this specification is found in Section 17.3.
The rest of this section describes the format of the various The rest of this section describes the format of the various
attributes defined in this specification. attributes defined in this specification.
14.1. MAPPED-ADDRESS 14.1. MAPPED-ADDRESS
The MAPPED-ADDRESS attribute indicates a reflexive transport address The MAPPED-ADDRESS attribute indicates a reflexive transport address
of the client. It consists of an 8-bit address family and a 16-bit of the client. It consists of an 8-bit address family and a 16-bit
port, followed by a fixed-length value representing the IP address. port, followed by a fixed-length value representing the IP address.
If the address family is IPv4, the address MUST be 32 bits. If the If the address family is IPv4, the address MUST be 32 bits. If the
skipping to change at page 35, line 7 skipping to change at page 37, line 5
compatibility with RFC 3489 [RFC3489] clients. compatibility with RFC 3489 [RFC3489] clients.
14.2. XOR-MAPPED-ADDRESS 14.2. XOR-MAPPED-ADDRESS
The XOR-MAPPED-ADDRESS attribute is identical to the MAPPED-ADDRESS The XOR-MAPPED-ADDRESS attribute is identical to the MAPPED-ADDRESS
attribute, except that the reflexive transport address is obfuscated attribute, except that the reflexive transport address is obfuscated
through the XOR function. through the XOR function.
The format of the XOR-MAPPED-ADDRESS is: The format of the XOR-MAPPED-ADDRESS is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0| Family | X-Port | |0 0 0 0 0 0 0 0| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (Variable) | X-Address (Variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of XOR-MAPPED-ADDRESS Attribute Figure 6: Format of XOR-MAPPED-ADDRESS Attribute
The Family represents the IP address family, and is encoded The Family represents the IP address family, and is encoded
identically to the Family in MAPPED-ADDRESS. identically to the Family in MAPPED-ADDRESS.
X-Port is computed by taking the mapped port in host byte order, X-Port is computed by taking the mapped port in host byte order,
XOR'ing it with the most significant 16 bits of the magic cookie, and 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 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 family is IPv4, X-Address is computed by taking the mapped IP
skipping to change at page 36, line 9 skipping to change at page 38, line 9
14.3. USERNAME 14.3. USERNAME
The USERNAME attribute is used for message integrity. It identifies The USERNAME attribute is used for message integrity. It identifies
the username and password combination used in the message-integrity the username and password combination used in the message-integrity
check. check.
The value of USERNAME is a variable-length value. It MUST contain a The value of USERNAME is a variable-length value. It MUST contain a
UTF-8 [RFC3629] encoded sequence of less than 513 bytes, and MUST UTF-8 [RFC3629] encoded sequence of less than 513 bytes, and MUST
have been processed using the OpaqueString profile [RFC7613]. have been processed using the OpaqueString profile [RFC7613].
14.4. MESSAGE-INTEGRITY 14.4. USERHASH
The USERHASH attribute is used as a replacement for the USERNAME
attribute when username anonymity is supported.
The value of USERHASH is a variable-length value. It MUST contain a
UTF-8 [RFC3629] encoded sequence of less than 513 bytes. The
username MUST have been processed using the OpaqueString profile
[RFC7613] before hashing.
The following is the operation that the client will perform to hash
the username:
userhash = SHA256(username ":" realm)
14.5. MESSAGE-INTEGRITY
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of
the STUN message. The MESSAGE-INTEGRITY attribute can be present in the STUN message. The MESSAGE-INTEGRITY attribute can be present in
any STUN message type. Since it uses the SHA1 hash, the HMAC will be any STUN message type. Since it uses the SHA1 hash, the HMAC will be
20 bytes. The text used as input to HMAC is the STUN message, at most 20 bytes. The HMAC MUST NOT be truncated below a minimum
including the header, up to and including the attribute preceding the size of XX. If truncation is employed then the HMAC size MUST be a
MESSAGE-INTEGRITY attribute. With the exception of the MESSAGE- multiple of YY. Truncation MUST be done from the most significant
INTEGRITY-SHA256 and FINGERPRINT attributes, which appear after byte to the least significant byte. STUN Usages can define their own
MESSAGE-INTEGRITY, agents MUST ignore all other attributes that truncation limits, as long as they adhere to the guidelines
follow MESSAGE-INTEGRITY. specificed above.
NOTE: We don't know what we're doing, we need a cryptographer to
weigh in on the above text.
The text used as input to HMAC is the STUN message, including the
header, up to and including the attribute preceding the MESSAGE-
INTEGRITY attribute. With the exception of the MESSAGE-INTEGRITY-
SHA256 and FINGERPRINT attributes, which appear after MESSAGE-
INTEGRITY, agents MUST ignore all other attributes that follow
MESSAGE-INTEGRITY.
The key for the HMAC depends on which credential mechanism is in use. The key for the HMAC depends on which credential mechanism is in use.
Section 9.1.1 defines the key for the short-term credential mechanism Section 9.1.1 defines the key for the short-term credential mechanism
and Section 9.2.1 defines the key for the long-term credential and Section 9.2.2 defines the key for the long-term credential
mechanism. Other credential mechanisms MUST define the key that is mechanism. Other credential mechanisms MUST define the key that is
used for the HMAC. used for the HMAC.
Based on the rules above, the hash used to construct MESSAGE- Based on the rules above, the hash used to construct MESSAGE-
INTEGRITY includes the length field from the STUN message header. INTEGRITY includes the length field from the STUN message header.
Prior to performing the hash, the MESSAGE-INTEGRITY attribute MUST be Prior to performing the hash, the MESSAGE-INTEGRITY attribute MUST be
inserted into the message (with dummy content). The length MUST then inserted into the message (with dummy content). The length MUST then
be set to point to the length of the message up to, and including, be set to point to the length of the message up to, and including,
the MESSAGE-INTEGRITY attribute itself, but excluding any attributes the MESSAGE-INTEGRITY attribute itself, but excluding any attributes
after it. Once the computation is performed, the value of the after it. Once the computation is performed, the value of the
MESSAGE-INTEGRITY attribute can be filled in, and the value of the MESSAGE-INTEGRITY attribute can be filled in, and the value of the
length in the STUN header can be set to its correct value -- the length in the STUN header can be set to its correct value -- the
length of the entire message. Similarly, when validating the length of the entire message. Similarly, when validating the
MESSAGE-INTEGRITY, the length field should be adjusted to point to MESSAGE-INTEGRITY, the length field should be adjusted to point to
the end of the MESSAGE-INTEGRITY attribute prior to calculating the the end of the MESSAGE-INTEGRITY attribute prior to calculating the
HMAC. Such adjustment is necessary when attributes, such as HMAC. Such adjustment is necessary when attributes, such as
FINGERPRINT, appear after MESSAGE-INTEGRITY. FINGERPRINT, appear after MESSAGE-INTEGRITY.
14.5. MESSAGE-INTEGRITY-SHA256 14.6. MESSAGE-INTEGRITY-SHA256
The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA-256 The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA-256
[RFC2104] of the STUN message. The MESSAGE-INTEGRITY-SHA256 [RFC2104] of the STUN message. The MESSAGE-INTEGRITY-SHA256
attribute can be present in any STUN message type. Since it uses the attribute can be present in any STUN message type. Since it uses the
SHA-256 hash, the HMAC will be 32 bytes. The text used as input to SHA1 hash, the HMAC will be at most 32 bytes. The HMAC MUST NOT be
HMAC is the STUN message, including the header, up to and including truncated below a minimum size of XX. If truncation is employed then
the attribute preceding the MESSAGE-INTEGRITY-SHA256 attribute. With the HMAC size MUST be a multiple of YY. Truncation MUST be done from
the exception of the FINGERPRINT attribute, which appears after the most significant byte to the least significant byte. STUN Usages
MESSAGE-INTEGRITY-SHA256, agents MUST ignore all other attributes can define their own truncation limits, as long as they adhere to the
that follow MESSAGE-INTEGRITY-SHA256. guidelines specificed above.
NOTE: We don't know what we're doing, we need a cryptographer to
weigh in on the above text.
The text used as input to HMAC is the STUN message, including the
header, up to and including the attribute preceding the MESSAGE-
INTEGRITY-SHA256 attribute. With the exception of the FINGERPRINT
attribute, which appears after MESSAGE-INTEGRITY-SHA256, agents MUST
ignore all other attributes that follow MESSAGE-INTEGRITY-SHA256.
The key for the HMAC depends on which credential mechanism is in use. The key for the HMAC depends on which credential mechanism is in use.
Section 9.1.1 defines the key for the short-term credential mechanism Section 9.1.1 defines the key for the short-term credential mechanism
and Section 9.2.1 defines the key for the long-term credential and Section 9.2.2 defines the key for the long-term credential
mechanism. Other credential mechanism MUST define the key that is mechanism. Other credential mechanism MUST define the key that is
used for the HMAC. used for the HMAC.
Based on the rules above, the hash used to construct MESSAGE- Based on the rules above, the hash used to construct MESSAGE-
INTEGRITY-SHA256 includes the length field from the STUN message INTEGRITY-SHA256 includes the length field from the STUN message
header. Prior to performing the hash, the MESSAGE-INTEGRITY-SHA256 header. Prior to performing the hash, the MESSAGE-INTEGRITY-SHA256
attribute MUST be inserted into the message (with dummy content). attribute MUST be inserted into the message (with dummy content).
The length MUST then be set to point to the length of the message up The length MUST then be set to point to the length of the message up
to, and including, the MESSAGE-INTEGRITY-SHA256 attribute itself, but to, and including, the MESSAGE-INTEGRITY-SHA256 attribute itself, but
excluding any attributes after it. Once the computation is excluding any attributes after it. Once the computation is
performed, the value of the MESSAGE-INTEGRITY-SHA256 attribute can be performed, the value of the MESSAGE-INTEGRITY-SHA256 attribute can be
filled in, and the value of the length in the STUN header can be set filled in, and the value of the length in the STUN header can be set
to its correct value -- the length of the entire message. Similarly, to its correct value -- the length of the entire message. Similarly,
when validating the MESSAGE-INTEGRITY-SHA256, the length field should when validating the MESSAGE-INTEGRITY-SHA256, the length field should
be adjusted to point to the end of the MESSAGE-INTEGRITY-SHA256 be adjusted to point to the end of the MESSAGE-INTEGRITY-SHA256
attribute prior to calculating the HMAC. Such adjustment is attribute prior to calculating the HMAC. Such adjustment is
necessary when attributes, such as FINGERPRINT, appear after MESSAGE- necessary when attributes, such as FINGERPRINT, appear after MESSAGE-
INTEGRITY-SHA256. INTEGRITY-SHA256.
14.6. FINGERPRINT 14.7. FINGERPRINT
The FINGERPRINT attribute MAY be present in all STUN messages. The The FINGERPRINT attribute MAY be present in all STUN messages. The
value of the attribute is computed as the CRC-32 of the STUN message value of the attribute is computed as the CRC-32 of the STUN message
up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with
the 32-bit value 0x5354554e (the XOR helps in cases where an the 32-bit value 0x5354554e (the XOR helps in cases where an
application packet is also using CRC-32 in it). The 32-bit CRC is application packet is also using CRC-32 in it). The 32-bit CRC is
the one defined in ITU V.42 [ITU.V42.2002], which has a generator the one defined in ITU V.42 [ITU.V42.2002], which has a generator
polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1.
When present, the FINGERPRINT attribute MUST be the last attribute in When present, the FINGERPRINT attribute MUST be the last attribute in
the message, and thus will appear after MESSAGE-INTEGRITY. the message, and thus will appear after MESSAGE-INTEGRITY.
skipping to change at page 38, line 5 skipping to change at page 40, line 40
covers the length field from the STUN message header. Therefore, covers the length field from the STUN message header. Therefore,
this value must be correct and include the CRC attribute as part of this value must be correct and include the CRC attribute as part of
the message length, prior to computation of the CRC. When using the the message length, prior to computation of the CRC. When using the
FINGERPRINT attribute in a message, the attribute is first placed FINGERPRINT attribute in a message, the attribute is first placed
into the message with a dummy value, then the CRC is computed, and into the message with a dummy value, then the CRC is computed, and
then the value of the attribute is updated. If the MESSAGE-INTEGRITY then the value of the attribute is updated. If the MESSAGE-INTEGRITY
attribute is also present, then it must be present with the correct attribute is also present, then it must be present with the correct
message-integrity value before the CRC is computed, since the CRC is message-integrity value before the CRC is computed, since the CRC is
done over the value of the MESSAGE-INTEGRITY attribute as well. done over the value of the MESSAGE-INTEGRITY attribute as well.
14.7. ERROR-CODE 14.8. ERROR-CODE
The ERROR-CODE attribute is used in error response messages. It The ERROR-CODE attribute is used in error response messages. It
contains a numeric error code value in the range of 300 to 699 plus a contains a numeric error code value in the range of 300 to 699 plus a
textual reason phrase encoded in UTF-8 [RFC3629], and is consistent textual reason phrase encoded in UTF-8 [RFC3629], and is consistent
in its code assignments and semantics with SIP [RFC3261] and HTTP in its code assignments and semantics with SIP [RFC3261] and HTTP
[RFC2616]. The reason phrase is meant for user consumption, and can [RFC2616]. The reason phrase is meant for user consumption, and can
be anything appropriate for the error code. Recommended reason be anything appropriate for the error code. Recommended reason
phrases for the defined error codes are included in the IANA registry phrases for the defined error codes are included in the IANA registry
for error codes. The reason phrase MUST be a UTF-8 [RFC3629] encoded for error codes. The reason phrase MUST be a UTF-8 [RFC3629] encoded
sequence of less than 128 characters (which can be as long as 763 sequence of less than 128 characters (which can be as long as 763
skipping to change at page 38, line 42 skipping to change at page 41, line 29
The Reserved bits SHOULD be 0, and are for alignment on 32-bit The Reserved bits SHOULD be 0, and are for alignment on 32-bit
boundaries. Receivers MUST ignore these bits. The Class represents boundaries. Receivers MUST ignore these bits. The Class represents
the hundreds digit of the error code. The value MUST be between 3 the hundreds digit of the error code. The value MUST be between 3
and 6. The Number represents the error code modulo 100, and its and 6. The Number represents the error code modulo 100, and its
value MUST be between 0 and 99. value MUST be between 0 and 99.
The following error codes, along with their recommended reason The following error codes, along with their recommended reason
phrases, are defined: phrases, are defined:
300 Try Alternate: The client should contact an alternate server for 300 Try Alternate: The client should contact an alternate server for
this request. This error response MUST only be sent if the this request. This error response MUST only be sent if the
request included a USERNAME attribute and a valid MESSAGE- request included either a USERNAME or USERHASH attribute and a
INTEGRITY attribute; otherwise, it MUST NOT be sent and error valid MESSAGE-INTEGRITY attribute; otherwise, it MUST NOT be sent
code 400 (Bad Request) is suggested. This error response MUST and error code 400 (Bad Request) is suggested. This error
be protected with the MESSAGE-INTEGRITY attribute, and receivers response MUST be protected with the MESSAGE-INTEGRITY attribute,
MUST validate the MESSAGE-INTEGRITY of this response before and receivers MUST validate the MESSAGE-INTEGRITY of this response
redirecting themselves to an alternate server. before redirecting themselves to an alternate server.
Note: Failure to generate and validate message integrity for NOTE: Failure to generate and validate message integrity for a 300
a 300 response allows an on-path attacker to falsify a 300 response allows an on-path attacker to falsify a 300 response thus
response thus causing subsequent STUN messages to be sent to causing subsequent STUN messages to be sent to a victim.
a victim.
400 Bad Request: The request was malformed. The client SHOULD NOT 400 Bad Request: The request was malformed. The client SHOULD NOT
retry the request without modification from the previous retry the request without modification from the previous attempt.
attempt. The server may not be able to generate a valid The server may not be able to generate a valid MESSAGE-INTEGRITY
MESSAGE-INTEGRITY for this error, so the client MUST NOT expect for this error, so the client MUST NOT expect a valid MESSAGE-
a valid MESSAGE-INTEGRITY attribute on this response. INTEGRITY attribute on this response.
401 Unauthorized: The request did not contain the correct 401 Unauthorized: The request did not contain the correct
credentials to proceed. The client should retry the request credentials to proceed. The client should retry the request with
with proper credentials. proper credentials.
420 Unknown Attribute: The server received a STUN packet containing 420 Unknown Attribute: The server received a STUN packet containing
a comprehension-required attribute that it did not understand. a comprehension-required attribute that it did not understand.
The server MUST put this unknown attribute in the UNKNOWN-
ATTRIBUTE attribute of its error response. The server MUST put this unknown attribute in the UNKNOWN-
ATTRIBUTE attribute of its error response.
438 Stale Nonce: The NONCE used by the client was no longer valid. 438 Stale Nonce: The NONCE used by the client was no longer valid.
The client should retry, using the NONCE provided in the The client should retry, using the NONCE provided in the response.
response.
500 Server Error: The server has suffered a temporary error. The 500 Server Error: The server has suffered a temporary error. The
client should try again. client should try again.
14.8. REALM 14.9. REALM
The REALM attribute may be present in requests and responses. It The REALM attribute may be present in requests and responses. It
contains text that meets the grammar for "realm-value" as described contains text that meets the grammar for "realm-value" as described
in RFC 3261 [RFC3261] but without the double quotes and their in RFC 3261 [RFC3261] but without the double quotes and their
surrounding whitespace. That is, it is an unquoted realm-value (and surrounding whitespace. That is, it is an unquoted realm-value (and
is therefore a sequence of qdtext or quoted-pair). It MUST be a is therefore a sequence of qdtext or quoted-pair). It MUST be a
UTF-8 [RFC3629] encoded sequence of less than 128 characters (which UTF-8 [RFC3629] encoded sequence of less than 128 characters (which
can be as long as 763 bytes), and MUST have been processed using the can be as long as 763 bytes), and MUST have been processed using the
OpaqueString profile [RFC7613]. OpaqueString profile [RFC7613].
Presence of the REALM attribute in a request indicates that long-term Presence of the REALM attribute in a request indicates that long-term
credentials are being used for authentication. Presence in certain credentials are being used for authentication. Presence in certain
error responses indicates that the server wishes the client to use a error responses indicates that the server wishes the client to use a
long-term credential for authentication. long-term credential for authentication.
14.9. NONCE 14.10. NONCE
The NONCE attribute may be present in requests and responses. It The NONCE attribute may be present in requests and responses. It
contains a sequence of qdtext or quoted-pair, which are defined in contains a sequence of qdtext or quoted-pair, which are defined in
RFC 3261 [RFC3261]. Note that this means that the NONCE attribute RFC 3261 [RFC3261]. Note that this means that the NONCE attribute
will not contain actual quote characters. See RFC 2617 [RFC2617], will not contain actual quote characters. See RFC 2617 [RFC2617],
Section 4.3, for guidance on selection of nonce values in a server. Section 4.3, for guidance on selection of nonce values in a server.
It MUST be less than 128 characters (which can be as long as 763 It MUST be less than 128 characters (which can be as long as 763
bytes). bytes).
14.10. 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 17.4. defined by this specification is found in Section 17.5.
The attribute contains a list of algorithm numbers and variable The attribute contains a list of algorithm numbers and variable
length parameters. The algorithm number is a 16-bit value as defined length parameters. The algorithm number is a 16-bit value as defined
in Section 17.4. The parameters start with the actual length of the in Section 17.5. The parameters start with the actual length of the
parameters as a 16-bit value, followed by the parameters that are parameters as a 16-bit value, followed by the parameters that are
specific to each algorithm. The parameters are padded to a 32-bit specific to each algorithm. The parameters are padded to a 32-bit
boundary, in the same manner as an attribute. boundary, in the same manner as an attribute.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm 1 Parameters Length | | Algorithm 1 | Algorithm 1 Parameters Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 Parameters (variable) | Algorithm 1 Parameters (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 2 | Algorithm 2 Parameters Length | | Algorithm 2 | Algorithm 2 Parameters Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 2 Parameter (variable) | Algorithm 2 Parameter (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ...
Figure 8: Format of PASSWORD-ALGORITHMS Attribute Figure 8: Format of PASSWORD-ALGORITHMS Attribute
14.11. PASSWORD-ALGORITHM 14.12. PASSWORD-ALGORITHM
The PASSWORD-ALGORITHM attribute is present only in requests. It The PASSWORD-ALGORITHM attribute is present only in requests. It
contains the algorithms that the server must use to derive the long- contains the algorithms that the server must use to derive the long-
term password. 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 17.4. defined by this specification is found in Section 17.5.
The attribute contains an algorithm number and variable length The attribute contains an algorithm number and variable length
parameters. The algorithm number is a 16-bit value as defined in parameters. The algorithm number is a 16-bit value as defined in
Section 17.4. The parameters starts with the actual length of the Section 17.5. The parameters starts with the actual length of the
parameters as a 16-bit value, followed by the parameters that are parameters as a 16-bit value, followed by the parameters that are
specific to the algorithm. The parameters are padded to a 32-bit specific to the algorithm. The parameters are padded to a 32-bit
boundary, in the same manner as an attribute. boundary, in the same manner as an attribute.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Algorithm Parameters Length | | Algorithm | Algorithm Parameters Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Parameters (variable) | Algorithm Parameters (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Format of PASSWORD-ALGORITHM Attribute Figure 9: Format of PASSWORD-ALGORITHM Attribute
14.12. UNKNOWN-ATTRIBUTES 14.13. UNKNOWN-ATTRIBUTES
The UNKNOWN-ATTRIBUTES attribute is present only in an error response The UNKNOWN-ATTRIBUTES attribute is present only in an error response
when the response code in the ERROR-CODE attribute is 420. when the response code in the ERROR-CODE attribute is 420.
The attribute contains a list of 16-bit values, each of which The attribute contains a list of 16-bit values, each of which
represents an attribute type that was not understood by the server. represents an attribute type that was not understood by the server.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 41, line 44 skipping to change at page 44, line 27
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 3 Type | Attribute 4 Type ... | Attribute 3 Type | Attribute 4 Type ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Format of UNKNOWN-ATTRIBUTES Attribute Figure 10: Format of UNKNOWN-ATTRIBUTES Attribute
Note: In [RFC3489], this field was padded to 32 by duplicating the Note: In [RFC3489], this field was padded to 32 by duplicating the
last attribute. In this version of the specification, the normal last attribute. In this version of the specification, the normal
padding rules for attributes are used instead. padding rules for attributes are used instead.
14.13. SOFTWARE 14.14. SOFTWARE
The SOFTWARE attribute contains a textual description of the software The SOFTWARE attribute contains a textual description of the software
being used by the agent sending the message. It is used by clients being used by the agent sending the message. It is used by clients
and servers. Its value SHOULD include manufacturer and version and servers. Its value SHOULD include manufacturer and version
number. The attribute has no impact on operation of the protocol, number. The attribute has no impact on operation of the protocol,
and serves only as a tool for diagnostic and debugging purposes. The and serves only as a tool for diagnostic and debugging purposes. The
value of SOFTWARE is variable length. It MUST be a UTF-8 [RFC3629] value of SOFTWARE is variable length. It MUST be a UTF-8 [RFC3629]
encoded sequence of less than 128 characters (which can be as long as encoded sequence of less than 128 characters (which can be as long as
763 bytes). 763 bytes).
14.14. ALTERNATE-SERVER 14.15. ALTERNATE-SERVER
The alternate server represents an alternate transport address The alternate server represents an alternate transport address
identifying a different STUN server that the STUN client should try. identifying a different STUN server that the STUN client should try.
It is encoded in the same way as MAPPED-ADDRESS, and thus refers to a It is encoded in the same way as MAPPED-ADDRESS, and thus refers to a
single server by IP address. The IP address family MUST be identical single server by IP address. The IP address family MUST be identical
to that of the source IP address of the request. to that of the source IP address of the request.
14.15. ALTERNATE-DOMAIN 14.16. ALTERNATE-DOMAIN
The alternate domain represents the domain name that is used to The alternate domain represents the domain name that is used to
verify the IP address in the ALTERNATE-SERVER attribute when the verify the IP address in the ALTERNATE-SERVER attribute when the
transport protocol uses TLS or DTLS. transport protocol uses TLS or DTLS.
The value of ALTERNATE-DOMAIN is variable length. It MUST be a UTF-8 The value of ALTERNATE-DOMAIN is variable length. It MUST be a UTF-8
[RFC3629] encoded sequence of less than 128 characters (which can be [RFC3629] encoded sequence of less than 128 characters (which can be
as long as 763 bytes). as long as 763 bytes).
15. Security Considerations 15. Security Considerations
skipping to change at page 46, line 16 skipping to change at page 49, line 4
Binding request/response transaction if one agent is behind a NAT and Binding request/response transaction if one agent is behind a NAT and
the other is on the public side of the NAT. the other is on the public side of the NAT.
The IAB has suggested that protocols developed for this purpose The IAB has suggested that protocols developed for this purpose
document a specific set of considerations. Because some STUN usages document a specific set of considerations. Because some STUN usages
provide UNSAF functions (such as ICE [I-D.ietf-mmusic-rfc5245bis] ), provide UNSAF functions (such as ICE [I-D.ietf-mmusic-rfc5245bis] ),
and others do not (such as SIP Outbound [RFC5626]), answers to these and others do not (such as SIP Outbound [RFC5626]), answers to these
considerations need to be addressed by the usages themselves. considerations need to be addressed by the usages themselves.
17. IANA Considerations 17. IANA Considerations
17.1. STUN Security Features Registry
17.1. STUN Methods Registry A STUN Security Feature set is a 24 bit value.
IANA is requested to create a new registry containing the STUN
Security Features that are protected by the bid down attack
prevention mechanism described in section Section 9.2.1.
The initial STUN Security Features are:
0x000000: Reserved
0x000001: Password algorithms
0x000002: Username anonymity
New Security Features are assigned by a Standard Action [RFC5226].
17.2. STUN Methods Registry
IANA is requested to update the reference from RFC 5389 to RFC-to-be IANA is requested to update the reference from RFC 5389 to RFC-to-be
for the following STUN methods: for the following STUN methods:
0x000: (Reserved) 0x000: (Reserved)
0x001: Binding 0x001: Binding
0x002: (Reserved; was SharedSecret) 0x002: (Reserved; was SharedSecret)
17.2. STUN Attribute Registry 17.3. STUN Attribute Registry
17.2.1. Updated Attributes 17.3.1. Updated Attributes
IANA is requested to update the reference from RFC 5389 to RFC-to-be IANA is requested to update the reference from RFC 5389 to RFC-to-be
for the following STUN methods: for the following STUN methods:
Comprehension-required range (0x0000-0x7FFF): Comprehension-required range (0x0000-0x7FFF):
0x0000: (Reserved) 0x0000: (Reserved)
0x0001: MAPPED-ADDRESS 0x0001: MAPPED-ADDRESS
0x0002: (Reserved; was RESPONSE-ADDRESS) 0x0002: (Reserved; was RESPONSE-ADDRESS)
0x0003: (Reserved; was CHANGE-REQUEST) 0x0003: (Reserved; was CHANGE-REQUEST)
0x0004: (Reserved; was SOURCE-ADDRESS) 0x0004: (Reserved; was SOURCE-ADDRESS)
skipping to change at page 47, line 27 skipping to change at page 50, line 27
0x000B: (Reserved; was REFLECTED-FROM) 0x000B: (Reserved; was REFLECTED-FROM)
0x0014: REALM 0x0014: REALM
0x0015: NONCE 0x0015: NONCE
0x0020: XOR-MAPPED-ADDRESS 0x0020: XOR-MAPPED-ADDRESS
Comprehension-optional range (0x8000-0xFFFF) Comprehension-optional range (0x8000-0xFFFF)
0x8022: SOFTWARE 0x8022: SOFTWARE
0x8023: ALTERNATE-SERVER 0x8023: ALTERNATE-SERVER
0x8028: FINGERPRINT 0x8028: FINGERPRINT
17.2.2. New Attributes 17.3.2. New Attributes
IANA is requested to add the following attribute to the STUN IANA is requested to add the following attribute to the STUN
Attribute Registry: Attribute Registry:
Comprehension-required range (0x0000-0x7FFF): Comprehension-required range (0x0000-0x7FFF):
0xXXXX: MESSAGE-INTEGRITY-SHA256 0xXXXX: MESSAGE-INTEGRITY-SHA256
0xXXXX: PASSWORD-ALGORITHM 0xXXXX: PASSWORD-ALGORITHM
0xXXXX: USERHASH
Comprehension-optional range (0x8000-0xFFFF) Comprehension-optional range (0x8000-0xFFFF)
0xXXXX: PASSSORD-ALGORITHMS 0xXXXX: PASSSORD-ALGORITHMS
0xXXXX: ALTERNATE-DOMAIN 0xXXXX: ALTERNATE-DOMAIN
17.3. STUN Error Code Registry 17.4. STUN Error Code Registry
IANA is requested to update the reference from RFC 5389 to RFC-to-be IANA is requested to update the reference from RFC 5389 to RFC-to-be
for the Error Codes given in Section 14.7. for the Error Codes given in Section 14.8.
17.4. Password Algorithm Registry 17.5. Password Algorithm Registry
IANA is requested to create a new registry for Password Algorithm. IANA is requested to create a new registry for Password Algorithm.
A Password Algorithm is a hex number in the range 0x0000 - 0xFFFF. A Password Algorithm is a hex number in the range 0x0000 - 0xFFFF.
The initial Password Algorithms are: The initial Password Algorithms are:
0x0001: MD5 0x0001: MD5
0x0002: SHA256 0x0002: SHA256
Password Algorithms in the first half of the range (0x0000 - 0x7FFF) Password Algorithms in the first half of the range (0x0000 - 0x7FFF)
are assigned by IETF Review [RFC5226]. Password Algorithms in the are assigned by IETF Review [RFC5226]. Password Algorithms in the
second half of the range (0x8000 - 0xFFFF) are assigned by Designated second half of the range (0x8000 - 0xFFFF) are assigned by Designated
Expert [RFC5226]. Expert [RFC5226].
17.4.1. Password Algorithms 17.5.1. Password Algorithms
17.4.1.1. MD5 17.5.1.1. MD5
This password algorithm is taken from [RFC1321]. This password algorithm is taken from [RFC1321].
The key length is 20 bytes and the parameters value is empty. The key length is 20 bytes and the parameters value is empty.
NOTE: This algorithm MUST only be used for compatibility with legacy NOTE: This algorithm MUST only be used for compatibility with legacy
systems. systems.
key = MD5(username ":" realm ":" OpaqueString(password)) key = MD5(username ":" realm ":" OpaqueString(password))
17.4.1.2. SHA256 17.5.1.2. SHA256
This password algorithm is taken from [RFC7616]. This password algorithm is taken from [RFC7616].
The key length is 32 bytes and the parameters value is empty. The key length is 32 bytes and the parameters value is empty.
key = SHA256(username ":" realm ":" OpaqueString(password)) key = SHA256(username ":" realm ":" OpaqueString(password))
17.5. STUN UDP and TCP Port Numbers 17.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: for the following ports:
stun 3478/tcp Session Traversal Utilities for NAT (STUN) port stun 3478/tcp Session Traversal Utilities for NAT (STUN) port
stun 3478/udp Session Traversal Utilities for NAT (STUN) port stun 3478/udp Session Traversal Utilities for NAT (STUN) port
stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port
18. Changes since RFC 5389 18. Changes since RFC 5389
This specification obsoletes RFC 5389 [RFC5389]. This specification This specification obsoletes RFC 5389 [RFC5389]. This specification
differs from RFC 5389 in the following ways: differs from RFC 5389 in the following ways:
o o TBD
19. References 19. References
19.1. Normative References 19.1. Normative References
[ITU.V42.2002] [ITU.V42.2002]
International Telecommunications Union, "Error-correcting International Telecommunications Union, "Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous Procedures for DCEs Using Asynchronous-to-Synchronous
Conversion", ITU-T Recommendation V.42, 2002. Conversion", ITU-T Recommendation V.42, 2002.
skipping to change at page 54, line 37 skipping to change at page 57, line 37
XX XX 00 20 MESSAGE-INTEGRITY-SHA256 attribute header XX XX 00 20 MESSAGE-INTEGRITY-SHA256 attribute header
62 fb 5e be } 62 fb 5e be }
ee 88 f1 0e } ee 88 f1 0e }
30 db ce 06 } 30 db ce 06 }
b2 c1 2e 64 } HMAC-SHA256 fingerprint b2 c1 2e 64 } HMAC-SHA256 fingerprint
8e fa b5 8c } 8e fa b5 8c }
80 e1 28 75 } 80 e1 28 75 }
79 33 84 0d } 79 33 84 0d }
01 43 9f ee } 01 43 9f ee }
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 by IANA. the value assigned to MESSAGE-INTEGRITY-SHA256 by IANA.
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-06 and draft-ietf- C.1. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf-
tram-stunbis-06
o Add USERHASH attribute to carry the hashed version of the
username.
o Add IANA registry and nonce encoding for Security Features that
need to be protected from bid down attacks.
o Modified MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 to support
truncation limits (pending cryptographic review),
C.2. 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.2. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- C.3. 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.3. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- C.4. 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.4. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- C.5. 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.5. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- C.6. 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 56, line 21 skipping to change at page 59, line 35
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.6. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- C.7. 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 57, line 8 skipping to change at page 60, line 21
* DNS discovery is done from the URI. * DNS discovery is done from the URI.
* Reorganized the text about default ports. * Reorganized the text about default ports.
o Add more C snippets. o Add more C snippets.
o Make clear that the cached RTO is discarded only if there is no o Make clear that the cached RTO is discarded only if there is no
new transations for 10 minutes. new transations for 10 minutes.
C.7. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.8. 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.8. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.9. 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 57, line 42 skipping to change at page 61, line 9
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.9. Modifications between draft-salgueiro-tram-stunbis-01 and draft- C.10. Modifications between draft-salgueiro-tram-stunbis-01 and draft-
salgueiro-tram-stunbis-00 salgueiro-tram-stunbis-00
o Restore the RFC 5389 text. o Restore the RFC 5389 text.
o Add list of open issues. o Add list of open issues.
Acknowledgements Acknowledgements
Thanks to Michael Tuexen, Tirumaleswar Reddy, Oleg Moskalenko, Simon Thanks to Michael Tuexen, Tirumaleswar Reddy, Oleg Moskalenko, Simon
Perreault, Benjamin Schwartz, Rifaat Shekh-Yusef, Alan Johnston, Perreault, Benjamin Schwartz, Rifaat Shekh-Yusef, Alan Johnston,
Jonathan Lennox and Brandon Williams for the comments, suggestions, Jonathan Lennox and Brandon Williams for the comments, suggestions,
 End of changes. 99 change blocks. 
269 lines changed or deleted 385 lines changed or added

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