--- 1/draft-ietf-behave-rfc3489bis-10.txt 2007-10-12 06:12:06.000000000 +0200 +++ 2/draft-ietf-behave-rfc3489bis-11.txt 2007-10-12 06:12:06.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: March 16, 2008 R. Mahy +Expires: April 13, 2008 R. Mahy Plantronics P. Matthews Avaya D. Wing Cisco - September 13, 2007 + October 11, 2007 Session Traversal Utilities for (NAT) (STUN) - draft-ietf-behave-rfc3489bis-10 + draft-ietf-behave-rfc3489bis-11 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 March 16, 2008. + This Internet-Draft will expire on April 13, 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 @@ -81,63 +81,63 @@ 7.3.3. Processing a Success Response . . . . . . . . . . . . 18 7.3.4. Processing an Error Response . . . . . . . . . . . . . 18 8. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 19 9. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 19 10. Authentication and Message-Integrity Mechanisms . . . . . . . 20 10.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . 24 - 10.2.1.1. First Request . . . . . . . . . . . . . . . . . . 24 + 10.2.1. Forming a Request . . . . . . . . . . . . . . . . . . 23 + 10.2.1.1. First Request . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . 37 15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . . 37 - 15.2.1. Attack I: DDoS Against a Target . . . . . . . . . . . 37 + 15.2.1. Attack I: DDoS Against a Target . . . . . . . . . . . 38 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 + 15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . . 39 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 39 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . . 39 17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 40 - 17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 40 + 17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 41 18. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 41 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 - 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 - 20.1. Normative References . . . . . . . . . . . . . . . . . . 42 + 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 + 20.1. Normative References . . . . . . . . . . . . . . . . . . 43 20.2. Informational References . . . . . . . . . . . . . . . . 43 - Appendix A. C Snippet to Determine STUN Message Types . . . . . . 44 + Appendix A. C Snippet to Determine STUN Message Types . . . . . . 45 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 @@ -563,28 +563,29 @@ result in the retransmission of a request. The value for RTO SHOULD be cached by an client after the completion of the transaction, and used as the starting value for RTO for the next transaction to the same server (based on equality of IP address). The value SHOULD be considered stale and discarded after 10 minutes. Retransmissions continue until a response is received, or until a total of 7 requests have been sent. If, after the last request, a - duration equal to 16 times the RTO has passed without a response, the - client SHOULD consider the transaction to have failed. A STUN - transaction over UDP is also considered failed if there has been a - transport failure of some sort, such as a fatal ICMP error. For - example, assuming an RTO of 100ms, requests would be sent at times - 0ms, 100ms, 300ms, 700ms, 1500ms, 3100ms, and 6300ms. If the client - has not received a response after 7900ms, the client will consider - the transaction to have timed out. + duration equal to 16 times the RTO has passed without a response + (providing ample time to get a response if only this final request + actually succeeds), the client SHOULD consider the transaction to + have failed. A STUN transaction over UDP is also considered failed + if there has been a transport failure of some sort, such as a fatal + ICMP error. For example, assuming an RTO of 100ms, requests would be + sent at times 0ms, 100ms, 300ms, 700ms, 1500ms, 3100ms, and 6300ms. + If the client has not received a response after 7900ms, the client + will consider the transaction to have timed out. 7.2.2. Sending over TCP or TLS-over-TCP For TCP and TLS-over-TCP, the client opens a TCP connection to the server. In some usage of STUN, STUN is sent as the only protocol over the TCP connection. In this case, it can be sent without the aid of any additional framing or demultiplexing. In other usages, or with other extensions, it may be multiplexed with other data over a TCP @@ -936,22 +937,22 @@ This credential is used to form a message integrity check in each request and in many responses. There is no challenge and response as in the long term mechanism; consequently, replay is prevented by virtue of the time-limited nature of the credential. 10.1.1. Forming a Request or Indication For a request or indication message, the agent MUST include the USERNAME and MESSAGE-INTEGRITY attributes in the message. The HMAC for the MESSAGE-INTEGRITY attribute is computed as described in - Section 14.4. The key for the HMAC is the password. Note that the - password is never included in the request or indication. + Section 14.4. Note that the password is never included in the + request or indication. 10.1.2. Receiving a Request or Indication After the agent has done the basic processing of a message, the agent performs the checks listed below in order specified: o If the message does not contain both a MESSAGE-INTEGRITY and a USERNAME attribute: * If the message is a request, the server MUST reject the request @@ -1040,34 +1041,20 @@ the client. Note that the long-term credential mechanism cannot be used to protect indications, since indications cannot be challenged. Usages utilizing indications must either use a short-term credential, or omit authentication and message integrity for them. Since the long-term credential mechanism is susceptible to offline dictionary attacks, deployments SHOULD utilize strong passwords. - For STUN servers used in conjunction with SIP servers, it is - desirable to use the same credentials for authentication to the SIP - server and STUN server. Typically, SIP systems utilizing SIP's - digest authentication mechanism do not actually store the password in - the database. Rather, they store a value called H(A1), which is - computed as: - - H(A1) = MD5(username ":" realm ":" password) - - If a system wishes to utilize this credential, the STUN password - 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. 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. @@ -1088,21 +1076,21 @@ 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. + cached password. 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, 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 @@ -1247,20 +1234,28 @@ message, and insert a MAPPED-ADDRESS attribute instead of an XOR- MAPPED-ADDRESS attribute. The client might, in rare situations, include either the RESPONSE- ADDRESS or CHANGE-REQUEST attributes. In these situations, the server will view these as unknown comprehension-required attributes and reply with an error response. Since the mechanisms utilizing those attributes are no longer supported, this behavior is acceptable. + The RFC 3489 version of STUN lacks both the Magic Cookie and the + FINGERPRINT attribute that allows for a very high probablility of + correctly identifying STUN messages when multiplexed with other + protocols. Therefore, STUN implementations that are backwards + compatible with RFC 3489 SHOULD NOT be used in cases where STUN will + be multiplexed with another protocol. However, that should not be an + issues as such multiplexing was not available in RFC 3489. + 13. STUN Usages STUN by itself is not a solution to the NAT traversal problem. Rather, STUN defines a tool that can be used inside a larger solution. The term "STUN Usage" is used for any solution that uses STUN as a component. At the time of writing, three STUN usages are defined: Interactive Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice], Client- initiated connections for SIP [I-D.ietf-sip-outbound], and NAT @@ -1307,21 +1302,21 @@ bit first. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (variable) .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 5: Format of STUN Attributes + Figure 4: Format of STUN Attributes The value in the Length field MUST contain the length of the Value part of the attribute, prior to padding, measured in bytes. Since STUN aligns attributes on 32 bit boundaries, attributes whose content is not a multiple of 4 bytes are padded with 1, 2 or 3 bytes of padding so that its value contains a multiple of 4 bytes. The padding bits are ignored, and may be any value. Any attribute type MAY appear more than once in a STUN message. Unless specified otherwise, the order of appearance is significant: @@ -1373,21 +1368,21 @@ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 0 0| Family | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Address (32 bits or 128 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 7: Format of MAPPED-ADDRESS attribute + Figure 6: Format of MAPPED-ADDRESS attribute The address family can take on the following values: 0x01:IPv4 0x02:IPv6 The first 8 bits of the MAPPED-ADDRESS MUST be set to 0 and MUST be ignored by receivers. These bits are present for aligning parameters on natural 32 bit boundaries. This attribute is used only by servers for achieving backwards @@ -1402,21 +1397,21 @@ The format of the XOR-MAPPED-ADDRESS is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x x x x x x x x| Family | X-Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | X-Address (Variable) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 9: Format of XOR-MAPPED-ADDRESS Attribute + Figure 8: 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 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 @@ -1453,21 +1448,34 @@ The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of the STUN message. The MESSAGE-INTEGRITY attribute can be present in any STUN message type. Since it uses the SHA1 hash, the HMAC will be 20 bytes. The text used as input to HMAC is the STUN message, including the header, up to and including the attribute preceding the MESSAGE-INTEGRITY attribute. With the exception of the FINGERPRINT attribute, which appears after MESSAGE-INTEGRITY, agents MUST ignore all other attributes that follow MESSAGE-INTEGRITY. - The key used as input to HMAC is the password. + The key for the HMAC depends on whether long term or short term + credentials are in use. For long term credentials: + + key = MD5(username ":" realm ":" password) + + For short term credentials: + + key = password + + The structure of the key when used with long term credentials + facilitates deployment in systems that also utilize SIP. Typically, + SIP systems utilizing SIP's digest authentication mechanism do not + actually store the password in the database. Rather, they store a + value called H(A1), which is equal to the key defined above. Based on the rules above, the hash includes the length field from the 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 @@ -1600,21 +1608,21 @@ represents an attribute type that was not understood by the server. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute 1 Type | Attribute 2 Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute 3 Type | Attribute 4 Type ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 11: Format of UNKNOWN-ATTRIBUTES attribute + Figure 12: Format of UNKNOWN-ATTRIBUTES attribute Note: In [RFC3489], this field was padded to 32 by duplicating the last attribute. In this version of the specification, the normal padding rules for attributes are used instead. 14.10. SERVER The server attribute contains a textual description of the software being used by the server, including manufacturer and version number. The attribute has no impact on operation of the protocol, and serves only as a tool for diagnostic and debugging purposes. The value of @@ -1661,72 +1669,82 @@ 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 with this attack, and it is mitigated by - ingress source address filtering. + 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. 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/Binding Response transaction. Since the usage of the reflexive address is a function of the usage, the applicability and remediation of these attacks is 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. 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-mmusic-ice]. Other usages may use other - means to prevent these attacks. + 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-mmusic-ice]. Other usages may use other means to prevent + these attacks. 15.2.1. Attack I: 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. + 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. + 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. 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 which was destined for the client. 15.2.4. Attack IV: Eavesdropping In this attack, the attacker forces the client to use a reflexive @@ -1736,23 +1754,23 @@ 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 SHA-1 for computation of the message - integrity. If, at a later time, SHA-1 is found to be compromised, - the following is the remedy that will be applied. + This specification uses HMAC-SHA-1 for computation of the message + integrity. If, at a later time, HMAC-SHA-1 is found to be + compromised, the following is the remedy that will be applied. We will define a STUN extension which introduces a new message integrity attribute, computed using a new hash. Clients would be required to include both the new and old message integrity attributes in their requests or indications. A new server will utilize the new message integrity attribute, and an old one, the old. After a transition period where mixed implementations are in deployment, the old message-integrity attribute will be deprecated by another specification, and clients will cease including it in requests.