RFC 8489
Session Traversal Utilities for NAT (STUN)
15. Operational Considerations
STUN MAY be used with anycast addresses, but only with UDP and in STUN Usages where authentication is not used.16. Security Considerations
Implementations and deployments of a STUN Usage using TLS or DTLS MUST follow the recommendations in [BCP195]. Implementations and deployments of a STUN Usage using the long-term credential mechanism (Section 9.2) MUST follow the recommendations in Section 5 of [RFC7616].16.1. Attacks against the Protocol
16.1.1. Outside Attacks
An attacker can try to modify STUN messages in transit, in order to cause a failure in STUN operation. These attacks are detected for both requests and responses through the message-integrity mechanism, using either a short-term or long-term credential. Of course, once detected, the manipulated packets will be dropped, causing the STUN transaction to effectively fail. This attack is possible only by an on-path attacker. An attacker that can observe, but not modify, STUN messages in- transit (for example, an attacker present on a shared access medium, such as Wi-Fi) can see a STUN request and then immediately send a STUN response, typically an error response, in order to disrupt STUN processing. This attack is also prevented for messages that utilize MESSAGE-INTEGRITY. However, some error responses, those related to authentication in particular, cannot be protected by MESSAGE- INTEGRITY. When STUN itself is run over a secure transport protocol (e.g., TLS), these attacks are completely mitigated. Depending on the STUN Usage, these attacks may be of minimal consequence and thus do not require message integrity to mitigate. For example, when STUN is used to a basic STUN server to discover a server reflexive candidate for usage with ICE, authentication and message integrity are not required since these attacks are detected during the connectivity check phase. The connectivity checks themselves, however, require protection for proper operation of ICE overall. As described in Section 13, STUN Usages describe when authentication and message integrity are needed.
Since STUN uses the HMAC of a shared secret for authentication and integrity protection, it is subject to offline dictionary attacks. When authentication is utilized, it SHOULD be with a strong password that is not readily subject to offline dictionary attacks. Protection of the channel itself, using TLS or DTLS, mitigates these attacks. STUN supports both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256, which makes STUN subject to bid-down attacks by an on-path attacker. An attacker could strip the MESSAGE-INTEGRITY-SHA256 attribute, leaving only the MESSAGE-INTEGRITY attribute and thus exploiting a potential vulnerability. Protection of the channel itself, using TLS or DTLS, mitigates these attacks. Timely removal of the support of MESSAGE-INTEGRITY in a future version of STUN is necessary. Note: The use of SHA-256 for password hashing does not meet modern standards, which are aimed at slowing down exhaustive password searches by providing a relatively slow minimum time to compute the hash. Although better algorithms such as Argon2 [Argon2] are available, SHA-256 was chosen for consistency with [RFC7616].16.1.2. Inside Attacks
A rogue client may try to launch a DoS attack against a server by sending it a large number of STUN requests. Fortunately, STUN requests can be processed statelessly by a server, making such attacks hard to launch effectively. 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 case, the response would be delivered to that source IP and port. There is no amplification of the number of packets with this attack (the STUN server sends one packet for each packet sent by the client), though there is a small increase in the amount of data, since STUN responses are typically larger than requests. This attack is mitigated by ingress source address filtering. Revealing the specific software version of the agent through the SOFTWARE attribute might allow them to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make usage of the SOFTWARE attribute a configurable option.16.1.3. Bid-Down Attacks
This document adds the possibility of selecting different algorithms to protect the confidentiality of the passwords stored on the server side when using the long-term credential mechanism while still
ensuring compatibility with MD5, which was the algorithm used in [RFC5389]. This selection works by having the server send to the client the list of algorithms supported in a PASSWORD-ALGORITHMS attribute and having the client send back a PASSWORD-ALGORITHM attribute containing the algorithm selected. Because the PASSWORD-ALGORITHMS attribute has to be sent in an unauthenticated response, an on-path attacker wanting to exploit an eventual vulnerability in MD5 can just strip the PASSWORD-ALGORITHMS attribute from the unprotected response, thus making the server subsequently act as if the client was implementing the version of this protocol defined in [RFC5389]. To protect against this attack and other similar bid-down attacks, the nonce is enriched with a set of security bits that indicates which security features are in use. In the case of the selection of the password algorithm, the matching bit is set in the nonce returned by the server in the same response that contains the PASSWORD- ALGORITHMS attribute. Because the nonce used in subsequent authenticated transactions is verified by the server to be identical to what was originally sent, it cannot be modified by an on-path attacker. Additionally, the client is mandated to copy the received PASSWORD-ALGORITHMS attribute in the next authenticated transaction to that server. An on-path attack that removes the PASSWORD-ALGORITHMS will be detected because the client will not be able to send it back to the server in the next authenticated transaction. The client will detect that attack because the security bit is set but the matching attribute is missing; this will end the session. A client using an older version of this protocol will not send the PASSWORD-ALGORITHMS back but can only use MD5 anyway, so the attack is inconsequential. The on-path attack may also try to remove the security bit together with the PASSWORD-ALGORITHMS attribute, but the server will discover that when the next authenticated transaction contains an invalid nonce. An on-path attack that removes some algorithms from the PASSWORD- ALGORITHMS attribute will be equally defeated because that attribute will be different from the original one when the server verifies it in the subsequent authenticated transaction. Note that the bid-down protection mechanism introduced in this document is inherently limited by the fact that it is not possible to detect an attack until the server receives the second request after the 401 (Unauthenticated) response.
SHA-256 was chosen as the new default for password hashing for its compatibility with [RFC7616], but because SHA-256 (like MD5) is a comparatively fast algorithm, it does little to deter brute-force attacks. Specifically, this means that if the user has a weak password, an attacker that captures a single exchange can use a brute-force attack to learn the user's password and then potentially impersonate the user to the server and to other servers where the same password was used. Note that such an attacker can impersonate the user to the server itself without any brute-force attack. A stronger (which is to say, slower) algorithm, like Argon2 [Argon2], would help both of these cases; however, in the first case, it would only help after the database entry for this user is updated to exclusively use that stronger mechanism. The bid-down defenses in this protocol prevent an attacker from forcing the client and server to complete a handshake using weaker algorithms than they jointly support, but only if the weakest joint algorithm is strong enough that it cannot be compromised by a brute- force attack. However, this does not defend against many attacks on those algorithms; specifically, an on-path attacker might perform a bid-down attack on a client that supports both Argon2 [Argon2] and SHA-256 for password hashing and use that to collect a MESSAGE- INTEGRITY-SHA256 value that it can then use for an offline brute- force attack. This would be detected when the server receives the second request, but that does not prevent the attacker from obtaining the MESSAGE-INTEGRITY-SHA256 value. Similarly, an attack against the USERHASH mechanism will not succeed in establishing a session as the server will detect that the feature was discarded on path, but the client would still have been convinced to send its username in the clear in the USERNAME attribute, thus disclosing it to the attacker. Finally, when the bid-down protection mechanism is employed for a future upgrade of the HMAC algorithm used to protect messages, it will offer only a limited protection if the current HMAC algorithm is already compromised.16.2. Attacks Affecting the Usage
This section lists attacks that might be launched against a usage of STUN. Each STUN Usage must consider whether these attacks are applicable to it and, if so, discuss countermeasures. Most of the attacks in this section revolve around an attacker modifying the reflexive address learned by a STUN client through a Binding request/response transaction. Since the usage of the
reflexive address is a function of the usage, the applicability and remediation of these attacks are usage-specific. In common situations, modification of the reflexive address by an on-path attacker is easy to do. Consider, for example, the common situation where STUN is run directly over UDP. In this case, an on-path attacker can modify the source IP address of the Binding request before it arrives at the STUN server. The STUN server will then return this IP address in the XOR-MAPPED-ADDRESS attribute to the client and send the response back to that (falsified) IP address and port. If the attacker can also intercept this response, it can direct it back towards the client. Protecting against this attack by using a message-integrity check is impossible, since a message- integrity value cannot cover the source IP address and the intervening NAT must be able to modify this value. Instead, one solution to prevent the attacks listed below is for the client to verify the reflexive address learned, as is done in ICE [RFC8445]. Other usages may use other means to prevent these attacks.16.2.1. Attack I: Distributed DoS (DDoS) against a Target
In this attack, the attacker provides one or more clients with the same faked reflexive address that points to the intended target. This will trick the STUN clients into thinking that their reflexive addresses are equal to that of the target. If the clients hand out that reflexive address in order to receive traffic on it (for example, in SIP messages), the traffic will instead be sent to the target. This attack can provide substantial amplification, especially when used with clients that are using STUN to enable multimedia applications. However, it can only be launched against targets for which packets from the STUN server to the target pass through the attacker, limiting the cases in which it is possible.16.2.2. Attack II: Silencing a Client
In this attack, the attacker provides a STUN client with a faked reflexive address. The reflexive address it provides is a transport address that routes to nowhere. As a result, the client won't receive any of the packets it expects to receive when it hands out the reflexive address. This exploitation is not very interesting for the attacker. It impacts a single client, which is frequently not the desired target. Moreover, any attacker that can mount the attack could also deny service to the client by other means, such as preventing the client from receiving any response from the STUN server, or even a DHCP server. As with the attack described in Section 16.2.1, this attack is only possible when the attacker is on path for packets sent from the STUN server towards this unused IP address.
16.2.3. Attack III: Assuming the Identity of a Client
This attack is similar to attack II. However, the faked reflexive address points to the attacker itself. This allows the attacker to receive traffic that was destined for the client.16.2.4. Attack IV: Eavesdropping
In this attack, the attacker forces the client to use a reflexive address that routes to itself. It then forwards any packets it receives to the client. This attack allows the attacker to observe all packets sent to the client. However, in order to launch the attack, the attacker must have already been able to observe packets from the client to the STUN server. In most cases (such as when the attack is launched from an access network), this means that the attacker could already observe packets sent to the client. This attack is, as a result, only useful for observing traffic by attackers on the path from the client to the STUN server, but not generally on the path of packets being routed towards the client. Note that this attack can be trivially launched by the STUN server itself, so users of STUN servers should have the same level of trust in the users of STUN servers as any other node that can insert itself into the communication flow.16.3. Hash Agility Plan
This specification uses HMAC-SHA256 for computation of the message integrity, sometimes in combination with HMAC-SHA1. If, at a later time, HMAC-SHA256 is found to be compromised, the following remedy should be applied: o Both a new message-integrity attribute and a new STUN Security Feature bit will be allocated in a Standards Track document. The new message-integrity attribute will have its value computed using a new hash. The STUN Security Feature bit will be used to simultaneously 1) signal to a STUN client using the long-term credential mechanism that this server supports this new hash algorithm and 2) prevent bid-down attacks on the new message- integrity attribute. o STUN clients and servers using the short-term credential mechanism will need to update the external mechanism that they use to signal what message-integrity attributes are in use. The bid-down protection mechanism described in this document is new and thus cannot currently protect against a bid-down attack that lowers the strength of the hash algorithm to HMAC-SHA1. This is why,
after a transition period, a new document updating this one will assign a new STUN Security Feature bit for deprecating HMAC-SHA1. When used, this bit will signal that HMAC-SHA1 is deprecated and should no longer be used. Similarly, if HMAC-SHA256 is found to be compromised, a new userhash attribute and a new STUN Security Feature bit will be allocated in a Standards Track document. The new userhash attribute will have its value computed using a new hash. The STUN Security Feature bit will be used to simultaneously 1) signal to a STUN client using the long- term credential mechanism that this server supports this new hash algorithm for the userhash attribute and 2) prevent bid-down attacks on the new userhash attribute.17. IAB Considerations
The IAB has studied the problem of Unilateral Self-Address Fixing (UNSAF), which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism [RFC3424]. STUN can be used to perform this function using a Binding request/ response transaction if one agent is behind a NAT and the other is on the public side of the NAT. The IAB has suggested that protocols developed for this purpose document a specific set of considerations. Because some STUN Usages provide UNSAF functions (such as ICE [RFC8445]) and others do not (such as SIP Outbound [RFC5626]), answers to these considerations need to be addressed by the usages themselves.18. IANA Considerations
18.1. STUN Security Features Registry
A STUN Security Feature set defines 24 bits as flags. IANA has created a new registry containing the STUN Security Features that are protected by the bid-down attack prevention mechanism described in Section 9.2.1. The initial STUN Security Features are: Bit 0: Password algorithms Bit 1: Username anonymity Bit 2-23: Unassigned
Bits are assigned starting from the most significant side of the bit set, so Bit 0 is the leftmost bit and Bit 23 is the rightmost bit. New Security Features are assigned by Standards Action [RFC8126].18.2. STUN Methods Registry
A STUN method is a hex number in the range 0x000-0x0FF. The encoding of a STUN method into a STUN message is described in Section 5. STUN methods in the range 0x000-0x07F are assigned by IETF Review [RFC8126]. STUN methods in the range 0x080-0x0FF are assigned by Expert Review [RFC8126]. The responsibility of the expert is to verify that the selected codepoint(s) is not in use and that the request is not for an abnormally large number of codepoints. Technical review of the extension itself is outside the scope of the designated expert responsibility. IANA has updated the name for method 0x002 as described below as well as updated the reference from RFC 5389 to RFC 8489 for the following STUN methods: 0x000: Reserved 0x001: Binding 0x002: Reserved; was SharedSecret prior to [RFC5389]18.3. STUN Attributes Registry
A STUN attribute type is a hex number in the range 0x0000-0xFFFF. STUN attribute types in the range 0x0000-0x7FFF are considered comprehension-required; STUN attribute types in the range 0x8000-0xFFFF are considered comprehension-optional. A STUN agent handles unknown comprehension-required and comprehension-optional attributes differently. STUN attribute types in the first half of the comprehension-required range (0x0000-0x3FFF) and in the first half of the comprehension- optional range (0x8000-0xBFFF) are assigned by IETF Review [RFC8126]. STUN attribute types in the second half of the comprehension-required range (0x4000-0x7FFF) and in the second half of the comprehension- optional range (0xC000-0xFFFF) are assigned by Expert Review [RFC8126]. The responsibility of the expert is to verify that the selected codepoint(s) are not in use and that the request is not for an abnormally large number of codepoints. Technical review of the extension itself is outside the scope of the designated expert responsibility.
18.3.1. Updated Attributes
IANA has updated the names for attributes 0x0002, 0x0004, 0x0005, 0x0007, and 0x000B as well as updated the reference from RFC 5389 to RFC 8489 for each the following STUN methods. In addition, [RFC5389] introduced a mistake in the name of attribute 0x0003; [RFC5389] called it CHANGE-ADDRESS when it was actually previously called CHANGE-REQUEST. Thus, IANA has updated the description for 0x0003 to read "Reserved; was CHANGE-REQUEST prior to [RFC5389]". Comprehension-required range (0x0000-0x7FFF): 0x0000: Reserved 0x0001: MAPPED-ADDRESS 0x0002: Reserved; was RESPONSE-ADDRESS prior to [RFC5389] 0x0003: Reserved; was CHANGE-REQUEST prior to [RFC5389] 0x0004: Reserved; was SOURCE-ADDRESS prior to [RFC5389] 0x0005: Reserved; was CHANGED-ADDRESS prior to [RFC5389] 0x0006: USERNAME 0x0007: Reserved; was PASSWORD prior to [RFC5389] 0x0008: MESSAGE-INTEGRITY 0x0009: ERROR-CODE 0x000A: UNKNOWN-ATTRIBUTES 0x000B: Reserved; was REFLECTED-FROM prior to [RFC5389] 0x0014: REALM 0x0015: NONCE 0x0020: XOR-MAPPED-ADDRESS Comprehension-optional range (0x8000-0xFFFF) 0x8022: SOFTWARE 0x8023: ALTERNATE-SERVER 0x8028: FINGERPRINT18.3.2. New Attributes
IANA has added the following attribute to the "STUN Attributes" registry: Comprehension-required range (0x0000-0x7FFF): 0x001C: MESSAGE-INTEGRITY-SHA256 0x001D: PASSWORD-ALGORITHM 0x001E: USERHASH Comprehension-optional range (0x8000-0xFFFF) 0x8002: PASSWORD-ALGORITHMS 0x8003: ALTERNATE-DOMAIN
18.4. STUN Error Codes Registry
A STUN error code is a number in the range 0-699. STUN error codes are accompanied by a textual reason phrase in UTF-8 [RFC3629] that is intended only for human consumption and can be anything appropriate; this document proposes only suggested values. STUN error codes are consistent in codepoint assignments and semantics with SIP [RFC3261] and HTTP [RFC7231]. New STUN error codes are assigned based on IETF Review [RFC8126]. The specification must carefully consider how clients that do not understand this error code will process it before granting the request. See the rules in Section 6.3.4. IANA has updated the reference from RFC 5389 to RFC 8489 for the error codes defined in Section 14.8. IANA has changed the name of the 401 error code from "Unauthorized" to "Unauthenticated".18.5. STUN Password Algorithms Registry
IANA has created a new registry titled "STUN Password Algorithms". A password algorithm is a hex number in the range 0x0000-0xFFFF. The initial contents of the "Password Algorithm" registry are as follows: 0x0000: Reserved 0x0001: MD5 0x0002: SHA-256 0x0003-0xFFFF: Unassigned Password algorithms in the first half of the range (0x0000-0x7FFF) are assigned by IETF Review [RFC8126]. Password algorithms in the second half of the range (0x8000-0xFFFF) are assigned by Expert Review [RFC8126].
18.5.1. Password Algorithms
18.5.1.1. MD5
This password algorithm is taken from [RFC1321]. The key length is 16 bytes, and the parameters value is empty. Note: This algorithm MUST only be used for compatibility with legacy systems. key = MD5(username ":" OpaqueString(realm) ":" OpaqueString(password))18.5.1.2. SHA-256
This password algorithm is taken from [RFC7616]. The key length is 32 bytes, and the parameters value is empty. key = SHA-256(username ":" OpaqueString(realm) ":" OpaqueString(password))18.6. STUN UDP and TCP Port Numbers
IANA has updated the reference from RFC 5389 to RFC 8489 for the following ports in the "Service Name and Transport Protocol Port Number Registry". stun 3478/tcp 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) port19. Changes since RFC 5389
This specification obsoletes [RFC5389]. This specification differs from RFC 5389 in the following ways: o Added support for DTLS-over-UDP [RFC6347]. o Made clear that the RTO is considered stale if there are no transactions with the server. o Aligned the RTO calculation with [RFC6298]. o Updated the ciphersuites for TLS. o Added support for STUN URI [RFC7064].
o Added support for SHA256 message integrity.
o Updated the Preparation, Enforcement, and Comparison of
Internationalized Strings (PRECIS) support to [RFC8265].
o Added protocol and registry to choose the password encryption
algorithm.
o Added support for anonymous username.
o Added protocol and registry for preventing bid-down attacks.
o Specified that sharing a NONCE is no longer permitted.
o Added the possibility of using a domain name in the alternate
server mechanism.
o Added more C snippets.
o Added test vector.
20. References
20.1. Normative References
[ITU.V42.2002]
International Telecommunication Union, "Error-correcting
procedures for DCEs using asynchronous-to-synchronous
conversion", ITU-T Recommendation V.42, March 2002.
[KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", SIGCOMM '87,
Proceedings of the ACM workshop on Frontiers in computer
communications technology, Pages 2-7,
DOI 10.1145/55483.55484, August 1987.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>. [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <https://www.rfc-editor.org/info/rfc1321>. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>. [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/info/rfc6151>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>. [RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- Huguenin, "URI Scheme for the Session Traversal Utilities for NAT (STUN) Protocol", RFC 7064, DOI 10.17487/RFC7064, November 2013, <https://www.rfc-editor.org/info/rfc7064>. [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, August 2014, <https://www.rfc-editor.org/info/rfc7350>. [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>. [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 8265, DOI 10.17487/RFC8265, October 2017, <https://www.rfc-editor.org/info/rfc8265>. [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, <https://www.rfc-editor.org/info/rfc8305>.
20.2. Informative References
[Argon2] Biryukov, A., Dinu, D., Khovratovich, D., and S. Josefsson, "The memory-hard Argon2 password hash and proof-of-work function", Work in Progress, draft-irtf- cfrg-argon2-09, November 2019. [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, May 2015, <https://www.rfc-editor.org/info/bcp195>. [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, <https://www.rfc-editor.org/info/rfc1952>. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, DOI 10.17487/RFC2279, January 1998, <https://www.rfc-editor.org/info/rfc2279>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>. [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, DOI 10.17487/RFC3424, November 2002, <https://www.rfc-editor.org/info/rfc3424>. [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, DOI 10.17487/RFC3454, December 2002, <https://www.rfc-editor.org/info/rfc3454>. [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, DOI 10.17487/RFC3489, March 2003, <https://www.rfc-editor.org/info/rfc3489>. [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, DOI 10.17487/RFC4013, February 2005, <https://www.rfc-editor.org/info/rfc4013>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, <https://www.rfc-editor.org/info/rfc4107>. [RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., and W. Beck, "RADIUS Extension for Digest Authentication", RFC 5090, DOI 10.17487/RFC5090, February 2008, <https://www.rfc-editor.org/info/rfc5090>. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>. [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, DOI 10.17487/RFC5626, October 2009, <https://www.rfc-editor.org/info/rfc5626>. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <https://www.rfc-editor.org/info/rfc5766>. [RFC5769] Denis-Courmont, R., "Test Vectors for Session Traversal Utilities for NAT (STUN)", RFC 5769, DOI 10.17487/RFC5769, April 2010, <https://www.rfc-editor.org/info/rfc5769>. [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, DOI 10.17487/RFC5780, May 2010, <https://www.rfc-editor.org/info/rfc5780>. [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, March 2012, <https://www.rfc-editor.org/info/rfc6544>. [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 8264, DOI 10.17487/RFC8264, October 2017, <https://www.rfc-editor.org/info/rfc8264>. [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. [STUN-PMTUD] Petit-Huguenin, M., Salgueiro, G., and F. Garrido, "Packetization Layer Path MTU Discovery (PLMTUD) For UDP Transports Using Session Traversal Utilities for NAT (STUN)", Work in Progress, draft-ietf-tram-stun-pmtud-15, December 2019. [UAX15] Unicode Standard Annex #15, "Unicode Normalization Forms", edited by Mark Davis and Ken Whistler. An integral part of The Unicode Standard, <http://unicode.org/reports/tr15/>.
Appendix A. C Snippet to Determine STUN Message Types
Given a 16-bit STUN message type value in host byte order in msg_type parameter, below are C macros to determine the STUN message types: <CODE BEGINS> #define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000) #define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010) #define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100) #define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110) <CODE ENDS> A function to convert method and class into a message type: <CODE BEGINS> int type(int method, int cls) { return (method & 0x1F80) << 2 | (method & 0x0070) << 1 | (method & 0x000F) | (cls & 0x0002) << 7 | (cls & 0x0001) << 4; } <CODE ENDS> A function to extract the method from the message type: <CODE BEGINS> int method(int type) { return (type & 0x3E00) >> 2 | (type & 0x00E0) >> 1 | (type & 0x000F); } <CODE ENDS> A function to extract the class from the message type: <CODE BEGINS> int cls(int type) { return (type & 0x0100) >> 7 | (type & 0x0010) >> 4; } <CODE ENDS>
Appendix B. Test Vectors
This section augments the list of test vectors defined in [RFC5769] with MESSAGE-INTEGRITY-SHA256. All the formats and definitions listed in Section 2 of [RFC5769] apply here.B.1. Sample Request with Long-Term Authentication with MESSAGE- INTEGRITY-SHA256 and USERHASH
This request uses the following parameters: Username: "<U+30DE><U+30C8><U+30EA><U+30C3><U+30AF><U+30B9>" (without quotes) unaffected by OpaqueString [RFC8265] processing Password: "The<U+00AD>M<U+00AA>tr<U+2168>" and "TheMatrIX" (without quotes) respectively before and after OpaqueString [RFC8265] processing Nonce: "obMatJos2AAACf//499k954d6OL34oL9FSTvy64sA" (without quotes) Realm: "example.org" (without quotes) 00 01 00 9c Request type and message length 21 12 a4 42 Magic cookie 78 ad 34 33 } c6 ad 72 c0 } Transaction ID 29 da 41 2e } 00 1e 00 20 USERHASH attribute header 4a 3c f3 8f } ef 69 92 bd } a9 52 c6 78 } 04 17 da 0f } Userhash value (32 bytes) 24 81 94 15 } 56 9e 60 b2 } 05 c4 6e 41 } 40 7f 17 04 } 00 15 00 29 NONCE attribute header 6f 62 4d 61 } 74 4a 6f 73 } 32 41 41 41 } 43 66 2f 2f } 34 39 39 6b } Nonce value and padding (3 bytes) 39 35 34 64 } 36 4f 4c 33 } 34 6f 4c 39 } 46 53 54 76 } 79 36 34 73 } 41 00 00 00 }
00 14 00 0b REALM attribute header
65 78 61 6d }
70 6c 65 2e } Realm value (11 bytes) and padding (1 byte)
6f 72 67 00 }
00 1c 00 20 MESSAGE-INTEGRITY-SHA256 attribute header
e4 68 6c 8f }
0e de b5 90 }
13 e0 70 90 }
01 0a 93 ef } HMAC-SHA256 value
cc bc cc 54 }
4c 0a 45 d9 }
f8 30 aa 6d }
6f 73 5a 01 }
Acknowledgements
Thanks to Michael Tuexen, Tirumaleswar Reddy, Oleg Moskalenko, Simon
Perreault, Benjamin Schwartz, Rifaat Shekh-Yusef, Alan Johnston,
Jonathan Lennox, Brandon Williams, Olle Johansson, Martin Thomson,
Mihaly Meszaros, Tolga Asveren, Noriyuki Torii, Spencer Dawkins, Dale
Worley, Matthew Miller, Peter Saint-Andre, Julien Elie, Mirja
Kuehlewind, Eric Rescorla, Ben Campbell, Adam Roach, Alexey Melnikov,
and Benjamin Kaduk for the comments, suggestions, and questions that
helped improve this document.
The Acknowledgements section of RFC 5389 appeared as follows:
The authors would like to thank Cedric Aoun, Pete Cordell, Cullen
Jennings, Bob Penfield, Xavier Marjou, Magnus Westerlund, Miguel
Garcia, Bruce Lowekamp, and Chris Sullivan for their comments, and
Baruch Sterman and Alan Hawrylyshen for initial implementations.
Thanks for Leslie Daigle, Allison Mankin, Eric Rescorla, and Henning
Schulzrinne for IESG and IAB input on this work.
Contributors
Christian Huitema and Joel Weinberger were original coauthors of
RFC 3489.
Authors' Addresses
Marc Petit-Huguenin Impedance Mismatch Email: marc@petit-huguenin.org Gonzalo Salgueiro Cisco 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America Email: gsalguei@cisco.com Jonathan Rosenberg Five9 Edison, NJ United States of America Email: jdrosen@jdrosen.net URI: http://www.jdrosen.net Dan Wing Citrix Systems, Inc. United States of America Email: dwing-ietf@fuggles.com Rohan Mahy Unaffiliated Email: rohan.ietf@gmail.com Philip Matthews Nokia 600 March Road Ottawa, Ontario K2K 2T6 Canada Phone: 613-784-3139 Email: philip_matthews@magma.ca