draft-ietf-tram-stunbis-04.txt   draft-ietf-tram-stunbis-05.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 27, 2015 D. Wing Expires: July 29, 2016 D. Wing
Cisco Cisco
R. Mahy R. Mahy
Plantronics Plantronics
P. Matthews P. Matthews
Avaya Avaya
March 26, 2015 January 26, 2016
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-04 draft-ietf-tram-stunbis-05
Abstract Abstract
Session Traversal Utilities for NAT (STUN) is a protocol that serves Session Traversal Utilities for NAT (STUN) is a protocol that serves
as a tool for other protocols in dealing with Network Address as a tool for other protocols in dealing with Network Address
Translator (NAT) traversal. It can be used by an endpoint to Translator (NAT) traversal. It can be used by an endpoint to
determine the IP address and port allocated to it by a NAT. It can determine the IP address and port allocated to it by a NAT. It can
also be used to check connectivity between two endpoints, and as a also be used to check connectivity between two endpoints, and as a
keep-alive protocol to maintain NAT bindings. STUN works with many keep-alive protocol to maintain NAT bindings. STUN works with many
existing NATs, and does not require any special behavior from them. existing NATs, and does not require any special behavior from them.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 27, 2015. This Internet-Draft will expire on July 29, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 50 skipping to change at page 2, line 50
7. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 20 7. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 20
8. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 20 8. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 20
8.1. STUN URI Scheme Semantics . . . . . . . . . . . . . . . . 21 8.1. STUN URI Scheme Semantics . . . . . . . . . . . . . . . . 21
9. Authentication and Message-Integrity Mechanisms . . . . . . . 22 9. Authentication and Message-Integrity Mechanisms . . . . . . . 22
9.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 22 9.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 22
9.1.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 22 9.1.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 22
9.1.2. Forming a Request or Indication . . . . . . . . . . . 23 9.1.2. Forming a Request or Indication . . . . . . . . . . . 23
9.1.3. Receiving a Request or Indication . . . . . . . . . . 23 9.1.3. Receiving a Request or Indication . . . . . . . . . . 23
9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 24 9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 24
9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 24 9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 24
9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 24 9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 25
9.2.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 25 9.2.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 26
9.2.2. Forming a Request . . . . . . . . . . . . . . . . . . 26 9.2.2. Forming a Request . . . . . . . . . . . . . . . . . . 26
9.2.2.1. First Request . . . . . . . . . . . . . . . . . . 26 9.2.2.1. First Request . . . . . . . . . . . . . . . . . . 26
9.2.2.2. Subsequent Requests . . . . . . . . . . . . . . . 27 9.2.2.2. Subsequent Requests . . . . . . . . . . . . . . . 27
9.2.3. Receiving a Request . . . . . . . . . . . . . . . . . 27 9.2.3. Receiving a Request . . . . . . . . . . . . . . . . . 27
9.2.4. Receiving a Response . . . . . . . . . . . . . . . . 28 9.2.4. Receiving a Response . . . . . . . . . . . . . . . . 29
10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 29 10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 30
11. Backwards Compatibility with RFC 5389 . . . . . . . . . . . . 30 11. Backwards Compatibility with RFC 5389 . . . . . . . . . . . . 31
12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 30 12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 31
13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 31 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 31
14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 32 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 32
14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 33 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 33
14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 34 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 34
14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 35 14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 35
14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 35 14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 35
14.5. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 36 14.5. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 36
14.6. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 36 14.6. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 37
14.7. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 37 14.7. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 37
14.8. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 38 14.8. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.9. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 39 14.9. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.10. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 39 14.10. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 39
14.11. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 40 14.11. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 40
14.12. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 40 14.12. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 41
14.13. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 41 14.13. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 41
14.14. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 41 14.14. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 42
14.15. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 41 14.15. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 42
15. Security Considerations . . . . . . . . . . . . . . . . . . . 41 15. Security Considerations . . . . . . . . . . . . . . . . . . . 42
15.1. Attacks against the Protocol . . . . . . . . . . . . . . 41 15.1. Attacks against the Protocol . . . . . . . . . . . . . . 42
15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 41 15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 42
15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 42 15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 43
15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 43 15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 43
15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 43 15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 44
15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 44 15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 44
15.2.3. Attack III: Assuming the Identity of a Client . . . 44 15.2.3. Attack III: Assuming the Identity of a Client . . . 45
15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 44 15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 45
15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 44 15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 45
16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 45 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 45
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . 45 17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . 46
17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . 45 17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . 46
17.2.1. Updated Attributes . . . . . . . . . . . . . . . . . 45 17.2.1. Updated Attributes . . . . . . . . . . . . . . . . . 46
17.2.2. New Attributes . . . . . . . . . . . . . . . . . . . 46 17.2.2. New Attributes . . . . . . . . . . . . . . . . . . . 47
17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 46 17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 47
17.4. Password Algorithm Registry . . . . . . . . . . . . . . 46 17.4. Password Algorithm Registry . . . . . . . . . . . . . . 47
17.4.1. Password Algorithms . . . . . . . . . . . . . . . . 47 17.4.1. Password Algorithms . . . . . . . . . . . . . . . . 48
17.4.1.1. SHA256 . . . . . . . . . . . . . . . . . . . . . 47 17.4.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 48
17.5. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 47 17.4.1.2. SHA256 . . . . . . . . . . . . . . . . . . . . . 48
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 47 17.5. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 48
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 48
19.1. Normative References . . . . . . . . . . . . . . . . . . 47 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
19.2. Informational References . . . . . . . . . . . . . . . . 49 19.1. Normative References . . . . . . . . . . . . . . . . . . 49
Appendix A. C Snippet to Determine STUN Message Types . . . . . 50 19.2. Informational References . . . . . . . . . . . . . . . . 50
Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 51 Appendix A. C Snippet to Determine STUN Message Types . . . . . 52
B.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 51 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 53
B.2. Modifications between draft-ietf-tram-stunbis-04 and B.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 53
draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 51 B.2. Modifications between draft-ietf-tram-stunbis-05 and
B.3. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 53
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 51 B.3. Modifications between draft-ietf-tram-stunbis-04 and
B.4. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 53
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 52 B.4. Modifications between draft-ietf-tram-stunbis-03 and
B.5. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 54
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 52 B.5. Modifications between draft-ietf-tram-stunbis-02 and
B.6. Modifications between draft-salgueiro-tram-stunbis-02 and draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 54
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 53 B.6. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 54
B.7. Modifications between draft-salgueiro-tram-stunbis-02 and B.7. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 53 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 55
B.8. Modifications between draft-salgueiro-tram-stunbis-01 and B.8. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 54 draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 55
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 54 B.9. Modifications between draft-salgueiro-tram-stunbis-01 and
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 54 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 56
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
The protocol defined in this specification, Session Traversal The protocol defined in this specification, Session Traversal
Utilities for NAT, provides a tool for dealing with NATs. It Utilities for NAT, provides a tool for dealing with NATs. It
provides a means for an endpoint to determine the IP address and port provides a means for an endpoint to determine the IP address and port
allocated by a NAT that corresponds to its private IP address and allocated by a NAT that corresponds to its private IP address and
port. It also provides a way for an endpoint to keep a NAT binding port. It also provides a way for an endpoint to keep a NAT binding
alive. With some extensions, the protocol can be used to do alive. With some extensions, the protocol can be used to do
connectivity checks between two endpoints connectivity checks between two endpoints
skipping to change at page 21, line 16 skipping to change at page 21, line 16
If the <host> part contains an IP address, then this IP address is If the <host> part contains an IP address, then this IP address is
used directly to contact the server. A "stuns" URI containing an IP used directly to contact the server. A "stuns" URI containing an IP
address MUST be rejected, unless the domain name is provided by the address MUST be rejected, unless the domain name is provided by the
same mechanism that provided the STUN URI, and that domain name can same mechanism that provided the STUN URI, and that domain name can
be passed to the verification code. be passed to the 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 <host> 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
skipping to change at page 23, line 10 skipping to change at page 23, line 10
key = OpaqueString(password) key = OpaqueString(password)
where the OpaqueString profile is defined in where the OpaqueString profile is defined in
[I-D.ietf-precis-saslprepbis]. [I-D.ietf-precis-saslprepbis].
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
what is the message integrity algorithm supported by both agents. In which message integrity algorithm is supported by both agents. In
this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST
be included in addition to USERNAME. The HMAC for the MESSAGE- be included in addition to USERNAME. The HMAC for the MESSAGE-
INTEGRITY attribute is computed as described in Section 14.4 and the INTEGRITY attribute is computed as described in Section 14.4 and the
HMAC for the MESSAGE-INTEGRITY-SHA256 attributes is computed as HMAC for the MESSAGE-INTEGRITY-SHA256 attributes is computed as
described in Section 14.5. Note that the password is never included described in Section 14.5. Note that the password is never included
in the request or indication. in the request or indication.
9.1.3. Receiving a Request or Indication 9.1.3. Receiving a Request or Indication
After the agent has done the basic processing of a message, the agent After the agent has done the basic processing of a message, the agent
skipping to change at page 24, line 19 skipping to change at page 24, line 19
* 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
contains a MESSAGE-INTEGRITY-SHA256 attribute MUST include the contains a MESSAGE-INTEGRITY-SHA256 attribute MUST include the
MESSAGE-INTEGRITY-SHA256 attribute, computed using the password MESSAGE-INTEGRITY-SHA256 attribute, computed using the password
utilized to authenticate the request. Any response generated by a utilized to authenticate the request. Any response generated by a
server to a request that contains only a MESSAGE-INTEGRITY attribute server to a request that contains only a MESSAGE-INTEGRITY attribute
MUST include the MESSAGE-INTEGRITY attribute, computed using the MUST include the MESSAGE-INTEGRITY attribute, computed using the
password utilized to authenticate the request. The response MUST NOT password utilized to authenticate the request. This means that only
contain the USERNAME attribute. one of these attributes can appear in a response. The response MUST
NOT contain the USERNAME attribute.
If any of the checks fail, a server MUST NOT include a MESSAGE- If any of the checks fail, a server MUST NOT include a MESSAGE-
INTEGRITY-SHA256, MESSAGE-INTEGRITY, or USERNAME attribute in the INTEGRITY-SHA256, MESSAGE-INTEGRITY, or USERNAME attribute in the
error response. This is because, in these failure cases, the server error response. This is because, in these failure cases, the server
cannot determine the shared secret necessary to compute the MESSAGE- cannot determine the shared secret necessary to compute the MESSAGE-
INTEGRITY-SHA256 or MESSAGE-INTEGRITY attributes. INTEGRITY-SHA256 or MESSAGE-INTEGRITY attributes.
9.1.4. Receiving a Response 9.1.4. Receiving a Response
The client looks for the MESSAGE-INTEGRITY-SHA256 or the MESSAGE- The client looks for the MESSAGE-INTEGRITY or the MESSAGE-INTEGRITY-
INTEGRITY attribute in the response. If present, the client computes SHA256 attribute in the response. If present, the client computes
the message integrity over the response as defined in Section 14.4 or the message integrity over the response as defined in Section 14.4 or
Section 14.5, using the same password it utilized for the request. Section 14.5, using the same password it utilized for the request.
If the resulting value matches the contents of the MESSAGE-INTEGRITY If the resulting value matches the contents of the MESSAGE-INTEGRITY
or MESSAGE-INTEGRITY-SHA256 attribute, the response is considered or MESSAGE-INTEGRITY-SHA256 attribute, the response is considered
authenticated. If the value does not match, or if both MESSAGE- authenticated. If the value does not match, or if both MESSAGE-
INTEGRITY and MESSAGE-INTEGRITY-SHA256 were absent, the response MUST INTEGRITY and MESSAGE-INTEGRITY-SHA256 were absent, the response MUST
be discarded, as if it was never received. This means that be discarded, as if it was never received. This means that
retransmits, if applicable, will continue. retransmits, if applicable, will continue.
If the client only sent one algorithm in the request (because of the
external indication in section Section 9.2.2, or this being a
subsequent request as defined in Section 9.1.5) the algorithm in the
response has to match.
9.1.5. Sending Subsequent Requests 9.1.5. Sending Subsequent Requests
A client sending subsequent requests to the same server a MAY choose A client sending subsequent requests to the same server MAY choose to
to send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY
attribute depending upon the attribute that was received in the attribute depending upon the attribute that was received in the
response to the initial request. response to the initial request. Here same server means same IP
address and port number, not just the same URL or SRV lookup result.
9.2. Long-Term Credential Mechanism 9.2. Long-Term Credential Mechanism
The long-term credential mechanism relies on a long-term credential, The long-term credential mechanism relies on a long-term credential,
in the form of a username and password that are shared between client in the form of a username and password that are shared between client
and server. The credential is considered long-term since it is and server. The credential is considered long-term since it is
assumed that it is provisioned for a user, and remains in effect assumed that it is provisioned for a user, and remains in effect
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.
skipping to change at page 27, line 38 skipping to change at page 27, line 41
MUST include a REALM value. It is RECOMMENDED that the REALM MUST include a REALM value. It is RECOMMENDED that the REALM
value be the domain name of the provider of the STUN server. The value be the domain name of the provider of the STUN server. The
response MUST include a NONCE, selected by the server. The server response MUST include a NONCE, selected by the server. The server
MUST ensure that the same NONCE cannot be selected for clients MUST ensure that the same NONCE cannot be selected for clients
that use different IP addresses and/or different ports. The that use different IP addresses and/or different ports. The
server MAY support alternate password algorithms, in which case it server MAY support alternate password algorithms, in which case it
can list them in preferential order in a PASSWORD-ALGORITHMS can list them in preferential order in a PASSWORD-ALGORITHMS
attribute. If the server adds a PASSWORD-ALGORITHMS attribute it attribute. If the server adds a PASSWORD-ALGORITHMS attribute it
MUST prepend the NONCE attribute value with the character string MUST prepend the NONCE attribute value with the character string
"obMatJos2". The response SHOULD NOT contain a USERNAME, MESSAGE- "obMatJos2". The response SHOULD NOT contain a USERNAME, MESSAGE-
INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute. INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute. The "obMatJos2"
https://github.com/meteor/meteor/wiki/Tracker-Manualiet The prefix is used to prevent bid down attacks on the password
"obMatJos2" prefix is used to prevent bid down attacks on the algorithm's negotiation.
password algorithm's negotiation.
Note that sharing a NONCE is no longer permitted, so trying to Note that sharing a NONCE is no longer permitted, so trying to
share one will result in a wasted transaction. share one will result in a wasted transaction.
o If the message contains a MESSAGE-INTEGRITY or a MESSAGE- o If the message contains a MESSAGE-INTEGRITY or a MESSAGE-
INTEGRITY-SHA256 attribute, but is missing the USERNAME, REALM, or INTEGRITY-SHA256 attribute, but is missing the USERNAME, REALM, or
NONCE attribute, the server MUST generate an error response with NONCE attribute, the server MUST generate an error response with
an error code of 400 (Bad Request). This response SHOULD NOT an error code of 400 (Bad Request). This response SHOULD NOT
include a USERNAME, NONCE, REALM, MESSAGE-INTEGRITY or MESSAGE- include a USERNAME, NONCE, REALM, MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY-SHA256 attribute. INTEGRITY-SHA256 attribute.
o If the NONCE attribute starts with the value "obMatJos2" but
PASSWORD-ALGORITHMS does not match, then the server MUST generate
an error response with an error code of 400 (Bad Request).
o If the NONCE attribute starts with the value "obMatJos2" but the o If the NONCE attribute starts with the value "obMatJos2" but the
PASSWORD-ALGORITHMS attribute is not present or is not identical request contains neither PASSWORD-ALGORITHMS nor PASSWORD-
to the PASSWORD-ALGORITHMS attribute sent in the response, the ALGORITHM, then the request is processed as though PASSWORD-
server MUST generate an error response with an error code of 400 ALGORITHM were MD5.
(Bad Request). This response SHOULD NOT include a USERNAME,
NONCE, REALM, MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256 o If the NONCE attribute starts with the value "obMatJos2" but only
attribute. one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is present, then
the server MUST generate an error response with an error code of
400 (Bad Request).
o If the NONCE attribute starts with the value "obMatJos2" but
PASSWORD-ALGORITHM does not match one of the entries in PASSWORD-
ALGORITHMS, then the server MUST generate an error response with
an error code of 400 (Bad Request).
o If the NONCE is no longer valid, the server MUST generate an error o If the NONCE is no longer valid, the server MUST generate an error
response with an error code of 438 (Stale Nonce). This response response with an error code of 438 (Stale Nonce). This response
MUST include NONCE and REALM attributes and SHOULD NOT include the MUST include NONCE and REALM attributes and SHOULD NOT include the
USERNAME, MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256 USERNAME, MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256
attribute. Servers can invalidate nonces in order to provide attribute. Servers can invalidate nonces in order to provide
additional security. See Section 4.3 of [RFC2617] for guidelines. additional security. See Section 4.3 of [RFC2617] for guidelines.
o If the username in the USERNAME attribute is not valid, the server o If the username in the USERNAME attribute is not valid, the server
MUST generate an error response with an error code of 401 MUST generate an error response with an error code of 401
skipping to change at page 28, line 41 skipping to change at page 29, line 6
same password, compute the value for the message integrity as same password, compute the value for the message integrity as
described in Section 14.4. If the resulting value does not match described in Section 14.4. If the resulting value does not match
the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE- the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE-
INTEGRITY-SHA256 attribute, the server MUST reject the request INTEGRITY-SHA256 attribute, the server MUST reject the request
with an error response. This response MUST use an error code of with an error response. This response MUST use an error code of
401 (Unauthorized). It MUST include REALM and NONCE attributes 401 (Unauthorized). It MUST include REALM and NONCE attributes
and SHOULD NOT include the USERNAME, MESSAGE-INTEGRITY, or and SHOULD NOT include the USERNAME, MESSAGE-INTEGRITY, or
MESSAGE-INTEGRITY-SHA256 attribute. MESSAGE-INTEGRITY-SHA256 attribute.
If these checks pass, the server continues to process the request. If these checks pass, the server continues to process the request.
Any response generated by the server (excepting the cases described Any response generated by the server (excepting the cases where a
above) MUST include both the MESSAGE-INTEGRITY and MESSAGE-INTEGRITY- server responds with an error code, which cannot be authenticated)
SHA256 attributes, computed using the username and password utilized MUST include MESSAGE-INTEGRITY-SHA256 attribute, computed using the
to authenticate the request. The REALM, NONCE, and USERNAME username and password utilized to authenticate the request, unless
the request was processed as though PASSWORD-ALGORITHM was MD5. In
that case the MESSAGE-INTEGRITY attribute MUST be used instead of the
MESSAGE-INTEGRITY-SHA256 attribute. The REALM, NONCE, and USERNAME
attributes SHOULD NOT be included. attributes SHOULD NOT be included.
9.2.4. Receiving a Response 9.2.4. Receiving a Response
If the response is an error response with an error code of 401 If the response is an error response with an error code of 401
(Unauthorized), the client MUST test if the NONCE attribute value (Unauthorized), the client MUST test if the NONCE attribute value
starts with the character string "obMatJos2". If the test succeeds starts with the character string "obMatJos2". If the test succeeds
and no PASSWORD-ALGORITHMS attribute is present, then the client MUST and no PASSWORD-ALGORITHMS attribute is present, then the client MUST
NOT retry the request with a new transaction. NOT retry the request with a new transaction.
skipping to change at page 29, line 19 skipping to change at page 29, line 35
transaction. This request MUST contain a USERNAME, determined by the transaction. This request MUST contain a USERNAME, determined by the
client as the appropriate username for the REALM from the error client as the appropriate username for the REALM from the error
response. The request MUST contain the REALM, copied from the error response. The request MUST contain the REALM, copied from the error
response. The request MUST contain the NONCE, copied from the error response. The request MUST contain the NONCE, copied from the error
response. If the response contains a PASSWORD-ALGORITHMS attribute, response. If the response contains a PASSWORD-ALGORITHMS attribute,
the request MUST contain the PASSWORD-ALGORITHMS attribute with the the request MUST contain the PASSWORD-ALGORITHMS attribute with the
same content. If the response contains a PASSWORD-ALGORITHMS same content. If the response contains a PASSWORD-ALGORITHMS
attribute, and this attribute contains at least one algorithm that is attribute, and this attribute contains at least one algorithm that is
supported by the client then the request MUST contain a PASSWORD- supported by the client then the request MUST contain a PASSWORD-
ALGORITHM attribute with the first algorithm supported on the list. ALGORITHM attribute with the first algorithm supported on the list.
if the response contains a MESSAGE-INTEGRITY-SHA256 attribute then If the response contains a PASSWORD-ALGORITHMS attribute, and this
the request MUST contain a MESSAGE-INTEGRITY-SHA256 attribute, attribute does not contain any algorithm that is supported by the
computed using the password associated with the username in the client, then the client MUST NOT retry the request with a new
USERNAME attribute. Else the request MUST contain the MESSAGE- transaction. The client MUST NOT perform this retry if it is not
INTEGRITY attribute, computed using the password associated with the changing the USERNAME or REALM or its associated password, from the
username in the USERNAME attribute. The client MUST NOT perform this previous attempt.
retry if it is not changing the USERNAME or REALM or its associated
password, from the previous attempt.
If the response is an error response with an error code of 438 (Stale If the response is an error response with an error code of 438 (Stale
Nonce), the client MUST retry the request, using the new NONCE Nonce), the client MUST retry the request, using the new NONCE
attribute supplied in the 438 (Stale Nonce) response. This retry attribute supplied in the 438 (Stale Nonce) response. This retry
MUST also include the USERNAME, REALM and either the MESSAGE- MUST also include the USERNAME, REALM and either the MESSAGE-
INTEGRITY or MESSAGE-INTEGRITY-SHA256 attributes. INTEGRITY or MESSAGE-INTEGRITY-SHA256 attributes.
For all other responses, if the NONCE attribute starts with the value
"obMatJos2" but PASSWORD-ALGORITHMS is not present, the response MUST
be ignored.
The client looks for the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY- The client looks for the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-
SHA256 attribute in the response (either success or failure). If SHA256 attribute in the response (either success or failure). If
present, the client computes the message integrity over the response present, the client computes the message integrity over the response
as defined in Section 14.4 or Section 14.5, using the same password as defined in Section 14.4 or Section 14.5, using the same password
it utilized for the request. If the resulting value matches the it utilized for the request. If the resulting value matches the
contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
attribute, the response is considered authenticated. If the value attribute, the response is considered authenticated. If the value
does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY- does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-
SHA256 were absent, the response MUST be discarded, as if it was SHA256 were absent, the response MUST be discarded, as if it was
never received. This means that retransmits, if applicable, will never received. This means that retransmits, if applicable, will
continue. continue.
If the response contains a PASSWORD-ALGORITHMS attribute, the
subsequent request MUST be authenticated using MESSAGE-INTEGRITY-
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. a usage must define if and when this extension is used.
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 an
ALTERNATE-SERVER attribute in the error response. The error response ALTERNATE-SERVER attribute in the error response. The error response
skipping to change at page 31, line 31 skipping to change at page 32, line 5
However, it can be utilized as part of a solution through STUN However, it can be utilized as part of a solution through STUN
usages. This is discussed further in Section 13. usages. This is discussed further in Section 13.
13. STUN Usages 13. STUN Usages
STUN by itself is not a solution to the NAT traversal problem. STUN by itself is not a solution to the NAT traversal problem.
Rather, STUN defines a tool that can be used inside a larger Rather, STUN defines a tool that can be used inside a larger
solution. The term "STUN usage" is used for any solution that uses solution. The term "STUN usage" is used for any solution that uses
STUN as a component. STUN as a component.
At the time of writing, three STUN usages are defined: Interactive
Connectivity Establishment (ICE) [I-D.ietf-mmusic-rfc5245bis],
Client-initiated connections for SIP [RFC5626], and NAT Behavior
Discovery [RFC5780]. Other STUN usages may be defined in the future.
A STUN usage defines how STUN is actually utilized -- when to send A STUN usage defines how STUN is actually utilized -- when to send
requests, what to do with the responses, and which optional requests, what to do with the responses, and which optional
procedures defined here (or in an extension to STUN) are to be used. procedures defined here (or in an extension to STUN) are to be used.
A usage would also define: A usage would also define:
o Which STUN methods are used. o Which STUN methods are used.
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.
skipping to change at page 39, line 24 skipping to change at page 39, line 49
The NONCE attribute may be present in requests and responses. It The NONCE attribute may be present in requests and responses. It
contains a sequence of qdtext or quoted-pair, which are defined in contains a sequence of qdtext or quoted-pair, which are defined in
RFC 3261 [RFC3261]. Note that this means that the NONCE attribute RFC 3261 [RFC3261]. Note that this means that the NONCE attribute
will not contain actual quote characters. See RFC 2617 [RFC2617], will not contain actual quote characters. See RFC 2617 [RFC2617],
Section 4.3, for guidance on selection of nonce values in a server. Section 4.3, for guidance on selection of nonce values in a server.
It MUST be less than 128 characters (which can be as long as 763 It MUST be less than 128 characters (which can be as long as 763
bytes). bytes).
14.10. PASSWORD-ALGORITHMS 14.10. PASSWORD-ALGORITHMS
The PASSWORD-ALGORITHMS attribute is present only in responses. It The PASSWORD-ALGORITHMS attribute may be present in requests and
contains the list of algorithms that the server can use to derive the responses. It contains the list of algorithms that the server can
long-term password. use to derive the long-term password.
The set of known algorithms is maintained by IANA. The initial set The set of known algorithms is maintained by IANA. The initial set
defined by this specification is found in Section 17.4. defined by this specification is found in Section 17.4.
The attribute contains a list of algorithm numbers and variable The attribute contains a list of algorithm numbers and variable
length parameters. The algorithm number is a 16-bit value as defined length parameters. The algorithm number is a 16-bit value as defined
in Section 17.4. The parameters start with the actual length of the in Section 17.4. The parameters start with the actual length of the
parameters as a 16-bit value, followed by the parameters that are parameters as a 16-bit value, followed by the parameters that are
specific to each algorithm. The parameters are padded to a 32-bit specific to each algorithm. The parameters are padded to a 32-bit
boundary, in the same manner as an attribute. boundary, in the same manner as an attribute.
skipping to change at page 47, line 7 skipping to change at page 48, line 7
for the Error Codes given in Section 14.7. for the Error Codes given in Section 14.7.
17.4. Password Algorithm Registry 17.4. Password Algorithm Registry
IANA is requested to create a new registry for Password Algorithm. IANA is requested to create a new registry for Password Algorithm.
A Password Algorithm is a hex number in the range 0x0000 - 0xFFFF. A Password Algorithm is a hex number in the range 0x0000 - 0xFFFF.
The initial Password Algorithms are: The initial Password Algorithms are:
0x0001: Salted SHA256 0x0001: MD5
0x0002: SHA256 0x0002: SHA256
Password Algorithms in the first half of the range (0x0000 - 0x7FFF) Password Algorithms in the first half of the range (0x0000 - 0x7FFF)
are assigned by IETF Review [RFC5226]. Password Algorithms in the are assigned by IETF Review [RFC5226]. Password Algorithms in the
second half of the range (0x8000 - 0xFFFF) are assigned by Designated second half of the range (0x8000 - 0xFFFF) are assigned by Designated
Expert [RFC5226]. Expert [RFC5226].
17.4.1. Password Algorithms 17.4.1. Password Algorithms
17.4.1.1. SHA256 17.4.1.1. MD5
This password algorithms is taken from [I-D.ietf-httpauth-digest]. This password algorithm is taken from [RFC1321].
The key length is 20 bytes and the parameters value is empty.
NOTE: This algorithm MUST only be used for compatibility with legacy
systems.
key = SHA256(username ":" realm ":" OpaqueString(password))
17.4.1.2. SHA256
This password algorithm is taken from [I-D.ietf-httpauth-digest].
The key length is 32 bytes and the parameters value is empty. The key length is 32 bytes and the parameters value is empty.
key = SHA256(username ":" realm ":" OpaqueString(password)) key = SHA256(username ":" realm ":" OpaqueString(password))
17.5. STUN UDP and TCP Port Numbers 17.5. STUN UDP and TCP Port Numbers
IANA is requested to update the reference from RFC 5389 to RFC-to-be IANA is requested to update the reference from RFC 5389 to RFC-to-be
for the following ports: for the following ports:
skipping to change at page 47, line 49 skipping to change at page 49, line 13
o o
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-precis-saslprepbis] [I-D.ietf-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Preparation, Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", draft-ietf-precis- Representing Usernames and Passwords", draft-ietf-precis-
saslprepbis-14 (work in progress), March 2015. saslprepbis-18 (work in progress), May 2015.
[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.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
1981. DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. DOI 10.17487/RFC1321, April 1992,
<http://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, February Hashing for Message Authentication", RFC 2104,
1997. DOI 10.17487/RFC2104, February 1997,
<http://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, DOI 10.17487/RFC2617, June 1999,
<http://www.rfc-editor.org/info/rfc2617>.
[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,
February 2000. DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[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, November 2003. 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[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, August 2008. (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[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, June "Computing TCP's Retransmission Timer", RFC 6298,
2011. DOI 10.17487/RFC6298, June 2011,
<http://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, January 2012. Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://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-
Huguenin, "URI Scheme for the Session Traversal Utilities Huguenin, "URI Scheme for the Session Traversal Utilities
for NAT (STUN) Protocol", RFC 7064, November 2013. for NAT (STUN) Protocol", RFC 7064, DOI 10.17487/RFC7064,
November 2013, <http://www.rfc-editor.org/info/rfc7064>.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Session Traversal Layer Security (DTLS) as Transport for Session Traversal
Utilities for NAT (STUN)", RFC 7350, August 2014. Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350,
August 2014, <http://www.rfc-editor.org/info/rfc7350>.
19.2. Informational References 19.2. Informational References
[I-D.ietf-httpauth-digest] [I-D.ietf-httpauth-digest]
Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest
Access Authentication", draft-ietf-httpauth-digest-15 Access Authentication", draft-ietf-httpauth-digest-19
(work in progress), March 2015. (work in progress), April 2015.
[I-D.ietf-mmusic-rfc5245bis] [I-D.ietf-mmusic-rfc5245bis]
Keranen, A. and J. Rosenberg, "Interactive Connectivity Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal for Offer/Answer Protocols", Translator (NAT) Traversal", draft-ietf-mmusic-
draft-ietf-mmusic-rfc5245bis-04 (work in progress), March rfc5245bis-05 (work in progress), September 2015.
2015.
[I-D.ietf-uta-tls-bcp] [I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre, Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft- "Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-11 (work in progress), February 2015. ietf-uta-tls-bcp-11 (work in progress), February 2015.
[KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time [KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", SIGCOMM 1987, Estimates in Reliable Transport Protocols", SIGCOMM 1987,
August 1987. August 1987.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>.
[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,
June 2002. DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for
Self-Address Fixing (UNSAF) Across Network Address UNilateral Self-Address Fixing (UNSAF) Across Network
Translation", RFC 3424, November 2002. Address Translation", RFC 3424, DOI 10.17487/RFC3424,
November 2002, <http://www.rfc-editor.org/info/rfc3424>.
[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,
March 2003. DOI 10.17487/RFC3489, March 2003,
<http://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, June 2005. Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <http://www.rfc-editor.org/info/rfc4107>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[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,
October 2008. DOI 10.17487/RFC5389, October 2008,
<http://www.rfc-editor.org/info/rfc5389>.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
Initiated Connections in the Session Initiation Protocol "Managing Client-Initiated Connections in the Session
(SIP)", RFC 5626, October 2009. Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009,
<http://www.rfc-editor.org/info/rfc5626>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010,
<http://www.rfc-editor.org/info/rfc5766>.
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using Session Traversal Utilities for NAT (STUN)", RFC Using Session Traversal Utilities for NAT (STUN)",
5780, May 2010. RFC 5780, DOI 10.17487/RFC5780, May 2010,
<http://www.rfc-editor.org/info/rfc5780>.
[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, March 2012. Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
March 2012, <http://www.rfc-editor.org/info/rfc6544>.
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:
#define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000) #define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000)
#define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010) #define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010)
#define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100) #define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100)
#define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110) #define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110)
skipping to change at page 51, line 30 skipping to change at page 53, line 30
This section must be removed before publication as an RFC. This section must be removed before publication as an RFC.
B.1. Open Issues B.1. Open Issues
1. Add reference RFC 5769 (stun vectors). 1. Add reference RFC 5769 (stun vectors).
2. Add flow diagram for long-term authenticattion. 2. Add flow diagram for long-term authenticattion.
3. Add vector for SHA256 password hash. 3. Add vector for SHA256 password hash.
B.2. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- B.2. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf-
tram-stunbis-04
o Address review comments from Jonathan Lexnnox and Brandon
Williams.
B.3. 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.
B.3. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- B.4. 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.
B.4. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- B.5. 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 52, line 38 skipping to change at page 54, line 47
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.
B.5. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- B.6. 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 53, line 25 skipping to change at page 55, line 33
* 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.
B.6. Modifications between draft-salgueiro-tram-stunbis-02 and draft- B.7. 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.
B.7. Modifications between draft-salgueiro-tram-stunbis-02 and draft- B.8. 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 54, line 11 skipping to change at page 56, line 19
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)
B.8. Modifications between draft-salgueiro-tram-stunbis-01 and draft- B.9. 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, and Alan Johnston Perreault, Benjamin Schwartz, Rifaat Shekh-Yusef, Alan Johnston,
for the comments, suggestions, and questions that helped improve this Jonathan Lennox and Brandon Williams for the comments, suggestions,
document. 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. 71 change blocks. 
150 lines changed or deleted 223 lines changed or added

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