draft-ietf-tram-stunbis-05.txt   draft-ietf-tram-stunbis-06.txt 
TRAM M. Petit-Huguenin TRAM M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Obsoletes: 5389 (if approved) G. Salgueiro Obsoletes: 5389 (if approved) G. Salgueiro
Intended status: Standards Track J. Rosenberg Intended status: Standards Track J. Rosenberg
Expires: July 29, 2016 D. Wing Expires: July 31, 2016 D. Wing
Cisco Cisco
R. Mahy R. Mahy
Plantronics Plantronics
P. Matthews P. Matthews
Avaya Avaya
January 26, 2016 January 28, 2016
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-05 draft-ietf-tram-stunbis-06
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 Network Address as a tool for other protocols in dealing with Network Address
Translator (NAT) traversal. It can be used by an endpoint to Translator (NAT) traversal. It can be used by an endpoint to
determine the IP address and port allocated to it by a NAT. It can determine the IP address and port allocated to it by a NAT. It can
also be used to check connectivity between two endpoints, and as a also be used to check connectivity between two endpoints, and as a
keep-alive protocol to maintain NAT bindings. STUN works with many keep-alive protocol to maintain NAT bindings. STUN works with many
existing NATs, and does not require any special behavior from them. existing NATs, and does not require any special behavior from them.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on July 29, 2016. This Internet-Draft will expire on July 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 9 skipping to change at page 3, line 9
9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 24 9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 24
9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 24 9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 24
9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 25 9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 25
9.2.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 26 9.2.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 26
9.2.2. Forming a Request . . . . . . . . . . . . . . . . . . 26 9.2.2. Forming a Request . . . . . . . . . . . . . . . . . . 26
9.2.2.1. First Request . . . . . . . . . . . . . . . . . . 26 9.2.2.1. First Request . . . . . . . . . . . . . . . . . . 26
9.2.2.2. Subsequent Requests . . . . . . . . . . . . . . . 27 9.2.2.2. Subsequent Requests . . . . . . . . . . . . . . . 27
9.2.3. Receiving a Request . . . . . . . . . . . . . . . . . 27 9.2.3. Receiving a Request . . . . . . . . . . . . . . . . . 27
9.2.4. Receiving a Response . . . . . . . . . . . . . . . . 29 9.2.4. Receiving a Response . . . . . . . . . . . . . . . . 29
10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 30 10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 30
11. Backwards Compatibility with RFC 5389 . . . . . . . . . . . . 31 11. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 31
12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 31 12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 31
13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 31 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 32
14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 32 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 33 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 34
14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 34 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 34
14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 35 14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 35
14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 35 14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 36
14.5. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 36 14.5. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 36
14.6. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 37 14.6. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 37
14.7. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 37 14.7. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 38
14.8. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 39 14.8. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.9. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 39 14.9. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 39
14.10. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 39 14.10. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 40
14.11. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 40 14.11. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 40
14.12. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 41 14.12. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 41
14.13. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 41 14.13. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 41
14.14. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 42 14.14. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 42
14.15. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 42 14.15. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 42
15. Security Considerations . . . . . . . . . . . . . . . . . . . 42 15. Security Considerations . . . . . . . . . . . . . . . . . . . 42
15.1. Attacks against the Protocol . . . . . . . . . . . . . . 42 15.1. Attacks against the Protocol . . . . . . . . . . . . . . 42
15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 42 15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 42
15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 43 15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 43
15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 43 15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 43
skipping to change at page 4, line 7 skipping to change at page 4, line 7
17.4. Password Algorithm Registry . . . . . . . . . . . . . . 47 17.4. Password Algorithm Registry . . . . . . . . . . . . . . 47
17.4.1. Password Algorithms . . . . . . . . . . . . . . . . 48 17.4.1. Password Algorithms . . . . . . . . . . . . . . . . 48
17.4.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 48 17.4.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 48
17.4.1.2. SHA256 . . . . . . . . . . . . . . . . . . . . . 48 17.4.1.2. SHA256 . . . . . . . . . . . . . . . . . . . . . 48
17.5. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 48 17.5. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 48
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 48 18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 48
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
19.1. Normative References . . . . . . . . . . . . . . . . . . 49 19.1. Normative References . . . . . . . . . . . . . . . . . . 49
19.2. Informational References . . . . . . . . . . . . . . . . 50 19.2. Informational References . . . . . . . . . . . . . . . . 50
Appendix A. C Snippet to Determine STUN Message Types . . . . . 52 Appendix A. C Snippet to Determine STUN Message Types . . . . . 52
Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 53 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 53
B.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 53 B.1. Sample Request with Long-Term Authentication with
B.2. Modifications between draft-ietf-tram-stunbis-05 and MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 53
draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 53 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 54
B.3. Modifications between draft-ietf-tram-stunbis-04 and C.1. Modifications between draft-ietf-tram-stunbis-06 and
draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 53 draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 54
B.4. Modifications between draft-ietf-tram-stunbis-03 and C.2. Modifications between draft-ietf-tram-stunbis-05 and
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 54 draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 55
B.5. Modifications between draft-ietf-tram-stunbis-02 and C.3. Modifications between draft-ietf-tram-stunbis-04 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 54 draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 55
B.6. Modifications between draft-ietf-tram-stunbis-01 and C.4. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 54 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 55
B.7. Modifications between draft-salgueiro-tram-stunbis-02 and C.5. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 55 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 55
B.8. Modifications between draft-salgueiro-tram-stunbis-02 and C.6. Modifications between draft-ietf-tram-stunbis-01 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 55 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 56
B.9. Modifications between draft-salgueiro-tram-stunbis-01 and C.7. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 56 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 57
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 56 C.8. Modifications between draft-salgueiro-tram-stunbis-02 and
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 56 draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 C.9. Modifications between draft-salgueiro-tram-stunbis-01 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 57
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 58
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
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 connectivity checks between two endpoints
skipping to change at page 5, line 10 skipping to change at page 5, line 15
Typically, a usage indicates when STUN messages get sent, which Typically, a usage indicates when STUN messages get sent, which
optional attributes to include, what server is used, and what optional attributes to include, what server is used, and what
authentication mechanism is to be used. Interactive Connectivity authentication mechanism is to be used. Interactive Connectivity
Establishment (ICE) [I-D.ietf-mmusic-rfc5245bis] is one usage of Establishment (ICE) [I-D.ietf-mmusic-rfc5245bis] is one usage of
STUN. SIP Outbound [RFC5626] is another usage of STUN. In some STUN. SIP Outbound [RFC5626] is another usage of STUN. In some
cases, a usage will require extensions to STUN. A STUN extension can cases, a usage will require extensions to STUN. A STUN extension can
be in the form of new methods, attributes, or error response codes. be in the form of new methods, attributes, or error response codes.
More information on STUN usages can be found in Section 13. More information on STUN usages can be found in Section 13.
Implementations and deployments of a STUN usage using TLS or DTLS Implementations and deployments of a STUN usage using TLS or DTLS
should follow the recommendations in [I-D.ietf-uta-tls-bcp]. should follow the recommendations in [RFC7525].
2. Overview of Operation 2. Overview of Operation
This section is descriptive only. This section is descriptive only.
/-----\ /-----\
// STUN \\ // STUN \\
| Server | | Server |
\\ // \\ //
\-----/ \-----/
skipping to change at page 22, line 49 skipping to change at page 22, line 49
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.
9.1.1. HMAC Key 9.1.1. HMAC Key
For short-term credentials the HMAC key is defined as follow: For short-term credentials the HMAC key is defined as follow:
key = OpaqueString(password) key = OpaqueString(password)
where the OpaqueString profile is defined in where the OpaqueString profile is defined in [RFC7613].
[I-D.ietf-precis-saslprepbis].
9.1.2. Forming a Request or Indication 9.1.2. 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, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attributes USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attributes
in the message unless the agent knows from an external indication in the message unless the agent knows from an external indication
which message integrity algorithm is supported by both agents. In which message integrity algorithm is supported by both agents. In
this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST
be included in addition to USERNAME. The HMAC for the MESSAGE- be included in addition to USERNAME. The HMAC for the MESSAGE-
INTEGRITY attribute is computed as described in Section 14.4 and the INTEGRITY attribute is computed as described in Section 14.4 and the
skipping to change at page 23, line 49 skipping to change at page 23, line 49
* If the message is an indication, the agent MUST silently * If the message is an indication, the agent MUST silently
discard the indication. discard the indication.
o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the
value for the message integrity as described in Section 14.5, value for the message integrity as described in Section 14.5,
using the password associated with the username. If the MESSAGE- using the password associated with the username. If the MESSAGE-
INTEGRITY-SHA256 attribute is not present, and using the same INTEGRITY-SHA256 attribute is not present, and using the same
password, compute the value for the message integrity as described password, compute the value for the message integrity as described
in Section 14.4. If the resulting value does not match the in Section 14.4. If the resulting value does not match the
contents of the MESSAGE-INTEGRITY-SHA256 attribute or the MESSAGE- contents of the corresponding attribute (MESSAGE-INTEGRITY-SHA256
INTEGRITY attribute: or MESSAGE-INTEGRITY):
* If the message is a request, the server MUST reject the request * If the message is a request, the server MUST reject the request
with an error response. This response MUST use an error code with an error response. This response MUST use an error code
of 401 (Unauthorized). of 401 (Unauthorized).
* If the message is an indication, the agent MUST silently * If the message is an indication, the agent MUST silently
discard the indication. discard the indication.
If these checks pass, the agent continues to process the request or If these checks pass, the agent continues to process the request or
indication. Any response generated by a server to a request that indication. Any response generated by a server to a request that
skipping to change at page 24, line 34 skipping to change at page 24, line 34
INTEGRITY-SHA256, MESSAGE-INTEGRITY, or USERNAME attribute in the INTEGRITY-SHA256, MESSAGE-INTEGRITY, or USERNAME attribute in the
error response. This is because, in these failure cases, the server error response. This is because, in these failure cases, the server
cannot determine the shared secret necessary to compute the MESSAGE- cannot determine the shared secret necessary to compute the MESSAGE-
INTEGRITY-SHA256 or MESSAGE-INTEGRITY attributes. INTEGRITY-SHA256 or MESSAGE-INTEGRITY attributes.
9.1.4. Receiving a Response 9.1.4. Receiving a Response
The client looks for the MESSAGE-INTEGRITY or the MESSAGE-INTEGRITY- The client looks for the MESSAGE-INTEGRITY or the MESSAGE-INTEGRITY-
SHA256 attribute in the response. If present, the client computes SHA256 attribute in the response. If present, the client computes
the message integrity over the response as defined in Section 14.4 or the message integrity over the response as defined in Section 14.4 or
Section 14.5, using the same password it utilized for the request. Section 14.5, respectively, using the same password it utilized for
If the resulting value matches the contents of the MESSAGE-INTEGRITY the request. If the resulting value matches the contents of the
or MESSAGE-INTEGRITY-SHA256 attribute, the response is considered MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute,
authenticated. If the value does not match, or if both MESSAGE- respectively, the response is considered authenticated. If the value
INTEGRITY and MESSAGE-INTEGRITY-SHA256 were absent, the response MUST does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-
be discarded, as if it was never received. This means that SHA256 were absent, the response MUST be discarded, as if it was
retransmits, if applicable, will continue. never received. This means that retransmits, if applicable, will
continue.
If the client only sent one algorithm in the request (because of the If the client only sent one algorithm in the request (because of the
external indication in section Section 9.2.2, or this being a external indication in section Section 9.2.2, or this being a
subsequent request as defined in Section 9.1.5) the algorithm in the subsequent request as defined in Section 9.1.5) the algorithm in the
response has to match. response has to match otherwise the response MUST be discarded.
9.1.5. Sending Subsequent Requests 9.1.5. Sending Subsequent Requests
A client sending subsequent requests to the same server MAY choose to A client sending subsequent requests to the same server MAY choose to
send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY
attribute depending upon the attribute that was received in the attribute depending upon the attribute that was received in the
response to the initial request. Here same server means same IP response to the initial request. Here same server means same IP
address and port number, not just the same URL or SRV lookup result. address and port number, not just the same URL or SRV lookup result.
9.2. Long-Term Credential Mechanism 9.2. Long-Term Credential Mechanism
skipping to change at page 26, line 13 skipping to change at page 26, line 13
they should follow best current practices around password structure. they should follow best current practices around password structure.
9.2.1. HMAC Key 9.2.1. HMAC Key
For long-term credentials that do not use a different algorithm, as For long-term credentials that do not use a different algorithm, as
specified by the PASSWORD-ALGORITHM attribute, the key is 16 bytes: specified by the PASSWORD-ALGORITHM attribute, the key is 16 bytes:
key = MD5(username ":" realm ":" OpaqueString(password)) key = MD5(username ":" realm ":" OpaqueString(password))
Where MD5 is defined in RFC 1321 [RFC1321] and the OpaqueString Where MD5 is defined in RFC 1321 [RFC1321] and the OpaqueString
profile is defined in [I-D.ietf-precis-saslprepbis]. profile is defined in [RFC7613].
The 16-byte key is formed by taking the MD5 hash of the result of 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 concatenating the following five fields: (1) the username, with any
quotes and trailing nulls removed, as taken from the USERNAME quotes and trailing nulls removed, as taken from the USERNAME
attribute (in which case OpaqueString has already been applied); (2) attribute (in which case OpaqueString has already been applied); (2)
a single colon; (3) the realm, with any quotes and trailing nulls a single colon; (3) the realm, with any quotes and trailing nulls
removed; (4) a single colon; and (5) the password, with any trailing removed; (4) a single colon; and (5) the password, with any trailing
nulls removed and after processing using OpaqueString. For example, nulls removed and after processing using OpaqueString. For example,
if the username was 'user', the realm was 'realm', and the password 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 was 'pass', then the 16-byte HMAC key would be the result of
skipping to change at page 28, line 8 skipping to change at page 28, line 8
share one will result in a wasted transaction. share one will result in a wasted transaction.
o If the message contains a MESSAGE-INTEGRITY or a MESSAGE- o If the message contains a MESSAGE-INTEGRITY or a MESSAGE-
INTEGRITY-SHA256 attribute, but is missing the USERNAME, REALM, or INTEGRITY-SHA256 attribute, but is missing the USERNAME, REALM, or
NONCE attribute, the server MUST generate an error response with NONCE attribute, the server MUST generate an error response with
an error code of 400 (Bad Request). This response SHOULD NOT an error code of 400 (Bad Request). This response SHOULD NOT
include a USERNAME, NONCE, REALM, MESSAGE-INTEGRITY or MESSAGE- include a USERNAME, NONCE, REALM, MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY-SHA256 attribute. INTEGRITY-SHA256 attribute.
o If the NONCE attribute starts with the value "obMatJos2" but o If the NONCE attribute starts with the value "obMatJos2" but
PASSWORD-ALGORITHMS does not match, then the server MUST generate PASSWORD-ALGORITHMS does not match the value sent in the response
an error response with an error code of 400 (Bad Request). that sent this NONCE, then the server MUST generate an error
response with an error code of 400 (Bad Request).
o If the NONCE attribute starts with the value "obMatJos2" but the o If the NONCE attribute starts with the value "obMatJos2" but the
request contains neither PASSWORD-ALGORITHMS nor PASSWORD- request contains neither PASSWORD-ALGORITHMS nor PASSWORD-
ALGORITHM, then the request is processed as though PASSWORD- ALGORITHM, then the request is processed as though PASSWORD-
ALGORITHM were MD5. ALGORITHM were MD5 (Note that if the original PASSWORD-ALGORITHMS
attribute did not contain MD5, this will result in a 400 Bad
Request in a later step below).
o If the NONCE attribute starts with the value "obMatJos2" but only o If the NONCE attribute starts with the value "obMatJos2" but only
one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is present, then one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is present, then
the server MUST generate an error response with an error code of the server MUST generate an error response with an error code of
400 (Bad Request). 400 (Bad Request).
o If the NONCE attribute starts with the value "obMatJos2" but o If the NONCE attribute starts with the value "obMatJos2" but
PASSWORD-ALGORITHM does not match one of the entries in PASSWORD- PASSWORD-ALGORITHM does not match one of the entries in PASSWORD-
ALGORITHMS, then the server MUST generate an error response with ALGORITHMS, then the server MUST generate an error response with
an error code of 400 (Bad Request). an error code of 400 (Bad Request).
o If the NONCE is no longer valid, the server MUST generate an error 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 response with an error code of 438 (Stale Nonce). This response
MUST include NONCE and REALM attributes and SHOULD NOT include the MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and
USERNAME, MESSAGE-INTEGRITY, or MESSAGE-INTEGRITY-SHA256 SHOULD NOT include the USERNAME, MESSAGE-INTEGRITY, or MESSAGE-
attribute. Servers can invalidate nonces in order to provide INTEGRITY-SHA256 attribute. Servers can invalidate nonces in
additional security. See Section 4.3 of [RFC2617] for guidelines. order to provide additional security. See Section 4.3 of
[RFC2617] for guidelines.
o If the username in the USERNAME attribute is not valid, the server o If the username in the USERNAME attribute is not valid, the server
MUST generate an error response with an error code of 401 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
provider of the STUN server. The response MUST include a NONCE, provider of the STUN server. The response MUST include a NONCE,
selected by the server. The response SHOULD NOT contain a selected by the server. The response MUST include a PASSWORD-
USERNAME, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute. ALGORITHMS attribute. The response SHOULD NOT contain a USERNAME,
MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute.
o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the
value for the message integrity as described in Section 14.5, value for the message integrity as described in Section 14.5,
using the password associated with the username. Else, using the using the password associated with the username. Else, using the
same password, compute the value for the message integrity as same password, compute the value for the message integrity as
described in Section 14.4. If the resulting value does not match described in Section 14.4. If the resulting value does not match
the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE- the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE-
INTEGRITY-SHA256 attribute, the server MUST reject the request INTEGRITY-SHA256 attribute, the server MUST reject the request
with an error response. This response MUST use an error code of with an error response. This response MUST use an error code of
401 (Unauthorized). It MUST include REALM and NONCE attributes 401 (Unauthorized). It MUST include REALM and NONCE attributes
and SHOULD NOT include the USERNAME, MESSAGE-INTEGRITY, or and SHOULD NOT include the USERNAME, MESSAGE-INTEGRITY, or
MESSAGE-INTEGRITY-SHA256 attribute. MESSAGE-INTEGRITY-SHA256 attribute.
For the responses sent by the steps above, the MESSAGE-INTEGRITY-
SHA256 attribute cannot be added.
If these checks pass, the server continues to process the request. If these checks pass, the server continues to process the request.
Any response generated by the server (excepting the cases where a Any response generated by the server MUST include MESSAGE-INTEGRITY-
server responds with an error code, which cannot be authenticated) SHA256 attribute, computed using the username and password utilized
MUST include MESSAGE-INTEGRITY-SHA256 attribute, computed using the to authenticate the request, unless the request was processed as
username and password utilized to authenticate the request, unless though PASSWORD-ALGORITHM was MD5 (because the request contained
the request was processed as though PASSWORD-ALGORITHM was MD5. In neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM). In that case
that case the MESSAGE-INTEGRITY attribute MUST be used instead of the the MESSAGE-INTEGRITY attribute MUST be used instead of the MESSAGE-
MESSAGE-INTEGRITY-SHA256 attribute. The REALM, NONCE, and USERNAME INTEGRITY-SHA256 attribute. The REALM, NONCE, and USERNAME
attributes SHOULD NOT be included. attributes SHOULD NOT be included.
9.2.4. Receiving a Response 9.2.4. Receiving a Response
If the response is an error response with an error code of 401 If the response is an error response with an error code of 401
(Unauthorized), the client MUST test if the NONCE attribute value (Unauthorized) or 438 (Stale Nonce), the client MUST test if the
starts with the character string "obMatJos2". If the test succeeds NONCE attribute value starts with the character string "obMatJos2".
and no PASSWORD-ALGORITHMS attribute is present, then the client MUST If the test succeeds and no PASSWORD-ALGORITHMS attribute is present,
NOT retry the request with a new transaction. then the client MUST NOT retry the request with a new transaction.
If the response is an error response with an error code of 401 If the response is an error response with an error code of 401
(Unauthorized), the client SHOULD retry the request with a new (Unauthorized), the client SHOULD retry the request with a new
transaction. This request MUST contain a USERNAME, determined by the transaction. This request MUST contain a USERNAME, determined by the
client as the appropriate username for the REALM from the error 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 REALM, copied from the error
response. The request MUST contain the NONCE, copied from the error response. The request MUST contain the NONCE, copied from the error
response. If the response contains a PASSWORD-ALGORITHMS attribute, response. If the response contains a PASSWORD-ALGORITHMS attribute,
the request MUST contain the PASSWORD-ALGORITHMS attribute with the the request MUST contain the PASSWORD-ALGORITHMS attribute with the
same content. If the response contains a PASSWORD-ALGORITHMS same content. If the response contains a PASSWORD-ALGORITHMS
skipping to change at page 31, line 9 skipping to change at page 31, line 17
client looks for an ALTERNATE-DOMAIN attribute. If the attribute is client looks for an ALTERNATE-DOMAIN attribute. If the attribute is
found, the domain MUST be used to validate the cartificate. If the found, the domain MUST be used to validate the cartificate. If the
attribute is not found, the same domain that was used for the attribute is not found, the same domain that was used for the
original request MUST be used to validate the certificate. If the original request MUST be used to validate the certificate. If the
client has been redirected to a server on which it has already tried client has been redirected to a server on which it has already tried
this request within the last five minutes, it MUST ignore the this request within the last five minutes, it MUST ignore the
redirection and consider the transaction to have failed. This redirection and consider the transaction to have failed. This
prevents infinite ping-ponging between servers in case of redirection prevents infinite ping-ponging between servers in case of redirection
loops. loops.
11. Backwards Compatibility with RFC 5389 11. Backwards Compatibility with RFC 3489
In addition to the backward compatibility already described in In addition to the backward compatibility already described in
Section 12 of [RFC5389], DTLS MUST NOT be used with RFC 3489 STUN Section 12 of [RFC5389], DTLS MUST NOT be used with RFC 3489 STUN
[RFC3489] (also referred to as "classic STUN"). Any STUN request or [RFC3489] (also referred to as "classic STUN"). Any STUN request or
indication without the magic cookie (see Section 6 of [RFC5389]) over indication without the magic cookie (see Section 6 of [RFC5389]) over
DTLS MUST always result in an error. DTLS MUST always result in an error.
12. Basic Server Behavior 12. Basic Server Behavior
This section defines the behavior of a basic, stand-alone STUN This section defines the behavior of a basic, stand-alone STUN
skipping to change at page 35, line 43 skipping to change at page 36, line 7
failure of STUN's message-integrity checking. failure of STUN's message-integrity checking.
14.3. USERNAME 14.3. USERNAME
The USERNAME attribute is used for message integrity. It identifies The USERNAME attribute is used for message integrity. It identifies
the username and password combination used in the message-integrity the username and password combination used in the message-integrity
check. check.
The value of USERNAME is a variable-length value. It MUST contain a The value of USERNAME is a variable-length value. It MUST contain a
UTF-8 [RFC3629] encoded sequence of less than 513 bytes, and MUST UTF-8 [RFC3629] encoded sequence of less than 513 bytes, and MUST
have been processed using the OpaqueString profile have been processed using the OpaqueString profile [RFC7613].
[I-D.ietf-precis-saslprepbis].
14.4. MESSAGE-INTEGRITY 14.4. MESSAGE-INTEGRITY
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 MESSAGE- MESSAGE-INTEGRITY attribute. With the exception of the MESSAGE-
INTEGRITY-SHA256 and FINGERPRINT attributes, which appear after INTEGRITY-SHA256 and FINGERPRINT attributes, which appear after
skipping to change at page 39, line 30 skipping to change at page 39, line 38
14.8. REALM 14.8. REALM
The REALM attribute may be present in requests and responses. It The REALM attribute may be present in requests and responses. It
contains text that meets the grammar for "realm-value" as described contains text that meets the grammar for "realm-value" as described
in RFC 3261 [RFC3261] but without the double quotes and their in RFC 3261 [RFC3261] but without the double quotes and their
surrounding whitespace. That is, it is an unquoted realm-value (and surrounding whitespace. That is, it is an unquoted realm-value (and
is therefore a sequence of qdtext or quoted-pair). It MUST be a is therefore a sequence of qdtext or quoted-pair). It MUST be a
UTF-8 [RFC3629] encoded sequence of less than 128 characters (which UTF-8 [RFC3629] encoded sequence of less than 128 characters (which
can be as long as 763 bytes), and MUST have been processed using the can be as long as 763 bytes), and MUST have been processed using the
OpaqueString profile [I-D.ietf-precis-saslprepbis]. OpaqueString profile [RFC7613].
Presence of the REALM attribute in a request indicates that long-term Presence of the REALM attribute in a request indicates that long-term
credentials are being used for authentication. Presence in certain credentials are being used for authentication. Presence in certain
error responses indicates that the server wishes the client to use a error responses indicates that the server wishes the client to use a
long-term credential for authentication. long-term credential for authentication.
14.9. NONCE 14.9. NONCE
The NONCE attribute may be present in requests and responses. It The NONCE attribute may be present in requests and responses. It
contains a sequence of qdtext or quoted-pair, which are defined in contains a sequence of qdtext or quoted-pair, which are defined in
skipping to change at page 47, line 9 skipping to change at page 47, line 9
17.2.1. Updated Attributes 17.2.1. Updated Attributes
IANA is requested to update the reference from RFC 5389 to RFC-to-be IANA is requested to update the reference from RFC 5389 to RFC-to-be
for the following STUN methods: for the following STUN methods:
Comprehension-required range (0x0000-0x7FFF): Comprehension-required range (0x0000-0x7FFF):
0x0000: (Reserved) 0x0000: (Reserved)
0x0001: MAPPED-ADDRESS 0x0001: MAPPED-ADDRESS
0x0002: (Reserved; was RESPONSE-ADDRESS) 0x0002: (Reserved; was RESPONSE-ADDRESS)
0x0003: (Reserved; was CHANGE-ADDRESS) 0x0003: (Reserved; was CHANGE-REQUEST)
0x0004: (Reserved; was SOURCE-ADDRESS) 0x0004: (Reserved; was SOURCE-ADDRESS)
0x0005: (Reserved; was CHANGED-ADDRESS) 0x0005: (Reserved; was CHANGED-ADDRESS)
0x0006: USERNAME 0x0006: USERNAME
0x0007: (Reserved; was PASSWORD) 0x0007: (Reserved; was PASSWORD)
0x0008: MESSAGE-INTEGRITY 0x0008: MESSAGE-INTEGRITY
0x0009: ERROR-CODE 0x0009: ERROR-CODE
0x000A: UNKNOWN-ATTRIBUTES 0x000A: UNKNOWN-ATTRIBUTES
0x000B: (Reserved; was REFLECTED-FROM) 0x000B: (Reserved; was REFLECTED-FROM)
0x0014: REALM 0x0014: REALM
0x0015: NONCE 0x0015: NONCE
skipping to change at page 48, line 26 skipping to change at page 48, line 26
17.4.1.1. MD5 17.4.1.1. MD5
This password algorithm is taken from [RFC1321]. This password algorithm is taken from [RFC1321].
The key length is 20 bytes and the parameters value is empty. The key length is 20 bytes and the parameters value is empty.
NOTE: This algorithm MUST only be used for compatibility with legacy NOTE: This algorithm MUST only be used for compatibility with legacy
systems. systems.
key = SHA256(username ":" realm ":" OpaqueString(password)) key = MD5(username ":" realm ":" OpaqueString(password))
17.4.1.2. SHA256 17.4.1.2. SHA256
This password algorithm is taken from [I-D.ietf-httpauth-digest]. This password algorithm is taken from [RFC7616].
The key length is 32 bytes and the parameters value is empty. The key length is 32 bytes and the parameters value is empty.
key = SHA256(username ":" realm ":" OpaqueString(password)) key = SHA256(username ":" realm ":" OpaqueString(password))
17.5. STUN UDP and TCP Port Numbers 17.5. STUN UDP and TCP Port Numbers
IANA is requested to update the reference from RFC 5389 to RFC-to-be IANA is requested to update the reference from RFC 5389 to RFC-to-be
for the following ports: for the following ports:
skipping to change at page 49, line 9 skipping to change at page 49, line 9
This specification obsoletes RFC 5389 [RFC5389]. This specification This specification obsoletes RFC 5389 [RFC5389]. This specification
differs from RFC 5389 in the following ways: differs from RFC 5389 in the following ways:
o o
19. References 19. References
19.1. Normative References 19.1. Normative References
[I-D.ietf-precis-saslprepbis]
Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", draft-ietf-precis-
saslprepbis-18 (work in progress), May 2015.
[ITU.V42.2002] [ITU.V42.2002]
International Telecommunications Union, "Error-correcting International Telecommunications Union, "Error-correcting
Procedures for DCEs Using Asynchronous-to-Synchronous Procedures for DCEs Using Asynchronous-to-Synchronous
Conversion", ITU-T Recommendation V.42, 2002. Conversion", ITU-T Recommendation V.42, 2002.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>. <http://www.rfc-editor.org/info/rfc791>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
skipping to change at page 50, line 42 skipping to change at page 50, line 37
[RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- [RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit-
Huguenin, "URI Scheme for the Session Traversal Utilities Huguenin, "URI Scheme for the Session Traversal Utilities
for NAT (STUN) Protocol", RFC 7064, DOI 10.17487/RFC7064, for NAT (STUN) Protocol", RFC 7064, DOI 10.17487/RFC7064,
November 2013, <http://www.rfc-editor.org/info/rfc7064>. November 2013, <http://www.rfc-editor.org/info/rfc7064>.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Session Traversal Layer Security (DTLS) as Transport for Session Traversal
Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350, Utilities for NAT (STUN)", RFC 7350, DOI 10.17487/RFC7350,
August 2014, <http://www.rfc-editor.org/info/rfc7350>. August 2014, <http://www.rfc-editor.org/info/rfc7350>.
19.2. Informational References [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 7613,
DOI 10.17487/RFC7613, August 2015,
<http://www.rfc-editor.org/info/rfc7613>.
[I-D.ietf-httpauth-digest] 19.2. Informational References
Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest
Access Authentication", draft-ietf-httpauth-digest-19
(work in progress), April 2015.
[I-D.ietf-mmusic-rfc5245bis] [I-D.ietf-mmusic-rfc5245bis]
Keranen, A. and J. Rosenberg, "Interactive Connectivity Keranen, A. and J. Rosenberg, "Interactive Connectivity
Establishment (ICE): A Protocol for Network Address Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal", draft-ietf-mmusic- Translator (NAT) Traversal", draft-ietf-mmusic-
rfc5245bis-05 (work in progress), September 2015. rfc5245bis-05 (work in progress), September 2015.
[I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-11 (work in progress), February 2015.
[KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time [KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", SIGCOMM 1987, Estimates in Reliable Transport Protocols", SIGCOMM 1987,
August 1987. August 1987.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, DOI 10.17487/RFC2616, June 1999,
<http://www.rfc-editor.org/info/rfc2616>. <http://www.rfc-editor.org/info/rfc2616>.
skipping to change at page 52, line 22 skipping to change at page 52, line 11
Initiation Protocol (SIP)", RFC 5626, Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009, DOI 10.17487/RFC5626, October 2009,
<http://www.rfc-editor.org/info/rfc5626>. <http://www.rfc-editor.org/info/rfc5626>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, Traversal Utilities for NAT (STUN)", RFC 5766,
DOI 10.17487/RFC5766, April 2010, DOI 10.17487/RFC5766, April 2010,
<http://www.rfc-editor.org/info/rfc5766>. <http://www.rfc-editor.org/info/rfc5766>.
[RFC5769] Denis-Courmont, R., "Test Vectors for Session Traversal
Utilities for NAT (STUN)", RFC 5769, DOI 10.17487/RFC5769,
April 2010, <http://www.rfc-editor.org/info/rfc5769>.
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery
Using Session Traversal Utilities for NAT (STUN)", Using Session Traversal Utilities for NAT (STUN)",
RFC 5780, DOI 10.17487/RFC5780, May 2010, RFC 5780, DOI 10.17487/RFC5780, May 2010,
<http://www.rfc-editor.org/info/rfc5780>. <http://www.rfc-editor.org/info/rfc5780>.
[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
"TCP Candidates with Interactive Connectivity "TCP Candidates with Interactive Connectivity
Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544, Establishment (ICE)", RFC 6544, DOI 10.17487/RFC6544,
March 2012, <http://www.rfc-editor.org/info/rfc6544>. March 2012, <http://www.rfc-editor.org/info/rfc6544>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
Digest Access Authentication", RFC 7616,
DOI 10.17487/RFC7616, September 2015,
<http://www.rfc-editor.org/info/rfc7616>.
Appendix A. C Snippet to Determine STUN Message Types Appendix A. C Snippet to Determine STUN Message Types
Given a 16-bit STUN message type value in host byte order in msg_type Given a 16-bit STUN message type value in host byte order in msg_type
parameter, below are C macros to determine the STUN message types: parameter, below are C macros to determine the STUN message types:
#define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000) #define IS_REQUEST(msg_type) (((msg_type) & 0x0110) == 0x0000)
#define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010) #define IS_INDICATION(msg_type) (((msg_type) & 0x0110) == 0x0010)
#define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100) #define IS_SUCCESS_RESP(msg_type) (((msg_type) & 0x0110) == 0x0100)
#define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110) #define IS_ERR_RESP(msg_type) (((msg_type) & 0x0110) == 0x0110)
skipping to change at page 53, line 18 skipping to change at page 53, line 18
return (type & 0x3E00) >> 2 | (type & 0x00E0) >> 1 return (type & 0x3E00) >> 2 | (type & 0x00E0) >> 1
| (type & 0x000F); | (type & 0x000F);
} }
A function to extract the class from the message type: A function to extract the class from the message type:
int cls(int type) { int cls(int type) {
return (type & 0x0100) >> 7 | (type & 0x0010) >> 4; return (type & 0x0100) >> 7 | (type & 0x0010) >> 4;
} }
Appendix B. Release notes Appendix B. Test Vectors
This section augments the list of test vectors defined in [RFC5769]
with MESSAGE-INTEGRITY-SHA256. All the formats and definitions
listed in Section 2 of [RFC5769] apply here.
B.1. Sample Request with Long-Term Authentication with MESSAGE-
INTEGRITY-SHA256
This request uses the following parameters:
Username: "<U+30DE><U+30C8><U+30EA><U+30C3><U+30AF><U+30B9>" (without
quotes) unaffected by OpaqueString [RFC7613] processing
Password: "The<U+00AD>M<U+00AA>tr<U+2168>" and "TheMatrIX" (without
quotes) respectively before and after OpaqueString processing
Nonce: "f//499k954d6OL34oL9FSTvy64sA" (without quotes)
Realm: "example.org" (without quotes)
00 01 00 80 Request type and message length
21 12 a4 42 Magic cookie
78 ad 34 33 }
c6 ad 72 c0 } Transaction ID
29 da 41 2e }
00 06 00 12 USERNAME attribute header
e3 83 9e e3 }
83 88 e3 83 }
aa e3 83 83 } Username value (18 bytes) and padding (2 bytes)
e3 82 af e3 }
82 b9 00 00 }
00 15 00 1c NONCE attribute header
66 2f 2f 34 }
39 39 6b 39 }
35 34 64 36 }
4f 4c 33 34 } Nonce value
6f 4c 39 46 }
53 54 76 79 }
36 34 73 41 }
00 14 00 0b REALM attribute header
65 78 61 6d }
70 6c 65 2e } Realm value (11 bytes) and padding (1 byte)
6f 72 67 00 }
XX XX 00 20 MESSAGE-INTEGRITY-SHA256 attribute header
62 fb 5e be }
ee 88 f1 0e }
30 db ce 06 }
b2 c1 2e 64 } HMAC-SHA256 fingerprint
8e fa b5 8c }
80 e1 28 75 }
79 33 84 0d }
01 43 9f ee }
NOTE: Before publication, the XX XX placeholder must be replaced by
the value assigned to MESSAGE-INTEGRITY-SHA256 by IANA.
Appendix C. Release notes
This section must be removed before publication as an RFC. This section must be removed before publication as an RFC.
B.1. Open Issues C.1. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf-
tram-stunbis-05
1. Add reference RFC 5769 (stun vectors). o Changed I-D references to RFC references.
2. Add flow diagram for long-term authenticattion. o Changed CHANGE-ADDRESS to CHANGE-REQUEST (Errata #4233).
3. Add vector for SHA256 password hash. o Added test vector for MESSAGE-INTEGRITY-SHA256.
B.2. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- o Address additional review comments from Jonathan Lennox and
Brandon Williams.
C.2. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf-
tram-stunbis-04 tram-stunbis-04
o Address review comments from Jonathan Lexnnox and Brandon o Address review comments from Jonathan Lennox and Brandon Williams.
Williams.
B.3. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- C.3. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf-
tram-stunbis-03 tram-stunbis-03
o Remove SCTP. o Remove SCTP.
o Remove DANE. o Remove DANE.
o s/MESSAGE-INTEGRITY2/MESSAGE-INTEGRITY-SHA256/ o s/MESSAGE-INTEGRITY2/MESSAGE-INTEGRITY-SHA256/
o Remove Salted SHA256 password hash. o Remove Salted SHA256 password hash.
o The RTO delay between transactions is removed. o The RTO delay between transactions is removed.
o Make clear that reusing NONCE will trigger a wasted round trip. o Make clear that reusing NONCE will trigger a wasted round trip.
B.4. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- C.4. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf-
tram-stunbis-02 tram-stunbis-02
o SCTP prefix is now 0b00000101 instead of 0x11. o SCTP prefix is now 0b00000101 instead of 0x11.
o Add SCTP at various places it was needed. o Add SCTP at various places it was needed.
o Update the hash agility plan to take in account HMAC-SHA-256. o Update the hash agility plan to take in account HMAC-SHA-256.
o Adds the bid down attack on message-integrity in the security o Adds the bid down attack on message-integrity in the security
section. section.
B.5. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- C.5. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf-
tram-stunbis-01 tram-stunbis-01
o STUN hash algorithm agility (currently only SHA-1 is allowed). o STUN hash algorithm agility (currently only SHA-1 is allowed).
o Clarify terminology, text and guidance for STUN fragmentation. o Clarify terminology, text and guidance for STUN fragmentation.
o Clarify whether it's valid to share nonces across TURN o Clarify whether it's valid to share nonces across TURN
allocations. allocations.
o Prevent the server to allocate the same NONCE to clients with o Prevent the server to allocate the same NONCE to clients with
skipping to change at page 54, line 47 skipping to change at page 56, line 21
transactions, not to serial transactions. That prevents a 3RTT transactions, not to serial transactions. That prevents a 3RTT
delay between the first transaction and the second transaction delay between the first transaction and the second transaction
with long term authentication. with long term authentication.
o Add text saying ORIGIN can increase a request size beyond the MTU o Add text saying ORIGIN can increase a request size beyond the MTU
and so require an SCTPoUDP transport. and so require an SCTPoUDP transport.
o Move the Acknowledgments and Contributor sections to the end of o Move the Acknowledgments and Contributor sections to the end of
the document, in accordance with RFC 7322 section 4. the document, in accordance with RFC 7322 section 4.
B.6. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- C.6. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf-
tram-stunbis-00 tram-stunbis-00
o Add negotiation mechanism for new password algorithms. o Add negotiation mechanism for new password algorithms.
o Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol. o Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol.
o Add support for SCTP to solve the fragmentation problem. o Add support for SCTP to solve the fragmentation problem.
o Merge RFC 7350: o Merge RFC 7350:
skipping to change at page 55, line 33 skipping to change at page 57, line 8
* DNS discovery is done from the URI. * DNS discovery is done from the URI.
* Reorganized the text about default ports. * Reorganized the text about default ports.
o Add more C snippets. o Add more C snippets.
o Make clear that the cached RTO is discarded only if there is no o Make clear that the cached RTO is discarded only if there is no
new transations for 10 minutes. new transations for 10 minutes.
B.7. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.7. Modifications between draft-salgueiro-tram-stunbis-02 and draft-
ietf-tram-stunbis-00 ietf-tram-stunbis-00
o Draft adopted as WG item. o Draft adopted as WG item.
B.8. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.8. Modifications between draft-salgueiro-tram-stunbis-02 and draft-
salgueiro-tram-stunbis-01 salgueiro-tram-stunbis-01
o Add definition of MESSAGE-INTEGRITY2. o Add definition of MESSAGE-INTEGRITY2.
o Update text and reference from RFC 2988 to RFC 6298. o Update text and reference from RFC 2988 to RFC 6298.
o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o s/The IAB has mandated/The IAB has suggested/ (Errata #3737).
o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972).
skipping to change at page 56, line 19 skipping to change at page 57, line 42
o Update text and reference from RFC 2988 to RFC 6298. o Update text and reference from RFC 2988 to RFC 6298.
o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o s/The IAB has mandated/The IAB has suggested/ (Errata #3737).
o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972).
o Fix section number and make clear that the original domain name is o Fix section number and make clear that the original domain name is
used for the server certificate verification. This is consistent used for the server certificate verification. This is consistent
with what RFC 5922 (section 4) is doing. (Errata #2010) with what RFC 5922 (section 4) is doing. (Errata #2010)
B.9. Modifications between draft-salgueiro-tram-stunbis-01 and draft- C.9. Modifications between draft-salgueiro-tram-stunbis-01 and draft-
salgueiro-tram-stunbis-00 salgueiro-tram-stunbis-00
o Restore the RFC 5389 text. o Restore the RFC 5389 text.
o Add list of open issues. o Add list of open issues.
Acknowledgements Acknowledgements
Thanks to Michael Tuexen, Tirumaleswar Reddy, Oleg Moskalenko, Simon Thanks to Michael Tuexen, Tirumaleswar Reddy, Oleg Moskalenko, Simon
Perreault, Benjamin Schwartz, Rifaat Shekh-Yusef, Alan Johnston, Perreault, Benjamin Schwartz, Rifaat Shekh-Yusef, Alan Johnston,
 End of changes. 49 change blocks. 
104 lines changed or deleted 179 lines changed or added

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