draft-ietf-behave-rfc3489bis-10.txt   draft-ietf-behave-rfc3489bis-11.txt 
BEHAVE Working Group J. Rosenberg BEHAVE Working Group J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 3489 (if approved) C. Huitema Obsoletes: 3489 (if approved) C. Huitema
Intended status: Standards Track Microsoft Intended status: Standards Track Microsoft
Expires: March 16, 2008 R. Mahy Expires: April 13, 2008 R. Mahy
Plantronics Plantronics
P. Matthews P. Matthews
Avaya Avaya
D. Wing D. Wing
Cisco Cisco
September 13, 2007 October 11, 2007
Session Traversal Utilities for (NAT) (STUN) Session Traversal Utilities for (NAT) (STUN)
draft-ietf-behave-rfc3489bis-10 draft-ietf-behave-rfc3489bis-11
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. 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 Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Session Traversal Utilities for NAT (STUN) is a protocol that serves Session Traversal Utilities for NAT (STUN) is a protocol that serves
as a tool for other protocols in dealing with NAT traversal. It can 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 be used by an endpoint to determine the IP address and port allocated
skipping to change at page 2, line 46 skipping to change at page 2, line 46
7.3.3. Processing a Success Response . . . . . . . . . . . . 18 7.3.3. Processing a Success Response . . . . . . . . . . . . 18
7.3.4. Processing an Error Response . . . . . . . . . . . . . 18 7.3.4. Processing an Error Response . . . . . . . . . . . . . 18
8. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 19 8. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 19
9. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 19 9. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 19
10. Authentication and Message-Integrity Mechanisms . . . . . . . 20 10. Authentication and Message-Integrity Mechanisms . . . . . . . 20
10.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 21 10.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 21
10.1.1. Forming a Request or Indication . . . . . . . . . . . 21 10.1.1. Forming a Request or Indication . . . . . . . . . . . 21
10.1.2. Receiving a Request or Indication . . . . . . . . . . 21 10.1.2. Receiving a Request or Indication . . . . . . . . . . 21
10.1.3. Receiving a Response . . . . . . . . . . . . . . . . . 22 10.1.3. Receiving a Response . . . . . . . . . . . . . . . . . 22
10.2. Long-term Credential Mechanism . . . . . . . . . . . . . 22 10.2. Long-term Credential Mechanism . . . . . . . . . . . . . 22
10.2.1. Forming a Request . . . . . . . . . . . . . . . . . . 24 10.2.1. Forming a Request . . . . . . . . . . . . . . . . . . 23
10.2.1.1. First Request . . . . . . . . . . . . . . . . . . 24 10.2.1.1. First Request . . . . . . . . . . . . . . . . . . 23
10.2.1.2. Subsequent Requests . . . . . . . . . . . . . . . 24 10.2.1.2. Subsequent Requests . . . . . . . . . . . . . . . 24
10.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 24 10.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 24
10.2.3. Receiving a Response . . . . . . . . . . . . . . . . . 25 10.2.3. Receiving a Response . . . . . . . . . . . . . . . . . 25
11. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . . 26 11. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . . 26
12. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 26 12. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 26
12.1. Changes to Client Processing . . . . . . . . . . . . . . 27 12.1. Changes to Client Processing . . . . . . . . . . . . . . 27
12.2. Changes to Server Processing . . . . . . . . . . . . . . 27 12.2. Changes to Server Processing . . . . . . . . . . . . . . 27
13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 28 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 27
14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 29 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 29
14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 30 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 30
14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 31 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 31
14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 32 14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 32
14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 32 14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 32
14.5. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . . 33 14.5. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . . 33
14.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 33 14.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 33
14.7. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 35 14.7. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.8. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 35 14.8. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.9. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 35 14.9. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 35
14.10. SERVER . . . . . . . . . . . . . . . . . . . . . . . . . 36 14.10. SERVER . . . . . . . . . . . . . . . . . . . . . . . . . 36
14.11. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 36 14.11. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 36
15. Security Considerations . . . . . . . . . . . . . . . . . . . 36 15. Security Considerations . . . . . . . . . . . . . . . . . . . 36
15.1. Attacks against the Protocol . . . . . . . . . . . . . . 36 15.1. Attacks against the Protocol . . . . . . . . . . . . . . 36
15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . . 36 15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . . 36
15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . 37 15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . 37
15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . . 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.2. Attack II: Silencing a Client . . . . . . . . . . . . 38
15.2.3. Attack III: Assuming the Identity of a Client . . . . 38 15.2.3. Attack III: Assuming the Identity of a Client . . . . 38
15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 38 15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 38
15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . . 38 15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . . 39
16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 39 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 39
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . . 39 17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . . 39
17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 40 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 18. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 41
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
20.1. Normative References . . . . . . . . . . . . . . . . . . 42 20.1. Normative References . . . . . . . . . . . . . . . . . . 43
20.2. Informational 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . . . . 47
1. Introduction 1. Introduction
The protocol defined in this specification, Session Traversal The protocol defined in this specification, Session Traversal
Utilities for NAT, provides a tool for dealing with NATs. It Utilities for NAT, provides a tool for dealing with NATs. It
provides a means for an endpoint to determine the IP address and port 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 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 port. It also provides a way for an endpoint to keep a NAT binding
skipping to change at page 13, line 35 skipping to change at page 13, line 35
result in the retransmission of a request. result in the retransmission of a request.
The value for RTO SHOULD be cached by an client after the completion 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 of the transaction, and used as the starting value for RTO for the
next transaction to the same server (based on equality of IP next transaction to the same server (based on equality of IP
address). The value SHOULD be considered stale and discarded after address). The value SHOULD be considered stale and discarded after
10 minutes. 10 minutes.
Retransmissions continue until a response is received, or until a Retransmissions continue until a response is received, or until a
total of 7 requests have been sent. If, after the last request, 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 duration equal to 16 times the RTO has passed without a response
client SHOULD consider the transaction to have failed. A STUN (providing ample time to get a response if only this final request
transaction over UDP is also considered failed if there has been a actually succeeds), the client SHOULD consider the transaction to
transport failure of some sort, such as a fatal ICMP error. For have failed. A STUN transaction over UDP is also considered failed
example, assuming an RTO of 100ms, requests would be sent at times if there has been a transport failure of some sort, such as a fatal
0ms, 100ms, 300ms, 700ms, 1500ms, 3100ms, and 6300ms. If the client ICMP error. For example, assuming an RTO of 100ms, requests would be
has not received a response after 7900ms, the client will consider sent at times 0ms, 100ms, 300ms, 700ms, 1500ms, 3100ms, and 6300ms.
the transaction to have timed out. 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 7.2.2. Sending over TCP or TLS-over-TCP
For TCP and TLS-over-TCP, the client opens a TCP connection to the For TCP and TLS-over-TCP, the client opens a TCP connection to the
server. server.
In some usage of STUN, STUN is sent as the only protocol over the TCP 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 connection. In this case, it can be sent without the aid of any
additional framing or demultiplexing. In other usages, or with other additional framing or demultiplexing. In other usages, or with other
extensions, it may be multiplexed with other data over a TCP extensions, it may be multiplexed with other data over a TCP
skipping to change at page 21, line 27 skipping to change at page 21, line 27
This credential is used to form a message integrity check in each This credential is used to form a message integrity check in each
request and in many responses. There is no challenge and response as request and in many responses. There is no challenge and response as
in the long term mechanism; consequently, replay is prevented by in the long term mechanism; consequently, replay is prevented by
virtue of the time-limited nature of the credential. virtue of the time-limited nature of the credential.
10.1.1. Forming a Request or Indication 10.1.1. Forming a Request or Indication
For a request or indication message, the agent MUST include the For a request or indication message, the agent MUST include the
USERNAME and MESSAGE-INTEGRITY attributes in the message. The HMAC USERNAME and MESSAGE-INTEGRITY attributes in the message. The HMAC
for the MESSAGE-INTEGRITY attribute is computed as described in for the MESSAGE-INTEGRITY attribute is computed as described in
Section 14.4. The key for the HMAC is the password. Note that the Section 14.4. Note that the password is never included in the
password is never included in the request or indication. request or indication.
10.1.2. Receiving a Request or Indication 10.1.2. Receiving a Request or Indication
After the agent has done the basic processing of a message, the agent After the agent has done the basic processing of a message, the agent
performs the checks listed below in order specified: performs the checks listed below in order specified:
o If the message does not contain both a MESSAGE-INTEGRITY and a o If the message does not contain both a MESSAGE-INTEGRITY and a
USERNAME attribute: USERNAME attribute:
* If the message is a request, the server MUST reject the request * If the message is a request, the server MUST reject the request
skipping to change at page 23, line 36 skipping to change at page 23, line 36
the client. the client.
Note that the long-term credential mechanism cannot be used to Note that the long-term credential mechanism cannot be used to
protect indications, since indications cannot be challenged. Usages protect indications, since indications cannot be challenged. Usages
utilizing indications must either use a short-term credential, or utilizing indications must either use a short-term credential, or
omit authentication and message integrity for them. omit authentication and message integrity for them.
Since the long-term credential mechanism is susceptible to offline Since the long-term credential mechanism is susceptible to offline
dictionary attacks, deployments SHOULD utilize strong passwords. 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 10.2.1. Forming a Request
There are two cases when forming a request. In the first case, this 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 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 its IP address and port). In the second case, the client is
submitting a subsequent request once a previous request/response submitting a subsequent request once a previous request/response
transaction has completed successfully. Forming a request as a transaction has completed successfully. Forming a request as a
consequence of a 401 or 438 error response is covered in consequence of a 401 or 438 error response is covered in
Section 10.2.3 and is not considered a "subsequent request" and thus 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. does not utilize the rules described in Section 10.2.1.2.
skipping to change at page 24, line 39 skipping to change at page 24, line 22
10.2.1.2. Subsequent Requests 10.2.1.2. Subsequent Requests
Once a request/response transaction has completed successfully, the Once a request/response transaction has completed successfully, the
client will have been been presented a realm and nonce by the server, client will have been been presented a realm and nonce by the server,
and selected a username and password with which it authenticated. and selected a username and password with which it authenticated.
The client SHOULD cache the username, password, realm, and nonce for The client SHOULD cache the username, password, realm, and nonce for
subsequent communications with the server. When the client sends a subsequent communications with the server. When the client sends a
subsequent request, it SHOULD include the USERNAME, REALM, and NONCE subsequent request, it SHOULD include the USERNAME, REALM, and NONCE
attributes with these cached values. It SHOULD include a MESSAGE- attributes with these cached values. It SHOULD include a MESSAGE-
INTEGRITY attributed, computed as described in Section 14.4 using the INTEGRITY attributed, computed as described in Section 14.4 using the
cached password as the key. cached password.
10.2.2. Receiving a Request 10.2.2. Receiving a Request
After the server has done the basic processing of a request, it After the server has done the basic processing of a request, it
performs the checks listed below in the order specified: performs the checks listed below in the order specified:
o If the message does not contain a MESSAGE-INTEGRITY attribute, 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 server MUST generate an error response with an error code of 401
(Unauthorized). This response MUST include a REALM value. It is (Unauthorized). This response MUST include a REALM value. It is
RECOMMENDED that the REALM value be the domain name of the RECOMMENDED that the REALM value be the domain name of the
skipping to change at page 28, line 6 skipping to change at page 27, line 38
message, and insert a MAPPED-ADDRESS attribute instead of an XOR- message, and insert a MAPPED-ADDRESS attribute instead of an XOR-
MAPPED-ADDRESS attribute. MAPPED-ADDRESS attribute.
The client might, in rare situations, include either the RESPONSE- The client might, in rare situations, include either the RESPONSE-
ADDRESS or CHANGE-REQUEST attributes. In these situations, the ADDRESS or CHANGE-REQUEST attributes. In these situations, the
server will view these as unknown comprehension-required attributes server will view these as unknown comprehension-required attributes
and reply with an error response. Since the mechanisms utilizing and reply with an error response. Since the mechanisms utilizing
those attributes are no longer supported, this behavior is those attributes are no longer supported, this behavior is
acceptable. 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 13. STUN Usages
STUN by itself is not a solution to the NAT traversal problem. STUN by itself is not a solution to the NAT traversal problem.
Rather, STUN defines a tool that can be used inside a larger Rather, STUN defines a tool that can be used inside a larger
solution. The term "STUN Usage" is used for any solution that uses solution. The term "STUN Usage" is used for any solution that uses
STUN as a component. STUN as a component.
At the time of writing, three STUN usages are defined: Interactive At the time of writing, three STUN usages are defined: Interactive
Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice], Client- Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice], Client-
initiated connections for SIP [I-D.ietf-sip-outbound], and NAT initiated connections for SIP [I-D.ietf-sip-outbound], and NAT
skipping to change at page 29, line 21 skipping to change at page 29, line 21
bit first. bit first.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable) .... | 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 The value in the Length field MUST contain the length of the Value
part of the attribute, prior to padding, measured in bytes. Since part of the attribute, prior to padding, measured in bytes. Since
STUN aligns attributes on 32 bit boundaries, attributes whose content 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 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 so that its value contains a multiple of 4 bytes. The
padding bits are ignored, and may be any value. padding bits are ignored, and may be any value.
Any attribute type MAY appear more than once in a STUN message. Any attribute type MAY appear more than once in a STUN message.
Unless specified otherwise, the order of appearance is significant: Unless specified otherwise, the order of appearance is significant:
skipping to change at page 30, line 48 skipping to change at page 30, line 48
0 1 2 3 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 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 | |0 0 0 0 0 0 0 0| Family | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address (32 bits or 128 bits) | | 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: The address family can take on the following values:
0x01:IPv4 0x01:IPv4
0x02:IPv6 0x02:IPv6
The first 8 bits of the MAPPED-ADDRESS MUST be set to 0 and MUST be 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 ignored by receivers. These bits are present for aligning parameters
on natural 32 bit boundaries. on natural 32 bit boundaries.
This attribute is used only by servers for achieving backwards This attribute is used only by servers for achieving backwards
skipping to change at page 31, line 32 skipping to change at page 31, line 32
The format of the XOR-MAPPED-ADDRESS is: The format of the XOR-MAPPED-ADDRESS is:
0 1 2 3 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 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 x x x x x x x| Family | X-Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| X-Address (Variable) | 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 The Family represents the IP address family, and is encoded
identically to the Family in MAPPED-ADDRESS. identically to the Family in MAPPED-ADDRESS.
X-Port is computed by taking the mapped port in host byte order, 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 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 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 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 address in host byte order, XOR'ing it with the magic cookie, and
converting the result to network byte order. If the IP address converting the result to network byte order. If the IP address
skipping to change at page 32, line 36 skipping to change at page 32, line 36
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of
the STUN message. The MESSAGE-INTEGRITY attribute can be present in 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 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, 20 bytes. The text used as input to HMAC is the STUN message,
including the header, up to and including the attribute preceding the including the header, up to and including the attribute preceding the
MESSAGE-INTEGRITY attribute. With the exception of the FINGERPRINT MESSAGE-INTEGRITY attribute. With the exception of the FINGERPRINT
attribute, which appears after MESSAGE-INTEGRITY, agents MUST ignore attribute, which appears after MESSAGE-INTEGRITY, agents MUST ignore
all other attributes that follow MESSAGE-INTEGRITY. 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 Based on the rules above, the hash includes the length field from the
STUN message header. This length indicates the length of the entire STUN message header. This length indicates the length of the entire
message, including the MESSAGE-INTEGRITY attribute itself. message, including the MESSAGE-INTEGRITY attribute itself.
Consequently, the MESSAGE-INTEGRITY attribute MUST be inserted into Consequently, the MESSAGE-INTEGRITY attribute MUST be inserted into
the message (with dummy content) prior to the computation of the the message (with dummy content) prior to the computation of the
integrity check. Once the computation is performed, the value 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 attribute can be filled in. This ensures the length has the correct
value when the hash is performed. Similarly, when validating the value when the hash is performed. Similarly, when validating the
MESSAGE-INTEGRITY, the length field should be adjusted to point to MESSAGE-INTEGRITY, the length field should be adjusted to point to
skipping to change at page 35, line 50 skipping to change at page 35, line 50
represents an attribute type that was not understood by the server. represents an attribute type that was not understood by the server.
0 1 2 3 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 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 1 Type | Attribute 2 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute 3 Type | Attribute 4 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 Note: In [RFC3489], this field was padded to 32 by duplicating the
last attribute. In this version of the specification, the normal last attribute. In this version of the specification, the normal
padding rules for attributes are used instead. padding rules for attributes are used instead.
14.10. SERVER 14.10. SERVER
The server attribute contains a textual description of the software The server attribute contains a textual description of the software
being used by the server, including manufacturer and version number. being used by the server, including manufacturer and version number.
The attribute has no impact on operation of the protocol, and serves The attribute has no impact on operation of the protocol, and serves
only as a tool for diagnostic and debugging purposes. The value of only as a tool for diagnostic and debugging purposes. The value of
skipping to change at page 37, line 17 skipping to change at page 37, line 17
15.1.2. Inside Attacks 15.1.2. Inside Attacks
A rogue client may try to launch a DoS attack against a server by A rogue client may try to launch a DoS attack against a server by
sending it a large number of STUN requests. Fortunately, STUN sending it a large number of STUN requests. Fortunately, STUN
requests can be processed statelessly by a server, making such requests can be processed statelessly by a server, making such
attacks hard to launch. attacks hard to launch.
A rogue client may use a STUN server as a reflector, sending it 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 requests with a falsified source IP address and port. In such a
case, the response would be delivered to that source IP and port. case, the response would be delivered to that source IP and port.
There is no amplification with this attack, and it is mitigated by There is no amplification of the number of packets with this attack
ingress source address filtering. (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 15.2. Attacks Affecting the Usage
This section lists attacks that might be launched against a usage of This section lists attacks that might be launched against a usage of
STUN. Each STUN usage must consider whether these attacks are STUN. Each STUN usage must consider whether these attacks are
applicable to it, and if so, discuss counter-measures. applicable to it, and if so, discuss counter-measures.
Most of the attacks in this section revolve around an attacker Most of the attacks in this section revolve around an attacker
modifying the reflexive address learned by a STUN client through a modifying the reflexive address learned by a STUN client through a
Binding Request/Binding Response transaction. Since the usage of the Binding Request/Binding Response transaction. Since the usage of the
reflexive address is a function of the usage, the applicability and reflexive address is a function of the usage, the applicability and
remediation of these attacks is usage-specific. In common remediation of these attacks is usage-specific. In common
situations, modification of the reflexive address by an on-path situations, modification of the reflexive address by an on-path
attacker is easy to do. Consider, for example, the common situation attacker is easy to do. Consider, for example, the common situation
where STUN is run directly over UDP. In this case, an on-path where STUN is run directly over UDP. In this case, an on-path
attacker can modify the source IP address of the Binding Request attacker can modify the source IP address of the Binding Request
before it arrives at the STUN server. The STUN server will then before it arrives at the STUN server. The STUN server will then
return this IP address in the XOR-MAPPED-ADDRESS attribute to the return this IP address in the XOR-MAPPED-ADDRESS attribute to the
client. Protecting against this attack by using a message-integrity client, and send the response back to that (falsified) IP address and
check is impossible, since a message-integrity value cannot cover the port. If the attacker can also intercept this response, it can
source IP address, since the intervening NAT must be able to modify direct it back towards the client. Protecting against this attack by
this value. Instead, one solution to preventing the attacks listed using a message-integrity check is impossible, since a message-
below is for the client to verify the reflexive address learned, as integrity value cannot cover the source IP address, since the
is done in ICE [I-D.ietf-mmusic-ice]. Other usages may use other intervening NAT must be able to modify this value. Instead, one
means to prevent these attacks. 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 15.2.1. Attack I: DDoS Against a Target
In this attack, the attacker provides one or more clients with the In this attack, the attacker provides one or more clients with the
same faked reflexive address that points to the intended target. same faked reflexive address that points to the intended target.
This will trick the STUN clients into thinking that their reflexive This will trick the STUN clients into thinking that their reflexive
addresses are equal to that of the target. If the clients hand out addresses are equal to that of the target. If the clients hand out
that reflexive address in order to receive traffic on it (for that reflexive address in order to receive traffic on it (for
example, in SIP messages), the traffic will instead be sent to the example, in SIP messages), the traffic will instead be sent to the
target. This attack can provide substantial amplification, target. This attack can provide substantial amplification,
especially when used with clients that are using STUN to enable 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 15.2.2. Attack II: Silencing a Client
In this attack, the attacker provides a STUN client with a faked In this attack, the attacker provides a STUN client with a faked
reflexive address. The reflexive address it provides is a transport reflexive address. The reflexive address it provides is a transport
address that routes to nowhere. As a result, the client won't 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 receive any of the packets it expects to receive when it hands out
the reflexive address. This exploitation is not very interesting for the reflexive address. This exploitation is not very interesting for
the attacker. It impacts a single client, which is frequently not the attacker. It impacts a single client, which is frequently not
the desired target. Moreover, any attacker that can mount the attack the desired target. Moreover, any attacker that can mount the attack
could also deny service to the client by other means, such as could also deny service to the client by other means, such as
preventing the client from receiving any response from the STUN 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 15.2.3. Attack III: Assuming the Identity of a Client
This attack is similar to attack II. However, the faked reflexive This attack is similar to attack II. However, the faked reflexive
address points to the attacker itself. This allows the attacker to address points to the attacker itself. This allows the attacker to
receive traffic which was destined for the client. receive traffic which was destined for the client.
15.2.4. Attack IV: Eavesdropping 15.2.4. Attack IV: Eavesdropping
In this attack, the attacker forces the client to use a reflexive In this attack, the attacker forces the client to use a reflexive
skipping to change at page 38, line 44 skipping to change at page 39, line 7
the attack, the attacker must have already been able to observe the attack, the attacker must have already been able to observe
packets from the client to the STUN server. In most cases (such as 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 when the attack is launched from an access network), this means that
the attacker could already observe packets sent to the client. This the attacker could already observe packets sent to the client. This
attack is, as a result, only useful for observing traffic by attack is, as a result, only useful for observing traffic by
attackers on the path from the client to the STUN server, but not attackers on the path from the client to the STUN server, but not
generally on the path of packets being routed towards the client. generally on the path of packets being routed towards the client.
15.3. Hash Agility Plan 15.3. Hash Agility Plan
This specification uses SHA-1 for computation of the message This specification uses HMAC-SHA-1 for computation of the message
integrity. If, at a later time, SHA-1 is found to be compromised, integrity. If, at a later time, HMAC-SHA-1 is found to be
the following is the remedy that will be applied. compromised, the following is the remedy that will be applied.
We will define a STUN extension which introduces a new message We will define a STUN extension which introduces a new message
integrity attribute, computed using a new hash. Clients would be integrity attribute, computed using a new hash. Clients would be
required to include both the new and old message integrity attributes required to include both the new and old message integrity attributes
in their requests or indications. A new server will utilize the new in their requests or indications. A new server will utilize the new
message integrity attribute, and an old one, the old. After a message integrity attribute, and an old one, the old. After a
transition period where mixed implementations are in deployment, the transition period where mixed implementations are in deployment, the
old message-integrity attribute will be deprecated by another old message-integrity attribute will be deprecated by another
specification, and clients will cease including it in requests. specification, and clients will cease including it in requests.
 End of changes. 26 change blocks. 
57 lines changed or deleted 75 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/