draft-ietf-tram-stunbis-07.txt   draft-ietf-tram-stunbis-08.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: November 27, 2016 D. Wing Expires: December 17, 2016 D. Wing
Cisco Cisco
R. Mahy R. Mahy
Plantronics Plantronics
P. Matthews P. Matthews
Avaya Avaya
May 26, 2016 June 15, 2016
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-07 draft-ietf-tram-stunbis-08
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 November 27, 2016. This Internet-Draft will expire on December 17, 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 4, line 9 skipping to change at page 4, line 9
17.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 50 17.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 50
17.5. Password Algorithm Registry . . . . . . . . . . . . . . 50 17.5. Password Algorithm Registry . . . . . . . . . . . . . . 50
17.5.1. Password Algorithms . . . . . . . . . . . . . . . . 51 17.5.1. Password Algorithms . . . . . . . . . . . . . . . . 51
17.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 51 17.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 51
17.5.1.2. SHA256 . . . . . . . . . . . . . . . . . . . . . 51 17.5.1.2. SHA256 . . . . . . . . . . . . . . . . . . . . . 51
17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 51 17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 51
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 51 18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 51
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
19.1. Normative References . . . . . . . . . . . . . . . . . . 52 19.1. Normative References . . . . . . . . . . . . . . . . . . 52
19.2. Informational References . . . . . . . . . . . . . . . . 53 19.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. C Snippet to Determine STUN Message Types . . . . . 55 Appendix A. C Snippet to Determine STUN Message Types . . . . . 56
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 56 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 56
B.1. Sample Request with Long-Term Authentication with B.1. Sample Request with Long-Term Authentication with
MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 56 MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 57
Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 57 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 59
C.1. Modifications between draft-ietf-tram-stunbis-07 and C.1. Modifications between draft-ietf-tram-stunbis-08 and
draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 57 draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 59
C.2. Modifications between draft-ietf-tram-stunbis-06 and C.2. Modifications between draft-ietf-tram-stunbis-07 and
draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 58 draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 59
C.3. Modifications between draft-ietf-tram-stunbis-05 and C.3. Modifications between draft-ietf-tram-stunbis-06 and
draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 58 draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 59
C.4. Modifications between draft-ietf-tram-stunbis-04 and C.4. Modifications between draft-ietf-tram-stunbis-05 and
draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 58 draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 60
C.5. Modifications between draft-ietf-tram-stunbis-03 and C.5. Modifications between draft-ietf-tram-stunbis-04 and
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 58 draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 60
C.6. Modifications between draft-ietf-tram-stunbis-02 and C.6. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 59 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 60
C.7. Modifications between draft-ietf-tram-stunbis-01 and C.7. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 59 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 60
C.8. Modifications between draft-salgueiro-tram-stunbis-02 and C.8. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 61
C.9. Modifications between draft-salgueiro-tram-stunbis-02 and C.9. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 62
C.10. Modifications between draft-salgueiro-tram-stunbis-01 and C.10. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 61 draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 62
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 61 C.11. Modifications between draft-salgueiro-tram-stunbis-01 and
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 61 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 62
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63
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 [I-D.ietf-ice-rfc5245bis],
[I-D.ietf-mmusic-rfc5245bis], or to relay packets between two or to relay packets between two endpoints [RFC5766].
endpoints [RFC5766].
In keeping with its tool nature, this specification defines an In keeping with its tool nature, this specification defines an
extensible packet format, defines operation over several transport extensible packet format, defines operation over several transport
protocols, and provides for two forms of authentication. protocols, and provides for two forms of authentication.
STUN is intended to be used in context of one or more NAT traversal STUN is intended to be used in context of one or more NAT traversal
solutions. These solutions are known as STUN usages. Each usage solutions. These solutions are known as STUN usages. Each usage
describes how STUN is utilized to achieve the NAT traversal solution. describes how STUN is utilized to achieve the NAT traversal solution.
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-ice-rfc5245bis] is one usage of STUN.
STUN. SIP Outbound [RFC5626] is another usage of STUN. In some SIP Outbound [RFC5626] is another usage of STUN. In some cases, a
cases, a usage will require extensions to STUN. A STUN extension can usage will require extensions to STUN. A STUN extension can be in
be in the form of new methods, attributes, or error response codes. the form of new methods, attributes, or error response codes. More
More information on STUN usages can be found in Section 13. 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 [RFC7525]. 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 \\
skipping to change at page 7, line 43 skipping to change at page 7, line 43
server copies that source transport address into an XOR-MAPPED- server copies that source transport address into an XOR-MAPPED-
ADDRESS attribute in the STUN Binding response and sends the Binding ADDRESS attribute in the STUN Binding response and sends the Binding
response back to the STUN client. As this packet passes back through response back to the STUN client. As this packet passes back through
a NAT, the NAT will modify the destination transport address in the a NAT, the NAT will modify the destination transport address in the
IP header, but the transport address in the XOR-MAPPED-ADDRESS IP header, but the transport address in the XOR-MAPPED-ADDRESS
attribute within the body of the STUN response will remain untouched. attribute within the body of the STUN response will remain untouched.
In this way, the client can learn its reflexive transport address In this way, the client can learn its reflexive transport address
allocated by the outermost NAT with respect to the STUN server. allocated by the outermost NAT with respect to the STUN server.
In some usages, STUN must be multiplexed with other protocols (e.g., In some usages, STUN must be multiplexed with other protocols (e.g.,
[I-D.ietf-mmusic-rfc5245bis], [RFC5626]). In these usages, there [I-D.ietf-ice-rfc5245bis], [RFC5626]). In these usages, there must
must be a way to inspect a packet and determine if it is a STUN be a way to inspect a packet and determine if it is a STUN packet or
packet or not. STUN provides three fields in the STUN header with not. STUN provides three fields in the STUN header with fixed values
fixed values that can be used for this purpose. If this is not that can be used for this purpose. If this is not sufficient, then
sufficient, then STUN packets can also contain a FINGERPRINT value, STUN packets can also contain a FINGERPRINT value, which can further
which can further be used to distinguish the packets. be used to distinguish the packets.
STUN defines a set of optional procedures that a usage can decide to STUN defines a set of optional procedures that a usage can decide to
use, called mechanisms. These mechanisms include DNS discovery, a use, called mechanisms. These mechanisms include DNS discovery, a
redirection technique to an alternate server, a fingerprint attribute redirection technique to an alternate server, a fingerprint attribute
for demultiplexing, and two authentication and message-integrity for demultiplexing, and two authentication and message-integrity
exchanges. The authentication mechanisms revolve around the use of a exchanges. The authentication mechanisms revolve around the use of a
username, password, and message-integrity value. Two authentication username, password, and message-integrity value. Two authentication
mechanisms, the long-term credential mechanism and the short-term mechanisms, the long-term credential mechanism and the short-term
credential mechanism, are defined in this specification. Each usage credential mechanism, are defined in this specification. Each usage
specifies the mechanisms allowed with that usage. specifies the mechanisms allowed with that usage.
In the long-term credential mechanism, the client and server share a In the long-term credential mechanism, the client and server share a
pre-provisioned username and password and perform a digest challenge/ pre-provisioned username and password and perform a digest challenge/
response exchange inspired by (but differing in details) to the one response exchange inspired by (but differing in details) to the one
defined for HTTP [RFC2617]. In the short-term credential mechanism, defined for HTTP [RFC2617]. In the short-term credential mechanism,
the client and the server exchange a username and password through the client and the server exchange a username and password through
some out-of-band method prior to the STUN exchange. For example, in some out-of-band method prior to the STUN exchange. For example, in
the ICE usage [I-D.ietf-mmusic-rfc5245bis] the two endpoints use out- the ICE usage [I-D.ietf-ice-rfc5245bis] the two endpoints use out-of-
of-band signaling to exchange a username and password. These are band signaling to exchange a username and password. These are used
used to integrity protect and authenticate the request and response. to integrity protect and authenticate the request and response.
There is no challenge or nonce used. There is no challenge or nonce used.
3. Terminology 3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant STUN [RFC2119] and indicate requirement levels for compliant STUN
implementations. implementations.
skipping to change at page 10, line 10 skipping to change at page 10, line 10
RTO: Retransmission TimeOut, which defines the initial period of RTO: Retransmission TimeOut, which defines the initial period of
time between transmission of a request and the first retransmit of time between transmission of a request and the first retransmit of
that request. that request.
5. STUN Message Structure 5. STUN Message Structure
STUN messages are encoded in binary using network-oriented format STUN messages are encoded in binary using network-oriented format
(most significant byte or octet first, also commonly known as big- (most significant byte or octet first, also commonly known as big-
endian). The transmission order is described in detail in Appendix B endian). The transmission order is described in detail in Appendix B
of RFC791 [RFC0791]. Unless otherwise noted, numeric constants are of RFC 791 [RFC0791]. Unless otherwise noted, numeric constants are
in decimal (base 10). in decimal (base 10).
All STUN messages MUST start with a 20-byte header followed by zero All STUN messages MUST start with a 20-byte header followed by zero
or more Attributes. The STUN header contains a STUN message type, or more Attributes. The STUN header contains a STUN message type,
magic cookie, transaction ID, and message length. magic cookie, transaction ID, and message length.
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| STUN Message Type | Message Length | |0 0| STUN Message Type | Message Length |
skipping to change at page 11, line 32 skipping to change at page 11, line 31
each method, a request, success response, error response, and each method, a request, success response, error response, and
indication are possible for that method. Extensions defining new indication are possible for that method. Extensions defining new
methods MUST indicate which classes are permitted for that method. methods MUST indicate which classes are permitted for that method.
For example, a Binding request has class=0b00 (request) and For example, a Binding request has class=0b00 (request) and
method=0b000000000001 (Binding) and is encoded into the first 16 bits method=0b000000000001 (Binding) and is encoded into the first 16 bits
as 0x0001. A Binding response has class=0b10 (success response) and as 0x0001. A Binding response has class=0b10 (success response) and
method=0b000000000001, and is encoded into the first 16 bits as method=0b000000000001, and is encoded into the first 16 bits as
0x0101. 0x0101.
NOTE: This unfortunate encoding is due to assignment of values in Note: This unfortunate encoding is due to assignment of values in
[RFC3489] that did not consider encoding Indications, Success, and [RFC3489] that did not consider encoding Indications, Success, and
Errors using bit fields. Errors using bit fields.
The magic cookie field MUST contain the fixed value 0x2112A442 in The magic cookie field MUST contain the fixed value 0x2112A442 in
network byte order. In RFC 3489 [RFC3489], this field was part of network byte order. In RFC 3489 [RFC3489], this field was part of
the transaction ID; placing the magic cookie in this location allows the transaction ID; placing the magic cookie in this location allows
a server to detect if the client will understand certain attributes a server to detect if the client will understand certain attributes
that were added in this revised specification. In addition, it aids that were added in this revised specification. In addition, it aids
in distinguishing STUN packets from packets of other protocols when in distinguishing STUN packets from packets of other protocols when
STUN is multiplexed with those other protocols on the same port. STUN is multiplexed with those other protocols on the same port.
skipping to change at page 23, line 33 skipping to change at page 23, line 33
a message, when receiving a message immediately after the basic a message, when receiving a message immediately after the basic
checks have been performed, and when doing the detailed processing of checks have been performed, and when doing the detailed processing of
error responses. error responses.
9.1. Short-Term Credential Mechanism 9.1. Short-Term Credential Mechanism
The short-term credential mechanism assumes that, prior to the STUN The short-term credential mechanism assumes that, prior to the STUN
transaction, the client and server have used some other protocol to transaction, the client and server have used some other protocol to
exchange a credential in the form of a username and password. This exchange a credential in the form of a username and password. This
credential is time-limited. The time limit is defined by the usage. credential is time-limited. The time limit is defined by the usage.
As an example, in the ICE usage [I-D.ietf-mmusic-rfc5245bis], the two As an example, in the ICE usage [I-D.ietf-ice-rfc5245bis], the two
endpoints use out-of-band signaling to agree on a username and endpoints use out-of-band signaling to agree on a username and
password, and this username and password are applicable for the password, and this username and password are applicable for the
duration of the media session. duration of the media session.
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.
9.1.1. HMAC Key 9.1.1. HMAC Key
skipping to change at page 29, line 30 skipping to change at page 29, line 30
server MAY support alternate password algorithms, in which case it server MAY support alternate password algorithms, in which case it
can list them in preferential order in a PASSWORD-ALGORITHMS can list them in preferential order in a PASSWORD-ALGORITHMS
attribute. If the server adds a PASSWORD-ALGORITHMS attribute it attribute. If the server adds a PASSWORD-ALGORITHMS attribute it
MUST prepend the NONCE attribute value with the "nonce cookie". MUST prepend the NONCE attribute value with the "nonce cookie".
The server MAY support anonymous username, in which case it can The server MAY support anonymous username, in which case it can
prepend the NONCE attribute value with the "nonce cookie" that has prepend the NONCE attribute value with the "nonce cookie" that has
the STUN Security Feature "Anonymous username" bit set to 1. The the STUN Security Feature "Anonymous username" bit set to 1. The
response SHOULD NOT contain a USERNAME, USERHASH, MESSAGE- response SHOULD NOT contain a USERNAME, USERHASH, MESSAGE-
INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute. INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute.
NOTE: Note that sharing a NONCE is no longer permitted, so trying to Note: Sharing a NONCE is no longer permitted, so trying to share one
share one will result in a wasted transaction. 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 either the USERNAME or INTEGRITY-SHA256 attribute, but is missing either the USERNAME or
USERHASH, REALM, or NONCE attribute, the server MUST generate an USERHASH, REALM, or NONCE attribute, the server MUST generate an
error response with an error code of 400 (Bad Request). This error response with an error code of 400 (Bad Request). This
response SHOULD NOT include a USERNAME, USERHASH, NONCE, REALM, response SHOULD NOT include a USERNAME, USERHASH, NONCE, REALM,
MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute. MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute.
o If the NONCE attribute starts with the "nonce cookie" with the o If the NONCE attribute starts with the "nonce cookie" with the
STUN Security Feature "Password algorithm" bit set to 1 but STUN Security Feature "Password algorithm" bit set to 1 but
skipping to change at page 38, line 14 skipping to change at page 38, line 14
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 [RFC7613]. have been processed using the OpaqueString profile [RFC7613].
14.4. USERHASH 14.4. USERHASH
The USERHASH attribute is used as a replacement for the USERNAME The USERHASH attribute is used as a replacement for the USERNAME
attribute when username anonymity is supported. attribute when username anonymity is supported.
The value of USERHASH is a variable-length value. It MUST contain a The value of USERHASH has a fixed length of 32 bytes. The username
UTF-8 [RFC3629] encoded sequence of less than 513 bytes. The MUST have been processed using the OpaqueString profile [RFC7613]
username MUST have been processed using the OpaqueString profile before hashing.
[RFC7613] before hashing.
The following is the operation that the client will perform to hash The following is the operation that the client will perform to hash
the username: the username:
userhash = SHA256(username ":" realm) userhash = SHA256(username ":" realm)
14.5. MESSAGE-INTEGRITY 14.5. 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
at most 20 bytes. The HMAC MUST NOT be truncated below a minimum at most 20 bytes. The HMAC MUST NOT be truncated below a minimum
size of XX. If truncation is employed then the HMAC size MUST be a size of 4. If truncation is employed then the HMAC size MUST be a
multiple of YY. Truncation MUST be done from the most significant multiple of XX. Truncation MUST be done from the most significant
byte to the least significant byte. STUN Usages can define their own byte to the least significant byte. STUN Usages can define their own
truncation limits, as long as they adhere to the guidelines truncation limits, as long as they adhere to the guidelines
specificed above. specificed above.
NOTE: We don't know what we're doing, we need a cryptographer to Note: We don't know what we're doing, we need a cryptographer to
weigh in on the above text. weigh in on the above text.
The text used as input to HMAC is the STUN message, including the The text used as input to HMAC is the STUN message, including the
header, up to and including the attribute preceding the MESSAGE- header, up to and including the attribute preceding the MESSAGE-
INTEGRITY attribute. With the exception of the MESSAGE-INTEGRITY- INTEGRITY attribute. With the exception of the MESSAGE-INTEGRITY-
SHA256 and FINGERPRINT attributes, which appear after MESSAGE- SHA256 and FINGERPRINT attributes, which appear after MESSAGE-
INTEGRITY, agents MUST ignore all other attributes that follow INTEGRITY, agents MUST ignore all other attributes that follow
MESSAGE-INTEGRITY. MESSAGE-INTEGRITY.
The key for the HMAC depends on which credential mechanism is in use. The key for the HMAC depends on which credential mechanism is in use.
skipping to change at page 39, line 26 skipping to change at page 39, line 24
the end of the MESSAGE-INTEGRITY attribute prior to calculating the the end of the MESSAGE-INTEGRITY attribute prior to calculating the
HMAC. Such adjustment is necessary when attributes, such as HMAC. Such adjustment is necessary when attributes, such as
FINGERPRINT, appear after MESSAGE-INTEGRITY. FINGERPRINT, appear after MESSAGE-INTEGRITY.
14.6. MESSAGE-INTEGRITY-SHA256 14.6. MESSAGE-INTEGRITY-SHA256
The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA-256 The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA-256
[RFC2104] of the STUN message. The MESSAGE-INTEGRITY-SHA256 [RFC2104] of the STUN message. The MESSAGE-INTEGRITY-SHA256
attribute can be present in any STUN message type. Since it uses the attribute can be present in any STUN message type. Since it uses the
SHA1 hash, the HMAC will be at most 32 bytes. The HMAC MUST NOT be SHA1 hash, the HMAC will be at most 32 bytes. The HMAC MUST NOT be
truncated below a minimum size of XX. If truncation is employed then truncated below a minimum size of 4. If truncation is employed then
the HMAC size MUST be a multiple of YY. Truncation MUST be done from the HMAC size MUST be a multiple of XX. Truncation MUST be done from
the most significant byte to the least significant byte. STUN Usages the most significant byte to the least significant byte. STUN Usages
can define their own truncation limits, as long as they adhere to the can define their own truncation limits, as long as they adhere to the
guidelines specificed above. guidelines specificed above.
NOTE: We don't know what we're doing, we need a cryptographer to Note: We don't know what we're doing, we need a cryptographer to
weigh in on the above text. weigh in on the above text.
The text used as input to HMAC is the STUN message, including the The text used as input to HMAC is the STUN message, including the
header, up to and including the attribute preceding the MESSAGE- header, up to and including the attribute preceding the MESSAGE-
INTEGRITY-SHA256 attribute. With the exception of the FINGERPRINT INTEGRITY-SHA256 attribute. With the exception of the FINGERPRINT
attribute, which appears after MESSAGE-INTEGRITY-SHA256, agents MUST attribute, which appears after MESSAGE-INTEGRITY-SHA256, agents MUST
ignore all other attributes that follow MESSAGE-INTEGRITY-SHA256. ignore all other attributes that follow MESSAGE-INTEGRITY-SHA256.
The key for the HMAC depends on which credential mechanism is in use. The key for the HMAC depends on which credential mechanism is in use.
Section 9.1.1 defines the key for the short-term credential mechanism Section 9.1.1 defines the key for the short-term credential mechanism
skipping to change at page 41, line 28 skipping to change at page 41, line 28
The Reserved bits SHOULD be 0, and are for alignment on 32-bit The Reserved bits SHOULD be 0, and are for alignment on 32-bit
boundaries. Receivers MUST ignore these bits. The Class represents boundaries. Receivers MUST ignore these bits. The Class represents
the hundreds digit of the error code. The value MUST be between 3 the hundreds digit of the error code. The value MUST be between 3
and 6. The Number represents the error code modulo 100, and its and 6. The Number represents the error code modulo 100, and its
value MUST be between 0 and 99. value MUST be between 0 and 99.
The following error codes, along with their recommended reason The following error codes, along with their recommended reason
phrases, are defined: phrases, are defined:
300 Try Alternate: The client should contact an alternate server for 300 Try Alternate: The client should contact an alternate server for
this request. This error response MUST only be sent if the this request. This error response MUST only be sent if the
request included either a USERNAME or USERHASH attribute and a request included either a USERNAME or USERHASH attribute and a
valid MESSAGE-INTEGRITY attribute; otherwise, it MUST NOT be sent valid MESSAGE-INTEGRITY attribute; otherwise, it MUST NOT be sent
and error code 400 (Bad Request) is suggested. This error and error code 400 (Bad Request) is suggested. This error
response MUST be protected with the MESSAGE-INTEGRITY attribute, response MUST be protected with the MESSAGE-INTEGRITY attribute,
and receivers MUST validate the MESSAGE-INTEGRITY of this response and receivers MUST validate the MESSAGE-INTEGRITY of this response
before redirecting themselves to an alternate server. before redirecting themselves to an alternate server.
NOTE: Failure to generate and validate message integrity for a 300 Note: Failure to generate and validate message integrity for a 300
response allows an on-path attacker to falsify a 300 response thus response allows an on-path attacker to falsify a 300 response thus
causing subsequent STUN messages to be sent to a victim. causing subsequent STUN messages to be sent to a victim.
400 Bad Request: The request was malformed. The client SHOULD NOT 400 Bad Request: The request was malformed. The client SHOULD NOT
retry the request without modification from the previous attempt. retry the request without modification from the previous attempt.
The server may not be able to generate a valid MESSAGE-INTEGRITY The server may not be able to generate a valid MESSAGE-INTEGRITY
for this error, so the client MUST NOT expect a valid MESSAGE- for this error, so the client MUST NOT expect a valid MESSAGE-
INTEGRITY attribute on this response. INTEGRITY attribute on this response.
401 Unauthorized: The request did not contain the correct 401 Unauthorized: The request did not contain the correct
credentials to proceed. The client should retry the request with credentials to proceed. The client should retry the request with
proper credentials. proper credentials.
420 Unknown Attribute: The server received a STUN packet containing 420 Unknown Attribute: The server received a STUN packet containing
a comprehension-required attribute that it did not understand. a comprehension-required attribute that it did not understand.
The server MUST put this unknown attribute in the UNKNOWN- The server MUST put this unknown attribute in the UNKNOWN-
ATTRIBUTE attribute of its error response. ATTRIBUTE attribute of its error response.
438 Stale Nonce: The NONCE used by the client was no longer valid. 438 Stale Nonce: The NONCE used by the client was no longer valid.
The client should retry, using the NONCE provided in the response. The client should retry, using the NONCE provided in the response.
500 Server Error: The server has suffered a temporary error. The 500 Server Error: The server has suffered a temporary error. The
client should try again. client should try again.
14.9. REALM 14.9. 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
skipping to change at page 44, line 23 skipping to change at page 44, line 23
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 10: Format of UNKNOWN-ATTRIBUTES Attribute Figure 10: 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.14. SOFTWARE 14.14. SOFTWARE
The SOFTWARE attribute contains a textual description of the software The SOFTWARE attribute contains a textual description of the software
being used by the agent sending the message. It is used by clients being used by the agent sending the message. It is used by clients
and servers. Its value SHOULD include manufacturer and version and servers. Its value SHOULD include manufacturer and version
number. The attribute has no impact on operation of the protocol, number. The attribute has no impact on operation of the protocol,
and serves only as a tool for diagnostic and debugging purposes. The and serves only as a tool for diagnostic and debugging purposes. The
skipping to change at page 47, line 6 skipping to change at page 47, line 6
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, and send the response back to that (falsified) IP address and client, and send the response back to that (falsified) IP address and
port. If the attacker can also intercept this response, it can port. If the attacker can also intercept this response, it can
direct it back towards the client. Protecting against this attack by direct it back towards the client. Protecting against this attack by
using a message-integrity check is impossible, since a message- using a message-integrity check is impossible, since a message-
integrity value cannot cover the source IP address, since the integrity value cannot cover the source IP address, since the
intervening NAT must be able to modify this value. Instead, one intervening NAT must be able to modify this value. Instead, one
solution to preventing the attacks listed below is for the client to solution to preventing the attacks listed below is for the client to
verify the reflexive address learned, as is done in ICE verify the reflexive address learned, as is done in ICE
[I-D.ietf-mmusic-rfc5245bis]. Other usages may use other means to [I-D.ietf-ice-rfc5245bis]. Other usages may use other means to
prevent these attacks. prevent these attacks.
15.2.1. Attack I: Distributed DoS (DDoS) against a Target 15.2.1. Attack I: Distributed DoS (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
skipping to change at page 48, line 42 skipping to change at page 48, line 42
The IAB has studied the problem of Unilateral Self-Address Fixing The IAB has studied the problem of Unilateral Self-Address Fixing
(UNSAF), which is the general process by which a client attempts to (UNSAF), which is the general process by which a client attempts to
determine its address in another realm on the other side of a NAT determine its address in another realm on the other side of a NAT
through a collaborative protocol reflection mechanism (RFC3424 through a collaborative protocol reflection mechanism (RFC3424
[RFC3424]). STUN can be used to perform this function using a [RFC3424]). STUN can be used to perform this function using a
Binding request/response transaction if one agent is behind a NAT and Binding request/response transaction if one agent is behind a NAT and
the other is on the public side of the NAT. the other is on the public side of the NAT.
The IAB has suggested that protocols developed for this purpose The IAB has suggested that protocols developed for this purpose
document a specific set of considerations. Because some STUN usages document a specific set of considerations. Because some STUN usages
provide UNSAF functions (such as ICE [I-D.ietf-mmusic-rfc5245bis] ), provide UNSAF functions (such as ICE [I-D.ietf-ice-rfc5245bis] ), and
and others do not (such as SIP Outbound [RFC5626]), answers to these others do not (such as SIP Outbound [RFC5626]), answers to these
considerations need to be addressed by the usages themselves. considerations need to be addressed by the usages themselves.
17. IANA Considerations 17. IANA Considerations
17.1. STUN Security Features Registry 17.1. STUN Security Features Registry
A STUN Security Feature set is a 24 bit value. A STUN Security Feature set is a 24 bit value.
IANA is requested to create a new registry containing the STUN IANA is requested to create a new registry containing the STUN
Security Features that are protected by the bid down attack Security Features that are protected by the bid down attack
prevention mechanism described in section Section 9.2.1. prevention mechanism described in section Section 9.2.1.
skipping to change at page 51, line 21 skipping to change at page 51, line 21
Expert [RFC5226]. Expert [RFC5226].
17.5.1. Password Algorithms 17.5.1. Password Algorithms
17.5.1.1. MD5 17.5.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 = MD5(username ":" realm ":" OpaqueString(password)) key = MD5(username ":" realm ":" OpaqueString(password))
17.5.1.2. SHA256 17.5.1.2. SHA256
This password algorithm is taken from [RFC7616]. 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.
skipping to change at page 51, line 48 skipping to change at page 51, line 48
stun 3478/tcp Session Traversal Utilities for NAT (STUN) port stun 3478/tcp Session Traversal Utilities for NAT (STUN) port
stun 3478/udp Session Traversal Utilities for NAT (STUN) port stun 3478/udp Session Traversal Utilities for NAT (STUN) port
stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port stuns 5349/tcp Session Traversal Utilities for NAT (STUN) port
18. Changes since RFC 5389 18. Changes since RFC 5389
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 TBD o Added support for DTLS-over-UDP (RFC 6347).
o Made clear that the RTO is considered stale if there is no
transactions with the server.
o Aligned the RTO calculation with RFC 6298.
o Updated the cipher suites for TLS.
o Added support for STUN URI (RFC 7064).
o Added support for SHA256 message integrity.
o Updated the PRECIS support to RFC 7613.
o Added protocol and registry to choose the password encryption
algorithm.
o Added support for anonymous username.
o Added protocol and registry for preventing biddown attacks.
o Sharing a NONCE is no longer permitted.
o Added the possibility of using a domain name in the alternate
server mechanism.
o Added more C snippets.
19. References 19. References
19.1. Normative References 19.1. Normative References
[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.
skipping to change at page 53, line 43 skipping to change at page 54, line 21
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>.
[RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation, [RFC7613] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 7613, Representing Usernames and Passwords", RFC 7613,
DOI 10.17487/RFC7613, August 2015, DOI 10.17487/RFC7613, August 2015,
<http://www.rfc-editor.org/info/rfc7613>. <http://www.rfc-editor.org/info/rfc7613>.
19.2. Informational References 19.2. Informative References
[I-D.ietf-mmusic-rfc5245bis] [I-D.ietf-ice-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-ice-rfc5245bis-01
rfc5245bis-05 (work in progress), September 2015. (work in progress), December 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 56, line 25 skipping to change at page 57, line 6
return (type & 0x0100) >> 7 | (type & 0x0010) >> 4; return (type & 0x0100) >> 7 | (type & 0x0010) >> 4;
} }
Appendix B. Test Vectors Appendix B. Test Vectors
This section augments the list of test vectors defined in [RFC5769] This section augments the list of test vectors defined in [RFC5769]
with MESSAGE-INTEGRITY-SHA256. All the formats and definitions with MESSAGE-INTEGRITY-SHA256. All the formats and definitions
listed in Section 2 of [RFC5769] apply here. listed in Section 2 of [RFC5769] apply here.
B.1. Sample Request with Long-Term Authentication with MESSAGE- B.1. Sample Request with Long-Term Authentication with MESSAGE-
INTEGRITY-SHA256 INTEGRITY-SHA256 and USERHASH
This request uses the following parameters: This request uses the following parameters:
Username: "<U+30DE><U+30C8><U+30EA><U+30C3><U+30AF><U+30B9>" (without Username: "<U+30DE><U+30C8><U+30EA><U+30C3><U+30AF><U+30B9>" (without
quotes) unaffected by OpaqueString [RFC7613] processing quotes) unaffected by OpaqueString [RFC7613] processing
Password: "The<U+00AD>M<U+00AA>tr<U+2168>" and "TheMatrIX" (without Password: "The<U+00AD>M<U+00AA>tr<U+2168>" and "TheMatrIX" (without
quotes) respectively before and after OpaqueString processing quotes) respectively before and after OpaqueString processing
Nonce: "f//499k954d6OL34oL9FSTvy64sA" (without quotes) Nonce: "obMatJos2AAACf//499k954d6OL34oL9FSTvy64sA" (without quotes)
Realm: "example.org" (without quotes) Realm: "example.org" (without quotes)
00 01 00 80 Request type and message length 00 01 00 9c Request type and message length
21 12 a4 42 Magic cookie 21 12 a4 42 Magic cookie
78 ad 34 33 } 78 ad 34 33 }
c6 ad 72 c0 } Transaction ID c6 ad 72 c0 } Transaction ID
29 da 41 2e } 29 da 41 2e }
00 06 00 12 USERNAME attribute header XX XX 00 20 USERHASH attribute header
e3 83 9e e3 } 4a 3c f3 8f }
83 88 e3 83 } ef 69 92 bd }
aa e3 83 83 } Username value (18 bytes) and padding (2 bytes) a9 52 c6 78 }
e3 82 af e3 } 04 17 da 0f } Userhash value (32 bytes)
82 b9 00 00 } 24 81 94 15 }
00 15 00 1c NONCE attribute header 56 9e 60 b2 }
66 2f 2f 34 } 05 c4 6e 41 }
39 39 6b 39 } 40 7f 17 04 }
35 34 64 36 } 00 15 00 29 NONCE attribute header
4f 4c 33 34 } Nonce value 6f 62 4d 61 }
6f 4c 39 46 } 74 4a 6f 73 }
53 54 76 79 } 32 41 41 41 }
36 34 73 41 } 43 66 2f 2f }
00 14 00 0b REALM attribute header 34 39 39 6b } Nonce value and padding (3 bytes)
65 78 61 6d } 39 35 34 64 }
70 6c 65 2e } Realm value (11 bytes) and padding (1 byte) 36 4f 4c 33 }
6f 72 67 00 } 34 6f 4c 39 }
XX XX 00 20 MESSAGE-INTEGRITY-SHA256 attribute header 46 53 54 76 }
62 fb 5e be } 79 36 34 73 }
ee 88 f1 0e } 41 00 00 00 }
30 db ce 06 } 00 14 00 0b REALM attribute header
b2 c1 2e 64 } HMAC-SHA256 fingerprint 65 78 61 6d }
8e fa b5 8c } 70 6c 65 2e } Realm value (11 bytes) and padding (1 byte)
80 e1 28 75 } 6f 72 67 00 }
79 33 84 0d } XX XX 00 20 MESSAGE-INTEGRITY-SHA256 attribute header
01 43 9f ee } c4 ec a2 b6 }
24 6f 26 be }
bc 2f 77 49 }
07 c2 00 a3 } HMAC-SHA256 value
76 c7 c2 8e }
b4 d1 26 60 }
bb fe 9f 28 }
0e 85 71 f2 }
NOTE: Before publication, the XX XX placeholder must be replaced by Note: Before publication, the XX XX placeholder must be replaced by
the value assigned to MESSAGE-INTEGRITY-SHA256 by IANA. the value assigned to MESSAGE-INTEGRITY-SHA256 and USERHASH by
IANA. The MESSAGE-INTEGRITY-SHA256 attribute value will need to
be updated after this.
Appendix C. Release notes Appendix C. Release notes
This section must be removed before publication as an RFC. This section must be removed before publication as an RFC.
C.1. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf- C.1. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf-
tram-stunbis-07
o Updated list of changes since RFC 5389.
o More examples are automatically generated.
o Message integrity truncation is fixed at a multiple of 4 bytes,
because the padding will not decrease by more than this.
o USERHASH contains the 32 bytes of the hash, not a character
string.
o Updated the example to use the USERHASH attribuet and the modified
NONCE attribute.
o Updated ICEbis reference.
C.2. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf-
tram-stunbis-06 tram-stunbis-06
o Add USERHASH attribute to carry the hashed version of the o Add USERHASH attribute to carry the hashed version of the
username. username.
o Add IANA registry and nonce encoding for Security Features that o Add IANA registry and nonce encoding for Security Features that
need to be protected from bid down attacks. need to be protected from bid down attacks.
o Modified MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 to support o Modified MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-SHA256 to support
truncation limits (pending cryptographic review), truncation limits (pending cryptographic review),
C.2. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf- C.3. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf-
tram-stunbis-05 tram-stunbis-05
o Changed I-D references to RFC references. o Changed I-D references to RFC references.
o Changed CHANGE-ADDRESS to CHANGE-REQUEST (Errata #4233). o Changed CHANGE-ADDRESS to CHANGE-REQUEST (Errata #4233).
o Added test vector for MESSAGE-INTEGRITY-SHA256. o Added test vector for MESSAGE-INTEGRITY-SHA256.
o Address additional review comments from Jonathan Lennox and o Address additional review comments from Jonathan Lennox and
Brandon Williams. Brandon Williams.
C.3. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- C.4. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf-
tram-stunbis-04 tram-stunbis-04
o Address review comments from Jonathan Lennox and Brandon Williams. o Address review comments from Jonathan Lennox and Brandon Williams.
C.4. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- C.5. 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.
C.5. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- C.6. 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.
C.6. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- C.7. 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 59, line 35 skipping to change at page 61, line 18
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.
C.7. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- C.8. 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 60, line 21 skipping to change at page 62, line 5
* 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.
C.8. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.9. 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.
C.9. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.10. 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).
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
skipping to change at page 61, line 9 skipping to change at page 62, line 39
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)
C.10. Modifications between draft-salgueiro-tram-stunbis-01 and draft- C.11. 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. 
126 lines changed or deleted 180 lines changed or added

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