draft-ietf-tram-stunbis-03.txt   draft-ietf-tram-stunbis-04.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
Intended status: Standards Track J. Rosenberg Intended status: Standards Track J. Rosenberg
Expires: September 27, 2015 D. Wing Expires: September 27, 2015 D. Wing
Cisco Cisco
R. Mahy R. Mahy
Plantronics Plantronics
P. Matthews P. Matthews
Avaya Avaya
March 26, 2015 March 26, 2015
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-03 draft-ietf-tram-stunbis-04
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 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. STUN Message Structure . . . . . . . . . . . . . . . . . . . 9 5. STUN Message Structure . . . . . . . . . . . . . . . . . . . 9
6. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 11 6. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 11
6.1. Forming a Request or an Indication . . . . . . . . . . . 11 6.1. Forming a Request or an Indication . . . . . . . . . . . 11
6.2. Sending the Request or Indication . . . . . . . . . . . . 12 6.2. Sending the Request or Indication . . . . . . . . . . . . 12
6.2.1. Sending over UDP or DTLS-over-UDP . . . . . . . . . . 13 6.2.1. Sending over UDP or DTLS-over-UDP . . . . . . . . . . 13
6.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . 14 6.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . 14
6.2.3. Sending over SCTP-over-UDP or SCTP-over-DTLS-over-UDP 15 6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP . . . . . 15
6.2.4. Sending over TLS-over-TCP or DTLS-over-UDP or SCTP- 6.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 16
over-DTLS-over-UDP . . . . . . . . . . . . . . . . . 17 6.3.1. Processing a Request . . . . . . . . . . . . . . . . 16
6.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 18 6.3.1.1. Forming a Success or Error Response . . . . . . . 17
6.3.1. Processing a Request . . . . . . . . . . . . . . . . 18 6.3.1.2. Sending the Success or Error Response . . . . . . 18
6.3.1.1. Forming a Success or Error Response . . . . . . . 19 6.3.2. Processing an Indication . . . . . . . . . . . . . . 18
6.3.1.2. Sending the Success or Error Response . . . . . . 20 6.3.3. Processing a Success Response . . . . . . . . . . . . 19
6.3.2. Processing an Indication . . . . . . . . . . . . . . 20 6.3.4. Processing an Error Response . . . . . . . . . . . . 19
6.3.3. Processing a Success Response . . . . . . . . . . . . 21 7. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 20
6.3.4. Processing an Error Response . . . . . . . . . . . . 21 8. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 20
7. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 22 8.1. STUN URI Scheme Semantics . . . . . . . . . . . . . . . . 21
8. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 22 9. Authentication and Message-Integrity Mechanisms . . . . . . . 22
8.1. STUN URI Scheme Semantics . . . . . . . . . . . . . . . . 23 9.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 22
9. Authentication and Message-Integrity Mechanisms . . . . . . . 24 9.1.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 24 9.1.2. Forming a Request or Indication . . . . . . . . . . . 23
9.1.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 24 9.1.3. Receiving a Request or Indication . . . . . . . . . . 23
9.1.2. Forming a Request or Indication . . . . . . . . . . . 25 9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 24
9.1.3. Receiving a Request or Indication . . . . . . . . . . 25 9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 24
9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 26 9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 24
9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 26 9.2.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 25
9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 26 9.2.2. Forming a Request . . . . . . . . . . . . . . . . . . 26
9.2.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 27 9.2.2.1. First Request . . . . . . . . . . . . . . . . . . 26
9.2.2. Forming a Request . . . . . . . . . . . . . . . . . . 28 9.2.2.2. Subsequent Requests . . . . . . . . . . . . . . . 27
9.2.2.1. First Request . . . . . . . . . . . . . . . . . . 28 9.2.3. Receiving a Request . . . . . . . . . . . . . . . . . 27
9.2.2.2. Subsequent Requests . . . . . . . . . . . . . . . 28 9.2.4. Receiving a Response . . . . . . . . . . . . . . . . 28
9.2.3. Receiving a Request . . . . . . . . . . . . . . . . . 29 10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 29
9.2.4. Receiving a Response . . . . . . . . . . . . . . . . 30 11. Backwards Compatibility with RFC 5389 . . . . . . . . . . . . 30
10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 31 12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 30
11. Backwards Compatibility with RFC 5389 . . . . . . . . . . . . 32 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 31
12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 32 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 32
13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 33 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 33
14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 34 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 34
14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 35 14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 35
14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 35 14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 35
14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 36 14.5. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 36
14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 37 14.6. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 36
14.5. MESSAGE-INTEGRITY2 . . . . . . . . . . . . . . . . . . . 37 14.7. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 37
14.6. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 38 14.8. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 38
14.7. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 39 14.9. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.8. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 40 14.10. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 39
14.9. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 40 14.11. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 40
14.10. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 41 14.12. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 40
14.11. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 41 14.13. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 41
14.12. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 42 14.14. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 41
14.13. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 42 14.15. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 41
14.14. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 43 15. Security Considerations . . . . . . . . . . . . . . . . . . . 41
14.15. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 43 15.1. Attacks against the Protocol . . . . . . . . . . . . . . 41
15. Security Considerations . . . . . . . . . . . . . . . . . . . 43 15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 41
15.1. Attacks against the Protocol . . . . . . . . . . . . . . 43 15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 42
15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 43 15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 43
15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 44 15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 43
15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 44 15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 44
15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 45 15.2.3. Attack III: Assuming the Identity of a Client . . . 44
15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 45 15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 44
15.2.3. Attack III: Assuming the Identity of a Client . . . 46 15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 44
15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 46 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 45
15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 46 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 46 17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . 45
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . 45
17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . 47 17.2.1. Updated Attributes . . . . . . . . . . . . . . . . . 45
17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . 47 17.2.2. New Attributes . . . . . . . . . . . . . . . . . . . 46
17.2.1. Updated Attributes . . . . . . . . . . . . . . . . . 47 17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 46
17.2.2. New Attributes . . . . . . . . . . . . . . . . . . . 48 17.4. Password Algorithm Registry . . . . . . . . . . . . . . 46
17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 48 17.4.1. Password Algorithms . . . . . . . . . . . . . . . . 47
17.4. Password Algorithm Registry . . . . . . . . . . . . . . 48 17.4.1.1. SHA256 . . . . . . . . . . . . . . . . . . . . . 47
17.4.1. Password Algorithms . . . . . . . . . . . . . . . . 49 17.5. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 47
17.4.1.1. SHA256 . . . . . . . . . . . . . . . . . . . . . 49 18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 47
17.4.1.2. Salted SHA256 . . . . . . . . . . . . . . . . . 49 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
17.5. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 49 19.1. Normative References . . . . . . . . . . . . . . . . . . 47
19.2. Informational References . . . . . . . . . . . . . . . . 49
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 49 Appendix A. C Snippet to Determine STUN Message Types . . . . . 50
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 51
19.1. Normative References . . . . . . . . . . . . . . . . . . 50 B.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 51
19.2. Informational References . . . . . . . . . . . . . . . . 52 B.2. Modifications between draft-ietf-tram-stunbis-04 and
Appendix A. C Snippet to Determine STUN Message Types . . . . . 53 draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 51
Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 54 B.3. Modifications between draft-ietf-tram-stunbis-03 and
B.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 54 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 51
B.2. Modifications between draft-ietf-tram-stunbis-03 and B.4. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 54 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 52
B.3. Modifications between draft-ietf-tram-stunbis-02 and B.5. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 55 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 52
B.4. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 55
B.5. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 56
B.6. Modifications between draft-salgueiro-tram-stunbis-02 and B.6. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 56 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 53
B.7. Modifications between draft-salgueiro-tram-stunbis-01 and B.7. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 57 draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 53
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57 B.8. Modifications between draft-salgueiro-tram-stunbis-01 and
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 57 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 54
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
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 12, line 28 skipping to change at page 12, line 28
IPv6 [RFC2460]. This value corresponds to the overall size of the IP IPv6 [RFC2460]. This value corresponds to the overall size of the IP
packet. Consequently, for IPv4, the actual STUN message would need packet. Consequently, for IPv4, the actual STUN message would need
to be less than 548 bytes (576 minus 20-byte IP header, minus 8-byte to be less than 548 bytes (576 minus 20-byte IP header, minus 8-byte
UDP header, assuming no IP options are used). UDP header, assuming no IP options are used).
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.
If a STUN client needs to send requests that are larger than the MTU, STUN provides no ability to handle the case where the request is
or if an application envisions that a response would be larger than under the MTU but the response would be larger than the MTU. It is
the MTU, then it MUST use SCTP-over-UDP or SCTP-over-DTLS-over-UDP as not envisioned that this limitation will be an issue for STUN. The
a transport, unless the purpose of sending an oversized packet is to MTU limitation is a SHOULD, and not a MUST, to account for cases
probe for MTU characteristics (see [RFC5780]). where STUN itself is being used to probe for MTU characteristics
[RFC5780]. Outside of this or similar applications, the MTU
Adding an ORIGIN attribute to a request, as specified in constraint MUST be followed.
[I-D.ietf-tram-stun-origin], may increase the size of a request
beyond the MTU such that it consequently triggers the use of SCTP-
over-UDP or SCTP-over-DTLS-over-UDP as a transport.
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, specifies how to send STUN messages over UDP, TCP, TLS-over-TCP, or
DTLS-over-UDP, SCTP-over-UDP, or SCTP-over-DTLS-over-UDP; other DTLS-over-UDP; other transport protocols may be added in the future.
transport protocols may be added in the future. The STUN usage must The STUN usage must specify which transport protocol is used, and how
specify which transport protocol is used, and how the agent the agent determines the IP address and port of the recipient.
determines the IP address and port of the recipient. Section 8 Section 8 describes a DNS-based method of determining the IP address
describes a DNS-based method of determining the IP address and port and port of a server that a usage may elect to use. STUN may be used
of a server that a usage may elect to use. STUN may be used with with anycast addresses, but only with UDP and in usages where
anycast addresses, but only with UDP and in usages where
authentication is not used. 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
space new parallel transactions to a server by RTO and SHOULD limit limit itself to ten outstanding transactions to the same server.
itself to ten outstanding transactions to the same server.
Parallel transactions are defined as transactions that can be sent
independently of each other. Serial transactions, on the other hand,
are a series of transactions that are each dependent on the
completion of the previous transaction (e.g., the second transaction
of a long term authentication). In contrast to parallel
transactions, a client need not space new serial transactions to a
server by RTO.
6.2.1. Sending over UDP or DTLS-over-UDP 6.2.1. Sending over UDP or DTLS-over-UDP
When running STUN over UDP or STUN over DTLS-over-UDP [RFC7350], it When running STUN over UDP or STUN over DTLS-over-UDP [RFC7350], it
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.
skipping to change at page 15, line 37 skipping to change at page 15, line 24
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
management in cases of overload. management in cases of overload.
6.2.3. Sending over SCTP-over-UDP or SCTP-over-DTLS-over-UDP 6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP
For SCTP-over-UDP [RFC6951] and SCTP-over-DTLS-over-UDP
[I-D.ietf-tsvwg-sctp-dtls-encaps], the client opens a Stream Control
Transmission Protocol (SCTP) connection to the server.
For some STUN usages, STUN is sent over SCTP as the only protocol
over the UDP association. In this case, it can be sent without the
aid of any additional demultiplexing. In other usages, or with other
extensions, it may be multiplexed with other data over a UDP
association. In that case, the SCTP source and destination ports
MUST be chosen so the eight most significant bits are 0b00000101 (5).
Reliability of STUN over SCTP-over-UDP and STUN over SCTP-over-DTLS-
over-UDP is handled by SCTP itself and there are no retransmissions
at the STUN protocol level. However, for a request/response
transaction, if the client has not received a response by Ti seconds
after it sent the INIT to establish the connection, it considers the
transaction to have timed out. Ti SHOULD be configurable and SHOULD
have a default of 39.5s. This value has been chosen to equalize the
SCTP-over-UDP, TCP, and UDP timeouts for the default initial RTO.
In addition, if the client is unable to establish the SCTP
connection, or the SCTP connection is reset or fails before a
response is received, any request/response transaction in progress is
considered to have failed.
The client MAY send multiple transactions over a single SCTP (or
SCTP-over-DTLS) connection and it MAY send another request before
receiving a response to the previous. Each transaction MUST use a
different SCTP stream ID. The client SHOULD keep the connection open
until it:
o has no further STUN requests or indications to send over that
connection, and
o has no plans to use any resources (such as a mapped address
(MAPPED-ADDRESS or XOR-MAPPED-ADDRESS) or relayed address
[RFC5766]) that were learned through STUN requests sent over that
connection, and
o has finished using all corresponding applications if multiplexing
other application protocols over that port
When using SCTP-over-UDP, the SCTP source port and destination port
MUST be selected so the eight most significant bits are set to
0b00000101. This permits multiplexing of STUN-over-UDP, STUN-over-
SCTP-over-UDP, DTLS, TURN channels and RTP/RTCP on the same socket as
specified in [I-D.ietf-avtcore-rfc5764-mux-fixes].
STUN indications MAY be sent unreliably by using the SCTP extension
in [RFC3758], augmented with the policies of
[I-D.ietf-tsvwg-sctp-prpolicies]. Each STUN usage MUST specify the
conditions under which STUN indications are sent reliably or not, and
MUST specify the policy for allocating an SCTP stream ID. The NAT
Discovery usage described in this document does not use STUN
indications.
At the server end, the server SHOULD keep the connection open and let
the client close it unless the server has determined that the
connection has timed out (for example, due to the client
disconnecting from the network). Bindings learned by the client will
remain valid in intervening NATs only while the connection remains
open. Only the client knows how long it needs the binding. The
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
ever open a connection back towards the client in order to send a
response. Servers SHOULD follow best practices regarding connection
management in cases of overload.
6.2.4. Sending over TLS-over-TCP or DTLS-over-UDP or SCTP-over-DTLS-
over-UDP
When STUN is run by itself over TLS-over-TCP or DTLS-over-UDP or When STUN is run by itself over TLS-over-TCP or DTLS-over-UDP, the
SCTP-over-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 When it receives the TLS Certificate message, the client SHOULD
verify the certificate and inspect the site identified by the verify the certificate and inspect the site identified by the
certificate. If the certificate is invalid or revoked, or if it does certificate. If the certificate is invalid or revoked, or if it does
not identify the appropriate party, the client MUST NOT send the STUN not identify the appropriate party, the client MUST NOT send the STUN
message or otherwise proceed with the STUN transaction. The client message or otherwise proceed with the STUN transaction. The client
MUST verify the identity of the server using the following procedure. MUST verify the identity of the server. To do that, it follows the
identification procedures defined in Section 3.1 of RFC 2818
STUN clients that are using the mechanism in Section 8, and that have [RFC2818]. Alternatively, a client MAY be configured with a set of
established that all DNS Resource Records from the Source Domain to domains or IP addresses that are trusted; if a certificate is
the Host Name are secure according to DNSsec [RFC4033] (i.e., that received that identifies one of those domains or IP addresses, the
the AD bit is set in all the DNS responses) MUST lookup a TLSA client considers the identity of the server to be verified.
Resource Record [RFC6698] for the protocol, port and Host Name
selected. If the TLSA Resource Record is secure then the STUN client
MUST use it to validate the certificate presented by the STUN server.
If there is no TLSA Resource Record or if the Resource Record is not
secure, then the client MUST fallback to the validation process
defined in Section 3.1 of RFC 2818 [RFC2818].
Alternatively, a client MAY be configured with a set of domains or IP
addresses that are trusted. If a certificate is received that
identifies one of those trusted domains or IP addresses, the client
considers the identity of the server to be verified.
When STUN is 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 or a SCTP-over-DTLS-over-UDP connection or a DTLS-over-UDP association, the mandatory ciphersuites
association, the mandatory ciphersuites and TLS handling procedures and TLS handling procedures operate as defined by those protocols.
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. First, a set of processing
operations is applied that is independent of the class. This is operations is applied that is independent of the class. This is
followed by class-specific processing, described in the subsections followed by class-specific processing, described in the subsections
skipping to change at page 19, line 9 skipping to change at page 17, line 9
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 The server then does any additional checking that the method or the
specific usage requires. If all the checks succeed, the server specific usage requires. If all the checks succeed, the server
formulates a success response as described below. formulates a success response as described below.
When run over UDP or DTLS-over-UDP or SCTP-over-UDP or SCTP-over- When run over UDP or DTLS-over-UDP, a request received by the server
DTLS-over-UDP, a request received by the server could be the first could be the first request of a transaction, or a retransmission.
request of a transaction, or a retransmission. The server MUST The server MUST respond to retransmissions such that the following
respond to retransmissions such that the following property is property is preserved: if the client receives the response to the
preserved: if the client receives the response to the retransmission retransmission and not the response that was sent to the original
and not the response that was sent to the original request, the request, the overall state on the client and server is identical to
overall state on the client and server is identical to the case where the case where only the response to the original retransmission is
only the response to the original retransmission is received, or received, or where both responses are received (in which case the
where both responses are received (in which case the client will use client will use the first). The easiest way to meet this requirement
the first). The easiest way to meet this requirement is for the is for the server to remember all transaction IDs received over UDP
server to remember all transaction IDs received over UDP or DTLS- or DTLS-over-UDP and their corresponding responses in the last 40
over-UDP and their corresponding responses in the last 40 seconds. seconds. However, this requires the server to hold state, and will
However, this requires the server to hold state, and will be be inappropriate for any requests which are not authenticated.
inappropriate for any requests which are not authenticated. Another Another way is to reprocess the request and recompute the response.
way is to reprocess the request and recompute the response. The The latter technique MUST only be applied to requests that are
latter technique MUST only be applied to requests that are idempotent idempotent (a request is considered idempotent when the same request
(a request is considered idempotent when the same request can be can be safely repeated without impacting the overall state of the
safely repeated without impacting the overall state of the system) system) and result in the same success response for the same request.
and result in the same success response for the same request. The The Binding method is considered to be idempotent. Note that there
Binding method is considered to be idempotent. Note that there are are certain rare network events that could cause the reflexive
certain rare network events that could cause the reflexive transport transport address value to change, resulting in a different mapped
address value to change, resulting in a different mapped address in address in different success responses. Extensions to STUN MUST
different success responses. Extensions to STUN MUST discuss the discuss the implications of request retransmissions on servers that
implications of request retransmissions on servers that do not store do not store transaction state.
transaction state.
6.3.1.1. Forming a Success or Error Response 6.3.1.1. Forming a Success or Error Response
When forming the response (success or error), the server follows the When forming the response (success or error), the server follows the
rules of Section 6. The method of the response is the same as that rules of Section 6. The method of the response is the same as that
of the request, and the message class is either "Success Response" or of the request, and the message class is either "Success Response" or
"Error Response". "Error Response".
For an error response, the server MUST add an ERROR-CODE attribute For an error response, the server MUST add an ERROR-CODE attribute
containing the error code specified in the processing above. The containing the error code specified in the processing above. The
skipping to change at page 20, line 17 skipping to change at page 18, line 17
attributes to the response (see Section 9). attributes to the response (see Section 9).
The server also adds any attributes required by the specific method The server also adds any attributes required by the specific method
or usage. In addition, the server SHOULD add a SOFTWARE attribute to or usage. In addition, the server SHOULD add a SOFTWARE attribute to
the message. the message.
For the Binding method, no additional checking is required unless the For the Binding method, no additional checking is required unless the
usage specifies otherwise. When forming the success response, the usage specifies otherwise. When forming the success response, the
server adds a XOR-MAPPED-ADDRESS attribute to the response, where the server adds a XOR-MAPPED-ADDRESS attribute to the response, where the
contents of the attribute are the source transport address of the contents of the attribute are the source transport address of the
request message. For UDP, DTLS-over-UDP, SCTP-over-UDP and SCTP- request message. For UDP or DTLS-over-UDP this is the source IP
over-DTLS-over-UDP, this is the source IP address and source UDP port address and source UDP port of the request message. For TCP and TLS-
of the request message. For TCP and TLS-over-TCP, this is the source over-TCP, this is the source IP address and source TCP port of the
IP address and source TCP port of the TCP connection as seen by the TCP connection as seen by the server.
server.
6.3.1.2. Sending the Success or Error Response 6.3.1.2. Sending the Success or Error Response
The response (success or error) is sent over the same transport as The response (success or error) is sent over the same transport as
the request was received on. If the request was received over UDP, the request was received on. If the request was received over UDP or
DTLS-over-UDP, SCTP-over-UDP and SCTP-over-DTLS-over-UDP, the DTLS-over-UDP the destination IP address and port of the response are
destination IP address and port of the response are the source IP the source IP address and port of the received request message, and
address and port of the received request message, and the source IP the source IP address and port of the response are equal to the
address and port of the response are equal to the destination IP destination IP address and port of the received request message. If
address and port of the received request message. If the request was the request was received over TCP or TLS-over-TCP, the response is
received over TCP or TLS-over-TCP, the response is sent back on the sent back on the same TCP connection as the request was received on.
same TCP connection as the request was received on.
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 The agent then does any additional checking that the method or the
specific usage requires. If all the checks succeed, the agent then specific usage requires. If all the checks succeed, the agent then
processes the indication. No response is generated for an processes the indication. No response is generated for an
indication. indication.
skipping to change at page 22, line 48 skipping to change at page 20, line 48
client to use DNS to determine the IP address and port of a server. client to use DNS to determine the IP address and port of a server.
A STUN usage must describe if and when this extension is used. To A STUN usage must describe if and when this extension is used. To
use this procedure, the client must know a STUN URI [RFC7064]; the use this procedure, the client must know a STUN URI [RFC7064]; the
usage must also describe how the client obtains this URI. Hard- usage must also describe how the client obtains this URI. Hard-
coding a STUN URI into software is NOT RECOMMENDED in case the domain coding a STUN URI into software is NOT RECOMMENDED in case the domain
name is lost or needs to change for legal or other reasons. name is lost or needs to change for legal or other reasons.
When a client wishes to locate a STUN server on the public Internet When a client wishes to locate a STUN server on the public Internet
that accepts Binding request/response transactions, the STUN URI that accepts Binding request/response transactions, the STUN URI
scheme is "stun". When it wishes to locate a STUN server that scheme is "stun". When it wishes to locate a STUN server that
accepts Binding request/response transactions over a TLS, or DTLS, or accepts Binding request/response transactions over a TLS, or DTLS
SCTP-over-DTLS session, the URI scheme is "stuns". session, the URI scheme is "stuns".
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 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 <host> part. The protocol in the SRV lookup is the
transport protocol the client will run STUN over: "udp" for UDP, transport protocol the client will run STUN over: "udp" for UDP and
"tcp" for TCP, and "sctp-udp" for SCTP-over-UDP. "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.
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. The default port for STUN over SCTP-over-UDP requests is XXXX. 5349. Servers can run STUN over DTLS on the same port as STUN over
The default port for STUN over SCTP-over-DTLS-over-UDP requests is
XXXX. 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
records for UDP and TCP. In all cases, the port in DNS MUST reflect records for UDP and TCP. In all cases, the port in DNS MUST reflect
the one on which the server is listening. the one on which the server is listening.
If no SRV records were found, the client performs an A or AAAA record If no SRV records were found, the client performs an A or AAAA record
skipping to change at page 25, line 8 skipping to change at page 23, line 8
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 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-INTEGRITY2, and MESSAGE-INTEGRITY attributes in the USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attributes
message. The HMAC for the MESSAGE-INTEGRITY attribute is computed as in the message unless the agent knows from an external indication
described in Section 14.4 and the HMAC for the MESSAGE-INTEGRITY2 what is the message integrity algorithm supported by both agents. In
attributes is computed as described in Section 14.5. Note that the this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST
password is never included in the request or indication. be included in addition to USERNAME. The HMAC for the MESSAGE-
INTEGRITY attribute is computed as described in Section 14.4 and the
HMAC for the MESSAGE-INTEGRITY-SHA256 attributes is computed as
described in Section 14.5. Note that the password is never included
in the request or indication.
9.1.3. Receiving a Request or Indication 9.1.3. Receiving a Request or Indication
After the agent has done the basic processing of a message, the agent After the agent has done the basic processing of a message, the agent
performs the checks listed below in order specified: performs the checks listed below in order specified:
o If the message does not contain 1) a MESSAGE-INTEGRITY or a o If the message does not contain 1) a MESSAGE-INTEGRITY or a
MESSAGE-INTEGRITY2 attribute and 2) a USERNAME attribute: MESSAGE-INTEGRITY-SHA256 attribute and 2) a USERNAME attribute:
* 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 400 (Bad Request). of 400 (Bad Request).
* 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 USERNAME does not contain a username value currently valid o If the USERNAME does not contain a username value currently valid
within the server: within the server:
* If the message is a request, the server MUST reject the request * If the message is a request, the server MUST reject the request
with an error response. This response MUST use an error code with an error response. This response MUST use an error code
of 401 (Unauthorized). of 401 (Unauthorized).
* If the message is an indication, the agent MUST silently * If the message is an indication, the agent MUST silently
discard the indication. discard the indication.
o If the MESSAGE-INTEGRITY2 attribute is present compute the value o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the
for the message integrity as described in Section 14.5, using the value for the message integrity as described in Section 14.5,
password associated with the username. If the MESSAGE-INTEGRITY2 using the password associated with the username. If the MESSAGE-
attribute is not present, and using the same password, compute the INTEGRITY-SHA256 attribute is not present, and using the same
value for the message integrity as described in Section 14.4. If password, compute the value for the message integrity as described
the resulting value does not match the contents of the MESSAGE- in Section 14.4. If the resulting value does not match the
INTEGRITY2 attribute or the MESSAGE-INTEGRITY attribute: contents of the MESSAGE-INTEGRITY-SHA256 attribute or the MESSAGE-
INTEGRITY attribute:
* If the message is a request, the server MUST reject the request * If the message is a request, the server MUST reject the request
with an error response. This response MUST use an error code with an error response. This response MUST use an error code
of 401 (Unauthorized). of 401 (Unauthorized).
* If the message is an indication, the agent MUST silently * If the message is an indication, the agent MUST silently
discard the indication. discard the indication.
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-INTEGRITY2 attribute MUST include the MESSAGE- contains a MESSAGE-INTEGRITY-SHA256 attribute MUST include the
INTEGRITY2 attribute, computed using the password utilized to MESSAGE-INTEGRITY-SHA256 attribute, computed using the password
authenticate the request. Any response generated by a server to a utilized to authenticate the request. Any response generated by a
request that contains only a MESSAGE-INTEGRITY attribute MUST include server to a request that contains only a MESSAGE-INTEGRITY attribute
the MESSAGE-INTEGRITY attribute, computed using the password utilized MUST include the MESSAGE-INTEGRITY attribute, computed using the
to authenticate the request. The response MUST NOT contain the password utilized to authenticate the request. The response MUST NOT
USERNAME attribute. 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-
INTEGRITY2, MESSAGE-INTEGRITY, or USERNAME attribute in the error INTEGRITY-SHA256, MESSAGE-INTEGRITY, or USERNAME attribute in the
response. This is because, in these failure cases, the server cannot error response. This is because, in these failure cases, the server
determine the shared secret necessary to compute the MESSAGE- cannot determine the shared secret necessary to compute the MESSAGE-
INTEGRITY2 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-INTEGRITY2 or the MESSAGE-INTEGRITY The client looks for the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-
attribute in the response. If present, the client computes the INTEGRITY attribute in the response. If present, the client computes
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-INTEGRITY2 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-INTEGRITY2 were absent, the response MUST be INTEGRITY and MESSAGE-INTEGRITY-SHA256 were absent, the response MUST
discarded, as if it was never received. This means that retransmits, be discarded, as if it was never received. This means that
if applicable, will continue. retransmits, if applicable, will continue.
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 a MAY choose
to send only the MESSAGE-INTEGRITY2 or the MESSAGE-INTEGRITY to 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.
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
skipping to change at page 28, line 37 skipping to change at page 26, line 45
transaction has completed successfully. Forming a request as a transaction has completed successfully. Forming a request as a
consequence of a 401 or 438 error response is covered in consequence of a 401 or 438 error response is covered in
Section 9.2.4 and is not considered a "subsequent request" and thus Section 9.2.4 and is not considered a "subsequent request" and thus
does not utilize the rules described in Section 9.2.2.2. does not utilize the rules described in Section 9.2.2.2.
9.2.2.1. First Request 9.2.2.1. First Request
If the client has not completed a successful request/response If the client has not completed a successful request/response
transaction with the server (as identified by hostname, if the DNS transaction with the server (as identified by hostname, if the DNS
procedures of Section 8 are used, else IP address if not), it SHOULD procedures of Section 8 are used, else IP address if not), it SHOULD
omit the USERNAME, MESSAGE-INTEGRITY, MESSAGE-INTEGRITY2, REALM, omit the USERNAME, MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-SHA256,
NONCE, PASSWORD-ALGORITHMS, and PASSWORD-ALGORITHM attributes. In REALM, NONCE, PASSWORD-ALGORITHMS, and PASSWORD-ALGORITHM attributes.
other words, the very first request is sent as if there were no In other words, the very first request is sent as if there were no
authentication or message integrity applied. authentication or message integrity applied.
9.2.2.2. Subsequent Requests 9.2.2.2. Subsequent Requests
Once a request/response transaction has completed successfully, the Once a request/response transaction has completed successfully, the
client will have been presented a realm and nonce by the server, and client will have been presented a realm and nonce by the server, and
selected a username and password with which it authenticated. The selected a username and password with which it authenticated. The
client SHOULD cache the username, password, realm, and nonce for client SHOULD cache the username, password, realm, and nonce for
subsequent communications with the server. When the client sends a subsequent communications with the server. When the client sends a
subsequent request, it SHOULD include the USERNAME, REALM, NONCE, and subsequent request, it SHOULD include the USERNAME, REALM, NONCE, and
PASSWORD-ALGORITHM attributes with these cached values. It SHOULD PASSWORD-ALGORITHM attributes with these cached values. It SHOULD
include a MESSAGE-INTEGRITY attribute or a MESSAGE-INTEGRITY2 include a MESSAGE-INTEGRITY attribute or a MESSAGE-INTEGRITY-SHA256
attribute, computed as described in Section 14.4 and Section 14.5 attribute, computed as described in Section 14.4 and Section 14.5
using the cached password. The choice between the two attributes using the cached password. The choice between the two attributes
depends on the attribute received in the response to the first depends on the attribute received in the response to the first
request. request.
9.2.3. Receiving a Request 9.2.3. Receiving a Request
After the server has done the basic processing of a request, it After the server has done the basic processing of a request, it
performs the checks listed below in the order specified: performs the checks listed below in the order specified:
o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE- o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY2 attribute, the server MUST generate an error response INTEGRITY-SHA256 attribute, the server MUST generate an error
with an error code of 401 (Unauthorized). This response MUST response with an error code of 401 (Unauthorized). This response
include a REALM value. It is RECOMMENDED that the REALM value be MUST include a REALM value. It is RECOMMENDED that the REALM
the domain name of the provider of the STUN server. The response value be the domain name of the provider of the STUN server. The
MUST include a NONCE, selected by the server. The server MUST response MUST include a NONCE, selected by the server. The server
ensure that the same NONCE cannot be selected for clients that use MUST ensure that the same NONCE cannot be selected for clients
different IP addresses and/or different ports. The server MAY that use different IP addresses and/or different ports. The
support alternate password algorithms, in which case it can list server MAY support alternate password algorithms, in which case it
them in preferential order in a PASSWORD-ALGORITHMS attribute. If can list them in preferential order in a PASSWORD-ALGORITHMS
the server adds a PASSWORD-ALGORITHMS attribute it MUST prepend attribute. If the server adds a PASSWORD-ALGORITHMS attribute it
the NONCE attribute value with the character string "obMatJos2". MUST prepend the NONCE attribute value with the character string
The response SHOULD NOT contain a USERNAME, MESSAGE-INTEGRITY or "obMatJos2". The response SHOULD NOT contain a USERNAME, MESSAGE-
MESSAGE-INTEGRITY2 attribute. The "obMatJos2" prefix is used to INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute.
prevent bid down attacks on the password algorithm's negotiation. https://github.com/meteor/meteor/wiki/Tracker-Manualiet The
"obMatJos2" prefix is used to prevent bid down attacks on the
password algorithm's negotiation.
Note that sharing a NONCE is no longer permitted, so trying to
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-
INTEGRITY2 attribute, but is missing the USERNAME, REALM, or NONCE INTEGRITY-SHA256 attribute, but is missing the USERNAME, REALM, or
attribute, the server MUST generate an error response with an NONCE attribute, the server MUST generate an error response with
error code of 400 (Bad Request). This response SHOULD NOT include an error code of 400 (Bad Request). This response SHOULD NOT
a USERNAME, NONCE, REALM, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY2 include a USERNAME, NONCE, REALM, MESSAGE-INTEGRITY or MESSAGE-
attribute. INTEGRITY-SHA256 attribute.
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 PASSWORD-ALGORITHMS attribute is not present or is not identical
to the PASSWORD-ALGORITHMS attribute sent in the response, the to the PASSWORD-ALGORITHMS attribute sent in the response, the
server MUST generate an error response with an error code of 400 server MUST generate an error response with an error code of 400
(Bad Request). This response SHOULD NOT include a USERNAME, (Bad Request). This response SHOULD NOT include a USERNAME,
NONCE, REALM, MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY2 attribute. NONCE, REALM, MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256
attribute.
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-INTEGRITY2 attribute. USERNAME, MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256
Servers can invalidate nonces in order to provide additional attribute. Servers can invalidate nonces in order to provide
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
(Unauthorized). This response MUST include a REALM value. It is (Unauthorized). This response MUST include a REALM value. It is
RECOMMENDED that the REALM value be the domain name of the RECOMMENDED that the REALM value be the domain name of the
provider of the STUN server. The response MUST include a NONCE, provider of the STUN server. The response MUST include a NONCE,
selected by the server. The response SHOULD NOT contain a selected by the server. The response SHOULD NOT contain a
USERNAME, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY2 attribute. USERNAME, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute.
o If the MESSAGE-INTEGRITY2 attribute is present compute the value o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the
for the message integrity as described in Section 14.5, using the value for the message integrity as described in Section 14.5,
password associated with the username. Else, using the same using the password associated with the username. Else, using the
password, compute the value for the message integrity as described same password, compute the value for the message integrity as
in Section 14.4. If the resulting value does not match the described in Section 14.4. If the resulting value does not match
contents of the MESSAGE-INTEGRITY attribute or the MESSAGE- the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE-
INTEGRITY2 attribute, the server MUST reject the request with an INTEGRITY-SHA256 attribute, the server MUST reject the request
error response. This response MUST use an error code of 401 with an error response. This response MUST use an error code of
(Unauthorized). It MUST include REALM and NONCE attributes and 401 (Unauthorized). It MUST include REALM and NONCE attributes
SHOULD NOT include the USERNAME, MESSAGE-INTEGRITY, or MESSAGE- and SHOULD NOT include the USERNAME, MESSAGE-INTEGRITY, or
INTEGRITY2 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 described
above) MUST include both the MESSAGE-INTEGRITY and MESSAGE-INTEGRITY2 above) MUST include both the MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-
attributes, computed using the username and password utilized to SHA256 attributes, computed using the username and password utilized
authenticate the request. The REALM, NONCE, and USERNAME attributes to authenticate the request. The REALM, NONCE, and USERNAME
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.
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
skipping to change at page 30, line 52 skipping to change at page 29, line 19
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-INTEGRITY2 attribute then the if the response contains a MESSAGE-INTEGRITY-SHA256 attribute then
request MUST contain a MESSAGE-INTEGRITY2 attribute, computed using the request MUST contain a MESSAGE-INTEGRITY-SHA256 attribute,
the password associated with the username in the USERNAME attribute.
Else the request MUST contain the MESSAGE-INTEGRITY attribute,
computed using the password associated with the username in the computed using the password associated with the username in the
USERNAME attribute. The client MUST NOT perform this retry if it is USERNAME attribute. Else the request MUST contain the MESSAGE-
not changing the USERNAME or REALM or its associated password, from INTEGRITY attribute, computed using the password associated with the
the previous attempt. username in the USERNAME attribute. The client MUST NOT perform this
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-INTEGRITY2 attributes. INTEGRITY or MESSAGE-INTEGRITY-SHA256 attributes.
The client looks for the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY2 The client looks for the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-
attribute in the response (either success or failure). If present, SHA256 attribute in the response (either success or failure). If
the client computes the message integrity over the response as present, the client computes the message integrity over the response
defined in Section 14.4 or Section 14.5, using the same password it as defined in Section 14.4 or Section 14.5, using the same password
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-INTEGRITY2 attribute, contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
the response is considered authenticated. If the value does not attribute, the response is considered authenticated. If the value
match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY2 were does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-
absent, the response MUST be discarded, as if it was never received. SHA256 were absent, the response MUST be discarded, as if it was
This means that retransmits, if applicable, will continue. never received. This means that retransmits, if applicable, will
continue.
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
message MAY be authenticated; however, there are uses cases for message MAY be authenticated; however, there are uses cases for
ALTERNATE-SERVER where authentication of the response is not possible ALTERNATE-SERVER where authentication of the response is not possible
or practical. If the transaction uses TLS or DTLS and if the or practical. If the transaction uses TLS or DTLS and if the
transaction is authenticated by a MESSAGE-INTEGRITY2 attribute and if transaction is authenticated by a MESSAGE-INTEGRITY-SHA256 attribute
the server wants to redirect to a server that uses a different and if the server wants to redirect to a server that uses a different
certificate, then it MUST include an ALTERNATE-DOMAIN attribute certificate, then it MUST include an ALTERNATE-DOMAIN attribute
containing the subjectAltName of that certificate. containing the subjectAltName of that certificate.
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
skipping to change at page 37, line 18 skipping to change at page 35, line 30
[I-D.ietf-precis-saslprepbis]. [I-D.ietf-precis-saslprepbis].
14.4. MESSAGE-INTEGRITY 14.4. MESSAGE-INTEGRITY
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of
the STUN message. The MESSAGE-INTEGRITY attribute can be present in the STUN message. The MESSAGE-INTEGRITY attribute can be present in
any STUN message type. Since it uses the SHA1 hash, the HMAC will be any STUN message type. Since it uses the SHA1 hash, the HMAC will be
20 bytes. The text used as input to HMAC is the STUN message, 20 bytes. The text used as input to HMAC is the STUN message,
including the header, up to and including the attribute preceding the including the header, up to and including the attribute preceding the
MESSAGE-INTEGRITY attribute. With the exception of the MESSAGE- MESSAGE-INTEGRITY attribute. With the exception of the MESSAGE-
INTEGRITY2 and FINGERPRINT attributes, which appear after MESSAGE- INTEGRITY-SHA256 and FINGERPRINT attributes, which appear after
INTEGRITY, agents MUST ignore all other attributes that follow MESSAGE-INTEGRITY, agents MUST ignore all other attributes that
MESSAGE-INTEGRITY. follow MESSAGE-INTEGRITY.
The key for the HMAC depends on which credential mechanism is in use. The key for the HMAC depends on which credential mechanism is in use.
Section 9.1.1 defines the key for the short-term credential mechanism Section 9.1.1 defines the key for the short-term credential mechanism
and Section 9.2.1 defines the key for the long-term credential and Section 9.2.1 defines the key for the long-term credential
mechanism. Other credential mechanisms MUST define the key that is mechanism. Other credential mechanisms MUST define the key that is
used for the HMAC. used for the HMAC.
Based on the rules above, the hash used to construct MESSAGE- Based on the rules above, the hash used to construct MESSAGE-
INTEGRITY includes the length field from the STUN message header. INTEGRITY includes the length field from the STUN message header.
Prior to performing the hash, the MESSAGE-INTEGRITY attribute MUST be Prior to performing the hash, the MESSAGE-INTEGRITY attribute MUST be
skipping to change at page 37, line 43 skipping to change at page 36, line 7
the MESSAGE-INTEGRITY attribute itself, but excluding any attributes the MESSAGE-INTEGRITY attribute itself, but excluding any attributes
after it. Once the computation is performed, the value of the after it. Once the computation is performed, the value of the
MESSAGE-INTEGRITY attribute can be filled in, and the value of the MESSAGE-INTEGRITY attribute can be filled in, and the value of the
length in the STUN header can be set to its correct value -- the length in the STUN header can be set to its correct value -- the
length of the entire message. Similarly, when validating the length of the entire message. Similarly, when validating the
MESSAGE-INTEGRITY, the length field should be adjusted to point to MESSAGE-INTEGRITY, the length field should be adjusted to point to
the end of the MESSAGE-INTEGRITY attribute prior to calculating the the end of the MESSAGE-INTEGRITY attribute prior to calculating the
HMAC. Such adjustment is necessary when attributes, such as HMAC. Such adjustment is necessary when attributes, such as
FINGERPRINT, appear after MESSAGE-INTEGRITY. FINGERPRINT, appear after MESSAGE-INTEGRITY.
14.5. MESSAGE-INTEGRITY2 14.5. MESSAGE-INTEGRITY-SHA256
The MESSAGE-INTEGRITY2 attribute contains an HMAC-SHA-256 [RFC2104] The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA-256
of the STUN message. The MESSAGE-INTEGRITY2 attribute can be present [RFC2104] of the STUN message. The MESSAGE-INTEGRITY-SHA256
in any STUN message type. Since it uses the SHA-256 hash, the HMAC attribute can be present in any STUN message type. Since it uses the
will be 32 bytes. The text used as input to HMAC is the STUN SHA-256 hash, the HMAC will be 32 bytes. The text used as input to
message, including the header, up to and including the attribute HMAC is the STUN message, including the header, up to and including
preceding the MESSAGE-INTEGRITY2 attribute. With the exception of the attribute preceding the MESSAGE-INTEGRITY-SHA256 attribute. With
the FINGERPRINT attribute, which appears after MESSAGE-INTEGRITY2, the exception of the FINGERPRINT attribute, which appears after
agents MUST ignore all other attributes that follow MESSAGE- MESSAGE-INTEGRITY-SHA256, agents MUST ignore all other attributes
INTEGRITY2. that follow MESSAGE-INTEGRITY-SHA256.
The key for the HMAC depends on which credential mechanism is in use. The key for the HMAC depends on which credential mechanism is in use.
Section 9.1.1 defines the key for the short-term credential mechanism Section 9.1.1 defines the key for the short-term credential mechanism
and Section 9.2.1 defines the key for the long-term credential and Section 9.2.1 defines the key for the long-term credential
mechanism. Other credential mechanism MUST define the key that is mechanism. Other credential mechanism MUST define the key that is
used for the HMAC. used for the HMAC.
Based on the rules above, the hash used to construct MESSAGE- Based on the rules above, the hash used to construct MESSAGE-
INTEGRITY2 includes the length field from the STUN message header. INTEGRITY-SHA256 includes the length field from the STUN message
Prior to performing the hash, the MESSAGE-INTEGRITY2 attribute MUST header. Prior to performing the hash, the MESSAGE-INTEGRITY-SHA256
be inserted into the message (with dummy content). The length MUST attribute MUST be inserted into the message (with dummy content).
then be set to point to the length of the message up to, and The length MUST then be set to point to the length of the message up
including, the MESSAGE-INTEGRITY2 attribute itself, but excluding any to, and including, the MESSAGE-INTEGRITY-SHA256 attribute itself, but
attributes after it. Once the computation is performed, the value of excluding any attributes after it. Once the computation is
the MESSAGE-INTEGRITY2 attribute can be filled in, and the value of performed, the value of the MESSAGE-INTEGRITY-SHA256 attribute can be
the length in the STUN header can be set to its correct value -- the filled in, and the value of the length in the STUN header can be set
length of the entire message. Similarly, when validating the to its correct value -- the length of the entire message. Similarly,
MESSAGE-INTEGRITY2, the length field should be adjusted to point to when validating the MESSAGE-INTEGRITY-SHA256, the length field should
the end of the MESSAGE-INTEGRITY2 attribute prior to calculating the be adjusted to point to the end of the MESSAGE-INTEGRITY-SHA256
HMAC. Such adjustment is necessary when attributes, such as attribute prior to calculating the HMAC. Such adjustment is
FINGERPRINT, appear after MESSAGE-INTEGRITY2. necessary when attributes, such as FINGERPRINT, appear after MESSAGE-
INTEGRITY-SHA256.
14.6. FINGERPRINT 14.6. FINGERPRINT
The FINGERPRINT attribute MAY be present in all STUN messages. The The FINGERPRINT attribute MAY be present in all STUN messages. The
value of the attribute is computed as the CRC-32 of the STUN message value of the attribute is computed as the CRC-32 of the STUN message
up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with
the 32-bit value 0x5354554e (the XOR helps in cases where an the 32-bit value 0x5354554e (the XOR helps in cases where an
application packet is also using CRC-32 in it). The 32-bit CRC is application packet is also using CRC-32 in it). The 32-bit CRC is
the one defined in ITU V.42 [ITU.V42.2002], which has a generator the one defined in ITU V.42 [ITU.V42.2002], which has a generator
polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1.
skipping to change at page 44, line 20 skipping to change at page 42, line 27
overall. As described in Section 13, STUN usages describe when overall. As described in Section 13, STUN usages describe when
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-INTEGRITY2, which is STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256,
subject to bid down attacks by an on-path attacker. Protection of which is subject to bid down attacks by an on-path attacker.
the channel itself, using TLS or DTLS, mitigates these attacks. Protection of the channel itself, using TLS or DTLS, mitigates these
Timely removal of the support of MESSAGE-INTEGRITY in a future attacks. Timely removal of the support of MESSAGE-INTEGRITY in a
version of STUN is necessary. future version of STUN is necessary.
15.1.2. Inside Attacks 15.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. attacks hard to launch.
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
skipping to change at page 48, line 33 skipping to change at page 46, line 33
0x8022: SOFTWARE 0x8022: SOFTWARE
0x8023: ALTERNATE-SERVER 0x8023: ALTERNATE-SERVER
0x8028: FINGERPRINT 0x8028: FINGERPRINT
17.2.2. New Attributes 17.2.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-INTEGRITY2 0xXXXX: MESSAGE-INTEGRITY-SHA256
0xXXXX: PASSWORD-ALGORITHM 0xXXXX: PASSWORD-ALGORITHM
Comprehension-optional range (0x8000-0xFFFF) Comprehension-optional range (0x8000-0xFFFF)
0xXXXX: PASSSORD-ALGORITHMS 0xXXXX: PASSSORD-ALGORITHMS
0xXXXX: ALTERNATE-DOMAIN 0xXXXX: ALTERNATE-DOMAIN
17.3. STUN Error Code Registry 17.3. STUN Error Code Registry
IANA is requested to update the reference from RFC 5389 to RFC-to-be IANA is requested to update the reference from RFC 5389 to RFC-to-be
for the Error Codes given in Section 14.7. for the Error Codes given in Section 14.7.
skipping to change at page 49, line 17 skipping to change at page 47, line 17
0x0001: Salted SHA256 0x0001: Salted SHA256
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
The default algorithm is "SHA256".
17.4.1.1. SHA256 17.4.1.1. SHA256
This password algorithms is taken from [I-D.ietf-httpauth-digest]. This password algorithms 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.4.1.2. Salted SHA256
This password algorithms is taken from [I-D.veltri-sip-alt-auth].
The key length is 32 bytes and the parameters contains the salt.
key = SHA256(username ":" realm ":" OpaqueString(password) ":" salt)
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:
stun 3478/tcp Session Traversal Utilities for NAT (STUN) port stun 3478/tcp Session Traversal Utilities for NAT (STUN) port
stun 3478/udp Session Traversal Utilities for NAT (STUN) port stun 3478/udp Session Traversal Utilities for NAT (STUN) port
stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port
18. Changes since RFC 5389 18. Changes since RFC 5389
This specification obsoletes RFC 5389 [RFC5389]. This specification This specification obsoletes RFC 5389 [RFC5389]. This specification
differs from RFC 5389 in the following ways: differs from RFC 5389 in the following ways:
o o
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-avtcore-rfc5764-mux-fixes]
Petit-Huguenin, M. and G. Salgueiro, "Multiplexing Scheme
Updates for Secure Real-time Transport Protocol (SRTP)
Extension for Datagram Transport Layer Security (DTLS)",
draft-ietf-avtcore-rfc5764-mux-fixes-02 (work in
progress), March 2015.
[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-14 (work in progress), March 2015.
[I-D.ietf-tsvwg-sctp-dtls-encaps]
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
dtls-encaps-09 (work in progress), January 2015.
[I-D.ietf-tsvwg-sctp-prpolicies]
Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
"Additional Policies for the Partial Reliability Extension
of the Stream Control Transmission Protocol", draft-ietf-
tsvwg-sctp-prpolicies-07 (work in progress), February
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, September
1981. 1981.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
skipping to change at page 51, line 25 skipping to change at page 48, line 43
[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. February 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[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, November 2003.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, May 2004.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[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, August 2008.
[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, June
2011. 2011.
[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, January 2012.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012.
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
Control Transmission Protocol (SCTP) Packets for End-Host
to End-Host Communication", RFC 6951, May 2013.
[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, November 2013.
[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, August 2014.
19.2. Informational References 19.2. Informational References
skipping to change at page 52, line 27 skipping to change at page 49, line 27
Access Authentication", draft-ietf-httpauth-digest-15 Access Authentication", draft-ietf-httpauth-digest-15
(work in progress), March 2015. (work in progress), March 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 for Offer/Answer Protocols",
draft-ietf-mmusic-rfc5245bis-04 (work in progress), March draft-ietf-mmusic-rfc5245bis-04 (work in progress), March
2015. 2015.
[I-D.ietf-tram-stun-origin]
Johnston, A., Uberti, J., Yoakum, J., and K. Singh, "An
Origin Attribute for the STUN Protocol", draft-ietf-tram-
stun-origin-05 (work in progress), February 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.
[I-D.veltri-sip-alt-auth]
Veltri, L., Salsano, S., and A. Polidoro, "HTTP digest
authentication using alternate password storage schemes",
draft-veltri-sip-alt-auth-00 (work in progress), April
2008.
[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, June 1999.
[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.
skipping to change at page 54, line 39 skipping to change at page 51, line 24
int cls(int type) { int cls(int type) {
return (type & 0x0100) >> 7 | (type & 0x0010) >> 4; return (type & 0x0100) >> 7 | (type & 0x0010) >> 4;
} }
Appendix B. Release notes Appendix B. Release notes
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. Integrate RFC 5769 (stun vectors) as examples 1. Add reference RFC 5769 (stun vectors).
B.2. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- 2. Add flow diagram for long-term authenticattion.
3. Add vector for SHA256 password hash.
B.2. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf-
tram-stunbis-03
o Remove SCTP.
o Remove DANE.
o s/MESSAGE-INTEGRITY2/MESSAGE-INTEGRITY-SHA256/
o Remove Salted SHA256 password hash.
o The RTO delay between transactions is removed.
o Make clear that reusing NONCE will trigger a wasted round trip.
B.3. 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.3. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- B.4. 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 Clarify terminology, text and guidance for STUN fragmentation.
o Clarify whether it's valid to share nonces across TURN
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
different IP address and/or different port. This prevent sharing different IP address and/or different port. This prevent sharing
the nonce between TURN allocations in TURN. the nonce between TURN allocations in TURN.
o Add reference to draft-ietf-uta-tls-bcp o Add reference to draft-ietf-uta-tls-bcp
o Add a new attribute ALTERNATE-DOMAIN to verify the certificate of o Add a new attribute ALTERNATE-DOMAIN to verify the certificate of
the ALTERNATE-SERVER after a 300 over (D)TLS. the ALTERNATE-SERVER after a 300 over (D)TLS.
o The RTP delay between transactions applies only to parallel o The RTP delay between transactions applies only to parallel
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.4. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- B.5. 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 56, line 14 skipping to change at page 53, line 25
* 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.5. Modifications between draft-salgueiro-tram-stunbis-02 and draft- B.6. 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.6. Modifications between draft-salgueiro-tram-stunbis-02 and draft- B.7. Modifications between draft-salgueiro-tram-stunbis-02 and draft-
salgueiro-tram-stunbis-01 salgueiro-tram-stunbis-01
o Add definition of MESSAGE-INTEGRITY2. o Add definition of MESSAGE-INTEGRITY2.
o Update text and reference from RFC 2988 to RFC 6298. o Update text and reference from RFC 2988 to RFC 6298.
o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o s/The IAB has mandated/The IAB has suggested/ (Errata #3737).
o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972).
skipping to change at page 57, line 5 skipping to change at page 54, line 11
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.7. Modifications between draft-salgueiro-tram-stunbis-01 and draft- B.8. 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, and Alan Johnston
 End of changes. 61 change blocks. 
450 lines changed or deleted 330 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/