draft-ietf-tram-stunbis-14.txt   draft-ietf-tram-stunbis-15.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 18, 2018 Cisco Expires: July 23, 2018 Cisco
D. Wing D. Wing
R. Mahy R. Mahy
Unaffiliated Unaffiliated
P. Matthews P. Matthews
Nokia Nokia
January 14, 2018 January 19, 2018
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-14 draft-ietf-tram-stunbis-15
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 42 skipping to change at page 1, line 42
This document obsoletes RFC 5389. This document obsoletes RFC 5389.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://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 18, 2018. This Internet-Draft will expire on July 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 8, line 26 skipping to change at page 8, line 26
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-ice-rfc5245bis] the two endpoints use out-of- the ICE usage [I-D.ietf-ice-rfc5245bis] the two endpoints use out-of-
band signaling to exchange a username and password. These are used band signaling to exchange a username and password. These are 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 [RFC2119] and and "OPTIONAL" are to be interpreted as described in BCP14, RFC 2119
indicate requirement levels for compliant STUN implementations. [RFC2119] and indicate requirement levels for compliant STUN
implementations.
4. Definitions 4. Definitions
STUN Agent: A STUN agent is an entity that implements the STUN STUN Agent: A STUN agent is an entity that implements the STUN
protocol. The entity can be either a STUN client or a STUN protocol. The entity can be either a STUN client or a STUN
server. server.
STUN Client: A STUN client is an entity that sends STUN requests and STUN Client: A STUN client is an entity that sends STUN requests and
receives STUN responses. A STUN client can also send indications. receives STUN responses. A STUN client can also send indications.
In this specification, the terms STUN client and client are In this specification, the terms STUN client and client are
skipping to change at page 22, line 34 skipping to change at page 22, line 34
without giving any details on what happens in the event of failure. without giving any details on what happens in the event of failure.
When following these procedures, if the STUN transaction times out When following these procedures, if the STUN transaction times out
without receipt of a response, the client SHOULD retry the request to without receipt of a response, the client SHOULD retry the request to
the next server in the ordered defined by RFC 2782. Such a retry is the next server in the ordered defined by RFC 2782. Such a retry is
only possible for request/response transmissions, since indication only possible for request/response transmissions, since indication
transactions generate no response or timeout. transactions generate no response or timeout.
In addition, instead of querying either the A or the AAAA resource In addition, instead of querying either the A or the AAAA resource
records for a domain name, the client MUST query both and try the records for a domain name, the client MUST query both and try the
requests with all the IP addresses received, as specified in requests with all the IP addresses received, as specified in
[RFC6555]. [RFC8305].
The default port for STUN requests is 3478, for both TCP and UDP. The default port for STUN requests is 3478, for both TCP and UDP.
The default port for STUN over TLS and STUN over DTLS requests is The default port for STUN over TLS and STUN over DTLS requests is
5349. Servers can run STUN over DTLS on the same port as STUN over 5349. Servers can run STUN over DTLS on the same port as STUN over
UDP if the server software supports determining whether the initial UDP if the server software supports determining whether the initial
message is a DTLS or STUN message. Servers can run STUN over TLS on message is a DTLS or STUN message. Servers can run STUN over TLS on
the same port as STUN over TCP if the server software supports the same port as STUN over TCP if the server software supports
determining whether the initial message is a TLS or STUN message. determining whether the initial message is a TLS or STUN message.
Administrators of STUN servers SHOULD use these ports in their SRV Administrators of STUN servers SHOULD use these ports in their SRV
records for UDP and TCP. In all cases, the port in DNS MUST reflect records for UDP and TCP. In all cases, the port in DNS MUST reflect
the one on which the server is listening. the one on which the server is listening.
If no SRV records were found, the client performs both an A and AAAA If no SRV records were found, the client performs both an A and AAAA
record lookup of the domain name, as described in [RFC6555]. The record lookup of the domain name, as described in [RFC8305]. The
result will be a list of IP addresses, each of which can be result will be a list of IP addresses, each of which can be
simultaneously contacted at the default port using UDP or TCP, simultaneously contacted at the default port using UDP or TCP,
independent of the STUN usage. For usages that require TLS, the independent of the STUN usage. For usages that require TLS, the
client connects to the IP addresses using the default STUN over TLS client connects to the IP addresses using the default STUN over TLS
port. For usages that require DTLS, the client connects to the IP port. For usages that require DTLS, the client connects to the IP
addresses using the default STUN over DTLS port. addresses using the default STUN over DTLS port.
9. Authentication and Message-Integrity Mechanisms 9. Authentication and Message-Integrity Mechanisms
This section defines two mechanisms for STUN that a client and server This section defines two mechanisms for STUN that a client and server
skipping to change at page 24, line 5 skipping to change at page 24, line 5
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 [RFC7613]. where the OpaqueString profile is defined in [RFC8265].
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.5 and the INTEGRITY attribute is computed as described in Section 14.5 and the
skipping to change at page 28, line 13 skipping to change at page 28, line 13
as defined in Section 17.1, is set to 1 in the "nonce cookie". as defined in Section 17.1, is set to 1 in the "nonce cookie".
9.2.2. HMAC Key 9.2.2. 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 ":" OpaqueString(realm) ":" OpaqueString(password)) key = MD5(username ":" OpaqueString(realm) ":" OpaqueString(password))
Where MD5 is defined in [RFC1321] and the OpaqueString profile is Where MD5 is defined in [RFC1321] and the OpaqueString profile is
defined in [RFC7613]. defined in [RFC8265].
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 and after processing using OpaqueString; (4) a single colon; removed and after processing using OpaqueString; (4) a single colon;
and (5) the password, with any trailing nulls removed and after and (5) the password, with any trailing nulls removed and after
processing using OpaqueString. For example, if the username was processing using OpaqueString. For example, if the username was
'user', the realm was 'realm', and the password was 'pass', then the 'user', the realm was 'realm', and the password was 'pass', then the
skipping to change at page 35, line 11 skipping to change at page 35, line 11
FINGERPRINT provides no benefit. Requiring it would break FINGERPRINT provides no benefit. Requiring it would break
compatibility with RFC 3489, and such compatibility is desirable in a compatibility with RFC 3489, and such compatibility is desirable in a
stand-alone server. Stand-alone STUN servers SHOULD support stand-alone server. Stand-alone STUN servers SHOULD support
backwards compatibility with [RFC3489] clients, as described in backwards compatibility with [RFC3489] clients, as described in
Section 11. Section 11.
It is RECOMMENDED that administrators of STUN servers provide DNS It is RECOMMENDED that administrators of STUN servers provide DNS
entries for those servers as described in Section 8. If both A and entries for those servers as described in Section 8. If both A and
AAAA Resource Records are returned then the client can simultaneously AAAA Resource Records are returned then the client can simultaneously
send STUN Binding requests to the IPv4 and IPv6 addresses (as send STUN Binding requests to the IPv4 and IPv6 addresses (as
specified in [RFC6555]), as the Binding request is idempotent. Note specified in [RFC8305]), as the Binding request is idempotent. Note
that the MAPPED-ADDRESS or XOR-MAPPED-ADDRESS attributes that are that the MAPPED-ADDRESS or XOR-MAPPED-ADDRESS attributes that are
returned will not necessarily match the address family of the server returned will not necessarily match the address family of the server
address used. address used.
A basic STUN server is not a solution for NAT traversal by itself. A basic STUN server is not a solution for NAT traversal by itself.
However, it can be utilized as part of a solution through STUN However, it can be utilized as part of a solution through STUN
usages. This is discussed further in Section 13. usages. This is discussed further in Section 13.
13. STUN Usages 13. STUN Usages
skipping to change at page 36, line 6 skipping to change at page 36, line 6
the integrity mechanism, as discussed in [RFC4107]. the integrity mechanism, as discussed in [RFC4107].
o What mechanisms are used to distinguish STUN messages from other o What mechanisms are used to distinguish STUN messages from other
messages. When STUN is run over TCP, a framing mechanism may be messages. When STUN is run over TCP, a framing mechanism may be
required. required.
o How a STUN client determines the IP address and port of the STUN o How a STUN client determines the IP address and port of the STUN
server. server.
o How simultaneous use of IPv4 and IPv6 addresses (Happy Eyeballs o How simultaneous use of IPv4 and IPv6 addresses (Happy Eyeballs
[RFC6555]) works with non-idempotent transactions when both [RFC8305]) works with non-idempotent transactions when both
address families are found for the STUN server. address families are found for the STUN server.
o Whether backwards compatibility to RFC 3489 is required. o Whether backwards compatibility to RFC 3489 is required.
o What optional attributes defined here (such as FINGERPRINT and o What optional attributes defined here (such as FINGERPRINT and
ALTERNATE-SERVER) or in other extensions are required. ALTERNATE-SERVER) or in other extensions are required.
o If MESSAGE-INTEGRITY-256 truncation is permitted, and the limits o If MESSAGE-INTEGRITY-256 truncation is permitted, and the limits
permitted for truncation. permitted for truncation.
skipping to change at page 39, line 19 skipping to change at page 39, line 19
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 [RFC7613]. have been processed using the OpaqueString profile [RFC8265].
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 has a fixed length of 32 bytes. The username The value of USERHASH has a fixed length of 32 bytes. The username
MUST have been processed using the OpaqueString profile [RFC7613] MUST have been processed using the OpaqueString profile [RFC8265]
before hashing. 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
skipping to change at page 41, line 22 skipping to change at page 41, line 22
necessary when attributes, such as FINGERPRINT, appear after MESSAGE- necessary when attributes, such as FINGERPRINT, appear after MESSAGE-
INTEGRITY-SHA256. INTEGRITY-SHA256.
14.7. FINGERPRINT 14.7. FINGERPRINT
The FINGERPRINT attribute MAY be present in all STUN messages. The The FINGERPRINT attribute MAY be present in all STUN messages. The
value of the attribute is computed as the CRC-32 of the STUN message value of the attribute is computed as the CRC-32 of the STUN message
up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with up to (but excluding) the FINGERPRINT attribute itself, XOR'ed with
the 32-bit value 0x5354554e (the XOR helps in cases where an the 32-bit value 0x5354554e (the XOR helps in cases where an
application packet is also using CRC-32 in it). The 32-bit CRC is application packet is also using CRC-32 in it). The 32-bit CRC is
the one defined in ITU V.42 [ITU.V42.1994], which has a generator the one defined in ITU V.42 [ITU.V42.2002], which has a generator
polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1.
See the sample code for the CRC-32 in Section 8 of [RFC1952]. See the sample code for the CRC-32 in Section 8 of [RFC1952].
When present, the FINGERPRINT attribute MUST be the last attribute in When present, the FINGERPRINT attribute MUST be the last attribute in
the message, and thus will appear after MESSAGE-INTEGRITY. the message, and thus will appear after MESSAGE-INTEGRITY.
The FINGERPRINT attribute can aid in distinguishing STUN packets from The FINGERPRINT attribute can aid in distinguishing STUN packets from
packets of other protocols. See Section 7. packets of other protocols. See Section 7.
As with MESSAGE-INTEGRITY, the CRC used in the FINGERPRINT attribute As with MESSAGE-INTEGRITY, the CRC used in the FINGERPRINT attribute
skipping to change at page 43, line 29 skipping to change at page 43, line 29
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 [RFC3261] but without the double quotes and their surrounding in [RFC3261] but without the double quotes and their surrounding
whitespace. That is, it is an unquoted realm-value (and is therefore whitespace. That is, it is an unquoted realm-value (and is therefore
a sequence of qdtext or quoted-pair). It MUST be a UTF-8 [RFC3629] a sequence of qdtext or quoted-pair). It MUST be a UTF-8 [RFC3629]
encoded sequence of less than 128 characters (which can be as long as encoded sequence of less than 128 characters (which can be as long as
763 bytes), and MUST have been processed using the OpaqueString 763 bytes), and MUST have been processed using the OpaqueString
profile [RFC7613]. profile [RFC8265].
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.10. NONCE 14.10. 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 53, line 23 skipping to change at page 53, line 23
transactions with the server. transactions with the server.
o Aligned the RTO calculation with RFC 6298. o Aligned the RTO calculation with RFC 6298.
o Updated the cipher suites for TLS. o Updated the cipher suites for TLS.
o Added support for STUN URI (RFC 7064). o Added support for STUN URI (RFC 7064).
o Added support for SHA256 message integrity. o Added support for SHA256 message integrity.
o Updated the PRECIS support to RFC 7613. o Updated the PRECIS support to RFC 8265.
o Added protocol and registry to choose the password encryption o Added protocol and registry to choose the password encryption
algorithm. algorithm.
o Added support for anonymous username. o Added support for anonymous username.
o Added protocol and registry for preventing biddown attacks. o Added protocol and registry for preventing biddown attacks.
o Sharing a NONCE is no longer permitted. o Sharing a NONCE is no longer permitted.
skipping to change at page 53, line 45 skipping to change at page 53, line 45
server mechanism. server mechanism.
o Added more C snippets. o Added more C snippets.
o Added test vector. o Added test vector.
19. References 19. References
19.1. Normative References 19.1. Normative References
[ITU.V42.1994] [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, 1994. 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, <https://www.rfc- DOI 10.17487/RFC0791, September 1981,
editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, <https://www.rfc- DOI 10.17487/RFC1122, October 1989,
editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992, <https://www.rfc- DOI 10.17487/RFC1321, April 1992,
editor.org/info/rfc1321>. <https://www.rfc-editor.org/info/rfc1321>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, <https://www.rfc- DOI 10.17487/RFC2104, February 1997,
editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, <https://www.rfc- DOI 10.17487/RFC2782, February 2000,
editor.org/info/rfc2782>. <https://www.rfc-editor.org/info/rfc2782>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, <https://www.rfc- DOI 10.17487/RFC5246, August 2008,
editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent,
"Computing TCP's Retransmission Timer", RFC 6298, "Computing TCP's Retransmission Timer", RFC 6298,
DOI 10.17487/RFC6298, June 2011, <https://www.rfc- DOI 10.17487/RFC6298, June 2011,
editor.org/info/rfc6298>. <https://www.rfc-editor.org/info/rfc6298>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <https://www.rfc-editor.org/info/rfc6555>.
[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, <https://www.rfc-editor.org/info/rfc7064>. November 2013, <https://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, <https://www.rfc-editor.org/info/rfc7350>. August 2014, <https://www.rfc-editor.org/info/rfc7350>.
[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, <https://www.rfc-
editor.org/info/rfc7613>.
[RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest [RFC7616] Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest
Access Authentication", RFC 7616, DOI 10.17487/RFC7616, Access Authentication", RFC 7616, DOI 10.17487/RFC7616,
September 2015, <https://www.rfc-editor.org/info/rfc7616>. September 2015, <https://www.rfc-editor.org/info/rfc7616>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 8200, STD 86, (IPv6) Specification", RFC 8200, STD 86,
DOI 10.17487/RFC8200, July 2017, <https://www.rfc- DOI 10.17487/RFC8200, July 2017,
editor.org/info/rf8200>. <https://www.rfc-editor.org/info/rf8200>.
[RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation,
Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", RFC 8265,
DOI 10.17487/RFC8265, October 2017,
<https://www.rfc-editor.org/info/rfc8265>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
19.2. Informative References 19.2. Informative References
[I-D.ietf-ice-rfc5245bis] [I-D.ietf-ice-rfc5245bis]
Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", draft-ietf-ice- Address Translator (NAT) Traversal", draft-ietf-ice-
rfc5245bis-15 (work in progress), November 2017. rfc5245bis-16 (work in progress), January 2018.
[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", August 1987. Estimates in Reliable Transport Protocols", August 1987.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", [RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, DOI 10.17487/RFC1952, May 1996, RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>. <https://www.rfc-editor.org/info/rfc1952>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002,
editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for [RFC3424] Daigle, L., Ed. and IAB, "IAB Considerations for
UNilateral Self-Address Fixing (UNSAF) Across Network UNilateral Self-Address Fixing (UNSAF) Across Network
Address Translation", RFC 3424, DOI 10.17487/RFC3424, Address Translation", RFC 3424, DOI 10.17487/RFC3424,
November 2002, <https://www.rfc-editor.org/info/rfc3424>. November 2002, <https://www.rfc-editor.org/info/rfc3424>.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
DOI 10.17487/RFC3489, March 2003, <https://www.rfc- DOI 10.17487/RFC3489, March 2003,
editor.org/info/rfc3489>. <https://www.rfc-editor.org/info/rfc3489>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <https://www.rfc-editor.org/info/rfc4107>. June 2005, <https://www.rfc-editor.org/info/rfc4107>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008, <https://www.rfc- DOI 10.17487/RFC5389, October 2008,
editor.org/info/rfc5389>. <https://www.rfc-editor.org/info/rfc5389>.
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., [RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed.,
"Managing Client-Initiated Connections in the Session "Managing Client-Initiated Connections in the Session
Initiation Protocol (SIP)", RFC 5626, Initiation Protocol (SIP)", RFC 5626,
DOI 10.17487/RFC5626, October 2009, <https://www.rfc- DOI 10.17487/RFC5626, October 2009,
editor.org/info/rfc5626>. <https://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, <https://www.rfc- DOI 10.17487/RFC5766, April 2010,
editor.org/info/rfc5766>. <https://www.rfc-editor.org/info/rfc5766>.
[RFC5769] Denis-Courmont, R., "Test Vectors for Session Traversal [RFC5769] Denis-Courmont, R., "Test Vectors for Session Traversal
Utilities for NAT (STUN)", RFC 5769, DOI 10.17487/RFC5769, Utilities for NAT (STUN)", RFC 5769, DOI 10.17487/RFC5769,
April 2010, <https://www.rfc-editor.org/info/rfc5769>. April 2010, <https://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,
<https://www.rfc-editor.org/info/rfc5780>. <https://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, <https://www.rfc-editor.org/info/rfc6544>. March 2012, <https://www.rfc-editor.org/info/rfc6544>.
[RFC7231] Fielding, R. and R. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and R. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, <https://www.rfc- DOI 10.17487/RFC7231, June 2014,
editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, May 2008, RFC 8126, DOI 10.17487/RFC8126, May 2008,
skipping to change at page 58, line 32 skipping to change at page 58, line 32
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 and USERHASH 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 [RFC8265] 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: "obMatJos2AAACf//499k954d6OL34oL9FSTvy64sA" (without quotes) Nonce: "obMatJos2AAACf//499k954d6OL34oL9FSTvy64sA" (without quotes)
Realm: "example.org" (without quotes) Realm: "example.org" (without quotes)
00 01 00 9c 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 }
 End of changes. 38 change blocks. 
61 lines changed or deleted 63 lines changed or added

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