Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8489

Session Traversal Utilities for NAT (STUN)

Pages: 67
Proposed Standard
Errata
Obsoletes:  5389
Part 3 of 3 – Pages 47 to 67
First   Prev   None

Top   ToC   RFC8489 - Page 47   prevText

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.
Top   ToC   RFC8489 - Page 48
   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
Top   ToC   RFC8489 - Page 49
   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.
Top   ToC   RFC8489 - Page 50
   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
Top   ToC   RFC8489 - Page 51
   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.
Top   ToC   RFC8489 - Page 52

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,
Top   ToC   RFC8489 - Page 53
   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
Top   ToC   RFC8489 - Page 54
   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.
Top   ToC   RFC8489 - Page 55

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: FINGERPRINT

18.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
Top   ToC   RFC8489 - Page 56

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].
Top   ToC   RFC8489 - Page 57

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) port

19. 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].
Top   ToC   RFC8489 - Page 58
   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>.
Top   ToC   RFC8489 - Page 59
   [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>.
Top   ToC   RFC8489 - Page 60
   [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>.
Top   ToC   RFC8489 - Page 61

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>.
Top   ToC   RFC8489 - Page 62
   [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>.
Top   ToC   RFC8489 - Page 63
   [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/>.
Top   ToC   RFC8489 - Page 64

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>
Top   ToC   RFC8489 - Page 65

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 }
Top   ToC   RFC8489 - Page 66
        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.
Top   ToC   RFC8489 - Page 67

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