< draft-ietf-behave-rfc3489bis-14.txt   draft-ietf-behave-rfc3489bis-15.txt >
BEHAVE Working Group J. Rosenberg BEHAVE Working Group J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 3489 (if approved) R. Mahy Obsoletes: 3489 (if approved) R. Mahy
Intended status: Standards Track Plantronics Intended status: Standards Track Plantronics
Expires: August 14, 2008 P. Matthews Expires: August 26, 2008 P. Matthews
Avaya Avaya
D. Wing D. Wing
Cisco Cisco
February 11, 2008 February 23, 2008
Session Traversal Utilities for (NAT) (STUN) Session Traversal Utilities for (NAT) (STUN)
draft-ietf-behave-rfc3489bis-14 draft-ietf-behave-rfc3489bis-15
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 39 skipping to change at page 1, line 39
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 August 14, 2008. This Internet-Draft will expire on August 26, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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 44 skipping to change at page 2, line 44
7.3.3. Processing a Success Response . . . . . . . . . . . . 19 7.3.3. Processing a Success Response . . . . . . . . . . . . 19
7.3.4. Processing an Error Response . . . . . . . . . . . . . 19 7.3.4. Processing an Error Response . . . . . . . . . . . . . 19
8. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 20 8. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 20
9. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 20 9. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 20
10. Authentication and Message-Integrity Mechanisms . . . . . . . 21 10. Authentication and Message-Integrity Mechanisms . . . . . . . 21
10.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 22 10.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 22
10.1.1. Forming a Request or Indication . . . . . . . . . . . 22 10.1.1. Forming a Request or Indication . . . . . . . . . . . 22
10.1.2. Receiving a Request or Indication . . . . . . . . . . 22 10.1.2. Receiving a Request or Indication . . . . . . . . . . 22
10.1.3. Receiving a Response . . . . . . . . . . . . . . . . . 23 10.1.3. Receiving a Response . . . . . . . . . . . . . . . . . 23
10.2. Long-term Credential Mechanism . . . . . . . . . . . . . 24 10.2. Long-term Credential Mechanism . . . . . . . . . . . . . 24
10.2.1. Forming a Request . . . . . . . . . . . . . . . . . . 24 10.2.1. Forming a Request . . . . . . . . . . . . . . . . . . 25
10.2.1.1. First Request . . . . . . . . . . . . . . . . . . 25 10.2.1.1. First Request . . . . . . . . . . . . . . . . . . 25
10.2.1.2. Subsequent Requests . . . . . . . . . . . . . . . 25 10.2.1.2. Subsequent Requests . . . . . . . . . . . . . . . 25
10.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 25 10.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 25
10.2.3. Receiving a Response . . . . . . . . . . . . . . . . . 26 10.2.3. Receiving a Response . . . . . . . . . . . . . . . . . 26
11. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . . 27 11. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . . 27
12. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 27 12. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 28
12.1. Changes to Client Processing . . . . . . . . . . . . . . 28 12.1. Changes to Client Processing . . . . . . . . . . . . . . 28
12.2. Changes to Server Processing . . . . . . . . . . . . . . 28 12.2. Changes to Server Processing . . . . . . . . . . . . . . 28
13. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 29 13. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 29
14. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 29 14. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 29
15. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 31 15. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 31
15.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 32 15.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 32
15.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 33 15.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 33
15.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 34 15.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 34
15.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 34 15.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 34
15.5. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . . 35 15.5. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . . 35
15.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 35 15.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 36
15.7. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 37 15.7. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 37
15.8. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 37 15.8. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 38
15.9. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 38 15.9. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 38
15.10. SERVER . . . . . . . . . . . . . . . . . . . . . . . . . 38 15.10. SERVER . . . . . . . . . . . . . . . . . . . . . . . . . 38
15.11. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 38 15.11. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 38
16. Security Considerations . . . . . . . . . . . . . . . . . . . 39 16. Security Considerations . . . . . . . . . . . . . . . . . . . 39
16.1. Attacks against the Protocol . . . . . . . . . . . . . . 39 16.1. Attacks against the Protocol . . . . . . . . . . . . . . 39
16.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . . 39 16.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . . 39
16.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . 39 16.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . 40
16.2. Attacks Affecting the Usage . . . . . . . . . . . . . . . 40 16.2. Attacks Affecting the Usage . . . . . . . . . . . . . . . 40
16.2.1. Attack I: DDoS Against a Target . . . . . . . . . . . 40 16.2.1. Attack I: DDoS Against a Target . . . . . . . . . . . 41
16.2.2. Attack II: Silencing a Client . . . . . . . . . . . . 41 16.2.2. Attack II: Silencing a Client . . . . . . . . . . . . 41
16.2.3. Attack III: Assuming the Identity of a Client . . . . 41 16.2.3. Attack III: Assuming the Identity of a Client . . . . 41
16.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 41 16.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 41
16.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . . 41 16.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . . 42
17. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 42 17. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 42
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
18.1. STUN Methods Registry . . . . . . . . . . . . . . . . . . 42 18.1. STUN Methods Registry . . . . . . . . . . . . . . . . . . 42
18.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 43 18.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 43
18.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 43 18.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 44
18.4. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . . 44 18.4. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . . 44
19. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 44 19. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 44
20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46 20. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46
21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 21. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 22. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
22.1. Normative References . . . . . . . . . . . . . . . . . . 46 22.1. Normative References . . . . . . . . . . . . . . . . . . 46
22.2. Informational References . . . . . . . . . . . . . . . . 47 22.2. Informational References . . . . . . . . . . . . . . . . 47
Appendix A. C Snippet to Determine STUN Message Types . . . . . . 48 Appendix A. C Snippet to Determine STUN Message Types . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Intellectual Property and Copyright Statements . . . . . . . . . . 50 Intellectual Property and Copyright Statements . . . . . . . . . . 51
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
alive. With some extensions, the protocol can be used to do alive. With some extensions, the protocol can be used to do
connectivity checks between two endpoints [I-D.ietf-mmusic-ice], or connectivity checks between two endpoints [I-D.ietf-mmusic-ice], or
skipping to change at page 13, line 5 skipping to change at page 13, line 5
defined in another document. defined in another document.
The agent then adds any attributes specified by the method or the The agent then adds any attributes specified by the method or the
usage. For example, some usages may specify that the agent use an usage. For example, some usages may specify that the agent use an
authentication method (Section 10) or the FINGERPRINT attribute authentication method (Section 10) or the FINGERPRINT attribute
(Section 8). (Section 8).
For the Binding method with no authentication, no attributes are For the Binding method with no authentication, no attributes are
required unless the usage specifies otherwise. required unless the usage specifies otherwise.
All STUN requests and responses sent over UDP MUST be less than the All STUN requests and responses sent over UDP SHOULD be less than the
path MTU, if known. If the path MTU is unknown, requests and path MTU, if known. If the path MTU is unknown, requests and
responses MUST be the smaller of 576 bytes and the first-hop MTU for responses SHOULD be the smaller of 576 bytes and the first-hop MTU
IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460]. STUN provides no for IPv4 [RFC1122] and 1280 bytes for IPv6 [RFC2460]. This value
ability to handle the case where the request is under the MTU but the corresponds to the overall size of the IP packet. Consequently, for
response would be larger than the MTU. It is not envisioned that IPv4, the actual STUN message would need to be less than 548 bytes
this limitation will be an issue for STUN. (576 minus 20 bytes IP header, minus 8 byte UDP header, assuming no
IP options are used). STUN provides no ability to handle the case
where the request is under the MTU but the response would be larger
than the MTU. It is not envisioned that this limitation will be an
issue for STUN. The MTU limitation is a SHOULD, and not a MUST, to
account for cases where STUN itself is being used to probe for MTU
characteristics [I-D.ietf-behave-nat-behavior-discovery]. Outside of
this or similar applications, the MTU constraint MUST be followed.
7.2. Sending the Request or Indication 7.2. Sending the Request or Indication
The agent then sends the request or indication. This document The agent then sends the request or indication. This document
specifies how to send STUN messages over UDP, TCP, or TLS-over-TCP; specifies how to send STUN messages over UDP, TCP, or TLS-over-TCP;
other transport protocols may be added in the future. The STUN usage other transport protocols may be added in the future. The STUN usage
must specify which transport protocol is used, and how the agent must specify which transport protocol is used, and how the agent
determines the IP address and port of the recipient. Section 9 determines the IP address and port of the recipient. Section 9
describes a DNS-based method of determining the IP address and port describes a DNS-based method of determining the IP address and port
of a server which a usage may elect to use. STUN may be used with of a server which a usage may elect to use. STUN may be used with
skipping to change at page 34, line 38 skipping to change at page 34, line 38
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 for the HMAC depends on whether long term or short term The key for the HMAC depends on whether long term or short term
credentials are in use. For long term credentials: credentials are in use. For long term credentials, the key is 16
bytes:
key = MD5(username ":" realm ":" SASLPrep(password)) key = MD5(username ":" realm ":" SASLPrep(password))
That is, the 16 byte key is formed by taking the MD5 hash of the
result of concatenating the following five fields: (1) The username,
with any quotes and trailing nulls removed, (2) A single colon, (3)
The realm, with any quotes and trailing nulls removed, (4) A single
colon, and (5) the password, with any trailing nulls removed and
after processing using SASLPrep. For example, if the username was
'user', the realm was 'realm', and the password was 'pass', then the
16-byte HMAC key would be the result of performing an MD5 hash on the
string 'user:realm:pass', the resulting hash being
0x8493fbc53ba582fb4c044c456bdc40eb.
For short term credentials: For short term credentials:
key = SASLPrep(password) key = SASLPrep(password)
Where MD5 is defined in RFC 1321 [RFC1321] and SASLPrep() is defined Where MD5 is defined in RFC 1321 [RFC1321] and SASLPrep() is defined
in [RFC4013]. in [RFC4013].
The structure of the key when used with long term credentials The structure of the key when used with long term credentials
facilitates deployment in systems that also utilize SIP. Typically, facilitates deployment in systems that also utilize SIP. Typically,
SIP systems utilizing SIP's digest authentication mechanism do not SIP systems utilizing SIP's digest authentication mechanism do not
skipping to change at page 47, line 50 skipping to change at page 48, line 13
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
[I-D.ietf-behave-turn] [I-D.ietf-behave-turn]
Rosenberg, J., "Traversal Using Relays around NAT (TURN): Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relay Extensions to Session Traversal Utilities for NAT Relays around NAT (TURN): Relay Extensions to Session
(STUN)", draft-ietf-behave-turn-04 (work in progress), Traversal Utilities for NAT (STUN)",
July 2007. draft-ietf-behave-turn-06 (work in progress),
January 2008.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-10 (work in progress), July 2007. draft-ietf-sip-outbound-11 (work in progress),
November 2007.
[I-D.ietf-behave-nat-behavior-discovery] [I-D.ietf-behave-nat-behavior-discovery]
MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using STUN", draft-ietf-behave-nat-behavior-discovery-01 Using STUN", draft-ietf-behave-nat-behavior-discovery-02
(work in progress), July 2007. (work in progress), November 2007.
[I-D.ietf-mmusic-ice-tcp] [I-D.ietf-mmusic-ice-tcp]
Rosenberg, J., "TCP Candidates with Interactive Rosenberg, J., "TCP Candidates with Interactive
Connectivity Establishment (ICE", Connectivity Establishment (ICE)",
draft-ietf-mmusic-ice-tcp-04 (work in progress), draft-ietf-mmusic-ice-tcp-05 (work in progress),
July 2007. November 2007.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
 End of changes. 22 change blocks. 
31 lines changed or deleted 52 lines changed or added

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