--- 1/draft-ietf-behave-rfc3489bis-08.txt 2007-08-17 19:12:04.000000000 +0200 +++ 2/draft-ietf-behave-rfc3489bis-09.txt 2007-08-17 19:12:04.000000000 +0200 @@ -1,25 +1,25 @@ BEHAVE Working Group J. Rosenberg Internet-Draft Cisco Obsoletes: 3489 (if approved) C. Huitema Intended status: Standards Track Microsoft -Expires: January 28, 2008 R. Mahy +Expires: February 18, 2008 R. Mahy Plantronics P. Matthews Avaya D. Wing Cisco - July 27, 2007 + August 17, 2007 Session Traversal Utilities for (NAT) (STUN) - draft-ietf-behave-rfc3489bis-08 + draft-ietf-behave-rfc3489bis-09 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -30,21 +30,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on January 28, 2008. + This Internet-Draft will expire on February 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated @@ -86,60 +86,60 @@ 10.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 20 10.1.1. Forming a Request or Indication . . . . . . . . . . . 21 10.1.2. Receiving a Request or Indication . . . . . . . . . . 21 10.1.3. Receiving a Response . . . . . . . . . . . . . . . . . 22 10.2. Long-term Credential Mechanism . . . . . . . . . . . . . 22 10.2.1. Forming a Request . . . . . . . . . . . . . . . . . . 23 10.2.1.1. First Request . . . . . . . . . . . . . . . . . . 24 10.2.1.2. Subsequent Requests . . . . . . . . . . . . . . . 24 10.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 24 10.2.3. Receiving a Response . . . . . . . . . . . . . . . . . 25 - 11. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . . 25 + 11. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . . 26 12. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 26 12.1. Changes to Client Processing . . . . . . . . . . . . . . 27 12.2. Changes to Server Processing . . . . . . . . . . . . . . 27 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 28 - 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 29 - 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 30 - 14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 31 - 14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 31 - 14.5. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . . 32 - 14.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 32 - 14.7. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 14.8. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 14.9. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 34 - 14.10. SERVER . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 14.11. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 35 - 15. Security Considerations . . . . . . . . . . . . . . . . . . . 35 - 15.1. Attacks against the Protocol . . . . . . . . . . . . . . 35 + 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 29 + 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 30 + 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 31 + 14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 32 + 14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 32 + 14.5. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . . 33 + 14.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 33 + 14.7. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 14.8. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 35 + 14.9. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 35 + 14.10. SERVER . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 14.11. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 36 + 15. Security Considerations . . . . . . . . . . . . . . . . . . . 36 + 15.1. Attacks against the Protocol . . . . . . . . . . . . . . 36 15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . . 36 - 15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . 36 - 15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . . 36 + 15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . 37 + 15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . . 37 15.2.1. Attack I: DDoS Against a Target . . . . . . . . . . . 37 - 15.2.2. Attack II: Silencing a Client . . . . . . . . . . . . 37 - 15.2.3. Attack III: Assuming the Identity of a Client . . . . 37 - 15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 37 + 15.2.2. Attack II: Silencing a Client . . . . . . . . . . . . 38 + 15.2.3. Attack III: Assuming the Identity of a Client . . . . 38 + 15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 38 15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . . 38 - 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 38 - 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 + 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 39 + 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . . 39 - 17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 39 + 17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 40 17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 40 - 18. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 40 + 18. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 41 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 20.1. Normative References . . . . . . . . . . . . . . . . . . 42 - 20.2. Informational References . . . . . . . . . . . . . . . . 42 + 20.2. Informational References . . . . . . . . . . . . . . . . 43 Appendix A. C Snippet to Determine STUN Message Types . . . . . . 44 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 - Intellectual Property and Copyright Statements . . . . . . . . . . 46 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 + Intellectual Property and Copyright Statements . . . . . . . . . . 47 1. Introduction The protocol defined in this specification, Session Traversal Utilities for NAT, provides a tool for dealing with NATs. It provides a means for an endpoint to determine the IP address and port allocated by a NAT that corresponds to its private IP address and port. It also provides a way for an endpoint to keep a NAT binding alive. With some extensions, the protocol can be used to do connectivity checks between two endpoints [I-D.ietf-mmusic-ice], or @@ -148,22 +148,22 @@ In keeping with its tool nature, this specification defines an extensible packet format, defines operation over several transport protocols, and provides for two forms of authentication. STUN is intended to be used in context of one or more NAT traversal solutions. These solutions are known as STUN usages. Each usage describes how STUN is utilized to achieve the NAT traversal solution. Typically, a usage indicates when STUN messages get sent, which optional attributes to include, what server is used, and what authentication mechanism is to be used. Interactive Connectivity - Establishment (ICE) [I-D.ietf-mmusic-ice] is one usage of ICE. SIP - Outbound [I-D.ietf-sip-outbound] is another usage of ICE. In some + Establishment (ICE) [I-D.ietf-mmusic-ice] is one usage of STUN. SIP + Outbound [I-D.ietf-sip-outbound] is another usage of STUN. In some cases, a usage will require extensions to STUN. A STUN extension can be in the form of new methods, attributes, or error response codes. More information on STUN usages can be found in Section 13. 2. Evolution from RFC 3489 STUN was originally defined in RFC 3489 [RFC3489]. That specification, sometimes referred to as "classic STUN", represented itself as a complete solution to the NAT traversal problem. In that solution, a client would discover whether it was behind a NAT, @@ -1058,81 +1058,96 @@ would be computed by taking the user-entered username and password, and using H(A1) as the STUN password. It is RECOMMENDED that clients utilize this construction for the STUN password. 10.2.1. Forming a Request There are two cases when forming a request. In the first case, this is the first request from the client to the server (as identified by its IP address and port). In the second case, the client is submitting a subsequent request once a previous request/response - transaction has completed successfully. + transaction has completed successfully. Forming a request as a + consequence of a 401 or 438 error response is covered in + Section 10.2.3 and is not considered a "subsequent request" and thus + does not utilize the rules described in Section 10.2.1.2. 10.2.1.1. First Request If the client has not completed a successful request/response - transaction with the server, it SHOULD omit the USERNAME, MESSAGE- - INTEGRITY, REALM, and NONCE attributes. In other words, the very - first request is sent as if there were no authentication or message - integrity applied. + transaction with the server (as identified by hostname, if the DNS + procedures of Section 9 are used, else IP address if not), it SHOULD + omit the USERNAME, MESSAGE-INTEGRITY, REALM, and NONCE attributes. + In other words, the very first request is sent as if there were no + authentication or message integrity applied. The exception to this + rule are requests sent to another server as a consequence of the + ALTERNATE-SERVER mechanism described in Section 11. Those requests + do include the USERNAME, REALM and NONCE from the original request, + along with a newly computed MESSAGE-INTEGRITY based on them. 10.2.1.2. Subsequent Requests Once a request/response transaction has completed successfully, the client will have been been presented a realm and nonce by the server, and selected a username and password with which it authenticated. The client SHOULD cache the username, password, realm, and nonce for subsequent communications with the server. When the client sends a subsequent request, it SHOULD include the USERNAME, REALM, and NONCE attributes with these cached values. It SHOULD include a MESSAGE- INTEGRITY attributed, computed as described in Section 14.4 using the cached password as the key. 10.2.2. Receiving a Request After the server has done the basic processing of a request, it performs the checks listed below in the order specified: - o If the message: - - * does not contain a MESSAGE-INTEGRITY attribute, - - * OR, it contains a USERNAME whose value is not a valid username, - - the server MUST generate an error response with an error code of - 401 (Unauthorized). This response MUST include a REALM value. It - is RECOMMENDED that the REALM value be the domain name of the + o If the message does not contain a MESSAGE-INTEGRITY attribute, the + server MUST generate an error response with an error code of 401 + (Unauthorized). This response MUST include a REALM value. It is + RECOMMENDED that the REALM value be the domain name of the provider of the STUN server. The response MUST include a NONCE, - selected by the server. + selected by the server. The response SHOULD NOT contain a + USERNAME or MESSAGE-INTEGRITY attribute. o If the message contains a MESSAGE-INTEGRITY attribute, but is missing the USERNAME, REALM or NONCE attributes, the server MUST generate an error response with an error code of 400 (Bad - Request). + Request). This response SHOULD NOT include a USERNAME, NONCE, + REALM or MESSAGE-INTEGRITY attribute. o If the NONCE is no longer valid, the server MUST generate an error response with an error code of 438 (Stale Nonce). This response - MUST include a NONCE and REALM attribute. + MUST include a NONCE and REALM attribute and SHOULD NOT incude the + USERNAME or MESSAGE-INTEGRITY attribute. + + o If the username in the USERNAME attribute is not valid, the server + MUST generate an error response with an error code of 401 + (Unauthorized). This response MUST include a REALM value. It is + RECOMMENDED that the REALM value be the domain name of the + provider of the STUN server. The response MUST include a NONCE, + selected by the server. The response SHOULD NOT contain a + USERNAME or MESSAGE-INTEGRITY attribute. o Using the password associated with the username in the USERNAME attribute, compute the value for the message-integrity as described in Section 14.4. If the resulting value does not match the contents of the MESSAGE-INTEGRITY attribute, the server MUST reject the request with an error response. This response MUST use an error code of 401 (Unauthorized). It MUST include a REALM and - NONCE attribute. + NONCE attribute and SHOULD NOT include the USERNAME or MESSAGE- + INTEGRITY attribute. - If these checks pass, the server continues to process the request or - indication. Any response generated by the server MUST include the - MESSAGE-INTEGRITY attribute, computed using the username and password - utilized to authenticate the request. The REALM, NONCE, and USERNAME - attributes SHOULD NOT be included. + If these checks pass, the server continues to process the request. + Any response generated by the server (excepting the cases described + above) MUST include the MESSAGE-INTEGRITY attribute, computed using + the username and password utilized to authenticate the request. The + REALM, NONCE, and USERNAME attributes SHOULD NOT be included. 10.2.3. Receiving a Response If the response is an error response, with an error code of 401 (Unauthorized), the client SHOULD retry the request with a new transaction. This request MUST contain a USERNAME, determined by the client as the appropriate username for the REALM from the error response. The request MUST contain the REALM, copied from the error response. The request MUST contain the NONCE, copied from the error response. The request MUST contain the MESSAGE-INTEGRITY attribute, @@ -1390,31 +1404,29 @@ |x x x x x x x x| Family | X-Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | X-Address (Variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Format of XOR-MAPPED-ADDRESS Attribute The Family represents the IP address family, and is encoded identically to the Family in MAPPED-ADDRESS. - X-Port is the mapped port, exclusive or'd with most significant 16 - bits of the magic cookie. If the IP address family is IPv4, - X-Address is the mapped IP address exclusive or'd with the magic - cookie. If the IP address family is IPv6, the X-Address is the - mapped IP address exclusively or'ed with the magic cookie and the 96- - bit transaction ID. - - For example, using the "^" character to indicate exclusive or, if the - IP address is 192.168.1.1 (0xc0a80101) and the port is 5555 (0x15B3), - the X-Port would be 0x15B3 ^ 0x2112 = 0x34A1, and the X-Address would - be 0xc0a80101 ^ 0x2112A442 = 0xe1baa543. + X-Port is computed by taking the mapped port in host byte order, + XOR'ing it with the most significant 16 bits of the magic cookie, and + then the converting the result to network byte order. If the IP + address family is IPv4, X-Address is computed by taking the mapped IP + address in host byte order, XOR'ing it with the magic cookie, and + converting the result to network byte order. If the IP address + family is IPv6, X-Address is computed by taking the mapped IP address + in host byte order, XOR'ing it with the magic cookie and the 96-bit + transaction ID, and converting the result to network byte order. The rules for encoding and processing the first 8 bits of the attribute's value, the rules for handling multiple occurrences of the attribute, and the rules for processing addresses families are the same as for MAPPED-ADDRESS. NOTE: XOR-MAPPED-ADDRESS and MAPPED-ADDRESS differ only in their encoding of the transport address. The former encodes the transport address by exclusive-or'ing it with the magic cookie. The latter encodes it directly in binary. RFC 3489 originally specified only @@ -1452,44 +1464,47 @@ STUN message header. This length indicates the length of the entire message, including the MESSAGE-INTEGRITY attribute itself. Consequently, the MESSAGE-INTEGRITY attribute MUST be inserted into the message (with dummy content) prior to the computation of the integrity check. Once the computation is performed, the value of the attribute can be filled in. This ensures the length has the correct value when the hash is performed. Similarly, when validating the MESSAGE-INTEGRITY, the length field should be adjusted to point to the end of the MESSAGE-INTEGRITY attribute prior to calculating the HMAC. Such adjustment is necessary when attributes, such as - FINTERPRINT, appear after MESSAGE-INTEGRITY. + FINGERPRINT, appear after MESSAGE-INTEGRITY. 14.5. FINGERPRINT The FINGERPRINT attribute may be present in all STUN messages. The value of the attribute is computed as the CRC-32 of the STUN message up to (but excluding) the FINGERPRINT attribute itself, xor-d with the 32 bit value 0x5354554e (the XOR helps in cases where an application packet is also using CRC-32 in it). The 32 bit CRC is the one defined in ITU V.42 [ITU.V42.1994], which has a generator polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. When present, the FINGERPRINT attribute MUST be the last attribute in the message, and thus will appear after MESSAGE-INTEGRITY. The FINGERPRINT attribute can aid in distinguishing STUN packets from packets of other protocols. See Section 8. - When using the FINGERPRINT attribute in a message, the attribute is - first placed into the message with a dummy value, then the CRC is - computed, and then the value of the attribute is updated. If the - MESSAGE-INTEGRITY attribute is also present, then it must be present - with the correct message-integrity value before the CRC is computed, - since the CRC is done over the value of the MESSAGE-INTEGRITY - attribute as well. + As with MESSAGE-INTEGRITY, the CRC used in the FINGERPRINT attribute + covers the length field from the STUN message header. Therefore, + this value must be correct, and include the CRC attribute as part of + the message length, prior to computation of the CRC. When using the + FINGERPRINT attribute in a message, the attribute is first placed + into the message with a dummy value, then the CRC is computed, and + then the value of the attribute is updated. If the MESSAGE-INTEGRITY + attribute is also present, then it must be present with the correct + message-integrity value before the CRC is computed, since the CRC is + done over the value of the MESSAGE-INTEGRITY attribute as well. 14.6. ERROR-CODE The ERROR-CODE attribute is used in Error Response messages. It contains a numeric error code value in the range of 300 to 699 plus a textual reason phrase encoded in UTF-8, and is consistent in its code assignments and semantics with SIP [RFC3261] and HTTP [RFC2616]. The reason phrase is meant for user consumption, and can be anything appropriate for the error code. Recommended reason phrases for the defined error codes are presented below. The reason phrase MUST be a @@ -1930,71 +1944,72 @@ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, + February 1997. + [ITU.V42.1994] International Telecommunications Union, "Error-correcting Procedures for DCEs Using Asynchronous-to-Synchronous Conversion", ITU-T Recommendation V.42, 1994. 20.2. Informational References - [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- - Hashing for Message Authentication", RFC 2104, - February 1997. - [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", - draft-ietf-mmusic-ice-16 (work in progress), June 2007. + draft-ietf-mmusic-ice-17 (work in progress), July 2007. [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, March 2003. [I-D.ietf-behave-turn] - Rosenberg, J., "Obtaining Relay Addresses from Simple - Traversal Underneath NAT (STUN)", - draft-ietf-behave-turn-03 (work in progress), March 2007. + Rosenberg, J., "Traversal Using Relays around NAT (TURN): + Relay Extensions to Session Traversal Utilities for NAT + (STUN)", draft-ietf-behave-turn-04 (work in progress), + July 2007. [I-D.ietf-sip-outbound] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", - draft-ietf-sip-outbound-09 (work in progress), June 2007. + draft-ietf-sip-outbound-10 (work in progress), July 2007. [I-D.ietf-behave-nat-behavior-discovery] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery - Using STUN", draft-ietf-behave-nat-behavior-discovery-00 - (work in progress), February 2007. + Using STUN", draft-ietf-behave-nat-behavior-discovery-01 + (work in progress), July 2007. [I-D.ietf-mmusic-ice-tcp] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE", - draft-ietf-mmusic-ice-tcp-03 (work in progress), - March 2007. + draft-ietf-mmusic-ice-tcp-04 (work in progress), + July 2007. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an