draft-ietf-tram-stunbis-16.txt   draft-ietf-tram-stunbis-17.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: September 6, 2018 Cisco Expires: November 4, 2018 Cisco
D. Wing D. Wing
R. Mahy R. Mahy
Unaffiliated Unaffiliated
P. Matthews P. Matthews
Nokia Nokia
March 5, 2018 May 3, 2018
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-16 draft-ietf-tram-stunbis-17
Abstract Abstract
Session Traversal Utilities for NAT (STUN) is a protocol that serves Session Traversal Utilities for NAT (STUN) is a protocol that serves
as a tool for other protocols in dealing with Network Address as a tool for other protocols in dealing with Network Address
Translator (NAT) traversal. It can be used by an endpoint to Translator (NAT) traversal. It can be used by an endpoint to
determine the IP address and port allocated to it by a NAT. It can determine the IP address and port allocated to it by a NAT. It can
also be used to check connectivity between two endpoints, and as a also be used to check connectivity between two endpoints, and as a
keep-alive protocol to maintain NAT bindings. STUN works with many keep-alive protocol to maintain NAT bindings. STUN works with many
existing NATs, and does not require any special behavior from them. existing NATs, and does not require any special behavior from them.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018. This Internet-Draft will expire on November 4, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. STUN Message Structure . . . . . . . . . . . . . . . . . . . 10 5. STUN Message Structure . . . . . . . . . . . . . . . . . . . 10
6. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 12 6. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 12
6.1. Forming a Request or an Indication . . . . . . . . . . . 12 6.1. Forming a Request or an Indication . . . . . . . . . . . 12
6.2. Sending the Request or Indication . . . . . . . . . . . . 13 6.2. Sending the Request or Indication . . . . . . . . . . . . 13
6.2.1. Sending over UDP or DTLS-over-UDP . . . . . . . . . . 14 6.2.1. Sending over UDP or DTLS-over-UDP . . . . . . . . . . 14
6.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . 15 6.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . 15
6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP . . . . . 16 6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP . . . . . 16
6.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 17 6.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 17
6.3.1. Processing a Request . . . . . . . . . . . . . . . . 17 6.3.1. Processing a Request . . . . . . . . . . . . . . . . 18
6.3.1.1. Forming a Success or Error Response . . . . . . . 18 6.3.1.1. Forming a Success or Error Response . . . . . . . 18
6.3.1.2. Sending the Success or Error Response . . . . . . 19 6.3.1.2. Sending the Success or Error Response . . . . . . 19
6.3.2. Processing an Indication . . . . . . . . . . . . . . 19 6.3.2. Processing an Indication . . . . . . . . . . . . . . 19
6.3.3. Processing a Success Response . . . . . . . . . . . . 20 6.3.3. Processing a Success Response . . . . . . . . . . . . 20
6.3.4. Processing an Error Response . . . . . . . . . . . . 20 6.3.4. Processing an Error Response . . . . . . . . . . . . 20
7. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 21 7. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 21
8. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 21 8. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 21
8.1. STUN URI Scheme Semantics . . . . . . . . . . . . . . . . 22 8.1. STUN URI Scheme Semantics . . . . . . . . . . . . . . . . 22
9. Authentication and Message-Integrity Mechanisms . . . . . . . 23 9. Authentication and Message-Integrity Mechanisms . . . . . . . 23
9.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 23 9.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 23
9.1.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 24 9.1.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 24
9.1.2. Forming a Request or Indication . . . . . . . . . . . 24 9.1.2. Forming a Request or Indication . . . . . . . . . . . 24
9.1.3. Receiving a Request or Indication . . . . . . . . . . 24 9.1.3. Receiving a Request or Indication . . . . . . . . . . 24
9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 25 9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 25
9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 26 9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 26
9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 26 9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 26
9.2.1. Bid Down Attack Prevention . . . . . . . . . . . . . 27 9.2.1. Bid Down Attack Prevention . . . . . . . . . . . . . 28
9.2.2. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 28 9.2.2. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 28
9.2.3. Forming a Request . . . . . . . . . . . . . . . . . . 28 9.2.3. Forming a Request . . . . . . . . . . . . . . . . . . 29
9.2.3.1. First Request . . . . . . . . . . . . . . . . . . 29 9.2.3.1. First Request . . . . . . . . . . . . . . . . . . 29
9.2.3.2. Subsequent Requests . . . . . . . . . . . . . . . 29 9.2.3.2. Subsequent Requests . . . . . . . . . . . . . . . 29
9.2.4. Receiving a Request . . . . . . . . . . . . . . . . . 29 9.2.4. Receiving a Request . . . . . . . . . . . . . . . . . 30
9.2.5. Receiving a Response . . . . . . . . . . . . . . . . 31 9.2.5. Receiving a Response . . . . . . . . . . . . . . . . 32
10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 33 10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 33
11. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 34 11. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 34
12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 34 12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 35
13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 36
14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 36 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 37
14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 37 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 38
14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 38 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 39
14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 39 14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 40
14.4. USERHASH . . . . . . . . . . . . . . . . . . . . . . . . 39 14.4. USERHASH . . . . . . . . . . . . . . . . . . . . . . . . 40
14.5. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 39 14.5. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 40
14.6. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 40 14.6. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 41
14.7. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 41 14.7. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 42
14.8. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 42 14.8. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 42
14.9. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 43 14.9. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 44
14.10. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 43 14.10. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 44
14.11. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 44 14.11. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 44
14.12. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 44 14.12. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 45
14.13. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 45 14.13. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 46
14.14. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 45 14.14. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 46
14.15. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 45 14.15. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 47
14.16. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 46 14.16. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 47
15. Security Considerations . . . . . . . . . . . . . . . . . . . 46 15. Operational Considerations . . . . . . . . . . . . . . . . . 47
15.1. Attacks against the Protocol . . . . . . . . . . . . . . 46 16. Security Considerations . . . . . . . . . . . . . . . . . . . 47
15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 46 16.1. Attacks against the Protocol . . . . . . . . . . . . . . 47
15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 47 16.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 47
15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 47 16.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 48
15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 48 16.1.3. Bid-Down Attacks . . . . . . . . . . . . . . . . . . 49
15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 48 16.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 50
15.2.3. Attack III: Assuming the Identity of a Client . . . 49 16.2.1. Attack I: Distributed DoS (DDoS) against a Target . 50
15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 49 16.2.2. Attack II: Silencing a Client . . . . . . . . . . . 51
15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 49 16.2.3. Attack III: Assuming the Identity of a Client . . . 51
16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 50 16.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 51
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 16.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 52
17.1. STUN Security Features Registry . . . . . . . . . . . . 50 17. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 52
17.2. STUN Methods Registry . . . . . . . . . . . . . . . . . 50 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
17.3. STUN Attribute Registry . . . . . . . . . . . . . . . . 50 18.1. STUN Security Features Registry . . . . . . . . . . . . 53
17.3.1. Updated Attributes . . . . . . . . . . . . . . . . . 51 18.2. STUN Methods Registry . . . . . . . . . . . . . . . . . 53
17.3.2. New Attributes . . . . . . . . . . . . . . . . . . . 51 18.3. STUN Attribute Registry . . . . . . . . . . . . . . . . 53
17.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 51 18.3.1. Updated Attributes . . . . . . . . . . . . . . . . . 53
17.5. STUN Password Algorithm Registry . . . . . . . . . . . . 52 18.3.2. New Attributes . . . . . . . . . . . . . . . . . . . 54
17.5.1. Password Algorithms . . . . . . . . . . . . . . . . 52 18.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 54
17.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 52 18.5. STUN Password Algorithm Registry . . . . . . . . . . . . 55
17.5.1.2. SHA-256 . . . . . . . . . . . . . . . . . . . . 52 18.5.1. Password Algorithms . . . . . . . . . . . . . . . . 55
18.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 55
17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 52 18.5.1.2. SHA-256 . . . . . . . . . . . . . . . . . . . . 55
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 53 18.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 55
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 19. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 56
19.1. Normative References . . . . . . . . . . . . . . . . . . 53 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
19.2. Informative References . . . . . . . . . . . . . . . . . 55 20.1. Normative References . . . . . . . . . . . . . . . . . . 56
Appendix A. C Snippet to Determine STUN Message Types . . . . . 57 20.2. Informative References . . . . . . . . . . . . . . . . . 59
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 58 Appendix A. C Snippet to Determine STUN Message Types . . . . . 61
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 62
B.1. Sample Request with Long-Term Authentication with B.1. Sample Request with Long-Term Authentication with
MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 58 MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 62
Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 60 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 64
C.1. Modifications between draft-ietf-tram-stunbis-16 and C.1. Modifications between draft-ietf-tram-stunbis-17 and
draft-ietf-tram-stunbis-15 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-16 . . . . . . . . . . . . . . . 64
C.2. Modifications between draft-ietf-tram-stunbis-15 and C.2. Modifications between draft-ietf-tram-stunbis-16 and
draft-ietf-tram-stunbis-14 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-15 . . . . . . . . . . . . . . . 64
C.3. Modifications between draft-ietf-tram-stunbis-14 and C.3. Modifications between draft-ietf-tram-stunbis-15 and
draft-ietf-tram-stunbis-13 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-14 . . . . . . . . . . . . . . . 65
C.4. Modifications between draft-ietf-tram-stunbis-13 and C.4. Modifications between draft-ietf-tram-stunbis-14 and
draft-ietf-tram-stunbis-12 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-13 . . . . . . . . . . . . . . . 65
C.5. Modifications between draft-ietf-tram-stunbis-12 and C.5. Modifications between draft-ietf-tram-stunbis-13 and
draft-ietf-tram-stunbis-11 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-12 . . . . . . . . . . . . . . . 65
C.6. Modifications between draft-ietf-tram-stunbis-11 and C.6. Modifications between draft-ietf-tram-stunbis-12 and
draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-11 . . . . . . . . . . . . . . . 65
C.7. Modifications between draft-ietf-tram-stunbis-10 and C.7. Modifications between draft-ietf-tram-stunbis-11 and
draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 66
C.8. Modifications between draft-ietf-tram-stunbis-09 and C.8. Modifications between draft-ietf-tram-stunbis-10 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 66
C.9. Modifications between draft-ietf-tram-stunbis-09 and C.9. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 67
C.10. Modifications between draft-ietf-tram-stunbis-08 and C.10. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 63 draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 67
C.11. Modifications between draft-ietf-tram-stunbis-07 and C.11. Modifications between draft-ietf-tram-stunbis-08 and
draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 68
C.12. Modifications between draft-ietf-tram-stunbis-06 and C.12. Modifications between draft-ietf-tram-stunbis-07 and
draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 68
C.13. Modifications between draft-ietf-tram-stunbis-05 and C.13. Modifications between draft-ietf-tram-stunbis-06 and
draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 68
C.14. Modifications between draft-ietf-tram-stunbis-04 and C.14. Modifications between draft-ietf-tram-stunbis-05 and
draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 68
C.15. Modifications between draft-ietf-tram-stunbis-03 and C.15. Modifications between draft-ietf-tram-stunbis-04 and
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 65 draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 69
C.16. Modifications between draft-ietf-tram-stunbis-02 and C.16. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 65 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 69
C.17. Modifications between draft-ietf-tram-stunbis-01 and C.17. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 66 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 69
C.18. Modifications between draft-salgueiro-tram-stunbis-02 and C.18. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 66 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 70
C.19. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 66
C.20. Modifications between draft-salgueiro-tram-stunbis-01 and C.19. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 67 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 71
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 67 C.20. Modifications between draft-salgueiro-tram-stunbis-02 and
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 68 draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 C.21. Modifications between draft-salgueiro-tram-stunbis-01 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 71
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72
1. Introduction 1. Introduction
The protocol defined in this specification, Session Traversal The protocol defined in this specification, Session Traversal
Utilities for NAT, provides a tool for dealing with NATs. It Utilities for NAT, provides a tool for dealing with NATs. It
provides a means for an endpoint to determine the IP address and port provides a means for an endpoint to determine the IP address and port
allocated by a NAT that corresponds to its private IP address and allocated by a NAT that corresponds to its private IP address and
port. It also provides a way for an endpoint to keep a NAT binding port. It also provides a way for an endpoint to keep a NAT binding
alive. With some extensions, the protocol can be used to do alive. With some extensions, the protocol can be used to do
connectivity checks between two endpoints [I-D.ietf-ice-rfc5245bis], connectivity checks between two endpoints [I-D.ietf-ice-rfc5245bis],
or to relay packets between two endpoints [RFC5766]. or to relay packets between two endpoints [RFC5766].
In keeping with its tool nature, this specification defines an In keeping with its tool nature, this specification defines an
extensible packet format, defines operation over several transport extensible packet format, defines operation over several transport
protocols, and provides for two forms of authentication. protocols, and provides for two forms of authentication.
STUN is intended to be used in context of one or more NAT traversal STUN is intended to be used in the context of one or more NAT
solutions. These solutions are known as STUN usages. Each usage traversal solutions. These solutions are known as STUN usages. Each
describes how STUN is utilized to achieve the NAT traversal solution. usage describes how STUN is utilized to achieve the NAT traversal
Typically, a usage indicates when STUN messages get sent, which solution. Typically, a usage indicates when STUN messages get sent,
optional attributes to include, what server is used, and what which optional attributes to include, what server is used, and what
authentication mechanism is to be used. Interactive Connectivity authentication mechanism is to be used. Interactive Connectivity
Establishment (ICE) [I-D.ietf-ice-rfc5245bis] is one usage of STUN. Establishment (ICE) [I-D.ietf-ice-rfc5245bis] is one usage of STUN.
SIP Outbound [RFC5626] is another usage of STUN. In some cases, a SIP Outbound [RFC5626] is another usage of STUN. In some cases, a
usage will require extensions to STUN. A STUN extension can be in usage will require extensions to STUN. A STUN extension can be in
the form of new methods, attributes, or error response codes. More the form of new methods, attributes, or error response codes. More
information on STUN usages can be found in Section 13. information on STUN usages can be found in Section 13.
Implementations and deployments of a STUN usage using TLS or DTLS
should follow the recommendations in [RFC7525].
2. Overview of Operation 2. Overview of Operation
This section is descriptive only. This section is descriptive only.
/-----\ /-----\
// STUN \\ // STUN \\
| Server | | Server |
\\ // \\ //
\-----/ \-----/
skipping to change at page 8, line 24 skipping to change at page 8, line 24
defined for HTTP [RFC7616]. In the short-term credential mechanism, defined for HTTP [RFC7616]. In the short-term credential mechanism,
the client and the server exchange a username and password through the client and the server exchange a username and password through
some out-of-band method prior to the STUN exchange. For example, in some out-of-band method prior to the STUN exchange. For example, in
the ICE usage [I-D.ietf-ice-rfc5245bis] the two endpoints use out-of- the ICE usage [I-D.ietf-ice-rfc5245bis] the two endpoints use out-of-
band signaling to exchange a username and password. These are used band signaling to exchange a username and password. These are used
to integrity protect and authenticate the request and response. to integrity protect and authenticate the request and response.
There is no challenge or nonce used. There is no challenge or nonce used.
3. Terminology 3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
and "OPTIONAL" are to be interpreted as described in BCP14, RFC 8174 "OPTIONAL" in this document are to be interpreted as described in BCP
[RFC8174] and indicate requirement levels for compliant STUN 14 [RFC2119][RFC8174] when, and only when, they appear in all
implementations. capitals, as shown here.
4. Definitions 4. Definitions
STUN Agent: A STUN agent is an entity that implements the STUN STUN Agent: A STUN agent is an entity that implements the STUN
protocol. The entity can be either a STUN client or a STUN protocol. The entity can be either a STUN client or a STUN
server. server.
STUN Client: A STUN client is an entity that sends STUN requests and STUN Client: A STUN client is an entity that sends STUN requests and
receives STUN responses and STUN indications. A STUN client can receives STUN responses and STUN indications. A STUN client can
also send indications. In this specification, the terms STUN also send indications. In this specification, the terms STUN
skipping to change at page 9, line 28 skipping to change at page 9, line 28
service or explicitly changes the credential. service or explicitly changes the credential.
Long-Term Password: The password from a long-term credential. Long-Term Password: The password from a long-term credential.
Short-Term Credential: A temporary username and associated password Short-Term Credential: A temporary username and associated password
that represent a shared secret between client and server. Short- that represent a shared secret between client and server. Short-
term credentials are obtained through some kind of protocol term credentials are obtained through some kind of protocol
mechanism between the client and server, preceding the STUN mechanism between the client and server, preceding the STUN
exchange. A short-term credential has an explicit temporal scope, exchange. A short-term credential has an explicit temporal scope,
which may be based on a specific amount of time (such as 5 which may be based on a specific amount of time (such as 5
minutes) or on an event (such as termination of a SIP dialog). minutes) or on an event (such as termination of a Session
The specific scope of a short-term credential is defined by the Initiation Protocol (SIP [RFC3261]) dialog). The specific scope
application usage. of a short-term credential is defined by the application usage.
Short-Term Password: The password component of a short-term Short-Term Password: The password component of a short-term
credential. credential.
STUN Indication: A STUN message that does not receive a response. STUN Indication: A STUN message that does not receive a response.
Attribute: The STUN term for a Type-Length-Value (TLV) object that Attribute: The STUN term for a Type-Length-Value (TLV) object that
can be added to a STUN message. Attributes are divided into two can be added to a STUN message. Attributes are divided into two
types: comprehension-required and comprehension-optional. STUN types: comprehension-required and comprehension-optional. STUN
agents can safely ignore comprehension-optional attributes they agents can safely ignore comprehension-optional attributes they
skipping to change at page 10, line 14 skipping to change at page 10, line 14
5. STUN Message Structure 5. STUN Message Structure
STUN messages are encoded in binary using network-oriented format STUN messages are encoded in binary using network-oriented format
(most significant byte or octet first, also commonly known as big- (most significant byte or octet first, also commonly known as big-
endian). The transmission order is described in detail in Appendix B endian). The transmission order is described in detail in Appendix B
of [RFC0791]. Unless otherwise noted, numeric constants are in of [RFC0791]. Unless otherwise noted, numeric constants are in
decimal (base 10). decimal (base 10).
All STUN messages comprise a 20-byte header followed by zero or more All STUN messages comprise a 20-byte header followed by zero or more
Attributes. The STUN header contains a STUN message type, magic Attributes. The STUN header contains a STUN message type, message
cookie, transaction ID, and message length. length, magic cookie, and transaction ID.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0| STUN Message Type | Message Length | |0 0| STUN Message Type | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic Cookie | | Magic Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Transaction ID (96 bits) | | Transaction ID (96 bits) |
skipping to change at page 11, line 39 skipping to change at page 11, line 39
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 [RFC3489], this field was part of the network byte order. In [RFC3489], this field was part of the
transaction ID; placing the magic cookie in this location allows a transaction ID; placing the magic cookie in this location allows a
server to detect if the client will understand certain attributes server to detect if the client will understand certain attributes
that were added in this revised specification. In addition, it aids that were added to STUN by [RFC5389]. In addition, it aids in
in distinguishing STUN packets from packets of other protocols when distinguishing STUN packets from packets of other protocols when STUN
STUN is multiplexed with those other protocols on the same port. is multiplexed with those other protocols on the same port.
The transaction ID is a 96-bit identifier, used to uniquely identify The transaction ID is a 96-bit identifier, used to uniquely identify
STUN transactions. For request/response transactions, the STUN transactions. For request/response transactions, the
transaction ID is chosen by the STUN client for the request and transaction ID is chosen by the STUN client for the request and
echoed by the server in the response. For indications, it is chosen echoed by the server in the response. For indications, it is chosen
by the agent sending the indication. It primarily serves to by the agent sending the indication. It primarily serves to
correlate requests with responses, though it also plays a small role correlate requests with responses, though it also plays a small role
in helping to prevent certain types of attacks. The server also uses in helping to prevent certain types of attacks. The server also uses
the transaction ID as a key to identify each transaction uniquely the transaction ID as a key to identify each transaction uniquely
across all clients. As such, the transaction ID MUST be uniformly across all clients. As such, the transaction ID MUST be uniformly
and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be and randomly chosen from the interval 0 .. 2**96-1, and MUST be
cryptographically random. Resends of the same request reuse the same cryptographically random. Resends of the same request reuse the same
transaction ID, but the client MUST choose a new transaction ID for transaction ID, but the client MUST choose a new transaction ID for
new transactions unless the new request is bit-wise identical to the new transactions unless the new request is bit-wise identical to the
previous request and sent from the same transport address to the same previous request and sent from the same transport address to the same
IP address. Success and error responses MUST carry the same IP address. Success and error responses MUST carry the same
transaction ID as their corresponding request. When an agent is transaction ID as their corresponding request. When an agent is
acting as a STUN server and STUN client on the same port, the acting as a STUN server and STUN client on the same port, the
transaction IDs in requests sent by the agent have no relationship to transaction IDs in requests sent by the agent have no relationship to
the transaction IDs in requests received by the agent. the transaction IDs in requests received by the agent.
skipping to change at page 12, line 51 skipping to change at page 12, line 51
defined in another document. defined in another document.
The agent then adds any attributes specified by the method or the The agent then adds any attributes specified by the method or the
usage. For example, some usages may specify that the agent use an usage. For example, some usages may specify that the agent use an
authentication method (Section 9) or the FINGERPRINT attribute authentication method (Section 9) or the FINGERPRINT attribute
(Section 7). (Section 7).
If the agent is sending a request, it SHOULD add a SOFTWARE attribute If the agent is sending a request, it SHOULD add a SOFTWARE attribute
to the request. Agents MAY include a SOFTWARE attribute in to the request. Agents MAY include a SOFTWARE attribute in
indications, depending on the method. Extensions to STUN should indications, depending on the method. Extensions to STUN should
discuss whether SOFTWARE is useful in new indications. discuss whether SOFTWARE is useful in new indications. Note that the
inclusion of a SOFTWARE attribute may have security implications; see
Section 16.1.2 for details.
For the Binding method with no authentication, no attributes are For the Binding method with no authentication, no attributes are
required unless the usage specifies otherwise. required unless the usage specifies otherwise.
All STUN messages sent over UDP or DTLS-over-UDP [RFC6347] SHOULD be All STUN messages sent over UDP or DTLS-over-UDP [RFC6347] SHOULD be
less than the path MTU, if known. less than the path MTU, if known.
If the path MTU is unknown for UDP, messages SHOULD be the smaller of If the path MTU is unknown for UDP, messages SHOULD be the smaller of
576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for 576 bytes and the first-hop MTU for IPv4 [RFC1122] and 1280 bytes for
IPv6 [RFC8200]. This value corresponds to the overall size of the IP IPv6 [RFC8200]. This value corresponds to the overall size of the IP
skipping to change at page 13, line 28 skipping to change at page 13, line 30
If the path MTU is unknown for DTLS-over-UDP, the rules described in If the path MTU is unknown for DTLS-over-UDP, the rules described in
the previous paragraph need to be adjusted to take into account the the previous paragraph need to be adjusted to take into account the
size of the (13-byte) DTLS Record header, the MAC size, and the size of the (13-byte) DTLS Record header, the MAC size, and the
padding size. padding size.
STUN provides no ability to handle the case where the request is STUN provides no ability to handle the case where the request is
under the MTU but the response would be larger than the MTU. It is under the MTU but the response would be larger than the MTU. It is
not envisioned that this limitation will be an issue for STUN. The not envisioned that this limitation will be an issue for STUN. The
MTU limitation is a SHOULD, and not a MUST, to account for cases MTU limitation is a SHOULD, and not a MUST, to account for cases
where STUN itself is being used to probe for MTU characteristics where STUN itself is being used to probe for MTU characteristics
[RFC5780]. Outside of this or similar applications, the MTU [RFC5780]. See also [I-D.ietf-tram-stun-pmtud] for a framework that
constraint MUST be followed. uses STUN to add Path MTU Discovery to protocols that lack one.
Outside of this or similar applications, the MTU constraint MUST be
followed.
6.2. Sending the Request or Indication 6.2. Sending the Request or Indication
The agent then sends the request or indication. This document The agent then sends the request or indication. This document
specifies how to send STUN messages over UDP, TCP, TLS-over-TCP, or specifies how to send STUN messages over UDP, TCP, TLS-over-TCP, or
DTLS-over-UDP; other transport protocols may be added in the future. DTLS-over-UDP; other transport protocols may be added in the future.
The STUN usage must specify which transport protocol is used, and how The STUN usage must specify which transport protocol is used, and how
the agent determines the IP address and port of the recipient. the agent determines the IP address and port of the recipient.
Section 8 describes a DNS-based method of determining the IP address Section 8 describes a DNS-based method of determining the IP address
and port of a server that a usage may elect to use. STUN may be used and port of a server that a usage may elect to use.
with anycast addresses, but only with UDP and in usages where
authentication is not used.
At any time, a client MAY have multiple outstanding STUN requests At any time, a client MAY have multiple outstanding STUN requests
with the same STUN server (that is, multiple transactions in with the same STUN server (that is, multiple transactions in
progress, with different transaction IDs). Absent other limits to progress, with different transaction IDs). Absent other limits to
the rate of new transactions (such as those specified by ICE for the rate of new transactions (such as those specified by ICE for
connectivity checks or when STUN is run over TCP), a client SHOULD connectivity checks or when STUN is run over TCP), a client SHOULD
limit itself to ten outstanding transactions to the same server. limit itself to ten outstanding transactions to the same server.
6.2.1. Sending over UDP or DTLS-over-UDP 6.2.1. Sending over UDP or DTLS-over-UDP
skipping to change at page 14, line 18 skipping to change at page 14, line 18
is possible that the STUN message might be dropped by the network. is possible that the STUN message might be dropped by the network.
Reliability of STUN request/response transactions is accomplished Reliability of STUN request/response transactions is accomplished
through retransmissions of the request message by the client through retransmissions of the request message by the client
application itself. STUN indications are not retransmitted; thus, application itself. STUN indications are not retransmitted; thus,
indication transactions over UDP or DTLS-over-UDP are not reliable. indication transactions over UDP or DTLS-over-UDP are not reliable.
A client SHOULD retransmit a STUN request message starting with an A client SHOULD retransmit a STUN request message starting with an
interval of RTO ("Retransmission TimeOut"), doubling after each interval of RTO ("Retransmission TimeOut"), doubling after each
retransmission. The RTO is an estimate of the round-trip time (RTT), retransmission. The RTO is an estimate of the round-trip time (RTT),
and is computed as described in [RFC6298], with two exceptions. and is computed as described in [RFC6298], with two exceptions.
First, the initial value for RTO SHOULD be greater than 500 ms. The First, the initial value for RTO SHOULD be greater or equal than 500
exception cases for this "SHOULD" are when other mechanisms are used ms. The exception cases for this "SHOULD" are when other mechanisms
to derive congestion thresholds (such as the ones defined in ICE for are used to derive congestion thresholds (such as the ones defined in
fixed rate streams), or when STUN is used in non-Internet ICE for fixed rate streams), or when STUN is used in non-Internet
environments with known network capacities. In fixed-line access environments with known network capacities. In fixed-line access
links, a value of 500 ms is RECOMMENDED. Second, the value of RTO links, a value of 500 ms is RECOMMENDED. Second, the value of RTO
SHOULD NOT be rounded up to the nearest second. Rather, a 1 ms SHOULD NOT be rounded up to the nearest second. Rather, a 1 ms
accuracy SHOULD be maintained. As with TCP, the usage of Karn's accuracy SHOULD be maintained. As with TCP, the usage of Karn's
algorithm is RECOMMENDED [KARN87]. When applied to STUN, it means algorithm is RECOMMENDED [KARN87]. When applied to STUN, it means
that RTT estimates SHOULD NOT be computed from STUN transactions that that RTT estimates SHOULD NOT be computed from STUN transactions that
result in the retransmission of a request. result in the retransmission of a request.
The value for RTO SHOULD be cached by a client after the completion The value for RTO SHOULD be cached by a client after the completion
of the transaction, and used as the starting value for RTO for the of the transaction, and used as the starting value for RTO for the
next transaction to the same server (based on equality of IP next transaction to the same server (based on equality of IP
address). The value SHOULD be considered stale and discarded after address). The value SHOULD be considered stale and discarded if no
10 minutes without any transactions to the same server. transactions have occurred to the same server in the last 10 minutes.
Retransmissions continue until a response is received, or until a Retransmissions continue until a response is received, or until a
total of Rc requests have been sent. Rc SHOULD be configurable and total of Rc requests have been sent. Rc SHOULD be configurable and
SHOULD have a default of 7. If, after the last request, a duration SHOULD have a default of 7. If, after the last request, a duration
equal to Rm times the RTO has passed without a response (providing equal to Rm times the RTO has passed without a response (providing
ample time to get a response if only this final request actually ample time to get a response if only this final request actually
succeeds), the client SHOULD consider the transaction to have failed. succeeds), the client SHOULD consider the transaction to have failed.
Rm SHOULD be configurable and SHOULD have a default of 16. A STUN Rm SHOULD be configurable and SHOULD have a default of 16. A STUN
transaction over UDP or DTLS-over-UDP is also considered failed if transaction over UDP or DTLS-over-UDP is also considered failed if
there has been a hard ICMP error [RFC1122]. For example, assuming an there has been a hard ICMP error [RFC1122]. For example, assuming an
skipping to change at page 15, line 29 skipping to change at page 15, line 29
Section 8 is for STUN alone, and not for STUN multiplexed with other Section 8 is for STUN alone, and not for STUN multiplexed with other
data. Consequently, no framing protocols are used in connections to data. Consequently, no framing protocols are used in connections to
those servers. When additional framing is utilized, the usage will those servers. When additional framing is utilized, the usage will
specify how the client knows to apply it and what port to connect to. specify how the client knows to apply it and what port to connect to.
For example, in the case of ICE connectivity checks, this information For example, in the case of ICE connectivity checks, this information
is learned through out-of-band negotiation between client and server. is learned through out-of-band negotiation between client and server.
Reliability of STUN over TCP and TLS-over-TCP is handled by TCP Reliability of STUN over TCP and TLS-over-TCP is handled by TCP
itself, and there are no retransmissions at the STUN protocol level. itself, and there are no retransmissions at the STUN protocol level.
However, for a request/response transaction, if the client has not However, for a request/response transaction, if the client has not
received a response by Ti seconds after it sent the SYN to establish received a response by Ti seconds after it sent the request message,
the connection, it considers the transaction to have timed out. Ti it considers the transaction to have timed out. Ti SHOULD be
SHOULD be configurable and SHOULD have a default of 39.5s. This configurable and SHOULD have a default of 39.5s. This value has been
value has been chosen to equalize the TCP and UDP timeouts for the chosen to equalize the TCP and UDP timeouts for the default initial
default initial RTO. RTO.
In addition, if the client is unable to establish the TCP connection, In addition, if the client is unable to establish the TCP connection,
or the TCP connection is reset or fails before a response is or the TCP connection is reset or fails before a response is
received, any request/response transaction in progress is considered received, any request/response transaction in progress is considered
to have failed. to have failed.
The client MAY send multiple transactions over a single TCP (or TLS- The client MAY send multiple transactions over a single TCP (or TLS-
over-TCP) connection, and it MAY send another request before over-TCP) connection, and it MAY send another request before
receiving a response to the previous request. The client SHOULD keep receiving a response to the previous request. The client SHOULD keep
the connection open until it: the connection open until it:
o has no further STUN requests or indications to send over that o has no further STUN requests or indications to send over that
connection, and connection, and
o has no plans to use any resources (such as a mapped address o has no plans to use any resources (such as a mapped address
(MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) or relayed address (MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) or relayed address
[RFC5766]) that were learned though STUN requests sent over that [RFC5766]) that were learned though STUN requests sent over that
connection, and connection, and
o if multiplexing other application protocols over that port, has o if multiplexing other application protocols over that port, has
finished using that other protocol, and finished using those other protocols, and
o if using that learned port with a remote peer, has established o if using that learned port with a remote peer, has established
communications with that remote peer, as is required by some TCP communications with that remote peer, as is required by some TCP
NAT traversal techniques (e.g., [RFC6544]). NAT traversal techniques (e.g., [RFC6544]).
The details of an eventual keep-alive mechanism are left to each STUN
Usage. In any case if a transaction fails because an idle TCP
connection doesn't work anymore the client SHOULD send an RST and try
to open a new TCP connection.
At the server end, the server SHOULD keep the connection open, and At the server end, the server SHOULD keep the connection open, and
let the client close it, unless the server has determined that the let the client close it, unless the server has determined that the
connection has timed out (for example, due to the client connection has timed out (for example, due to the client
disconnecting from the network). Bindings learned by the client will disconnecting from the network). Bindings learned by the client will
remain valid in intervening NATs only while the connection remains remain valid in intervening NATs only while the connection remains
open. Only the client knows how long it needs the binding. The open. Only the client knows how long it needs the binding. The
server SHOULD NOT close a connection if a request was received over server SHOULD NOT close a connection if a request was received over
that connection for which a response was not sent. A server MUST NOT that connection for which a response was not sent. A server MUST NOT
ever open a connection back towards the client in order to send a ever open a connection back towards the client in order to send a
response. Servers SHOULD follow best practices regarding connection response. Servers SHOULD follow best practices regarding connection
skipping to change at page 16, line 35 skipping to change at page 16, line 40
When STUN is run by itself over TLS-over-TCP or DTLS-over-UDP, the When STUN is run by itself over TLS-over-TCP or DTLS-over-UDP, the
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suites MUST be TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suites MUST be
implemented and other cipher suites MAY be implemented. Perfect implemented and other cipher suites MAY be implemented. Perfect
Forward Secrecy (PFS) cipher suites MUST be preferred over non-PFS Forward Secrecy (PFS) cipher suites MUST be preferred over non-PFS
cipher suites. Cipher suites with known weaknesses, such as those cipher suites. Cipher suites with known weaknesses, such as those
based on (single) DES and RC4, MUST NOT be used. Implementations based on (single) DES and RC4, MUST NOT be used. Implementations
MUST disable TLS-level compression. MUST disable TLS-level compression.
When it receives the TLS Certificate message, the client SHOULD These recommendations are just a part of the recommendations in
verify the certificate and inspect the site identified by the [BCP195] that implementations and deployments of a STUN Usage using
certificate. If the certificate is invalid or revoked, or if it does TLS or DTLS MUST follow.
not identify the appropriate party, the client MUST NOT send the STUN
message or otherwise proceed with the STUN transaction. The client When it receives the TLS Certificate message, the client MUST verify
MUST verify the identity of the server. To do that, it follows the the certificate and inspect the site identified by the certificate.
identification procedures defined in [RFC6125]. Alternatively, a If the certificate is invalid or revoked, or if it does not identify
client MAY be configured with a set of IP addresses that are trusted; the appropriate party, the client MUST NOT send the STUN message or
if a certificate is received that identifies one of those IP otherwise proceed with the STUN transaction. The client MUST verify
addresses, the client considers the identity of the server to be the identity of the server. To do that, it follows the
verified. identification procedures defined in [RFC6125], with a certificate
containing an identifier of type DNS-ID or CN-ID, eventually with
wildcards, but not of type SRV-ID or URI-ID. Alternatively, a client
MAY be configured with a set of IP addresses that are trusted; if a
certificate is received that identifies one of those IP addresses,
the client considers the identity of the server to be verified.
When STUN is run multiplexed with other protocols over a TLS-over-TCP When STUN is run multiplexed with other protocols over a TLS-over-TCP
connection or a DTLS-over-UDP association, the mandatory ciphersuites connection or a DTLS-over-UDP association, the mandatory ciphersuites
and TLS handling procedures operate as defined by those protocols. and TLS handling procedures operate as defined by those protocols.
6.3. Receiving a STUN Message 6.3. Receiving a STUN Message
This section specifies the processing of a STUN message. The This section specifies the processing of a STUN message. The
processing specified here is for STUN messages as defined in this processing specified here is for STUN messages as defined in this
specification; additional rules for backwards compatibility are specification; additional rules for backwards compatibility are
defined in Section 11. Those additional procedures are optional, and defined in Section 11. Those additional procedures are optional, and
usages can elect to utilize them. First, a set of processing usages can elect to utilize them. Fcirst, a set of processing
operations is applied that is independent of the class. This is operations is applied that is independent of the class. This is
followed by class-specific processing, described in the subsections followed by class-specific processing, described in the subsections
that follow. that follow.
When a STUN agent receives a STUN message, it first checks that the When a STUN agent receives a STUN message, it first checks that the
message obeys the rules of Section 5. It checks that the first two message obeys the rules of Section 5. It checks that the first two
bits are 0, that the magic cookie field has the correct value, that bits are 0, that the magic cookie field has the correct value, that
the message length is sensible, and that the method value is a the message length is sensible, and that the method value is a
supported method. It checks that the message class is allowed for supported method. It checks that the message class is allowed for
the particular method. If the message class is "Success Response" or the particular method. If the message class is "Success Response" or
skipping to change at page 18, line 5 skipping to change at page 18, line 13
request. request.
6.3.1. Processing a Request 6.3.1. Processing a Request
If the request contains one or more unknown comprehension-required If the request contains one or more unknown comprehension-required
attributes, the server replies with an error response with an error attributes, the server replies with an error response with an error
code of 420 (Unknown Attribute), and includes an UNKNOWN-ATTRIBUTES code of 420 (Unknown Attribute), and includes an UNKNOWN-ATTRIBUTES
attribute in the response that lists the unknown comprehension- attribute in the response that lists the unknown comprehension-
required attributes. required attributes.
The server then does any additional checking that the method or the Otherwise the server then does any additional checking that the
specific usage requires. If all the checks succeed, the server method or the specific usage requires. If all the checks succeed,
formulates a success response as described below. the server formulates a success response as described below.
When run over UDP or DTLS-over-UDP, a request received by the server When run over UDP or DTLS-over-UDP, a request received by the server
could be the first request of a transaction, or a retransmission. could be the first request of a transaction, or a retransmission.
The server MUST respond to retransmissions such that the following The server MUST respond to retransmissions such that the following
property is preserved: if the client receives the response to the property is preserved: if the client receives the response to the
retransmission and not the response that was sent to the original retransmission and not the response that was sent to the original
request, the overall state on the client and server is identical to request, the overall state on the client and server is identical to
the case where only the response to the original retransmission is the case where only the response to the original retransmission is
received, or where both responses are received (in which case the received, or where both responses are received (in which case the
client will use the first). The easiest way to meet this requirement client will use the first). The easiest way to meet this requirement
skipping to change at page 19, line 41 skipping to change at page 19, line 47
sent back on the same TCP connection as the request was received on. sent back on the same TCP connection as the request was received on.
The server is allowed to send responses in a different order than it The server is allowed to send responses in a different order than it
received the requests. received the requests.
6.3.2. Processing an Indication 6.3.2. Processing an Indication
If the indication contains unknown comprehension-required attributes, If the indication contains unknown comprehension-required attributes,
the indication is discarded and processing ceases. the indication is discarded and processing ceases.
The agent then does any additional checking that the method or the Otherwise the agent then does any additional checking that the method
specific usage requires. If all the checks succeed, the agent then or the specific usage requires. If all the checks succeed, the agent
processes the indication. No response is generated for an then processes the indication. No response is generated for an
indication. indication.
For the Binding method, no additional checking or processing is For the Binding method, no additional checking or processing is
required, unless the usage specifies otherwise. The mere receipt of required, unless the usage specifies otherwise. The mere receipt of
the message by the agent has refreshed the "bindings" in the the message by the agent has refreshed the "bindings" in the
intervening NATs. intervening NATs.
Since indications are not re-transmitted over UDP or DTLS-over-UDP Since indications are not re-transmitted over UDP or DTLS-over-UDP
(unlike requests), there is no need to handle re-transmissions of (unlike requests), there is no need to handle re-transmissions of
indications at the sending agent. indications at the sending agent.
6.3.3. Processing a Success Response 6.3.3. Processing a Success Response
If the success response contains unknown comprehension-required If the success response contains unknown comprehension-required
attributes, the response is discarded and the transaction is attributes, the response is discarded and the transaction is
considered to have failed. considered to have failed.
The client then does any additional checking that the method or the Otherwise the client then does any additional checking that the
specific usage requires. If all the checks succeed, the client then method or the specific usage requires. If all the checks succeed,
processes the success response. the client then processes the success response.
For the Binding method, the client checks that the XOR-MAPPED-ADDRESS For the Binding method, the client checks that the XOR-MAPPED-ADDRESS
attribute is present in the response. The client checks the address attribute is present in the response. The client checks the address
family specified. If it is an unsupported address family, the family specified. If it is an unsupported address family, the
attribute SHOULD be ignored. If it is an unexpected but supported attribute SHOULD be ignored. If it is an unexpected but supported
address family (for example, the Binding transaction was sent over address family (for example, the Binding transaction was sent over
IPv4, but the address family specified is IPv6), then the client MAY IPv4, but the address family specified is IPv6), then the client MAY
accept and use the value. accept and use the value.
6.3.4. Processing an Error Response 6.3.4. Processing an Error Response
If the error response contains unknown comprehension-required If the error response contains unknown comprehension-required
attributes, or if the error response does not contain an ERROR-CODE attributes, or if the error response does not contain an ERROR-CODE
attribute, then the transaction is simply considered to have failed. attribute, then the transaction is simply considered to have failed.
The client then does any processing specified by the authentication Otherwise the client then does any processing specified by the
mechanism (see Section 9). This may result in a new transaction authentication mechanism (see Section 9). This may result in a new
attempt. transaction attempt.
The processing at this point depends on the error code, the method, The processing at this point depends on the error code, the method,
and the usage; the following are the default rules: and the usage; the following are the default rules:
o If the error code is 300 through 399, the client SHOULD consider o If the error code is 300 through 399, the client SHOULD consider
the transaction as failed unless the ALTERNATE-SERVER extension the transaction as failed unless the ALTERNATE-SERVER extension
(Section 10) is being used. (Section 10) is being used.
o If the error code is 400 through 499, the client declares the o If the error code is 400 through 499, the client declares the
transaction failed; in the case of 420 (Unknown Attribute), the transaction failed; in the case of 420 (Unknown Attribute), the
response should contain a UNKNOWN-ATTRIBUTES attribute that gives response should contain a UNKNOWN-ATTRIBUTES attribute that gives
additional information. additional information.
o If the error code is 500 through 599, the client MAY resend the o If the error code is 500 through 599, the client MAY resend the
request; clients that do so MUST limit the number of times they do request; clients that do so MUST limit the number of times they do
this. this. Unless a specific error code specifies a different value,
the number of retransmissions SHOULD be limited to 4.
Any other error code causes the client to consider the transaction Any other error code causes the client to consider the transaction
failed. failed.
7. FINGERPRINT Mechanism 7. FINGERPRINT Mechanism
This section describes an optional mechanism for STUN that aids in This section describes an optional mechanism for STUN that aids in
distinguishing STUN messages from packets of other protocols when the distinguishing STUN messages from packets of other protocols when the
two are multiplexed on the same transport address. This mechanism is two are multiplexed on the same transport address. This mechanism is
optional, and a STUN usage must describe if and when it is used. The optional, and a STUN usage must describe if and when it is used. The
skipping to change at page 22, line 14 skipping to change at page 22, line 20
The syntax of the "stun" and "stuns" URIs are defined in Section 3.1 The syntax of the "stun" and "stuns" URIs are defined in Section 3.1
of [RFC7064]. STUN usages MAY define additional URI schemes. of [RFC7064]. STUN usages MAY define additional URI schemes.
8.1. STUN URI Scheme Semantics 8.1. STUN URI Scheme Semantics
If the <host> part of a "stun" URI contains an IP address, then this If the <host> part of a "stun" URI contains an IP address, then this
IP address is used directly to contact the server. A "stuns" URI IP address is used directly to contact the server. A "stuns" URI
containing an IP address MUST be rejected, unless the domain name is containing an IP address MUST be rejected, unless the domain name is
provided by the same mechanism that provided the STUN URI, and that provided by the same mechanism that provided the STUN URI, and that
domain name can be passed to the verification code. domain name can be passed to the (D)TLS SNI and certificate
verification code.
If the URI does not contain an IP address, the domain name contained If the URI does not contain an IP address, the domain name contained
in the <host> part is resolved to a transport address using the SRV in the <host> part is resolved to a transport address using the SRV
procedures specified in [RFC2782]. The DNS SRV service name is the procedures specified in [RFC2782]. The DNS SRV service name is the
content of the <scheme> part. The protocol in the SRV lookup is the content of the <scheme> part. The protocol in the SRV lookup is the
transport protocol the client will run STUN over: "udp" for UDP and transport protocol the client will run STUN over: "udp" for UDP and
"tcp" for TCP. "tcp" for TCP.
The procedures of RFC 2782 are followed to determine the server to The procedures of RFC 2782 are followed to determine the server to
contact. RFC 2782 spells out the details of how a set of SRV records contact. RFC 2782 spells out the details of how a set of SRV records
is sorted and then tried. However, RFC 2782 only states that the is sorted and then tried. However, RFC 2782 only states that the
client should "try to connect to the (protocol, address, service)" client should "try to connect to the (protocol, address, service)"
without giving any details on what happens in the event of failure. without giving any details on what happens in the event of failure.
When following these procedures, if the STUN transaction times out When following these procedures, if the STUN transaction times out
without receipt of a response, the client SHOULD retry the request to without receipt of a response, the client SHOULD retry the request to
the next server in the ordered defined by RFC 2782. Such a retry is the next server in the ordered defined by RFC 2782. Such a retry is
only possible for request/response transmissions, since indication only possible for request/response transmissions, since indication
transactions generate no response or timeout. transactions generate no response or timeout.
In addition, instead of querying either the A or the AAAA resource In addition, instead of querying either the A or the AAAA resource
records for a domain name, the client MUST query both and try the records for a domain name, a dual-stack IPv4/IPv6 client MUST query
requests with all the IP addresses received, as specified in both and try the requests with all the IP addresses received, as
[RFC8305]. specified in [RFC8305].
The default port for STUN requests is 3478, for both TCP and UDP. The default port for STUN requests is 3478, for both TCP and UDP.
The default port for STUN over TLS and STUN over DTLS requests is The default port for STUN over TLS and STUN over DTLS requests is
5349. Servers can run STUN over DTLS on the same port as STUN over 5349. Servers can run STUN over DTLS on the same port as STUN over
UDP if the server software supports determining whether the initial UDP if the server software supports determining whether the initial
message is a DTLS or STUN message. Servers can run STUN over TLS on message is a DTLS or STUN message. Servers can run STUN over TLS on
the same port as STUN over TCP if the server software supports the same port as STUN over TCP if the server software supports
determining whether the initial message is a TLS or STUN message. determining whether the initial message is a TLS or STUN message.
Administrators of STUN servers SHOULD use these ports in their SRV Administrators of STUN servers SHOULD use these ports in their SRV
skipping to change at page 23, line 46 skipping to change at page 24, line 4
that follow the MESSAGE-INTEGRITY-SHA256 attribute if the MESSAGE- that follow the MESSAGE-INTEGRITY-SHA256 attribute if the MESSAGE-
INTEGRITY attribute is not present, with the exception of the INTEGRITY attribute is not present, with the exception of the
FINGERPRINT attribute. FINGERPRINT attribute.
9.1. Short-Term Credential Mechanism 9.1. Short-Term Credential Mechanism
The short-term credential mechanism assumes that, prior to the STUN The short-term credential mechanism assumes that, prior to the STUN
transaction, the client and server have used some other protocol to transaction, the client and server have used some other protocol to
exchange a credential in the form of a username and password. This exchange a credential in the form of a username and password. This
credential is time-limited. The time limit is defined by the usage. credential is time-limited. The time limit is defined by the usage.
As an example, in the ICE usage [I-D.ietf-ice-rfc5245bis], the two As an example, in the ICE usage [I-D.ietf-ice-rfc5245bis], the two
endpoints use out-of-band signaling to agree on a username and endpoints use out-of-band signaling to agree on a username and
password, and this username and password are applicable for the password, and this username and password are applicable for the
duration of the media session. duration of the media session.
This credential is used to form a message-integrity check in each This credential is used to form a message-integrity check in each
request and in many responses. There is no challenge and response as request and in many responses. There is no challenge and response as
in the long-term mechanism; consequently, replay is prevented by in the long-term mechanism; consequently, replay is limited by virtue
virtue of the time-limited nature of the credential. of the time-limited nature of the credential.
9.1.1. HMAC Key 9.1.1. HMAC Key
For short-term credentials the HMAC key is defined as follow: For short-term credentials the HMAC key is defined as follow:
key = OpaqueString(password) key = OpaqueString(password)
where the OpaqueString profile is defined in [RFC8265]. where the OpaqueString profile is defined in [RFC8265]. The encoding
used is UTF-8 [RFC3629].
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.5 and the INTEGRITY attribute is computed as described in Section 14.5 and the
skipping to change at page 25, line 11 skipping to change at page 25, line 18
* 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 (Unauthenticated). of 401 (Unauthenticated).
* 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.6, 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, then use the same
password, compute the value for the message integrity as described password to compute the value for the message integrity as
in Section 14.5. If the resulting value does not match the described in Section 14.5. If the resulting value does not match
contents of the corresponding attribute (MESSAGE-INTEGRITY-SHA256 the contents of the corresponding attribute (MESSAGE-INTEGRITY-
or MESSAGE-INTEGRITY): SHA256 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 (Unauthenticated). of 401 (Unauthenticated).
* 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.
If these checks pass, the agent continues to process the request or If these checks pass, the agent continues to process the request or
indication. Any response generated by a server to a request that indication. Any response generated by a server to a request that
skipping to change at page 26, line 15 skipping to change at page 26, line 22
the contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 the contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
attribute, respectively, the response is considered authenticated. attribute, respectively, the response is considered authenticated.
If the value does not match, or if both MESSAGE-INTEGRITY and If the value does not match, or if both MESSAGE-INTEGRITY and
MESSAGE-INTEGRITY-SHA256 were absent, the processing depends on the MESSAGE-INTEGRITY-SHA256 were absent, the processing depends on the
request been sent over a reliable or an unreliable transport. request been sent over a reliable or an unreliable transport.
If the request was sent over an unreliable transport, the response If the request was sent over an unreliable transport, the response
MUST be discarded, as if it was never received. This means that MUST be discarded, as if it was never received. This means that
retransmits, if applicable, will continue. If all the responses retransmits, if applicable, will continue. If all the responses
received are discarded then instead of signalling a timeout after received are discarded then instead of signalling a timeout after
ending the transaction the layer MUST signal that an attack took ending the transaction the layer MUST signal that the integrity
place. protection was violated.
If the request was sent over a reliable transport, the response MUST If the request was sent over a reliable transport, the response MUST
be discarded and the layer MUST immediately end the transaction and be discarded and the layer MUST immediately end the transaction and
signal that an attack took place. signal that the integrity protection was violated.
9.1.5. Sending Subsequent Requests 9.1.5. Sending Subsequent Requests
A client sending subsequent requests to the same server MUST send A client sending subsequent requests to the same server MUST send
only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY attribute only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY attribute
that matches the attribute that was received in the response to the that matches the attribute that was received in the response to the
initial request. Here same server means same IP address and port initial request. Here same server means same IP address and port
number, not just the same URI or SRV lookup result. number, not just the same URI or SRV lookup result.
9.2. Long-Term Credential Mechanism 9.2. Long-Term Credential Mechanism
skipping to change at page 26, line 46 skipping to change at page 27, line 5
until the user is no longer a subscriber of the system, or is until the user is no longer a subscriber of the system, or is
changed. This is basically a traditional "log-in" username and changed. This is basically a traditional "log-in" username and
password given to users. password given to users.
Because these usernames and passwords are expected to be valid for Because these usernames and passwords are expected to be valid for
extended periods of time, replay prevention is provided in the form extended periods of time, replay prevention is provided in the form
of a digest challenge. In this mechanism, the client initially sends of a digest challenge. In this mechanism, the client initially sends
a request, without offering any credentials or any integrity checks. a request, without offering any credentials or any integrity checks.
The server rejects this request, providing the user a realm (used to The server rejects this request, providing the user a realm (used to
guide the user or agent in selection of a username and password) and guide the user or agent in selection of a username and password) and
a nonce. The nonce provides the replay protection. It is a cookie, a nonce. The nonce provides a limited replay protection. It is a
selected by the server, and encoded in such a way as to indicate a cookie, selected by the server, and encoded in such a way as to
duration of validity or client identity from which it is valid. The indicate a duration of validity or client identity from which it is
client retries the request, this time including its username and the valid. Only the server needs to know about the internal structure of
realm, and echoing the nonce provided by the server. The client also the cookie. The client retries the request, this time including its
includes a message-integrity, which provides an HMAC over the entire username and the realm, and echoing the nonce provided by the server.
The client also includes one of the message-integrity attributes
defined in this document, which provides an HMAC over the entire
request, including the nonce. The server validates the nonce and request, including the nonce. The server validates the nonce and
checks the message integrity. If they match, the request is checks the message integrity. If they match, the request is
authenticated. If the nonce is no longer valid, it is considered authenticated. If the nonce is no longer valid, it is considered
"stale", and the server rejects the request, providing a new nonce. "stale", and the server rejects the request, providing a new nonce.
In subsequent requests to the same server, the client reuses the In subsequent requests to the same server, the client reuses the
nonce, username, realm, and password it used previously. In this nonce, username, realm, and password it used previously. In this
way, subsequent requests are not rejected until the nonce becomes way, subsequent requests are not rejected until the nonce becomes
invalid by the server, in which case the rejection provides a new invalid by the server, in which case the rejection provides a new
nonce to the client. nonce to the client.
Note that the long-term credential mechanism cannot be used to Note that the long-term credential mechanism cannot be used to
protect indications, since indications cannot be challenged. Usages protect indications, since indications cannot be challenged. Usages
utilizing indications must either use a short-term credential or omit utilizing indications must either use a short-term credential or omit
authentication and message integrity for them. authentication and message integrity for them.
To indicate that it supports this specification, a server MUST To indicate that it supports this specification, a server MUST
prepend the NONCE attribute value with the character string composed prepend the NONCE attribute value with the character string composed
of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648] of "obMatJos2" concatenated with the (4 character) Base64 [RFC4648]
encoding of the 24 bit STUN Security Features as defined in 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 Section 18.1. The 24 bit Security Feature set is encoded as 3 bytes,
integer in network order. If no security features are used, then the with bit 0 as the most significant bit of the first byte and bit 23
value 0 MUST be encoded instead. For the remainder of this document as the least significant bit of the third byte. If no security
the term "nonce cookie" will refer to the complete 13 character features are used, then a byte array with all 24 bits set to zero
string prepended to the NONCE attribute value. MUST be encoded instead. For the remainder of this document the term
"nonce cookie" will refer to the complete 13 character string
prepended to the NONCE attribute value.
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. Bid Down Attack Prevention 9.2.1. Bid Down Attack Prevention
This document introduces two new security features that provide the This document introduces two new security features that provide the
ability to choose the algorithm used for password protection as well ability to choose the algorithm used for password protection as well
as the ability to use an anonymous username. Both of these as the ability to use an anonymous username. Both of these
capabilities are optional in order to remain backwards compatible capabilities are optional in order to remain backwards compatible
with previous versions of the STUN protocol. with previous versions of the STUN protocol.
These new capabilities are subject to bid down attacks whereby an These new capabilities are subject to bid-down attacks whereby an
attacker in the message path can remove these capabilities and force attacker in the message path can remove these capabilities and force
weaker security properties. To prevent these kinds of attacks from weaker security properties. To prevent these kinds of attacks from
going undetected, the nonce is enhanced with additional information. going undetected, the nonce is enhanced with additional information.
The value of the "nonce cookie" will vary based on the specific STUN The value of the "nonce cookie" will vary based on the specific STUN
Security Features bit values selected. When this document makes Security Features bit values selected. When this document makes
reference to the "nonce cookie" in a section discussing a specific reference to the "nonce cookie" in a section discussing a specific
STUN Security Feature it is understood that the corresponding STUN STUN Security Feature it is understood that the corresponding STUN
Security Feature bit in the "nonce cookie" is set to 1. Security Feature bit in the "nonce cookie" is set to 1.
For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS
security feature, it is implied that the "Password algorithms" bit, security feature, it is implied that the "Password algorithms" bit,
as defined in Section 17.1, is set to 1 in the "nonce cookie". as defined in Section 18.1, is set to 1 in the "nonce cookie".
9.2.2. HMAC Key 9.2.2. HMAC Key
For long-term credentials that do not use a different algorithm, as For long-term credentials that do not use a different algorithm, as
specified by the PASSWORD-ALGORITHM attribute, the key is 16 bytes: specified by the PASSWORD-ALGORITHM attribute, the key is 16 bytes:
key = MD5(username ":" OpaqueString(realm) ":" OpaqueString(password)) key = MD5(username ":" OpaqueString(realm)
":" OpaqueString(password))
Where MD5 is defined in [RFC1321] and the OpaqueString profile is Where MD5 is defined in [RFC1321] and [RFC6151], and the OpaqueString
defined in [RFC8265]. profile is defined in [RFC8265]. The encoding used is UTF-8
[RFC3629].
The 16-byte key is formed by taking the MD5 hash of the result of The 16-byte key is formed by taking the MD5 hash of the result of
concatenating the following five fields: (1) the username, with any concatenating the following five fields: (1) the username, with any
quotes and trailing nulls removed, as taken from the USERNAME quotes and trailing nulls removed, as taken from the USERNAME
attribute (in which case OpaqueString has already been applied); (2) attribute (in which case OpaqueString has already been applied); (2)
a single colon; (3) the realm, with any quotes and trailing nulls a single colon; (3) the realm, with any quotes and trailing nulls
removed and after processing using OpaqueString; (4) a single colon; removed and after processing using OpaqueString; (4) a single colon;
and (5) the password, with any trailing nulls removed and after and (5) the password, with any trailing nulls removed and after
processing using OpaqueString. For example, if the username was processing using OpaqueString. For example, if the username was
'user', the realm was 'realm', and the password was 'pass', then the 'user', the realm was 'realm', and the password was 'pass', then the
16-byte HMAC key would be the result of performing an MD5 hash on the 16-byte HMAC key would be the result of performing an MD5 hash on the
string 'user:realm:pass', the resulting hash being string 'user:realm:pass', the resulting hash being
0x8493fbc53ba582fb4c044c456bdc40eb. 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 [RFC3261]. facilitates deployment in systems that also utilize SIP [RFC3261].
Typically, SIP systems utilizing SIP's digest authentication Typically, SIP systems utilizing SIP's digest authentication
mechanism do not actually store the password in the database. mechanism do not actually store the password in the database.
Rather, they store a value called H(A1), which is equal to the key Rather, they store a value called H(A1), which is equal to the key
defined above. defined above. For example, this mechanism can be used with the
authentication extensions defined in [RFC5090].
When a PASSWORD-ALGORITHM is used, the key length and algorithm to When a PASSWORD-ALGORITHM is used, the key length and algorithm to
use are described in Section 17.5.1. use are described in Section 18.5.1.
9.2.3. 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
hostname, if the DNS procedures of Section 8 are used, else IP hostname, if the DNS procedures of Section 8 are used, else IP
address if not). In the second case, the client is submitting a address if not). In the second case, the client is submitting a
subsequent request once a previous request/response transaction has subsequent request once a previous request/response transaction has
completed successfully. Forming a request as a consequence of a 401 completed successfully. Forming a request as a consequence of a 401
or 438 error response is covered in Section 9.2.5 and is not or 438 error response is covered in Section 9.2.5 and is not
skipping to change at page 29, line 26 skipping to change at page 29, line 43
If the client has not completed a successful request/response If the client has not completed a successful request/response
transaction with the server, it MUST omit the USERNAME, USERHASH, transaction with the server, it MUST omit the USERNAME, USERHASH,
MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256, REALM, NONCE, PASSWORD- MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256, REALM, NONCE, PASSWORD-
ALGORITHMS, and PASSWORD-ALGORITHM attributes. In other words, the ALGORITHMS, and PASSWORD-ALGORITHM attributes. In other words, the
first request is sent as if there were no authentication or message first request is sent as if there were no authentication or message
integrity applied. integrity applied.
9.2.3.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, the client will
client will have been presented a realm and nonce by the server, and have been presented a realm and nonce by the server, and selected a
selected a username and password with which it authenticated. The username and password with which it authenticated. The client SHOULD
client SHOULD cache the username, password, realm, and nonce for cache the username, password, realm, and nonce for subsequent
subsequent communications with the server. When the client sends a communications with the server. When the client sends a subsequent
subsequent request, it MUST include either the USERNAME or USERHASH, request, it MUST include either the USERNAME or USERHASH, REALM,
REALM, NONCE, and PASSWORD-ALGORITHM attributes with these cached NONCE, and PASSWORD-ALGORITHM attributes with these cached values.
values. It MUST include a MESSAGE-INTEGRITY attribute or a MESSAGE- It MUST include a MESSAGE-INTEGRITY attribute or a MESSAGE-INTEGRITY-
INTEGRITY-SHA256 attribute, computed as described in Section 14.5 and SHA256 attribute, computed as described in Section 14.5 and
Section 14.6 using the cached password. The choice between the two Section 14.6 using the cached password. The choice between the two
attributes depends on the attribute received in the response to the attributes depends on the attribute received in the response to the
first request. first request.
9.2.4. 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. Note that
it is RECOMMENDED that the REALM value be the domain name of the
provider of the STUN server:
o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE- o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY-SHA256 attribute, the server MUST generate an error INTEGRITY-SHA256 attribute, the server MUST generate an error
response with an error code of 401 (Unauthenticated). This response with an error code of 401 (Unauthenticated). This
response MUST include a REALM value. It is RECOMMENDED that the response MUST include a REALM value. The response MUST include a
REALM value be the domain name of the provider of the STUN server. NONCE, selected by the server. The server MUST NOT choose the
The response MUST include a NONCE, selected by the server. The same NONCE for two requests unless they have the same source IP
server MUST NOT choose the same NONCE for two requests unless they address and port. The server MAY support alternate password
have the same source IP address and port. The server MAY support algorithms, in which case it can list them in preferential order
alternate password algorithms, in which case it can list them in in a PASSWORD-ALGORITHMS attribute. If the server adds a
preferential order in a PASSWORD-ALGORITHMS attribute. If the PASSWORD-ALGORITHMS attribute it MUST set the STUN Security
server adds a PASSWORD-ALGORITHMS attribute it MUST set the STUN Feature "Password algorithms" bit set to 1. The server MAY
Security Feature "Password algorithms" bit set to 1. The server support anonymous username, in which case it MUST set the STUN
MAY support anonymous username, in which case it MUST set the STUN
Security Feature "Username anonymity" bit set to 1. The response Security Feature "Username anonymity" bit set to 1. The response
SHOULD NOT contain a USERNAME, USERHASH, MESSAGE-INTEGRITY or SHOULD NOT contain a USERNAME, USERHASH, MESSAGE-INTEGRITY or
MESSAGE-INTEGRITY-SHA256 attribute. MESSAGE-INTEGRITY-SHA256 attribute.
Note: Reusing a NONCE for different source IP addresses or ports was Note: Reusing a NONCE for different source IP addresses or ports was
not explicitly forbidden in [RFC5389]. not explicitly forbidden in [RFC5389].
o If the message contains a MESSAGE-INTEGRITY or a MESSAGE- o If the message contains a MESSAGE-INTEGRITY or a MESSAGE-
INTEGRITY-SHA256 attribute, but is missing either the USERNAME or INTEGRITY-SHA256 attribute, but is missing either the USERNAME or
USERHASH, REALM, or NONCE attribute, the server MUST generate an USERHASH, REALM, or NONCE attribute, the server MUST generate an
error response with an error code of 400 (Bad Request). This error response with an error code of 400 (Bad Request). This
response SHOULD NOT include a USERNAME, USERHASH, NONCE, or REALM. response SHOULD NOT include a USERNAME, USERHASH, NONCE, or REALM.
The response cannot contain a MESSAGE-INTEGRITY or MESSAGE- The response cannot contain a MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY-SHA256 attribute, as the attributes required to generate INTEGRITY-SHA256 attribute, as the attributes required to generate
them are missing. them are missing.
o If the NONCE attribute starts with the "nonce cookie" with the o If the NONCE attribute starts with the "nonce cookie" with the
STUN Security Feature "Password algorithm" bit set to 1, the STUN Security Feature "Password algorithms" bit set to 1, the
server performs these checks in the order specified: server performs these checks in the order specified:
* If the request contains neither PASSWORD-ALGORITHMS nor * If the 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-ALGORITHM were MD5 (Note that if the PASSWORD-
PASSWORD-ALGORITHMS attribute did not contain MD5, this will ALGORITHMS attribute is present but does not contain MD5, this
result in a 400 Bad Request in a later step below). will result in a 400 Bad Request in a later step below).
* Otherwise, unless (1) PASSWORD-ALGORITHM and PASSWORD- * Otherwise, unless (1) PASSWORD-ALGORITHM and PASSWORD-
ALGORITHMS are both present, (2) PASSWORD-ALGORITHMS matches ALGORITHMS are both present, (2) PASSWORD-ALGORITHMS matches
the value sent in the response that sent this NONCE, and (3) the value sent in the response that sent this NONCE, and (3)
PASSWORD-ALGORITHM matches one of the entries in PASSWORD- PASSWORD-ALGORITHM matches one of the entries in PASSWORD-
ALGORITHMS, the server MUST generate an error response with an ALGORITHMS, the server MUST generate an error response with an
error code of 400 (Bad Request). error code of 400 (Bad Request).
o If the NONCE is no longer valid and at the same time the MESSAGE- o If the NONCE is no longer valid and at the same time the MESSAGE-
INTEGRITY or a MESSAGE-INTEGRITY-SHA256 attribute is invalid, the INTEGRITY or a MESSAGE-INTEGRITY-SHA256 attribute is invalid, the
server MUST generate an error response with an error code of 401. server MUST generate an error response with an error code of 401.
This response MUST include NONCE, REALM, and PASSWORD-ALGORITHMS This response MUST include NONCE, REALM, and PASSWORD-ALGORITHMS
attributes and SHOULD NOT include the USERNAME or USERHASH attributes and SHOULD NOT include the USERNAME or USERHASH
attribute. The NONCE attribute value MUST be valid. The response attribute. The NONCE attribute value MUST be valid. The response
MAY include a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MAY include a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
attribute, using the previous NONCE to calculate it. attribute, using the previous NONCE to calculate it.
o If the NONCE is no longer valid, the server MUST generate an error o If the NONCE is no longer valid, the server MUST generate an error
response with an error code of 438 (Stale Nonce). This response response with an error code of 438 (Stale Nonce). This response
MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and
SHOULD NOT include the USERNAME, USERHASH attribute, The NONCE SHOULD NOT include the USERNAME, USERHASH attribute. The NONCE
attribute value MUST be valid. The response MAY include a attribute value MUST be valid. The response MAY include a
MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, using the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, using the
previous NONCE to calculate it. Servers can revoke nonces in previous NONCE to calculate it. Servers can revoke nonces in
order to provide additional security. See Section 5.4 of order to provide additional security. See Section 5.4 of
[RFC7616] for guidelines. [RFC7616] for guidelines.
o If the value of the USERNAME or USERHASH attribute is not valid, o If the value of the USERNAME or USERHASH attribute is not valid,
the server MUST generate an error response with an error code of the server MUST generate an error response with an error code of
401 (Unauthenticated). This response MUST include a REALM value. 401 (Unauthenticated). This response MUST include a REALM value.
It is RECOMMENDED that the REALM value be the domain name of the The response MUST include a NONCE, selected by the server. The
provider of the STUN server. The response MUST include a NONCE, response MUST include a PASSWORD-ALGORITHMS attribute. The
selected by the server. The response MUST include a PASSWORD- response SHOULD NOT contain a USERNAME, USERHASH attribute. The
ALGORITHMS attribute. The response SHOULD NOT contain a USERNAME, response MAY include a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-
USERHASH attribute. The response MAY include a MESSAGE-INTEGRITY SHA256 attribute, using the previous key to calculate it.
or MESSAGE-INTEGRITY-SHA256 attribute, using the previous password
to calculate it.
o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the
value for the message integrity as described in Section 14.6, value for the message integrity as described in Section 14.6,
using the password associated with the username. Else, using the using the password associated with the username. Else, using the
same password, compute the value for the message integrity as same password, compute the value for the message integrity as
described in Section 14.5. If the resulting value does not match described in Section 14.5. If the resulting value does not match
the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE- the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE-
INTEGRITY-SHA256 attribute, the server MUST reject the request INTEGRITY-SHA256 attribute, the server MUST reject the request
with an error response. This response MUST use an error code of with an error response. This response MUST use an error code of
401 (Unauthenticated). It MUST include REALM and NONCE attributes 401 (Unauthenticated). It MUST include REALM and NONCE attributes
skipping to change at page 32, line 5 skipping to change at page 32, line 21
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, USERNAME and USERHASH INTEGRITY-SHA256 attribute. The REALM, NONCE, USERNAME and USERHASH
attributes SHOULD NOT be included. attributes SHOULD NOT be included.
9.2.5. 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
(Unauthenticated) or 438 (Stale Nonce), the client MUST test if the (Unauthenticated) or 438 (Stale Nonce), the client MUST test if the
NONCE attribute value starts with the "nonce cookie". If the test NONCE attribute value starts with the "nonce cookie". If the test
succeeds and the "nonce cookie" has the STUN Security Feature succeeds and the "nonce cookie" has the STUN Security Feature
"Password algorithm" bit set to 1 but no PASSWORD-ALGORITHMS "Password algorithms" bit set to 1 but no PASSWORD-ALGORITHMS
attribute is present, then the client MUST NOT retry the request with attribute is present, then the client MUST NOT retry the request with
a new transaction. 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
(Unauthenticated), the client SHOULD retry the request with a new (Unauthenticated), the client SHOULD retry the request with a new
transaction. This request MUST contain a USERNAME or a USERHASH, transaction. This request MUST contain a USERNAME or a USERHASH,
determined by the client as the appropriate username for the REALM determined by the client as the appropriate username for the REALM
from the error response. If the "nonce cookie" was present and had from the error response. If the "nonce cookie" was present and had
the STUN Security Feature "Username anonymity" bit set to 1 then the the STUN Security Feature "Username anonymity" bit set to 1 then the
USERHASH attribute MUST be used, else the USERNAME attribute MUST be USERHASH attribute MUST be used, else the USERNAME attribute MUST be
skipping to change at page 32, line 38 skipping to change at page 33, line 6
changing the USERNAME or USERHASH or REALM or its associated changing the USERNAME or USERHASH or REALM or its associated
password, from the 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 either the USERNAME or USERHASH, REALM and either MUST also include either the USERNAME or USERHASH, REALM and either
the MESSAGE-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 For all other responses, if the NONCE attribute starts with the
"nonce cookie" with the STUN Security Feature "Password algorithm" "nonce cookie" with the STUN Security Feature "Password algorithms"
bit set to 1 but PASSWORD-ALGORITHMS is not present, the response bit set to 1 but PASSWORD-ALGORITHMS is not present, the response
MUST be ignored. MUST be ignored.
If the response is an error response with an error code of 400, and If the response is an error response with an error code of 400, and
does not contains either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY- does not contains either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-
SHA256 attribute then the response MUST be discarded, as if it was SHA256 attribute then 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.
Note: In that case the 400 will never reach the application, Note: In that case the 400 will never reach the application,
skipping to change at page 33, line 20 skipping to change at page 33, line 34
contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
attribute, the response is considered authenticated. If the value attribute, the response is considered authenticated. If the value
does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY- does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-
SHA256 were absent, the processing depends on the request been sent SHA256 were absent, the processing depends on the request been sent
over a reliable or an unreliable transport. over a reliable or an unreliable transport.
If the request was sent over an unreliable transport, the response If the request was sent over an unreliable transport, the response
MUST be discarded, as if it was never received. This means that MUST be discarded, as if it was never received. This means that
retransmits, if applicable, will continue. If all the reponses retransmits, if applicable, will continue. If all the reponses
received are discarded then instead of signalling a timeout after received are discarded then instead of signalling a timeout after
ending the transaction the layer MUST signal that an attack took ending the transaction the layer MUST signal that the integrity
place. protection was violated.
If the request was sent over a reliable transport, the response MUST If the request was sent over a reliable transport, the response MUST
be discarded and the layer MUST immediately end the transaction and be discarded and the layer MUST immediately end the transaction and
signal that an attack took place. signal that the integrity protection was violated.
If the response contains a PASSWORD-ALGORITHMS attribute, the If the response contains a PASSWORD-ALGORITHMS attribute, all the
subsequent request MUST be authenticated using MESSAGE-INTEGRITY- subsequent requests MUST be authenticated using MESSAGE-INTEGRITY-
SHA256 only. SHA256 only.
10. ALTERNATE-SERVER Mechanism 10. ALTERNATE-SERVER Mechanism
This section describes a mechanism in STUN that allows a server to This section describes a mechanism in STUN that allows a server to
redirect a client to another server. This extension is optional, and redirect a client to another server. This extension is optional, and
a usage must define if and when this extension is used. The a usage must define if and when this extension is used. The
ALTERNATE-SERVER attribute carries an IP address. ALTERNATE-SERVER attribute carries an IP address.
A server using this extension redirects a client to another server by A server using this extension redirects a client to another server by
replying to a request message with an error response message with an replying to a request message with an error response message with an
error code of 300 (Try Alternate). The server MUST include an error code of 300 (Try Alternate). The server MUST include at least
ALTERNATE-SERVER attribute in the error response. The error response one ALTERNATE-SERVER attribute in the error response, which MUST
message MAY be authenticated; however, there are use cases for contain an IP address of the same family as the source IP address of
ALTERNATE-SERVER where authentication of the response is not possible the request message. The server SHOULD include an additional
or practical. If the transaction uses TLS or DTLS and if the ALTERNATE-SERVER attribute, after the mandatory one, that contains an
transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute IP address of the other family than the source IP address of the
and if the server wants to redirect to a server that uses a different request message. The error response message MAY be authenticated;
certificate, then it MUST include an ALTERNATE-DOMAIN attribute however, there are use cases for ALTERNATE-SERVER where
containing the subjectAltName of that certificate. authentication of the response is not possible or practical. If the
transaction uses TLS or DTLS and if the transaction is authenticated
by a MESSAGE-INTEGRITY-SHA256 attribute and if the server wants to
redirect to a server that uses a different certificate, then it MUST
include an ALTERNATE-DOMAIN attribute containing the name inside the
subjectAltName of that certificate. This series of conditions on the
MESSAGE-INTEGRITY-SHA256 attribute indicates that the transaction is
authenticated and that the client implements this specification and
therefore can process the ALTERNATE-DOMAIN attribute.
A client using this extension handles a 300 (Try Alternate) error A client using this extension handles a 300 (Try Alternate) error
code as follows. The client looks for an ALTERNATE-SERVER attribute code as follows. The client looks for an ALTERNATE-SERVER attribute
in the error response. If one is found, then the client considers in the error response. If one is found, then the client considers
the current transaction as failed, and reattempts the request with the current transaction as failed, and reattempts the request with
the server specified in the attribute, using the same transport the server specified in the attribute, using the same transport
protocol used for the previous request. That request, if protocol used for the previous request. That request, if
authenticated, MUST utilize the same credentials that the client authenticated, MUST utilize the same credentials that the client
would have used in the request to the server that performed the would have used in the request to the server that performed the
redirection. If the transport protocol uses TLS or DTLS, then the redirection. If the transport protocol uses TLS or DTLS, then the
client looks for an ALTERNATE-DOMAIN attribute. If the attribute is client looks for an ALTERNATE-DOMAIN attribute. If the attribute is
found, the domain MUST be used to validate the certificate using the found, the domain MUST be used to validate the certificate using the
recommendations in [RFC6125]. If the attribute is not found, the recommendations in [RFC6125]. The certificate MUST contain an
identifier of type DNS-ID or CN-ID, eventually with wildcards, but
not of type SRV-ID or URI-ID. If the attribute is not found, the
same domain that was used for the original request MUST be used to same domain that was used for the original request MUST be used to
validate the certificate. If the client has been redirected to a validate the certificate. If the client has been redirected to a
server to which it has already sent this request within the last five server to which it has already sent this request within the last five
minutes, it MUST ignore the redirection and consider the transaction minutes, it MUST ignore the redirection and consider the transaction
to have failed. This prevents infinite ping-ponging between servers to have failed. This prevents infinite ping-ponging between servers
in case of redirection loops. in case of redirection loops.
11. Backwards Compatibility with RFC 3489 11. Backwards Compatibility with RFC 3489
In addition to the backward compatibility already described in In addition to the backward compatibility already described in
skipping to change at page 34, line 48 skipping to change at page 35, line 26
server functionality became the sole STUN Usage defined in that server functionality became the sole STUN Usage defined in that
document. This STUN Usage is also known as Basic STUN Server. document. This STUN Usage is also known as Basic STUN Server.
The STUN server MUST support the Binding method. It SHOULD NOT The STUN server MUST support the Binding method. It SHOULD NOT
utilize the short-term or long-term credential mechanism. This is utilize the short-term or long-term credential mechanism. This is
because the work involved in authenticating the request is more than because the work involved in authenticating the request is more than
the work in simply processing it. It SHOULD NOT utilize the the work in simply processing it. It SHOULD NOT utilize the
ALTERNATE-SERVER mechanism for the same reason. It MUST support UDP ALTERNATE-SERVER mechanism for the same reason. It MUST support UDP
and TCP. It MAY support STUN over TCP/TLS or STUN over UDP/DTLS; and TCP. It MAY support STUN over TCP/TLS or STUN over UDP/DTLS;
however, DTLS and TLS provide minimal security benefits in this basic however, DTLS and TLS provide minimal security benefits in this basic
mode of operation. It MAY utilize the FINGERPRINT mechanism but MUST mode of operation. It does not require a keep-alive mechanism
NOT require it. Since the stand-alone server only runs STUN, because a TCP or TLS-over-TCP connection is closed after the end of
FINGERPRINT provides no benefit. Requiring it would break the Binding transaction. It MAY utilize the FINGERPRINT mechanism
but MUST NOT require it. Since the stand-alone server only runs
STUN, FINGERPRINT provides no benefit. Requiring it would break
compatibility with RFC 3489, and such compatibility is desirable in a compatibility with RFC 3489, and such compatibility is desirable in a
stand-alone server. Stand-alone STUN servers SHOULD support stand-alone server. Stand-alone STUN servers SHOULD support
backwards compatibility with [RFC3489] clients, as described in backwards compatibility with [RFC3489] clients, as described in
Section 11. Section 11.
It is RECOMMENDED that administrators of STUN servers provide DNS It is RECOMMENDED that administrators of STUN servers provide DNS
entries for those servers as described in Section 8. If both A and entries for those servers as described in Section 8. If both A and
AAAA Resource Records are returned then the client can simultaneously AAAA Resource Records are returned then the client can simultaneously
send STUN Binding requests to the IPv4 and IPv6 addresses (as send STUN Binding requests to the IPv4 and IPv6 addresses (as
specified in [RFC8305]), as the Binding request is idempotent. Note specified in [RFC8305]), as the Binding request is idempotent. Note
skipping to change at page 35, line 45 skipping to change at page 36, line 29
o What transports are used. If DTLS-over-UDP is used then o What transports are used. If DTLS-over-UDP is used then
implementing the denial-of-service countermeasure described in implementing the denial-of-service countermeasure described in
Section 4.2.1 of [RFC6347] is mandatory. Section 4.2.1 of [RFC6347] is mandatory.
o What authentication and message-integrity mechanisms are used. o What authentication and message-integrity mechanisms are used.
o The considerations around manual vs. automatic key derivation for o The considerations around manual vs. automatic key derivation for
the integrity mechanism, as discussed in [RFC4107]. the integrity mechanism, as discussed in [RFC4107].
o What mechanisms are used to distinguish STUN messages from other o What mechanisms are used to distinguish STUN messages from other
messages. When STUN is run over TCP, a framing mechanism may be messages. When STUN is run over TCP or TLS-over-TCP, a framing
required. mechanism may be required.
o How a STUN client determines the IP address and port of the STUN o How a STUN client determines the IP address and port of the STUN
server. server.
o How simultaneous use of IPv4 and IPv6 addresses (Happy Eyeballs o How simultaneous use of IPv4 and IPv6 addresses (Happy Eyeballs
[RFC8305]) works with non-idempotent transactions when both [RFC8305]) works with non-idempotent transactions when both
address families are found for the STUN server. address families are found for the STUN server.
o Whether backwards compatibility to RFC 3489 is required. o Whether backwards compatibility to RFC 3489 is required.
o What optional attributes defined here (such as FINGERPRINT and o What optional attributes defined here (such as FINGERPRINT and
ALTERNATE-SERVER) or in other extensions are required. ALTERNATE-SERVER) or in other extensions are required.
o If MESSAGE-INTEGRITY-SHA256 truncation is permitted, and the o If MESSAGE-INTEGRITY-SHA256 truncation is permitted, and the
limits permitted for truncation. limits permitted for truncation.
o The keep-alive mechanism if STUN is run over TCP or TLS-over-TCP.
o If Anycast addresses can be used for the server in case TCP or
TLS-over-TCP, or authentication are used.
In addition, any STUN usage must consider the security implications In addition, any STUN usage must consider the security implications
of using STUN in that usage. A number of attacks against STUN are of using STUN in that usage. A number of attacks against STUN are
known (see the Security Considerations section in this document), and known (see the Security Considerations section in this document), and
any usage must consider how these attacks can be thwarted or any usage must consider how these attacks can be thwarted or
mitigated. mitigated.
Finally, a usage must consider whether its usage of STUN is an Finally, a usage must consider whether its usage of STUN is an
example of the Unilateral Self-Address Fixing approach to NAT example of the Unilateral Self-Address Fixing approach to NAT
traversal, and if so, address the questions raised in RFC 3424 traversal, and if so, address the questions raised in RFC 3424
[RFC3424]. [RFC3424].
skipping to change at page 36, line 51 skipping to change at page 37, line 39
| Value (variable) .... | Value (variable) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of STUN Attributes Figure 4: Format of STUN Attributes
The value in the length field MUST contain the length of the Value The value in the length field MUST contain the length of the Value
part of the attribute, prior to padding, measured in bytes. Since part of the attribute, prior to padding, measured in bytes. Since
STUN aligns attributes on 32-bit boundaries, attributes whose content STUN aligns attributes on 32-bit boundaries, attributes whose content
is not a multiple of 4 bytes are padded with 1, 2, or 3 bytes of is not a multiple of 4 bytes are padded with 1, 2, or 3 bytes of
padding so that its value contains a multiple of 4 bytes. The padding so that its value contains a multiple of 4 bytes. The
padding bits are ignored, and may be any value. padding bits MUST be set to zero on sending and must be ignored by
the receiver.
Any attribute type MAY appear more than once in a STUN message. Any attribute type MAY appear more than once in a STUN message.
Unless specified otherwise, the order of appearance is significant: Unless specified otherwise, the order of appearance is significant:
only the first occurrence needs to be processed by a receiver, and only the first occurrence needs to be processed by a receiver, and
any duplicates MAY be ignored by a receiver. any duplicates MAY be ignored by a receiver.
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.3. set defined by this specification is found in Section 18.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 38, line 32 skipping to change at page 39, line 26
|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 XOR'ing the mapped port with the most
XOR'ing it with the most significant 16 bits of the magic cookie, and significant 16 bits of the magic cookie. If the IP address family is
then the converting the result to network byte order. If the IP IPv4, X-Address is computed by XOR'ing the mapped IP address with the
address family is IPv4, X-Address is computed by taking the mapped IP magic cookie. If the IP address family is IPv6, X-Address is
address in host byte order, XOR'ing it with the magic cookie, and computed by XOR'ing the mapped IP address with the concatenation of
converting the result to network byte order. If the IP address the magic cookie and the 96-bit transaction ID. In all cases, the
family is IPv6, X-Address is computed by taking the mapped IP address XOR operation works on its inputs in network byte order (that is, the
in host byte order, XOR'ing it with the concatenation of the magic order they will be encoded in the message).
cookie and the 96-bit transaction ID, and converting the result to
network byte order.
The rules for encoding and processing the first 8 bits of the The rules for encoding and processing the first 8 bits of the
attribute's value, the rules for handling multiple occurrences of the attribute's value, the rules for handling multiple occurrences of the
attribute, and the rules for processing address families are the same attribute, and the rules for processing address families are the same
as for MAPPED-ADDRESS. as for MAPPED-ADDRESS.
Note: XOR-MAPPED-ADDRESS and MAPPED-ADDRESS differ only in their Note: XOR-MAPPED-ADDRESS and MAPPED-ADDRESS differ only in their
encoding of the transport address. The former encodes the transport encoding of the transport address. The former encodes the transport
address by exclusive-or'ing it with the magic cookie. The latter address by exclusive-or'ing it with the magic cookie. The latter
encodes it directly in binary. RFC 3489 originally specified only encodes it directly in binary. RFC 3489 originally specified only
MAPPED-ADDRESS. However, deployment experience found that some NATs MAPPED-ADDRESS. However, deployment experience found that some NATs
rewrite the 32-bit binary payloads containing the NAT's public IP rewrite the 32-bit binary payloads containing the NAT's public IP
address, such as STUN's MAPPED-ADDRESS attribute, in the well-meaning address, such as STUN's MAPPED-ADDRESS attribute, in the well-meaning
but misguided attempt at providing a generic ALG function. Such but misguided attempt at providing a generic Application Layer
behavior interferes with the operation of STUN and also causes Gateway (ALG) function. Such behavior interferes with the operation
failure of STUN's message-integrity checking. of STUN and also causes failure of STUN's message-integrity checking.
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 containing the The value of USERNAME is a variable-length value containing the
authentication username. It MUST contain a UTF-8 [RFC3629] encoded authentication username. It MUST contain a UTF-8 [RFC3629] encoded
sequence of less than 509 bytes, and MUST have been processed using sequence of less than 509 bytes, and MUST have been processed using
the OpaqueString profile [RFC8265]. A compliant implementation MUST the UsernameCasePreserved profile [RFC8265]. A compliant
be able to parse UTF-8 encoded sequence of less than 763. implementation MUST be able to parse UTF-8 encoded sequence of 763 or
less bytes, to be compatible with [RFC5389] that mistakenly assumed
up to 6 bytes per characters encoded.
14.4. USERHASH 14.4. USERHASH
The USERHASH attribute is used as a replacement for the USERNAME The USERHASH attribute is used as a replacement for the USERNAME
attribute when username anonymity is supported. attribute when username anonymity is supported.
The value of USERHASH has a fixed length of 32 bytes. The username The value of USERHASH has a fixed length of 32 bytes. The username
and the realm MUST have been processed using the OpaqueString profile and the realm MUST have been processed using the
[RFC8265] before hashing. UsernameCasePreserved profile [RFC8265] before hashing.
The following is the operation that the client will perform to hash The following is the operation that the client will perform to hash
the username: the username:
userhash = SHA-256(Opaque(username) ":" Opaque(realm)) userhash = SHA-256(UsernameCasePreserved(username)
":" OpaqueString(realm))
14.5. MESSAGE-INTEGRITY 14.5. MESSAGE-INTEGRITY
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of
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 SHA-1 hash, the HMAC will any STUN message type. Since it uses the SHA-1 hash, the HMAC will
be 20 bytes. be 20 bytes.
The key for the HMAC depends on which credential mechanism is in use. The key for the HMAC depends on which credential mechanism is in use.
Section 9.1.1 defines the key for the short-term credential mechanism Section 9.1.1 defines the key for the short-term credential mechanism
skipping to change at page 40, line 4 skipping to change at page 40, line 49
be 20 bytes. be 20 bytes.
The key for the HMAC depends on which credential mechanism is in use. The key for the HMAC depends on which credential mechanism is in use.
Section 9.1.1 defines the key for the short-term credential mechanism Section 9.1.1 defines the key for the short-term credential mechanism
and Section 9.2.2 defines the key for the long-term credential and Section 9.2.2 defines the key for the long-term credential
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.
The text used as input to HMAC is the STUN message, up to and The text used as input to HMAC is the STUN message, up to and
including the attribute preceding the MESSAGE-INTEGRITY attribute. including the attribute preceding the MESSAGE-INTEGRITY attribute.
The length field of the STUN message header is adjusted to point to The length field of the STUN message header is adjusted to point to
the end of the MESSAGE-INTEGRITY attribute. The value of the the end of the MESSAGE-INTEGRITY attribute. The value of the
MESSAGE-INTEGRITY attribute is set to a dummy value. MESSAGE-INTEGRITY attribute is set to a dummy value.
Once the computation is performed, the value of the MESSAGE-INTEGRITY Once the computation is performed, the value of the MESSAGE-INTEGRITY
attribute is filled in, and the value of the length in the STUN attribute is filled in, and the value of the length in the STUN
header is set to its correct value -- the length of the entire header is set to its correct value -- the length of the entire
message. message. Similarly, when validating the MESSAGE-INTEGRITY, the
length field in the STUN header must be adjusted to point to the end
Similarly, when validating the MESSAGE-INTEGRITY, the length field in of the MESSAGE-INTEGRITY attribute prior to calculating the HMAC over
the STUN header must be adjusted to point to the end of the MESSAGE- the STUN message, up to and including the attribute preceding the
INTEGRITY attribute prior to calculating the HMAC over the STUN MESSAGE-INTEGRITY attribute. Such adjustment is necessary when
message, up to and including the attribute preceding the MESSAGE- attributes, such as FINGERPRINT and MESSAGE-INTEGRITY-SHA256, appear
INTEGRITY attribute. Such adjustment is necessary when attributes, after MESSAGE-INTEGRITY. See also [RFC5769] for examples of such
such as FINGERPRINT and MESSAGE-INTEGRITY-SHA256, appear after
MESSAGE-INTEGRITY. See also [RFC5769] for examples of such
calculations. calculations.
14.6. MESSAGE-INTEGRITY-SHA256 14.6. MESSAGE-INTEGRITY-SHA256
The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA256 The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA256
[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. The MESSAGE- attribute can be present in any STUN message type. The MESSAGE-
INTEGRITY-SHA256 attribute contains an initial portion of the HMAC- INTEGRITY-SHA256 attribute contains an initial portion of the HMAC-
SHA-256 [RFC2104] of the STUN message. The value will be at most 32 SHA-256 [RFC2104] of the STUN message. The value will be at most 32
bytes and MUST be a positive multiple of 4 bytes. The HMAC MUST NOT bytes, but MUST be at least 16 bytes, and MUST be a multiple of 4
be truncated below a minimum size of 16 bytes. The value must be the bytes. The value must be the full 32 bytes unless the STUN Usage
full 32 bytes unless the STUN Usage explicitly specifies that explicitly specifies that truncation is allowed. STUN Usages may
truncation is allowed. STUN Usages may specify a minimum length specify a minimum length longer than 16 bytes.
longer than 4 bytes.
The key for the HMAC depends on which credential mechanism is in use. The key for the HMAC depends on which credential mechanism is in use.
Section 9.1.1 defines the key for the short-term credential mechanism Section 9.1.1 defines the key for the short-term credential mechanism
and Section 9.2.2 defines the key for the long-term credential and Section 9.2.2 defines the key for the long-term credential
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.
The text used as input to HMAC is the STUN message, up to and The text used as input to HMAC is the STUN message, up to and
including the attribute preceding the MESSAGE-INTEGRITY-SHA256 including the attribute preceding the MESSAGE-INTEGRITY-SHA256
attribute. The length field of the STUN message header is adjusted attribute. The length field of the STUN message header is adjusted
skipping to change at page 41, line 27 skipping to change at page 42, line 15
14.7. FINGERPRINT 14.7. FINGERPRINT
The FINGERPRINT attribute MAY be present in all STUN messages. The FINGERPRINT attribute MAY be present in all STUN messages.
The value of the attribute is computed as the CRC-32 of the STUN The value of the attribute is computed as the CRC-32 of the STUN
message up to (but excluding) the FINGERPRINT attribute itself, message up to (but excluding) the FINGERPRINT attribute itself,
XOR'ed with the 32-bit value 0x5354554e. (The XOR operation ensures XOR'ed with the 32-bit value 0x5354554e. (The XOR operation ensures
that the FINGERPRINT test will not report a false positive on a that the FINGERPRINT test will not report a false positive on a
packet containing a CRC-32 generated by an application protocol.) packet containing a CRC-32 generated by an application protocol.)
The 32-bit CRC is the one defined in ITU V.42 [ITU.V42.2002], which The 32-bit CRC is the one defined in ITU V.42 [ITU.V42.2002], which
has a generator polynomial of has a generator polynomial of x^32 + x^26 + x^23 + x^22 + x^16 + x^12
x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. See the sample + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1. See the sample
code for the CRC-32 in Section 8 of [RFC1952]. code for the CRC-32 in Section 8 of [RFC1952].
When present, the FINGERPRINT attribute MUST be the last attribute in When present, the FINGERPRINT attribute MUST be the last attribute in
the message, and thus will appear after MESSAGE-INTEGRITY and the message, and thus will appear after MESSAGE-INTEGRITY and
MESSAGE-INTEGRITY-SHA256. MESSAGE-INTEGRITY-SHA256.
The FINGERPRINT attribute can aid in distinguishing STUN packets from The FINGERPRINT attribute can aid in distinguishing STUN packets from
packets of other protocols. See Section 7. packets of other protocols. See Section 7.
As with MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, the CRC used As with MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, the CRC used
skipping to change at page 42, line 11 skipping to change at page 42, line 45
integrity value before the CRC is computed, since the CRC is done integrity value before the CRC is computed, since the CRC is done
over the value of the MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 over the value of the MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256
attributes as well. attributes as well.
14.8. 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
[RFC7231]. The reason phrase is meant for user consumption, and can [RFC7231]. The reason phrase is meant for diagnostic purposes, and
be anything appropriate for the error code. Recommended reason can 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 509 sequence of less than 128 characters (which can be as long as 509
bytes when encoding them or 763 bytes when decoding them). bytes when encoding them or 763 bytes when decoding them).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, should be 0 |Class| Number | | Reserved, should be 0 |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 42, line 44 skipping to change at page 43, line 31
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 binary encoding of the error code and 6. The Number represents the binary encoding of the error code
modulo 100, and its value MUST be between 0 and 99. modulo 100, and its 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 either a USERNAME or USERHASH attribute and a request included either a USERNAME or USERHASH attribute and a
valid MESSAGE-INTEGRITY attribute; otherwise, it MUST NOT be sent valid MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute;
and error code 400 (Bad Request) is suggested. This error otherwise, it MUST NOT be sent and error code 400 (Bad Request) is
response MUST be protected with the MESSAGE-INTEGRITY attribute, suggested. This error response MUST be protected with the
and receivers MUST validate the MESSAGE-INTEGRITY of this response MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, and
before redirecting themselves to an alternate server. receivers MUST validate the MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY-SHA256 of this response before redirecting themselves to
an alternate server.
Note: Failure to generate and validate message integrity for a 300 Note: Failure to generate and validate message integrity for a 300
response allows an on-path attacker to falsify a 300 response thus response allows an on-path attacker to falsify a 300 response thus
causing subsequent STUN messages to be sent to a victim. causing subsequent STUN messages to be sent to 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 attempt. retry the request without modification from the previous attempt.
The server may not be able to generate a valid MESSAGE-INTEGRITY The server may not be able to generate a valid MESSAGE-INTEGRITY
for this error, so the client MUST NOT expect a valid MESSAGE- or MESSAGE-INTEGRITY-SHA256 for this error, so the client MUST NOT
INTEGRITY attribute on this response. expect a valid MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
attribute on this response.
401 Unauthenticated: The request did not contain the correct 401 Unauthenticated: The request did not contain the correct
credentials to proceed. The client should retry the request with credentials to proceed. The client should retry the request 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- The server MUST put this unknown attribute in the UNKNOWN-
ATTRIBUTE attribute of its error response. ATTRIBUTE attribute of its error response.
skipping to change at page 43, line 34 skipping to change at page 44, line 24
client should try again. client should try again.
14.9. REALM 14.9. REALM
The REALM attribute may be present in requests and responses. It The REALM attribute may be present in requests and responses. It
contains text that meets the grammar for "realm-value" as described contains text that meets the grammar for "realm-value" as described
in [RFC3261] but without the double quotes and their surrounding in [RFC3261] but without the double quotes and their surrounding
whitespace. That is, it is an unquoted realm-value (and is therefore whitespace. That is, it is an unquoted realm-value (and is therefore
a sequence of qdtext or quoted-pair). It MUST be a UTF-8 [RFC3629] a sequence of qdtext or quoted-pair). 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
509 bytes when encoding them and a long as 763 bytes when decoding 509 bytes when encoding them and as long as 763 bytes when decoding
them), and MUST have been processed using the OpaqueString profile them), and MUST have been processed using the OpaqueString profile
[RFC8265]. [RFC8265].
Presence of the REALM attribute in a request indicates that long-term Presence of the REALM attribute in a request indicates that long-term
credentials are being used for authentication. Presence in certain credentials are being used for authentication. Presence in certain
error responses indicates that the server wishes the client to use a error responses indicates that the server wishes the client to use a
long-term credential in that realm for authentication. long-term credential in that realm for authentication.
14.10. NONCE 14.10. NONCE
The NONCE attribute may be present in requests and responses. It The NONCE attribute may be present in requests and responses. It
contains a sequence of qdtext or quoted-pair, which are defined in contains a sequence of qdtext or quoted-pair, which are defined in
RFC 3261 [RFC3261]. Note that this means that the NONCE attribute RFC 3261 [RFC3261]. Note that this means that the NONCE attribute
will not contain actual the surrounding quote characters. See will not contain the actual surrounding quote characters. See
[RFC7616], Section 5.4, for guidance on selection of nonce values in [RFC7616], Section 5.4, for guidance on selection of nonce values in
a server. It MUST be less than 128 characters (which can be as long a server. It MUST be less than 128 characters (which can be as long
as 763 bytes). as 509 bytes when encoding them and a long as 763 bytes when decoding
them).
14.11. PASSWORD-ALGORITHMS 14.11. PASSWORD-ALGORITHMS
The PASSWORD-ALGORITHMS attribute may be present in requests and The PASSWORD-ALGORITHMS attribute may be present in requests and
responses. It contains the list of algorithms that the server can responses. It contains the list of algorithms that the server can
use to derive the long-term password. use to derive the long-term password.
The set of known algorithms is maintained by IANA. The initial set The set of known algorithms is maintained by IANA. The initial set
defined by this specification is found in Section 17.5. defined by this specification is found in Section 18.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.5. The parameters start with the length (prior to in Section 18.5. The parameters start with the length (prior to
padding) of the parameters as a 16-bit value, followed by the padding) of the parameters as a 16-bit value, followed by the
parameters that are specific to each algorithm. The parameters are parameters that are specific to each algorithm. The parameters are
padded to a 32-bit boundary, in the same manner as an attribute. padded to a 32-bit 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)
skipping to change at page 44, line 39 skipping to change at page 45, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 2 Parameter (variable) | Algorithm 2 Parameter (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | ...
Figure 8: Format of PASSWORD-ALGORITHMS Attribute Figure 8: Format of PASSWORD-ALGORITHMS Attribute
14.12. 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 a key from
term password. 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.5. defined by this specification is found in Section 18.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.5. The parameters starts with the length (prior to Section 18.5. The parameters starts with the length (prior to
padding) of the parameters as a 16-bit value, followed by the padding) of the parameters as a 16-bit value, followed by the
parameters that are specific to the algorithm. The parameters are parameters that are specific to the algorithm. The parameters are
padded to a 32-bit boundary, in the same manner as an attribute. padded to a 32-bit boundary, in the same manner as an attribute.
Similarly, the padding bits MUST be set to zero on sending and MUST
be ignored by the receiver.
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
skipping to change at page 45, line 34 skipping to change at page 46, line 34
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 1 Type | Attribute 2 Type | | Attribute 1 Type | Attribute 2 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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, thPetriNet
padding rules for attributes are used instead. m --> PetriNet m --> e normal padding rules for attributes are
used instead.
14.14. 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
509 when encoding them and as long as 763 bytes when decoding them). 509 when encoding them and as long as 763 bytes when decoding them).
14.15. 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.
to that of the source IP address of the request.
14.16. 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 valid
[RFC3629] encoded sequence of less than 128 characters (which can be DNS name [RFC1123] (including A-labels [RFC5890]) of 255 or less
as long as 509 bytes when encoding them and as long as 763 bytes when ASCII characters.
decoding them).
15. Security Considerations 15. Operational Considerations
15.1. Attacks against the Protocol STUN MAY be used with anycast addresses, but only with UDP and in
STUN Usages where authentication is not used.
15.1.1. Outside Attacks 16. Security Considerations
Implementations and deployments of a STUN Usage using TLS or DTLS
MUST follow the recommendations in [BCP195].
Implementations and deployments of a STUN Usage using the Long-Term
Credential Mechanism (Section 9.2) MUST follow the recommendations in
Section 5 of [RFC7616].
16.1. Attacks against the Protocol
16.1.1. Outside Attacks
An attacker can try to modify STUN messages in transit, in order to An attacker can try to modify STUN messages in transit, in order to
cause a failure in STUN operation. These attacks are detected for cause a failure in STUN operation. These attacks are detected for
both requests and responses through the message-integrity mechanism, both requests and responses through the message-integrity mechanism,
using either a short-term or long-term credential. Of course, once using either a short-term or long-term credential. Of course, once
detected, the manipulated packets will be dropped, causing the STUN detected, the manipulated packets will be dropped, causing the STUN
transaction to effectively fail. This attack is possible only by an transaction to effectively fail. This attack is possible only by an
on-path attacker. on-path attacker.
An attacker that can observe, but not modify, STUN messages in- An attacker that can observe, but not modify, STUN messages in-
skipping to change at page 47, line 13 skipping to change at page 48, line 28
authentication and message integrity are needed. authentication and message integrity are needed.
Since STUN uses the HMAC of a shared secret for authentication and Since STUN uses the HMAC of a shared secret for authentication and
integrity protection, it is subject to offline dictionary attacks. integrity protection, it is subject to offline dictionary attacks.
When authentication is utilized, it SHOULD be with a strong password When authentication is utilized, it SHOULD be with a strong password
that is not readily subject to offline dictionary attacks. that is not readily subject to offline dictionary attacks.
Protection of the channel itself, using TLS or DTLS, mitigates these Protection of the channel itself, using TLS or DTLS, mitigates these
attacks. attacks.
STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256,
which is subject to bid down attacks by an on-path attacker. which is subject to bid-down attacks by an on-path attacker that
would strip the MESSAGE-INTEGRITY-SHA256 attribute leaving only the
MESSAGE-INTEGRITY attribute and exploiting a potential vulnerability.
Protection of the channel itself, using TLS or DTLS, mitigates these Protection of the channel itself, using TLS or DTLS, mitigates these
attacks. Timely removal of the support of MESSAGE-INTEGRITY in a attacks. Timely removal of the support of MESSAGE-INTEGRITY in a
future version of STUN is necessary. future version of STUN is necessary.
15.1.2. Inside Attacks 16.1.2. Inside Attacks
A rogue client may try to launch a DoS attack against a server by A rogue client may try to launch a DoS attack against a server by
sending it a large number of STUN requests. Fortunately, STUN sending it a large number of STUN requests. Fortunately, STUN
requests can be processed statelessly by a server, making such requests can be processed statelessly by a server, making such
attacks hard to launch effectively. attacks hard to launch effectively.
A rogue client may use a STUN server as a reflector, sending it A rogue client may use a STUN server as a reflector, sending it
requests with a falsified source IP address and port. In such a requests with a falsified source IP address and port. In such a
case, the response would be delivered to that source IP and port. case, the response would be delivered to that source IP and port.
There is no amplification of the number of packets with this attack There is no amplification of the number of packets with this attack
skipping to change at page 47, line 40 skipping to change at page 49, line 11
client), though there is a small increase in the amount of data, client), though there is a small increase in the amount of data,
since STUN responses are typically larger than requests. This attack since STUN responses are typically larger than requests. This attack
is mitigated by ingress source address filtering. is mitigated by ingress source address filtering.
Revealing the specific software version of the agent through the Revealing the specific software version of the agent through the
SOFTWARE attribute might allow them to become more vulnerable to SOFTWARE attribute might allow them to become more vulnerable to
attacks against software that is known to contain security holes. attacks against software that is known to contain security holes.
Implementers SHOULD make usage of the SOFTWARE attribute a Implementers SHOULD make usage of the SOFTWARE attribute a
configurable option. configurable option.
15.2. Attacks Affecting the Usage 16.1.3. Bid-Down Attacks
This document adds the possibility of selecting different algorithms
for protecting the confidentiality of the passwords stored on the
server side when using the Long-Term Credential Mechanism, while
still ensuring compatibility with MD5, which was the algorithm used
in a previous versin of this protocol. It works by having the server
send back to the client the list of algorithms supported in a
PASSWORD-ALGORITHMS attribute, and having the client send back a
PASSWORD-ALGORITHM attribute containing the algorithm selected.
Because the PASSWORD-ALGORITHMS attribute has to be sent in an
unauthenticated response, an on-path attacker wanting to exploit an
eventual vulnerability in MD5 can just strip the PASSWORD-ALGORITHMS
attribute from the unprotected response, thus making the server
subsequently act as if the client was implementing a previous version
of this protocol.
To protect against this attack and other similar bid-down attacks,
the nonce is enriched with a set of security bits which indicates
which security features are in use. In the case of the selection of
the password algorithm the matching bit is set in the nonce returned
by the server in the same response that contains the PASSWORD-
ALGORITHMS attribute. Because the nonce used in subsequent
authenticated transactions is verified by the server to be identical
to what was originally sent, it cannot be modified by an on-path
attacker. Additionally, the client is mandated to copy the received
PASSWORD-ALGORITHMS attribute in the next authenticated transaction
to that server.
An on-path attack that removes the PASSWORD-ALGORITHMS will be
detected because the client will not be able to send it back to the
server in the next authenticated transaction. The client will detect
that attack because the security bit is set, but the matching
attribute is missing, ending the session. A client using an older
version of this protocol will not send the PASSWORD-ALGORITHMS back
but can only use MD5 anyway, so the attack is inconsequential.
The on-path attack may also try to remove the security bit together
with the PASSWORD-ALGORITHMS attribute, but the server will discover
that when the next authenticated transaction contains an invalid
nonce.
An on-path attack that removes some algorithms from the PASSWORD-
ALGORITHMS attribute will be equally defeated because that attribute
will be different from the original one when the server verifies it
in the subsequent authenticated transaction.
16.2. Attacks Affecting the Usage
This section lists attacks that might be launched against a usage of This section lists attacks that might be launched against a usage of
STUN. Each STUN usage must consider whether these attacks are STUN. Each STUN usage must consider whether these attacks are
applicable to it, and if so, discuss counter-measures. applicable to it, and if so, discuss counter-measures.
Most of the attacks in this section revolve around an attacker Most of the attacks in this section revolve around an attacker
modifying the reflexive address learned by a STUN client through a modifying the reflexive address learned by a STUN client through a
Binding request/response transaction. Since the usage of the Binding request/response transaction. Since the usage of the
reflexive address is a function of the usage, the applicability and reflexive address is a function of the usage, the applicability and
remediation of these attacks are usage-specific. In common remediation of these attacks are usage-specific. In common
skipping to change at page 48, line 16 skipping to change at page 50, line 35
before it arrives at the STUN server. The STUN server will then before it arrives at the STUN server. The STUN server will then
return this IP address in the XOR-MAPPED-ADDRESS attribute to the return this IP address in the XOR-MAPPED-ADDRESS attribute to the
client, and send the response back to that (falsified) IP address and client, and send the response back to that (falsified) IP address and
port. If the attacker can also intercept this response, it can port. If the attacker can also intercept this response, it can
direct it back towards the client. Protecting against this attack by direct it back towards the client. Protecting against this attack by
using a message-integrity check is impossible, since a message- using a message-integrity check is impossible, since a message-
integrity value cannot cover the source IP address, since the integrity value cannot cover the source IP address, since the
intervening NAT must be able to modify this value. Instead, one intervening NAT must be able to modify this value. Instead, one
solution to preventing the attacks listed below is for the client to solution to preventing the attacks listed below is for the client to
verify the reflexive address learned, as is done in ICE verify the reflexive address learned, as is done in ICE
[I-D.ietf-ice-rfc5245bis]. Other usages may use other means to [I-D.ietf-ice-rfc5245bis]. X-Port is computed by taking the mapped
prevent these attacks. port in host byte order, XOR'ing it with the most significant 16 bits
of the magic cookie, and then the converting the result to network
byte order. If the IP address family is IPv4, X-Address is computed
by taking the mapped IP address in host byte order, XOR'ing it with
the magic cookie, and converting the result to network byte order.
If the IP address family is IPv6, X-Address is computed by taking the
mapped IP address in host byte order, XOR'ing it with the
concatenation of the magic cookie and the 96-bit transaction ID, and
converting the result to network byte order.
15.2.1. Attack I: Distributed DoS (DDoS) against a Target Other usages may use other means to prevent these attacks.
16.2.1. Attack I: Distributed DoS (DDoS) against a Target
In this attack, the attacker provides one or more clients with the In this attack, the attacker provides one or more clients with the
same faked reflexive address that points to the intended target. same faked reflexive address that points to the intended target.
This will trick the STUN clients into thinking that their reflexive This will trick the STUN clients into thinking that their reflexive
addresses are equal to that of the target. If the clients hand out addresses are equal to that of the target. If the clients hand out
that reflexive address in order to receive traffic on it (for that reflexive address in order to receive traffic on it (for
example, in SIP messages), the traffic will instead be sent to the example, in SIP messages), the traffic will instead be sent to the
target. This attack can provide substantial amplification, target. This attack can provide substantial amplification,
especially when used with clients that are using STUN to enable especially when used with clients that are using STUN to enable
multimedia applications. However, it can only be launched against multimedia applications. However, it can only be launched against
targets for which packets from the STUN server to the target pass targets for which packets from the STUN server to the target pass
through the attacker, limiting the cases in which it is possible. through the attacker, limiting the cases in which it is possible.
15.2.2. Attack II: Silencing a Client 16.2.2. Attack II: Silencing a Client
In this attack, the attacker provides a STUN client with a faked In this attack, the attacker provides a STUN client with a faked
reflexive address. The reflexive address it provides is a transport reflexive address. The reflexive address it provides is a transport
address that routes to nowhere. As a result, the client won't address that routes to nowhere. As a result, the client won't
receive any of the packets it expects to receive when it hands out receive any of the packets it expects to receive when it hands out
the reflexive address. This exploitation is not very interesting for the reflexive address. This exploitation is not very interesting for
the attacker. It impacts a single client, which is frequently not the attacker. It impacts a single client, which is frequently not
the desired target. Moreover, any attacker that can mount the attack the desired target. Moreover, any attacker that can mount the attack
could also deny service to the client by other means, such as could also deny service to the client by other means, such as
preventing the client from receiving any response from the STUN preventing the client from receiving any response from the STUN
server, or even a DHCP server. As with the attack in Section 15.2.1, server, or even a DHCP server. As with the attack in Section 16.2.1,
this attack is only possible when the attacker is on path for packets this attack is only possible when the attacker is on path for packets
sent from the STUN server towards this unused IP address. sent from the STUN server towards this unused IP address.
15.2.3. Attack III: Assuming the Identity of a Client 16.2.3. Attack III: Assuming the Identity of a Client
This attack is similar to attack II. However, the faked reflexive This attack is similar to attack II. However, the faked reflexive
address points to the attacker itself. This allows the attacker to address points to the attacker itself. This allows the attacker to
receive traffic that was destined for the client. receive traffic that was destined for the client.
15.2.4. Attack IV: Eavesdropping 16.2.4. Attack IV: Eavesdropping
In this attack, the attacker forces the client to use a reflexive In this attack, the attacker forces the client to use a reflexive
address that routes to itself. It then forwards any packets it address that routes to itself. It then forwards any packets it
receives to the client. This attack would allow the attacker to receives to the client. This attack would allow the attacker to
observe all packets sent to the client. However, in order to launch observe all packets sent to the client. However, in order to launch
the attack, the attacker must have already been able to observe the attack, the attacker must have already been able to observe
packets from the client to the STUN server. In most cases (such as packets from the client to the STUN server. In most cases (such as
when the attack is launched from an access network), this means that when the attack is launched from an access network), this means that
the attacker could already observe packets sent to the client. This the attacker could already observe packets sent to the client. This
attack is, as a result, only useful for observing traffic by attack is, as a result, only useful for observing traffic by
attackers on the path from the client to the STUN server, but not attackers on the path from the client to the STUN server, but not
generally on the path of packets being routed towards the client. generally on the path of packets being routed towards the client.
15.3. Hash Agility Plan Note that this attack can be trivially launched by the STUN server
itself, so users of STUN servers should have the same level of trust
in them as any other node that can insert themselves into the
communication flow.
This specification uses both HMAC-SHA1 and HMAC-SHA256 for 16.3. Hash Agility Plan
computation of the message integrity. If, at a later time, HMAC-
SHA256 is found to be compromised, the following is the remedy that This specification uses both HMAC-SHA256 for computation of the
will be applied: message integrity, sometimes in combination with HMAC-SHA1. If, at a
later time, HMAC-SHA256 is found to be compromised, the following is
the remedy that will be applied:
o Both a new message-integrity attribute and a new STUN Security o Both a new message-integrity attribute and a new STUN Security
Feature bit will be allocated in a Standard Track document. The Feature bit will be allocated in a Standard Track document. The
new message-integrity attribute will have its value computed using new message-integrity attribute will have its value computed using
a new hash. The STUN Security Feature bit will be used to a new hash. The STUN Security Feature bit will be used to
simultaneously signal to a STUN client using the Long Term simultaneously signal to a STUN client using the Long Term
Credential Mechanism that this server supports this new hash Credential Mechanism that this server supports this new hash
algorithm, and will prevent bid down attacks on the new message- algorithm, and will prevent bid-down attacks on the new message-
integrity attribute. integrity attribute.
o STUN Client and Server using the Short Term Credential Mechanism o STUN Clients and Servers using the Short Term Credential Mechanism
will need to get an updated external mechanism that they can use will need to update the external mechanism that they use to signal
to signal what message-integrity attributes are in use. what message-integrity attributes are in use.
The bid down protection mechanism described in this document is new, The bid-down protection mechanism described in this document is new,
and thus cannot currently protect against a bid down attack that and thus cannot currently protect against a bid-down attack that
lowers the strength of the hash algorithm to HMAC-SHA1. This is why, lowers the strength of the hash algorithm to HMAC-SHA1. This is why,
after a transition period, a new document updating this document will after a transition period, a new document updating this document will
assign a new STUN Security Feature bit for deprecating HMAC-SHA1. assign a new STUN Security Feature bit for deprecating HMAC-SHA1.
When used, this bit will signal that HMAC-SHA1 is deprecated and When used, this bit will signal that HMAC-SHA1 is deprecated and
should no longer be used. should no longer be used.
16. IAB Considerations Similarly, if SHA256 is found to be compromised, a new user-hash
attribute and a new STUN Security Feature bit will be allocated in a
Standards Track document. The new user-hash attribute will have its
value computed using a new hash. The STUN Security Feature bit will
be used to simultaneously signal to a STUN client using the Long Term
Credential Mechanism that this server supports this new hash
algorithm for the user-hash attribute, and will prevent bid-down
attacks on the new user-hash attribute.
17. IAB Considerations
The IAB has studied the problem of Unilateral Self-Address Fixing The IAB has studied the problem of Unilateral Self-Address Fixing
(UNSAF), which is the general process by which a client attempts to (UNSAF), which is the general process by which a client attempts to
determine its address in another realm on the other side of a NAT determine its address in another realm on the other side of a NAT
through a collaborative protocol reflection mechanism ([RFC3424]). through a collaborative protocol reflection mechanism ([RFC3424]).
STUN can be used to perform this function using a Binding request/ STUN can be used to perform this function using a Binding request/
response transaction if one agent is behind a NAT and the other is on response transaction if one agent is behind a NAT and the other is on
the public side of the NAT. the public side of the NAT.
The IAB has suggested that protocols developed for this purpose The IAB has suggested that protocols developed for this purpose
document a specific set of considerations. Because some STUN usages document a specific set of considerations. Because some STUN usages
provide UNSAF functions (such as ICE [I-D.ietf-ice-rfc5245bis] ), and provide UNSAF functions (such as ICE [I-D.ietf-ice-rfc5245bis] ), and
others do not (such as SIP Outbound [RFC5626]), answers to these others do not (such as SIP Outbound [RFC5626]), answers to these
considerations need to be addressed by the usages themselves. considerations need to be addressed by the usages themselves.
17. IANA Considerations 18. IANA Considerations
17.1. STUN Security Features Registry 18.1. STUN Security Features Registry
A STUN Security Feature set defines 24 bit as flags. A STUN Security Feature set defines 24 bit as flags.
IANA is requested to create a new registry containing the STUN IANA is requested to create a new registry containing the STUN
Security Features that are protected by the bid down attack Security Features that are protected by the bid-down attack
prevention mechanism described in section Section 9.2.1. prevention mechanism described in section Section 9.2.1.
The initial STUN Security Features are: The initial STUN Security Features are:
Bit 0: Password algorithms Bit 0: Password algorithms
Bit 1: Username anonymity Bit 1: Username anonymity
Bit 2-23: Unassigned Bit 2-23: Unassigned
Bits are assigned starting from the most significant side of the bit
set, so Bit 0 is the leftmost bit and Bit 23 the rightmost bit.
New Security Features are assigned by a Standards Action [RFC8126]. New Security Features are assigned by a Standards Action [RFC8126].
17.2. STUN Methods Registry 18.2. STUN Methods Registry
IANA is requested to update the name for method 0x002 and the IANA is requested to update the name for method 0x002 and the
reference from RFC 5389 to RFC-to-be for the following STUN methods: reference from RFC 5389 to RFC-to-be for the following STUN methods:
0x000: (Reserved) 0x000: (Reserved)
0x001: Binding 0x001: Binding
0x002: (Reserved; prior to [RFC5389] this was SharedSecret) 0x002: (Reserved; prior to [RFC5389] this was SharedSecret)
17.3. STUN Attribute Registry 18.3. STUN Attribute Registry
17.3.1. Updated Attributes
18.3.1. Updated Attributes
IANA is requested to update the names for attributes 0x0002, 0x0003, IANA is requested to update the names for attributes 0x0002, 0x0003,
0x0004, 0x0005, 0x0007, and 0x000B, and the reference from RFC 5389 0x0004, 0x0005, 0x0007, and 0x000B, and the reference from RFC 5389
to RFC-to-be for the following STUN methods: to RFC-to-be for the following STUN methods:
Comprehension-required range (0x0000-0x7FFF): Comprehension-required range (0x0000-0x7FFF):
0x0000: (Reserved) 0x0000: (Reserved)
0x0001: MAPPED-ADDRESS 0x0001: MAPPED-ADDRESS
0x0002: (Reserved; prior to [RFC5389] this was RESPONSE-ADDRESS) 0x0002: (Reserved; prior to [RFC5389] this was RESPONSE-ADDRESS)
0x0003: (Reserved; prior to [RFC5389] this was CHANGE-REQUEST) 0x0003: CHANGE-REQUEST
0x0004: (Reserved; prior to [RFC5389] this was SOURCE-ADDRESS) 0x0004: (Reserved; prior to [RFC5389] this was SOURCE-ADDRESS)
0x0005: (Reserved; prior to [RFC5389] this was CHANGED-ADDRESS) 0x0005: (Reserved; prior to [RFC5389] this was CHANGED-ADDRESS)
0x0006: USERNAME 0x0006: USERNAME
0x0007: (Reserved; prior to [RFC5389] this was PASSWORD) 0x0007: (Reserved; prior to [RFC5389] this was PASSWORD)
0x0008: MESSAGE-INTEGRITY 0x0008: MESSAGE-INTEGRITY
0x0009: ERROR-CODE 0x0009: ERROR-CODE
0x000A: UNKNOWN-ATTRIBUTES 0x000A: UNKNOWN-ATTRIBUTES
0x000B: (Reserved; prior to [RFC5389] this was REFLECTED-FROM) 0x000B: (Reserved; prior to [RFC5389] this was REFLECTED-FROM)
0x0014: REALM 0x0014: REALM
0x0015: NONCE 0x0015: NONCE
0x0020: XOR-MAPPED-ADDRESS 0x0020: XOR-MAPPED-ADDRESS
Comprehension-optional range (0x8000-0xFFFF) Comprehension-optional range (0x8000-0xFFFF)
0x8022: SOFTWARE 0x8022: SOFTWARE
0x8023: ALTERNATE-SERVER 0x8023: ALTERNATE-SERVER
0x8028: FINGERPRINT 0x8028: FINGERPRINT
17.3.2. New Attributes 18.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 0xXXXX: USERHASH
Comprehension-optional range (0x8000-0xFFFF) Comprehension-optional range (0x8000-0xFFFF)
0xXXXX: PASSWORD-ALGORITHMS 0xXXXX: PASSWORD-ALGORITHMS
0xXXXX: ALTERNATE-DOMAIN 0xXXXX: ALTERNATE-DOMAIN
17.4. STUN Error Code Registry 18.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.8. for the Error Codes given in Section 14.8.
IANA is requested to change the name of the 401 Error Code from IANA is requested to change the name of the 401 Error Code from
"Unauthorized" to "Unauthenticated". "Unauthorized" to "Unauthenticated".
17.5. STUN Password Algorithm Registry 18.5. STUN 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:
0x0000: Reserved 0x0000: Reserved
0x0001: MD5 0x0001: MD5
0x0002: SHA-256 0x0002: SHA-256
0x0003-0xFFFF: Unassigned 0x0003-0xFFFF: Unassigned
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 [RFC8126]. Password Algorithms in the are assigned by IETF Review [RFC8126]. 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 [RFC8126]. Expert [RFC8126].
17.5.1. Password Algorithms 18.5.1. Password Algorithms
17.5.1.1. MD5 18.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 16 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 ":" OpaqueString(realm)
":" OpaqueString(password))
17.5.1.2. SHA-256 18.5.1.2. SHA-256
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 = SHA-256(username ":" realm ":" OpaqueString(password)) key = SHA-256(username ":" OpaqueString(realm)
":" OpaqueString(password))
17.6. STUN UDP and TCP Port Numbers 18.6. STUN UDP and TCP Port Numbers
IANA is requested to update the reference from RFC 5389 to RFC-to-be IANA is requested to update the reference from RFC 5389 to RFC-to-be
for the following ports in the Service Name and Transport Protocol for the following ports in the Service Name and Transport Protocol
Port Number Registry. Port Number Registry.
stun 3478/tcp Session Traversal Utilities for NAT (STUN) port stun 3478/tcp Session Traversal Utilities for NAT (STUN) port
stun 3478/udp Session Traversal Utilities for NAT (STUN) port stun 3478/udp Session Traversal Utilities for NAT (STUN) port
stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port
18. Changes since RFC 5389 19. Changes since RFC 5389
This specification obsoletes [RFC5389]. This specification differs This specification obsoletes [RFC5389]. This specification differs
from RFC 5389 in the following ways: from RFC 5389 in the following ways:
o Added support for DTLS-over-UDP [RFC6347]. o Added support for DTLS-over-UDP [RFC6347].
o Made clear that the RTO is considered stale if there is no o Made clear that the RTO is considered stale if there is no
transactions with the server. transactions with the server.
o Aligned the RTO calculation with [RFC6298]. o Aligned the RTO calculation with [RFC6298].
skipping to change at page 53, line 45 skipping to change at page 56, line 45
o Sharing a NONCE is no longer permitted. o Sharing a NONCE is no longer permitted.
o Added the possibility of using a domain name in the alternate o Added the possibility of using a domain name in the alternate
server mechanism. server mechanism.
o Added more C snippets. o Added more C snippets.
o Added test vector. o Added test vector.
19. References 20. References
19.1. Normative References 20.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.
[KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", August 1987.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989,
<http://www.rfc-editor.org/info/rfc1123>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992, DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>. <https://www.rfc-editor.org/info/rfc1321>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>. <https://www.rfc-editor.org/info/rfc2782>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<http://www.rfc-editor.org/info/rfc6151>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>. <https://www.rfc-editor.org/info/rfc6298>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- [RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit-
skipping to change at page 55, line 43 skipping to change at page 59, line 16
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 8265, Representing Usernames and Passwords", RFC 8265,
DOI 10.17487/RFC8265, October 2017, DOI 10.17487/RFC8265, October 2017,
<https://www.rfc-editor.org/info/rfc8265>. <https://www.rfc-editor.org/info/rfc8265>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>. <https://www.rfc-editor.org/info/rfc8305>.
19.2. Informative References 20.2. Informative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-16 (work in progress), January 2018. rfc5245bis-20 (work in progress), March 2018.
[KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time [I-D.ietf-tram-stun-pmtud]
Estimates in Reliable Transport Protocols", August 1987. Petit-Huguenin, M. and G. Salgueiro, "Path MTU Discovery
Using Session Traversal Utilities for NAT (STUN)", draft-
ietf-tram-stun-pmtud-07 (work in progress), March 2018.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, DOI 10.17487/RFC1952, May 1996, RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>. <https://www.rfc-editor.org/info/rfc1952>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
skipping to change at page 56, line 30 skipping to change at page 60, line 15
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
DOI 10.17487/RFC3489, March 2003, DOI 10.17487/RFC3489, March 2003,
<https://www.rfc-editor.org/info/rfc3489>. <https://www.rfc-editor.org/info/rfc3489>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <https://www.rfc-editor.org/info/rfc4107>. June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D.,
and W. Beck, "RADIUS Extension for Digest Authentication",
RFC 5090, DOI 10.17487/RFC5090, February 2008,
<http://www.rfc-editor.org/info/rfc5090>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>. <https://www.rfc-editor.org/info/rfc5389>.
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
"Managing Client-Initiated Connections in the Session "Managing Client-Initiated Connections in the Session
Initiation Protocol (SIP)", RFC 5626, Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009, DOI 10.17487/RFC5626, October 2009,
<https://www.rfc-editor.org/info/rfc5626>. <https://www.rfc-editor.org/info/rfc5626>.
skipping to change at page 57, line 20 skipping to change at page 61, line 10
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
March 2012, <https://www.rfc-editor.org/info/rfc6544>. March 2012, <https://www.rfc-editor.org/info/rfc6544>.
[RFC7231] Fielding, R. and R. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and R. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, May 2008, RFC 8126, DOI 10.17487/RFC8126, May 2008,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Appendix A. C Snippet to Determine STUN Message Types Appendix A. C Snippet to Determine STUN Message Types
Given a 16-bit STUN message type value in host byte order in msg_type Given a 16-bit STUN message type value in host byte order in msg_type
parameter, below are C macros to determine the STUN message types: parameter, below are C macros to determine the STUN message types:
skipping to change at page 57, line 47 skipping to change at page 61, line 31
#define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000) #define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000)
#define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010) #define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010)
#define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100) #define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100)
#define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110) #define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110)
<CODE ENDS> <CODE ENDS>
A function to convert method and class into a message type: A function to convert method and class into a message type:
<CODE BEGINS> <CODE BEGINS>
int type(int method, int cls) { int type(int method, int cls) {
return (method & 0x0F80) << 9 | (method & 0x0070) << 5 return (method & 0x1F80) << 2 | (method & 0x0070) << 1
| (method & 0x000F) | (cls & 0x0002) << 8 | (method & 0x000F) | (cls & 0x0002) << 7
| (cls & 0x0001) << 4; | (cls & 0x0001) << 4;
} }
<CODE ENDS> <CODE ENDS>
A function to extract the method from the message type: A function to extract the method from the message type:
<CODE BEGINS> <CODE BEGINS>
int method(int type) { int method(int type) {
return (type & 0x3E00) >> 2 | (type & 0x00E0) >> 1 return (type & 0x3E00) >> 2 | (type & 0x00E0) >> 1
| (type & 0x000F); | (type & 0x000F);
} }
<CODE ENDS> <CODE ENDS>
A function to extract the class from the message type: A function to extract the class from the message type:
<CODE BEGINS> <CODE BEGINS>
int cls(int type) { int cls(int type) {
return (type & 0x0100) >> 7 | (type & 0x0010) >> 4; return (type & 0x0100) >> 7 | (type & 0x0010) >> 4;
} }
<CODE ENDS> <CODE ENDS>
skipping to change at page 58, line 38 skipping to change at page 62, line 22
INTEGRITY-SHA256 and USERHASH INTEGRITY-SHA256 and USERHASH
This request uses the following parameters: This request uses the following parameters:
Username: "<U+30DE><U+30C8><U+30EA><U+30C3><U+30AF><U+30B9>" (without Username: "<U+30DE><U+30C8><U+30EA><U+30C3><U+30AF><U+30B9>" (without
quotes) unaffected by OpaqueString [RFC8265] processing quotes) unaffected by OpaqueString [RFC8265] processing
Password: "The<U+00AD>M<U+00AA>tr<U+2168>" and "TheMatrIX" (without Password: "The<U+00AD>M<U+00AA>tr<U+2168>" and "TheMatrIX" (without
quotes) respectively before and after OpaqueString processing quotes) respectively before and after OpaqueString processing
Nonce: "obMatJos2AAACf//499k954d6OL34oL9FSTvy64sA" (without quotes) Nonce: "obMatJos2QAAAf//499k954d6OL34oL9FSTvy64sA" (without quotes)
Realm: "example.org" (without quotes) Realm: "example.org" (without quotes)
00 01 00 9c Request type and message length 00 01 00 9c Request type and message length
21 12 a4 42 Magic cookie 21 12 a4 42 Magic cookie
78 ad 34 33 } 78 ad 34 33 }
c6 ad 72 c0 } Transaction ID c6 ad 72 c0 } Transaction ID
29 da 41 2e } 29 da 41 2e }
XX XX 00 20 USERHASH attribute header XX XX 00 20 USERHASH attribute header
4a 3c f3 8f } 4a 3c f3 8f }
ef 69 92 bd } ef 69 92 bd }
skipping to change at page 60, line 9 skipping to change at page 64, line 9
Note: Before publication, the XX XX placeholder must be replaced by Note: Before publication, the XX XX placeholder must be replaced by
the value assigned to MESSAGE-INTEGRITY-SHA256 and USERHASH by the value assigned to MESSAGE-INTEGRITY-SHA256 and USERHASH by
IANA. The MESSAGE-INTEGRITY-SHA256 attribute value will need to IANA. The MESSAGE-INTEGRITY-SHA256 attribute value will need to
be updated after this. be updated after this.
Appendix C. Release notes Appendix C. Release notes
This section must be removed before publication as an RFC. This section must be removed before publication as an RFC.
C.1. Modifications between draft-ietf-tram-stunbis-16 and draft-ietf- C.1. Modifications between draft-ietf-tram-stunbis-17 and draft-ietf-
tram-stunbis-16
o Modifications following IESG, GENART and SECDIR reviews.
C.2. Modifications between draft-ietf-tram-stunbis-16 and draft-ietf-
tram-stunbis-15 tram-stunbis-15
o Replace "failure response" with "error response". o Replace "failure response" with "error response".
o Fix wrong section number. o Fix wrong section number.
o Use "Username anonymity" everywhere. o Use "Username anonymity" everywhere.
o Align with UTF-8 deprecation. o Align with UTF-8 deprecation.
skipping to change at page 61, line 5 skipping to change at page 65, line 12
o s/invalidate/revoke/. o s/invalidate/revoke/.
o Removed sentences about checking USERHASH in responses, as this o Removed sentences about checking USERHASH in responses, as this
should not happen. should not happen.
o Specify that ALTERNATE-SERVER carries an IP address. o Specify that ALTERNATE-SERVER carries an IP address.
o More modifications following review... o More modifications following review...
C.2. Modifications between draft-ietf-tram-stunbis-15 and draft-ietf- C.3. Modifications between draft-ietf-tram-stunbis-15 and draft-ietf-
tram-stunbis-14 tram-stunbis-14
o Reverted the RFC 2119 boilerplate to what was in RFC 5389. o Reverted the RFC 2119 boilerplate to what was in RFC 5389.
o Reverted the V.42 reference to the 2002 version. o Reverted the V.42 reference to the 2002 version.
o Updated some references. o Updated some references.
C.3. Modifications between draft-ietf-tram-stunbis-14 and draft-ietf- C.4. Modifications between draft-ietf-tram-stunbis-14 and draft-ietf-
tram-stunbis-13 tram-stunbis-13
o Reorder the paragraphs in section 9.1.4. o Reorder the paragraphs in section 9.1.4.
o The realm is now processed through Opaque in section 9.2.2. o The realm is now processed through Opaque in section 9.2.2.
o Make clear in section 9.2.4 that it is an exclusive-xor. o Make clear in section 9.2.4 that it is an exclusive-xor.
o Removed text that implied that nonce sharing was explicitly o Removed text that implied that nonce sharing was explicitly
permitted in RFC 5389. permitted in RFC 5389.
o In same section, s/username/value/ for USERCASH. o In same section, s/username/value/ for USERCASH.
o Modify the IANA requests to explicitly say that the reserved o Modify the IANA requests to explicitly say that the reserved
codepoints were prior to RFC 5389. codepoints were prior to RFC 5389.
C.4. Modifications between draft-ietf-tram-stunbis-13 and draft-ietf- C.5. Modifications between draft-ietf-tram-stunbis-13 and draft-ietf-
tram-stunbis-12 tram-stunbis-12
o Update references. o Update references.
o Fixes some text following Shepherd review. o Fixes some text following Shepherd review.
o Update co-author info. o Update co-author info.
C.5. Modifications between draft-ietf-tram-stunbis-12 and draft-ietf- C.6. Modifications between draft-ietf-tram-stunbis-12 and draft-ietf-
tram-stunbis-11 tram-stunbis-11
o Clarifies the procedure to define a new hash algorithm for o Clarifies the procedure to define a new hash algorithm for
message-integrity. message-integrity.
o Explain the procedure to deprecate SHA1 as message-integrity. o Explain the procedure to deprecate SHA1 as message-integrity.
o Added procedure for Happy Eyeballs (RFC 6555). o Added procedure for Happy Eyeballs (RFC 6555).
o Added verification that Happy Eyeballs works in the STUN Usage o Added verification that Happy Eyeballs works in the STUN Usage
checklist. checklist.
o Add reference to Base64 RFC. o Add reference to Base64 RFC.
o Changed co-author affiliation. o Changed co-author affiliation.
C.6. Modifications between draft-ietf-tram-stunbis-11 and draft-ietf- C.7. Modifications between draft-ietf-tram-stunbis-11 and draft-ietf-
tram-stunbis-10 tram-stunbis-10
o Made clear that the same HMAC than received in response of short o Made clear that the same HMAC than received in response of short
term credential must be used for subsequent transactions. term credential must be used for subsequent transactions.
o s/URL/URI/ o s/URL/URI/
o The "nonce cookie" is now mandatory to signal that SHA256 must be o The "nonce cookie" is now mandatory to signal that SHA256 must be
used in the next transaction. used in the next transaction.
o s/SHA1/SHA256/ o s/SHA1/SHA256/
o Changed co-author affiliation. o Changed co-author affiliation.
C.7. Modifications between draft-ietf-tram-stunbis-10 and draft-ietf- C.8. Modifications between draft-ietf-tram-stunbis-10 and draft-ietf-
tram-stunbis-09 tram-stunbis-09
o Removed the reserved value in the security registry, as it does o Removed the reserved value in the security registry, as it does
not make sense in a bitset. not make sense in a bitset.
o Updated change list. o Updated change list.
o Updated the minimum truncation size for M-I-256 to 16 bytes. o Updated the minimum truncation size for M-I-256 to 16 bytes.
o Changed the truncation order to match RFC 7518. o Changed the truncation order to match RFC 7518.
skipping to change at page 62, line 47 skipping to change at page 67, line 5
o Stated that STUN Usages have to explicitly state that they can use o Stated that STUN Usages have to explicitly state that they can use
truncation. truncation.
o Removed truncation from the MESSAGE-INTEGRITY attribute. o Removed truncation from the MESSAGE-INTEGRITY attribute.
o Add reference to C code in RFC 1952. o Add reference to C code in RFC 1952.
o Replaced RFC 2818 reference to RFC 6125. o Replaced RFC 2818 reference to RFC 6125.
C.8. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- C.9. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf-
tram-stunbis-08 tram-stunbis-08
o Removed the reserved value in the security registry, as it does o Removed the reserved value in the security registry, as it does
not make sense in a bitset. not make sense in a bitset.
o Updated change list. o Updated change list.
o Updated the minimum truncation size for M-I-256 to 16 bytes. o Updated the minimum truncation size for M-I-256 to 16 bytes.
o Changed the truncation order to match RFC 7518. o Changed the truncation order to match RFC 7518.
skipping to change at page 63, line 22 skipping to change at page 67, line 28
o Stated that STUN Usages have to explicitly state that they can use o Stated that STUN Usages have to explicitly state that they can use
truncation. truncation.
o Removed truncation from the MESSAGE-INTEGRITY attribute. o Removed truncation from the MESSAGE-INTEGRITY attribute.
o Add reference to C code in RFC 1952. o Add reference to C code in RFC 1952.
o Replaced RFC 2818 reference to RFC 6125. o Replaced RFC 2818 reference to RFC 6125.
C.9. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- C.10. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf-
tram-stunbis-08 tram-stunbis-08
o Packets discarded in a reliable or unreliable transaction triggers o Packets discarded in a reliable or unreliable transaction triggers
an attack error instead of a timeout error. An attack error on a an attack error instead of a timeout error. An attack error on a
reliable transport is signaled immediately instead of waiting for reliable transport is signaled immediately instead of waiting for
the timeout. the timeout.
o Explicitly state that a received 400 response without o Explicitly state that a received 400 response without
authentication will be dropped until timeout. authentication will be dropped until timeout.
o Clarify the SHOULD omit/include rules in LTCM. o Clarify the SHOULD omit/include rules in LTCM.
skipping to change at page 63, line 47 skipping to change at page 68, line 5
o The 401 and 438 error response to subsequent requests may use the o The 401 and 438 error response to subsequent requests may use the
previous NONCE/password to authenticate, if they are still previous NONCE/password to authenticate, if they are still
available. available.
o Change "401 Unauthorized" to "401 Unauthenticated" o Change "401 Unauthorized" to "401 Unauthenticated"
o Make clear that in some cases it is impossible to add a MI or MI2 o Make clear that in some cases it is impossible to add a MI or MI2
even if the text says SHOULD NOT. even if the text says SHOULD NOT.
C.10. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf- C.11. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf-
tram-stunbis-07 tram-stunbis-07
o Updated list of changes since RFC 5389. o Updated list of changes since RFC 5389.
o More examples are automatically generated. o More examples are automatically generated.
o Message integrity truncation is fixed at a multiple of 4 bytes, o Message integrity truncation is fixed at a multiple of 4 bytes,
because the padding will not decrease by more than this. because the padding will not decrease by more than this.
o USERHASH contains the 32 bytes of the hash, not a character o USERHASH contains the 32 bytes of the hash, not a character
string. string.
o Updated the example to use the USERHASH attribute and the modified o Updated the example to use the USERHASH attribute and the modified
NONCE attribute. NONCE attribute.
o Updated ICEbis reference. o Updated ICEbis reference.
C.11. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf- C.12. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf-
tram-stunbis-06 tram-stunbis-06
o Add USERHASH attribute to carry the hashed version of the o Add USERHASH attribute to carry the hashed version of the
username. username.
o Add IANA registry and nonce encoding for Security Features that o Add IANA registry and nonce encoding for Security Features that
need to be protected from bid down attacks. need to be protected from bid-down attacks.
o Modified MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 to support o Modified MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 to support
truncation limits (pending cryptographic review), truncation limits (pending cryptographic review),
C.12. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf- C.13. 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.13. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- C.14. 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.14. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- C.15. 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.15. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- C.16. 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.16. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- C.17. 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 66, line 5 skipping to change at page 70, line 13
transactions, not to serial transactions. That prevents a 3RTT transactions, not to serial transactions. That prevents a 3RTT
delay between the first transaction and the second transaction delay between the first transaction and the second transaction
with long term authentication. with long term authentication.
o Add text saying ORIGIN can increase a request size beyond the MTU o Add text saying ORIGIN can increase a request size beyond the MTU
and so require an SCTPoUDP transport. and so require an SCTPoUDP transport.
o Move the Acknowledgments and Contributor sections to the end of o Move the Acknowledgments and Contributor sections to the end of
the document, in accordance with RFC 7322 section 4. the document, in accordance with RFC 7322 section 4.
C.17. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- C.18. 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 66, line 40 skipping to change at page 71, line 5
* DNS discovery is done from the URI. * DNS discovery is done from the URI.
* Reorganized the text about default ports. * Reorganized the text about default ports.
o Add more C snippets. o Add more C snippets.
o Make clear that the cached RTO is discarded only if there is no o Make clear that the cached RTO is discarded only if there is no
new transations for 10 minutes. new transations for 10 minutes.
C.18. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.19. 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.19. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.20. 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 67, line 25 skipping to change at page 71, line 39
o Update text and reference from RFC 2988 to RFC 6298. o Update text and reference from RFC 2988 to RFC 6298.
o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o s/The IAB has mandated/The IAB has suggested/ (Errata #3737).
o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972).
o Fix section number and make clear that the original domain name is o Fix section number and make clear that the original domain name is
used for the server certificate verification. This is consistent used for the server certificate verification. This is consistent
with what RFC 5922 (section 4) is doing. (Errata #2010) with what RFC 5922 (section 4) is doing. (Errata #2010)
C.20. Modifications between draft-salgueiro-tram-stunbis-01 and draft- C.21. 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, Brandon Williams, Olle Johansson, Martin Thomson, Jonathan Lennox, Brandon Williams, Olle Johansson, Martin Thomson,
Mihaly Meszaros, Tolga Asveren, Noriyuki Torii, Spencer Dawkins, and Mihaly Meszaros, Tolga Asveren, Noriyuki Torii, Spencer Dawkins, Dale
Dale Worley for the comments, suggestions, and questions that helped Worley, Matthew Miller, Peter Saint-Andre, Julien Elie, Mirja
improve this document. Kuehlewind, Eric Rescorla, Ben Campbell, Adam Roach, Alexey Melnikov,
and Benjamin Kaduk for the comments, suggestions, and questions that
helped improve this document.
The authors of RFC 5389 would like to thank Cedric Aoun, Pete The authors of RFC 5389 would like to thank Cedric Aoun, Pete
Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus
Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for
their comments, and Baruch Sterman and Alan Hawrylyshen for initial their comments, and Baruch Sterman and Alan Hawrylyshen for initial
implementations. Thanks for Leslie Daigle, Allison Mankin, Eric implementations. Thanks for Leslie Daigle, Allison Mankin, Eric
Rescorla, and Henning Schulzrinne for IESG and IAB input on this Rescorla, and Henning Schulzrinne for IESG and IAB input on this
work. work.
Contributors Contributors
 End of changes. 171 change blocks. 
402 lines changed or deleted 575 lines changed or added

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