Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-13
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8489.
|
|
|---|---|---|---|
| Authors | Marc Petit-Huguenin , Gonzalo Salgueiro , Jonathan Rosenberg , Dan Wing , Rohan Mahy , Philip Matthews | ||
| Last updated | 2017-12-18 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
ARTART Telechat review
(of
-16)
by Peter Saint-Andre
Ready w/nits
GENART Telechat review
(of
-16)
by Dale Worley
Ready w/nits
GENART Last Call review
(of
-15)
by Dale Worley
Ready w/issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | In WG Last Call | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 8489 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-tram-stunbis-13
It is encoded in the same way as MAPPED-ADDRESS, and thus refers to a single server by IP address. The IP address family MUST be identical to that of the source IP address of the request. 14.16. ALTERNATE-DOMAIN The alternate domain represents the domain name that is used to verify the IP address in the ALTERNATE-SERVER attribute when the transport protocol uses TLS or DTLS. The value of ALTERNATE-DOMAIN is variable length. It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes). 15. Security Considerations 15.1. Attacks against the Protocol 15.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. Petit-Huguenin, et al. Expires June 21, 2018 [Page 46] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 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 is subject to bid down attacks by an on-path attacker. 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. 15.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. 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. 15.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 counter-measures. 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 Petit-Huguenin, et al. Expires June 21, 2018 [Page 47] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 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, since the intervening NAT must be able to modify this value. Instead, one solution to preventing the attacks listed below is for the client to verify the reflexive address learned, as is done in ICE [I-D.ietf-ice-rfc5245bis]. Other usages may use other means to prevent these attacks. 15.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. 15.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 in Section 15.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. Petit-Huguenin, et al. Expires June 21, 2018 [Page 48] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 15.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. 15.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 would allow 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. 15.3. Hash Agility Plan This specification uses both HMAC-SHA-1 and HMAC-SHA-256 for computation of the message integrity. If, at a later time, HMAC- SHA-256 is found to be compromised, the following is the remedy that will be applied: o Both a new message-integrity attribute and a new STUN Security Feature bit will be allocated in a Standard 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 signal to a STUN client using the Long Term Credential Mechanism that this server supports this new hash algorithm, and will prevent bid down attacks on the new message- integrity attribute. o STUN Client and Server using the Short Term Credential Mechanism will need to get an updated external mechanism that they can 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-SHA-1. This is why, after a transition period, a new document updating this document will assign a new STUN Security Feature bit for deprecating HMAC-SHA- 1. When used, this bit will signal that HMAC-SHA-1 is deprecated and should no longer be used. Petit-Huguenin, et al. Expires June 21, 2018 [Page 49] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 16. 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 [I-D.ietf-ice-rfc5245bis] ), and others do not (such as SIP Outbound [RFC5626]), answers to these considerations need to be addressed by the usages themselves. 17. IANA Considerations 17.1. STUN Security Features Registry A STUN Security Feature set is a 24 bit value. IANA is requested to create a new registry containing the STUN Security Features that are protected by the bid down attack prevention mechanism described in section Section 9.2.1. The initial STUN Security Features are: 0x000001: Password algorithms 0x000002: Username anonymity New Security Features are assigned by a Standard Action [RFC8126]. 17.2. STUN Methods Registry IANA is requested to update the reference from RFC 5389 to RFC-to-be for the following STUN methods: 0x000: (Reserved) 0x001: Binding 0x002: (Reserved; was SharedSecret) 17.3. STUN Attribute Registry Petit-Huguenin, et al. Expires June 21, 2018 [Page 50] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 17.3.1. Updated Attributes IANA is requested to update the reference from RFC 5389 to RFC-to-be for the following STUN methods: Comprehension-required range (0x0000-0x7FFF): 0x0000: (Reserved) 0x0001: MAPPED-ADDRESS 0x0002: (Reserved; was RESPONSE-ADDRESS) 0x0003: (Reserved; was CHANGE-REQUEST) 0x0004: (Reserved; was SOURCE-ADDRESS) 0x0005: (Reserved; was CHANGED-ADDRESS) 0x0006: USERNAME 0x0007: (Reserved; was PASSWORD) 0x0008: MESSAGE-INTEGRITY 0x0009: ERROR-CODE 0x000A: UNKNOWN-ATTRIBUTES 0x000B: (Reserved; was REFLECTED-FROM) 0x0014: REALM 0x0015: NONCE 0x0020: XOR-MAPPED-ADDRESS Comprehension-optional range (0x8000-0xFFFF) 0x8022: SOFTWARE 0x8023: ALTERNATE-SERVER 0x8028: FINGERPRINT 17.3.2. New Attributes IANA is requested to add the following attribute to the STUN Attribute Registry: Comprehension-required range (0x0000-0x7FFF): 0xXXXX: MESSAGE-INTEGRITY-SHA256 0xXXXX: PASSWORD-ALGORITHM 0xXXXX: USERHASH Comprehension-optional range (0x8000-0xFFFF) 0xXXXX: PASSSORD-ALGORITHMS 0xXXXX: ALTERNATE-DOMAIN 17.4. STUN Error Code Registry IANA is requested to update the reference from RFC 5389 to RFC-to-be for the Error Codes given in Section 14.8. Petit-Huguenin, et al. Expires June 21, 2018 [Page 51] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 17.5. Password Algorithm Registry IANA is requested to create a new registry for Password Algorithm. A Password Algorithm is a hex number in the range 0x0000 - 0xFFFF. The initial Password Algorithms are: 0x0001: MD5 0x0002: SHA256 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 Designated Expert [RFC8126]. 17.5.1. Password Algorithms 17.5.1.1. MD5 This password algorithm is taken from [RFC1321]. The key length is 20 bytes and the parameters value is empty. Note: This algorithm MUST only be used for compatibility with legacy systems. key = MD5(username ":" realm ":" OpaqueString(password)) 17.5.1.2. SHA256 This password algorithm is taken from [RFC7616]. The key length is 32 bytes and the parameters value is empty. key = SHA256(username ":" realm ":" OpaqueString(password)) 17.6. STUN UDP and TCP Port Numbers IANA is requested to update the reference from RFC 5389 to RFC-to-be for the following ports: 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 Petit-Huguenin, et al. Expires June 21, 2018 [Page 52] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 18. 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 (RFC 6347). o Made clear that the RTO is considered stale if there is no transactions with the server. o Aligned the RTO calculation with RFC 6298. o Updated the cipher suites for TLS. o Added support for STUN URI (RFC 7064). o Added support for SHA256 message integrity. o Updated the PRECIS support to RFC 7613. o Added protocol and registry to choose the password encryption algorithm. o Added support for anonymous username. o Added protocol and registry for preventing biddown attacks. o 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. 19. References 19.1. Normative References [ITU.V42.1994] International Telecommunications Union, "Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion", ITU-T Recommendation V.42, 1994. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc- editor.org/info/rfc791>. Petit-Huguenin, et al. Expires June 21, 2018 [Page 53] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 [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>. [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, <http://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>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc- editor.org/info/rfc5246>. [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>. [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>. Petit-Huguenin, et al. Expires June 21, 2018 [Page 54] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 [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>. [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, <https://www.rfc-editor.org/info/rfc6555>. [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>. [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords", RFC 7613, DOI 10.17487/RFC7613, August 2015, <https://www.rfc- editor.org/info/rfc7613>. [RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <https://www.rfc-editor.org/info/rfc7616>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 8200, STD 86, DOI 10.17487/RFC8200, July 2017, <https://www.rfc- editor.org/info/rf8200>. 19.2. Informative References [I-D.ietf-ice-rfc5245bis] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", draft-ietf-ice- rfc5245bis-15 (work in progress), November 2017. [KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", August 1987. [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>. Petit-Huguenin, et al. Expires June 21, 2018 [Page 55] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 [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>. [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>. [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>. [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>. Petit-Huguenin, et al. Expires June 21, 2018 [Page 56] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 [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. and R. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc- editor.org/info/rfc7231>. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, May 2008, <https://www.rfc-editor.org/info/rfc8126>. 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 & 0x0F80) << 9 | (method & 0x0070) << 5 | (method & 0x000F) | (cls & 0x0002) << 8 | (cls & 0x0001) << 4; } <CODE ENDS> A function to extract the method from the message type: Petit-Huguenin, et al. Expires June 21, 2018 [Page 57] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 <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 [RFC7613] processing Password: "The<U+00AD>M<U+00AA>tr<U+2168>" and "TheMatrIX" (without quotes) respectively before and after OpaqueString processing Nonce: "obMatJos2AAACf//499k954d6OL34oL9FSTvy64sA" (without quotes) Realm: "example.org" (without quotes) Petit-Huguenin, et al. Expires June 21, 2018 [Page 58] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 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 } XX XX 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 } XX XX 00 20 MESSAGE-INTEGRITY-SHA256 attribute header c4 ec a2 b6 } 24 6f 26 be } bc 2f 77 49 } 07 c2 00 a3 } HMAC-SHA256 value 76 c7 c2 8e } b4 d1 26 60 } bb fe 9f 28 } 0e 85 71 f2 } Note: Before publication, the XX XX placeholder must be replaced by the value assigned to MESSAGE-INTEGRITY-SHA256 and USERHASH by IANA. The MESSAGE-INTEGRITY-SHA256 attribute value will need to be updated after this. Petit-Huguenin, et al. Expires June 21, 2018 [Page 59] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 Appendix C. Release notes This section must be removed before publication as an RFC. C.1. Modifications between draft-ietf-tram-stunbis-13 and draft-ietf- tram-stunbis-12 o Update references. o Fixes some text following Shepherd review. o Update co-author info. C.2. Modifications between draft-ietf-tram-stunbis-12 and draft-ietf- tram-stunbis-11 o Clarifies the procedure to define a new hash algorithm for message-integrity. o Explain the procedure to deprecate SHA1 as message-integrity. o Added procedure for Happy Eyeballs (RFC 6555). o Added verification that Happy Eyeballs works in the STUN Usage checklist. o Add reference to Base64 RFC. o Changed co-author affiliation. C.3. Modifications between draft-ietf-tram-stunbis-11 and draft-ietf- tram-stunbis-10 o Made clear that the same HMAC than received in response of short term credential must be used for subsequent transactions. o s/URL/URI/ o The "nonce cookie" is now mandatory to signal that SHA256 must be used in the next transaction. o s/SHA1/SHA256/ o Changed co-author affiliation. Petit-Huguenin, et al. Expires June 21, 2018 [Page 60] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 C.4. Modifications between draft-ietf-tram-stunbis-10 and draft-ietf- tram-stunbis-09 o Removed the reserved value in the security registry, as it does not make sense in a bitset. o Updated change list. o Updated the minimum truncation size for M-I-256 to 16 bytes. o Changed the truncation order to match RFC 7518. o Fixed bugs in truncation boundary text. o Stated that STUN Usages have to explicitly state that they can use truncation. o Removed truncation from the MESSAGE-INTEGRITY attribute. o Add reference to C code in RFC 1952. o Replaced RFC 2818 reference to RFC 6125. C.5. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- tram-stunbis-08 o Removed the reserved value in the security registry, as it does not make sense in a bitset. o Updated change list. o Updated the minimum truncation size for M-I-256 to 16 bytes. o Changed the truncation order to match RFC 7518. o Fixed bugs in truncation boundary text. o Stated that STUN Usages have to explicitly state that they can use truncation. o Removed truncation from the MESSAGE-INTEGRITY attribute. o Add reference to C code in RFC 1952. o Replaced RFC 2818 reference to RFC 6125. Petit-Huguenin, et al. Expires June 21, 2018 [Page 61] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 C.6. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- tram-stunbis-08 o Packets discarded in a reliable or unreliable transaction triggers an attack error instead of a timeout error. An attack error on a reliable transport is signaled immediately instead of waiting for the timeout. o Explicitly state that a received 400 response without authentication will be dropped until timeout. o Clarify the SHOULD omit/include rules in LTCM. o If the nonce and the hmac are both invalid, then a 401 is sent instead of a 438. o The 401 and 438 error response to subsequent requests may use the previous NONCE/password to authenticate, if they are still available. o Change "401 Unauthorized" to "401 Unauthenticated" o Make clear that in some cases it is impossible to add a MI or MI2 even if the text says SHOULD NOT. C.7. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf- tram-stunbis-07 o Updated list of changes since RFC 5389. o More examples are automatically generated. o Message integrity truncation is fixed at a multiple of 4 bytes, because the padding will not decrease by more than this. o USERHASH contains the 32 bytes of the hash, not a character string. o Updated the example to use the USERHASH attribute and the modified NONCE attribute. o Updated ICEbis reference. Petit-Huguenin, et al. Expires June 21, 2018 [Page 62] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 C.8. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf- tram-stunbis-06 o Add USERHASH attribute to carry the hashed version of the username. o Add IANA registry and nonce encoding for Security Features that need to be protected from bid down attacks. o Modified MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 to support truncation limits (pending cryptographic review), C.9. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf- tram-stunbis-05 o Changed I-D references to RFC references. o Changed CHANGE-ADDRESS to CHANGE-REQUEST (Errata #4233). o Added test vector for MESSAGE-INTEGRITY-SHA256. o Address additional review comments from Jonathan Lennox and Brandon Williams. C.10. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- tram-stunbis-04 o Address review comments from Jonathan Lennox and Brandon Williams. C.11. 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. Petit-Huguenin, et al. Expires June 21, 2018 [Page 63] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 C.12. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- tram-stunbis-02 o SCTP prefix is now 0b00000101 instead of 0x11. o Add SCTP at various places it was needed. 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 section. C.13. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- 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 different IP address and/or different port. This prevent sharing the nonce between TURN allocations in TURN. o Add reference to draft-ietf-uta-tls-bcp o Add a new attribute ALTERNATE-DOMAIN to verify the certificate of the ALTERNATE-SERVER after a 300 over (D)TLS. o The RTP delay between transactions applies only to parallel transactions, not to serial transactions. That prevents a 3RTT delay between the first transaction and the second transaction with long term authentication. o Add text saying ORIGIN can increase a request size beyond the MTU and so require an SCTPoUDP transport. o Move the Acknowledgments and Contributor sections to the end of the document, in accordance with RFC 7322 section 4. C.14. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- tram-stunbis-00 o Add negotiation mechanism for new password algorithms. o Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol. Petit-Huguenin, et al. Expires June 21, 2018 [Page 64] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 o Add support for SCTP to solve the fragmentation problem. o Merge RFC 7350: * Split the "Sending over..." sections in 3. * Add DTLS-over-UDP as transport. * Update the cipher suites and cipher/compression restrictions. * A stuns uri with an IP address is rejected. * Replace most of the RFC 3489 compatibility by a reference to the section in RFC 5389. * Update the STUN Usages list with transport applicability. o Merge RFC 7064: * DNS discovery is done from the URI. * Reorganized the text about default ports. o Add more C snippets. o Make clear that the cached RTO is discarded only if there is no new transations for 10 minutes. C.15. Modifications between draft-salgueiro-tram-stunbis-02 and draft- ietf-tram-stunbis-00 o Draft adopted as WG item. C.16. Modifications between draft-salgueiro-tram-stunbis-02 and draft- salgueiro-tram-stunbis-01 o Add definition of MESSAGE-INTEGRITY2. o Update text and reference from RFC 2988 to RFC 6298. o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix section number and make clear that the original domain name is used for the server certificate verification. This is consistent with what RFC 5922 (section 4) is doing. (Errata #2010) Petit-Huguenin, et al. Expires June 21, 2018 [Page 65] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 o Remove text transitioning from RFC 3489. o Add definition of MESSAGE-INTEGRITY2. o Update text and reference from RFC 2988 to RFC 6298. o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix section number and make clear that the original domain name is used for the server certificate verification. This is consistent with what RFC 5922 (section 4) is doing. (Errata #2010) C.17. Modifications between draft-salgueiro-tram-stunbis-01 and draft- salgueiro-tram-stunbis-00 o Restore the RFC 5389 text. o Add list of open issues. 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 and Tolga Asveren for the comments, suggestions, and questions that helped improve this document. The authors of RFC 5389 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 co-authors of RFC 3489. Authors' Addresses Marc Petit-Huguenin Impedance Mismatch Email: marc@petit-huguenin.org Petit-Huguenin, et al. Expires June 21, 2018 [Page 66] Internet-Draft Session Traversal Utilities for NAT (STUN) December 2017 Gonzalo Salgueiro Cisco 7200-12 Kit Creek Road Research Triangle Park, NC 27709 US Email: gsalguei@cisco.com Jonathan Rosenberg Cisco Edison, NJ US Email: jdrosen@cisco.com URI: http://www.jdrosen.net Dan Wing 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 Petit-Huguenin, et al. Expires June 21, 2018 [Page 67]