draft-ietf-tram-stunbis-10.txt   draft-ietf-tram-stunbis-11.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: August 20, 2017 D. Wing Expires: September 14, 2017 Cisco
Cisco D. Wing
R. Mahy R. Mahy
Plantronics Plantronics
P. Matthews P. Matthews
Avaya Avaya
February 16, 2017 March 13, 2017
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-10 draft-ietf-tram-stunbis-11
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 49
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 August 20, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. STUN Message Structure . . . . . . . . . . . . . . . . . . . 10 5. STUN Message Structure . . . . . . . . . . . . . . . . . . . 10
6. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 12 6. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 12
6.1. Forming a Request or an Indication . . . . . . . . . . . 12 6.1. Forming a Request or an Indication . . . . . . . . . . . 12
6.2. Sending the Request or Indication . . . . . . . . . . . . 13 6.2. Sending the Request or Indication . . . . . . . . . . . . 13
6.2.1. Sending over UDP or DTLS-over-UDP . . . . . . . . . . 14 6.2.1. Sending over UDP or DTLS-over-UDP . . . . . . . . . . 14
6.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . 15 6.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . 15
6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP . . . . . 16 6.2.3. Sending over TLS-over-TCP or DTLS-over-UDP . . . . . 16
skipping to change at page 2, line 52 skipping to change at page 2, line 52
8.1. STUN URI Scheme Semantics . . . . . . . . . . . . . . . . 22 8.1. STUN URI Scheme Semantics . . . . . . . . . . . . . . . . 22
9. Authentication and Message-Integrity Mechanisms . . . . . . . 23 9. Authentication and Message-Integrity Mechanisms . . . . . . . 23
9.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 23 9.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 23
9.1.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 23 9.1.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 23
9.1.2. Forming a Request or Indication . . . . . . . . . . . 24 9.1.2. Forming a Request or Indication . . . . . . . . . . . 24
9.1.3. Receiving a Request or Indication . . . . . . . . . . 24 9.1.3. Receiving a Request or Indication . . . . . . . . . . 24
9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 25 9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 25
9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 26 9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 26
9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 26 9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 26
9.2.1. Bid Down Attack Prevention . . . . . . . . . . . . . 27 9.2.1. Bid Down Attack Prevention . . . . . . . . . . . . . 27
9.2.2. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 27 9.2.2. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 28
9.2.3. Forming a Request . . . . . . . . . . . . . . . . . . 28 9.2.3. Forming a Request . . . . . . . . . . . . . . . . . . 28
9.2.3.1. First Request . . . . . . . . . . . . . . . . . . 28 9.2.3.1. First Request . . . . . . . . . . . . . . . . . . 29
9.2.3.2. Subsequent Requests . . . . . . . . . . . . . . . 29 9.2.3.2. Subsequent Requests . . . . . . . . . . . . . . . 29
9.2.4. Receiving a Request . . . . . . . . . . . . . . . . . 29 9.2.4. Receiving a Request . . . . . . . . . . . . . . . . . 29
9.2.5. Receiving a Response . . . . . . . . . . . . . . . . 31 9.2.5. Receiving a Response . . . . . . . . . . . . . . . . 31
10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 33 10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 33
11. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 34 11. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 34
12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 34 12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 34
13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 35 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 35
14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 36 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 36
14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 37 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 37
14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 37 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 37
skipping to change at page 4, line 15 skipping to change at page 4, line 15
17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 52 17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 52
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 52 18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 52
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
19.1. Normative References . . . . . . . . . . . . . . . . . . 53 19.1. Normative References . . . . . . . . . . . . . . . . . . 53
19.2. Informative References . . . . . . . . . . . . . . . . . 55 19.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. C Snippet to Determine STUN Message Types . . . . . 57 Appendix A. C Snippet to Determine STUN Message Types . . . . . 57
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 58 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 58
B.1. Sample Request with Long-Term Authentication with B.1. Sample Request with Long-Term Authentication with
MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 58 MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 58
Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 60 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 60
C.1. Modifications between draft-ietf-tram-stunbis-09 and C.1. Modifications between draft-ietf-tram-stunbis-11 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-10 . . . . . . . . . . . . . . . 60
C.2. Modifications between draft-ietf-tram-stunbis-09 and C.2. Modifications between draft-ietf-tram-stunbis-10 and
draft-ietf-tram-stunbis-09 . . . . . . . . . . . . . . . 60
C.3. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 60
C.3. Modifications between draft-ietf-tram-stunbis-08 and C.4. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 61
C.5. Modifications between draft-ietf-tram-stunbis-08 and
draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 61
C.4. Modifications between draft-ietf-tram-stunbis-07 and C.6. Modifications between draft-ietf-tram-stunbis-07 and
draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 62
C.5. Modifications between draft-ietf-tram-stunbis-06 and C.7. Modifications between draft-ietf-tram-stunbis-06 and
draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 62
C.6. Modifications between draft-ietf-tram-stunbis-05 and C.8. Modifications between draft-ietf-tram-stunbis-05 and
draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 62
C.7. Modifications between draft-ietf-tram-stunbis-04 and C.9. Modifications between draft-ietf-tram-stunbis-04 and
draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 62
C.8. Modifications between draft-ietf-tram-stunbis-03 and C.10. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 63
C.9. Modifications between draft-ietf-tram-stunbis-02 and C.11. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 63
C.10. Modifications between draft-ietf-tram-stunbis-01 and C.12. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 63
C.11. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 64 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 64
C.12. Modifications between draft-salgueiro-tram-stunbis-02 and C.13. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 64
C.14. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 64 draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 64
C.13. Modifications between draft-salgueiro-tram-stunbis-01 and C.15. Modifications between draft-salgueiro-tram-stunbis-01 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 64 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 65
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 64 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 65
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
The protocol defined in this specification, Session Traversal The protocol defined in this specification, Session Traversal
Utilities for NAT, provides a tool for dealing with NATs. It Utilities for NAT, provides a tool for dealing with NATs. It
provides a means for an endpoint to determine the IP address and port provides a means for an endpoint to determine the IP address and port
allocated by a NAT that corresponds to its private IP address and allocated by a NAT that corresponds to its private IP address and
port. It also provides a way for an endpoint to keep a NAT binding port. It also provides a way for an endpoint to keep a NAT binding
alive. With some extensions, the protocol can be used to do alive. With some extensions, the protocol can be used to do
connectivity checks between two endpoints [I-D.ietf-ice-rfc5245bis], connectivity checks between two endpoints [I-D.ietf-ice-rfc5245bis],
skipping to change at page 26, line 5 skipping to change at page 26, line 5
MUST be discarded, as if it was never received. This means that MUST be discarded, as if it was never received. This means that
retransmits, if applicable, will continue. If all the reponses retransmits, if applicable, will continue. If all the reponses
received are discarded then instead of signalling a timeout after received are discarded then instead of signalling a timeout after
ending the transaction the layer MUST signal that an attack took ending the transaction the layer MUST signal that an attack took
place. place.
If the request was sent over a reliable transport, the response MUST If the request was sent over a reliable transport, the response MUST
be discarded and the layer MUST immediately end the transaction and be discarded and the layer MUST immediately end the transaction and
signal that an attack took place. signal that an attack took place.
If the client only sent one algorithm in the request (because of the If the client only sent only one of MESSAGE-INTEGRITY or MESSAGE-
external indication in section Section 9.2.3, or this being a INTEGRITY-SHA256 attributes in the request (because of the external
subsequent request as defined in Section 9.1.5) the algorithm in the indication in section Section 9.2.3, or this being a subsequent
response has to match otherwise the response MUST be discarded. request as defined in Section 9.1.5) the algorithm in the response
has to match otherwise the response MUST be discarded.
9.1.5. Sending Subsequent Requests 9.1.5. Sending Subsequent Requests
A client sending subsequent requests to the same server MAY choose to A client sending subsequent requests to the same server MUST send
send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY attribute
attribute depending upon the attribute that was received in the that matches the attribute that was received in the response to the
response to the initial request. Here same server means same IP initial request. Here same server means same IP address and port
address and port number, not just the same URL or SRV lookup result. number, not just the same URI or SRV lookup result.
9.2. Long-Term Credential Mechanism 9.2. Long-Term Credential Mechanism
The long-term credential mechanism relies on a long-term credential, The long-term credential mechanism relies on a long-term credential,
in the form of a username and password that are shared between client in the form of a username and password that are shared between client
and server. The credential is considered long-term since it is and server. The credential is considered long-term since it is
assumed that it is provisioned for a user, and remains in effect assumed that it is provisioned for a user, and remains in effect
until the user is no longer a subscriber of the system, or is until the user is no longer a subscriber of the system, or is
changed. This is basically a traditional "log-in" username and changed. This is basically a traditional "log-in" username and
password given to users. password given to users.
skipping to change at page 27, line 7 skipping to change at page 27, line 10
nonce, username, realm, and password it used previously. In this nonce, username, realm, and password it used previously. In this
way, subsequent requests are not rejected until the nonce becomes way, subsequent requests are not rejected until the nonce becomes
invalid by the server, in which case the rejection provides a new invalid by the server, in which case the rejection provides a new
nonce to the client. nonce to the client.
Note that the long-term credential mechanism cannot be used to Note that the long-term credential mechanism cannot be used to
protect indications, since indications cannot be challenged. Usages protect indications, since indications cannot be challenged. Usages
utilizing indications must either use a short-term credential or omit utilizing indications must either use a short-term credential or omit
authentication and message integrity for them. authentication and message integrity for them.
To indicate that it supports this specification, a server MUST
prepend the NONCE attribute value with the character string composed
of "obMatJos2" concatenated with the Base64 encoding of the 24 bit
STUN Security Features as defined in Section 17.1. The 24 bit
Security Feature set is encoded as a 24 bit integer in network order.
If no security features are used, then the value 0 MUST be encoded
instead. For the remainder of this document the term "nonce cookie"
will refer to the complete 13 character string prepended to the NONCE
attribute value.
Since the long-term credential mechanism is susceptible to offline Since the long-term credential mechanism is susceptible to offline
dictionary attacks, deployments SHOULD utilize passwords that are dictionary attacks, deployments SHOULD utilize passwords that are
difficult to guess. In cases where the credentials are not entered difficult to guess. In cases where the credentials are not entered
by the user, but are rather placed on a client device during device by the user, but are rather placed on a client device during device
provisioning, the password SHOULD have at least 128 bits of provisioning, the password SHOULD have at least 128 bits of
randomness. In cases where the credentials are entered by the user, randomness. In cases where the credentials are entered by the user,
they should follow best current practices around password structure. they should follow best current practices around password structure.
9.2.1. Bid Down Attack Prevention 9.2.1. Bid Down Attack Prevention
skipping to change at page 27, line 28 skipping to change at page 27, line 41
ability to choose the algorithm used for password protection as well ability to choose the algorithm used for password protection as well
as the ability to use an anonymous username. Both of these as the ability to use an anonymous username. Both of these
capabilities are optional in order to remain backwards compatible capabilities are optional in order to remain backwards compatible
with previous versions of the STUN protocol. with previous versions of the STUN protocol.
These new capabilities are subject to bid down attacks whereby an These new capabilities are subject to bid down attacks whereby an
attacker in the message path can remove these capabilities and force attacker in the message path can remove these capabilities and force
weaker security properties. To prevent these kinds of attacks from weaker security properties. To prevent these kinds of attacks from
going undetected, the nonce is enhanced with additional information. going undetected, the nonce is enhanced with additional information.
If the server uses one of the security features subject to bid down
attack protection it MUST prepend the NONCE attribute value with the
character string composed of "obMatJos2" concatenated with the Base64
encoding of the 24 bit STUN Security Features as defined in
Section 17.1. The 24 bit Security Feature set is encoded as a 24 bit
integer in network order. For the remainder of this document the
term "nonce cookie" will refer to the complete 13 character string
prepended to the NONCE attribute value.
The value of the "nonce cookie" will vary based on the specific STUN The value of the "nonce cookie" will vary based on the specific STUN
Security Features bit values selected. When this document makes Security Features bit values selected. When this document makes
reference to the "nonce cookie" in a section discussing a specific reference to the "nonce cookie" in a section discussing a specific
STUN Security Feature it is understood that the corresponding STUN STUN Security Feature it is understood that the corresponding STUN
Security Feature bit in the "nonce cookie" is set to 1. Security Feature bit in the "nonce cookie" is set to 1.
For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS
security feature, it is implied that the "Password algorithms" bit, security feature, it is implied that the "Password algorithms" bit,
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".
skipping to change at page 29, line 38 skipping to change at page 29, line 46
INTEGRITY-SHA256 attribute, the server MUST generate an error INTEGRITY-SHA256 attribute, the server MUST generate an error
response with an error code of 401 (Unauthenticated). This response with an error code of 401 (Unauthenticated). This
response MUST include a REALM value. It is RECOMMENDED that the response MUST include a REALM value. It is RECOMMENDED that the
REALM value be the domain name of the provider of the STUN server. REALM value be the domain name of the provider of the STUN server.
The response MUST include a NONCE, selected by the server. The The response MUST include a NONCE, selected by the server. The
server MUST ensure that the same NONCE cannot be selected for server MUST ensure that the same NONCE cannot be selected for
clients that use different IP addresses and/or different ports. clients that use different IP addresses and/or different ports.
The server MAY support alternate password algorithms, in which The server MAY support alternate password algorithms, in which
case it can list them in preferential order in a PASSWORD- case it can list them in preferential order in a PASSWORD-
ALGORITHMS attribute. If the server adds a PASSWORD-ALGORITHMS ALGORITHMS attribute. If the server adds a PASSWORD-ALGORITHMS
attribute it MUST prepend the NONCE attribute value with the attribute it MUST set the STUN Security Feature "Password
"nonce cookie" that has the STUN Security Feature "Password
algorithms" bit set to 1. The server MAY support anonymous algorithms" bit set to 1. The server MAY support anonymous
username, in which case it can prepend the NONCE attribute value username, in which case it MUST set the STUN Security Feature
with the "nonce cookie" that has the STUN Security Feature
"Anonymous username" bit set to 1. The response SHOULD NOT "Anonymous username" bit set to 1. The response SHOULD NOT
contain a USERNAME, USERHASH, MESSAGE-INTEGRITY or MESSAGE- contain a USERNAME, USERHASH, MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY-SHA256 attribute. INTEGRITY-SHA256 attribute.
Note: Sharing a NONCE is no longer permitted, so trying to share one Note: Sharing a NONCE is no longer permitted, so trying to 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
skipping to change at page 31, line 30 skipping to change at page 31, line 37
using the password associated with the username. Else, using the using the password associated with the username. Else, using the
same password, compute the value for the message integrity as same password, compute the value for the message integrity as
described in Section 14.5. If the resulting value does not match described in Section 14.5. If the resulting value does not match
the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE- the contents of the MESSAGE-INTEGRITY attribute or the MESSAGE-
INTEGRITY-SHA256 attribute, the server MUST reject the request INTEGRITY-SHA256 attribute, the server MUST reject the request
with an error response. This response MUST use an error code of with an error response. This response MUST use an error code of
401 (Unauthenticated). It MUST include REALM and NONCE attributes 401 (Unauthenticated). It MUST include REALM and NONCE attributes
and SHOULD NOT include the USERNAME, USERHASH, MESSAGE-INTEGRITY, and SHOULD NOT include the USERNAME, USERHASH, MESSAGE-INTEGRITY,
or MESSAGE-INTEGRITY-SHA256 attribute. or MESSAGE-INTEGRITY-SHA256 attribute.
For the responses sent by the steps above, the MESSAGE-INTEGRITY-
SHA256 attribute cannot be added.
If these checks pass, the server continues to process the request. If these checks pass, the server continues to process the request.
Any response generated by the server MUST include MESSAGE-INTEGRITY- Any response generated by the server MUST include MESSAGE-INTEGRITY-
SHA256 attribute, computed using the username and password utilized SHA256 attribute, computed using the username and password utilized
to authenticate the request, unless the request was processed as to authenticate the request, unless the request was processed as
though PASSWORD-ALGORITHM was MD5 (because the request contained though PASSWORD-ALGORITHM was MD5 (because the request contained
neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM). In that case neither PASSWORD-ALGORITHMS nor PASSWORD-ALGORITHM). In that case
the MESSAGE-INTEGRITY attribute MUST be used instead of the MESSAGE- the MESSAGE-INTEGRITY attribute MUST be used instead of the MESSAGE-
INTEGRITY-SHA256 attribute. The REALM, NONCE, USERNAME and USERHASH INTEGRITY-SHA256 attribute. The REALM, NONCE, USERNAME and USERHASH
attributes SHOULD NOT be included. attributes SHOULD NOT be included.
skipping to change at page 40, line 14 skipping to change at page 40, line 14
MESSAGE-INTEGRITY, the length field should be adjusted to point to MESSAGE-INTEGRITY, the length field should be adjusted to point to
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 SHA256 hash, the HMAC will be at most 32 bytes. The HMAC MUST NOT be
truncated below a minimum size of 16 bytes. If truncation is truncated below a minimum size of 16 bytes. If truncation is
employed then the HMAC size MUST be a multiple of 4. Truncation MUST employed then the HMAC size MUST be a multiple of 4. Truncation MUST
be done by stripping off the final bytes. STUN Usages can define be done by stripping off the final bytes. STUN Usages can define
their own truncation limits, as long as they adhere to the guidelines their own truncation limits, as long as they adhere to the guidelines
specificed above. STUN Usages that do not define truncation limits specificed above. STUN Usages that do not define truncation limits
MUST NOT use truncation at all. MUST NOT use truncation at all.
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
skipping to change at page 60, line 9 skipping to change at page 60, line 9
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 and USERHASH by the value assigned to MESSAGE-INTEGRITY-SHA256 and USERHASH by
IANA. The MESSAGE-INTEGRITY-SHA256 attribute value will need to IANA. The MESSAGE-INTEGRITY-SHA256 attribute value will need to
be updated after this. 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-09 and draft-ietf- C.1. Modifications between draft-ietf-tram-stunbis-11 and draft-ietf-
tram-stunbis-10
o Made clear that the same HMAC than received in response of short
term credential must be used for subsequent transactions.
o s/URL/URI/
o The "nonce cookie" is now mandatory to signal that SHA256 must be
used in the next transaction.
o s/SHA1/SHA256/
o Changed co-author affiliation.
C.2. Modifications between draft-ietf-tram-stunbis-10 and draft-ietf-
tram-stunbis-09
o Removed the reserved value in the security registry, as it does
not make sense in a bitset.
o Updated change list.
o Updated the minimum trancation size for M-I-256 to 16 bytes.
o Changed the truncation order to match RFC 7518.
o Fixed bugs in truncation boundary text.
o Stated that STUN Usages have to explicitly state that they can use
truncation.
o Removed truncation from the MESSAGE-INTEGRITY attribute.
o Add reference to C code in RFC 1952.
o Replaced RFC 2818 reference to RFC 6125.
C.3. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf-
tram-stunbis-08 tram-stunbis-08
o Removed the reserved value in the security registry, as it does o Removed the reserved value in the security registry, as it does
not make sense in a bitset. not make sense in a bitset.
o Updated change list. o Updated change list.
o Updated the minimum trancation size for M-I-256 to 16 bytes. o Updated the minimum trancation size for M-I-256 to 16 bytes.
o Changed the truncation order to match RFC 7518. o Changed the truncation order to match RFC 7518.
skipping to change at page 60, line 32 skipping to change at page 61, line 22
o Stated that STUN Usages have to explicitly state that they can use o Stated that STUN Usages have to explicitly state that they can use
truncation. truncation.
o Removed truncation from the MESSAGE-INTEGRITY attrbute. o Removed truncation from the MESSAGE-INTEGRITY attrbute.
o Add reference to C code in RFC 1952. o Add reference to C code in RFC 1952.
o Replaced RFC 2818 reference to RFC 6125. o Replaced RFC 2818 reference to RFC 6125.
C.2. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf- C.4. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf-
tram-stunbis-08 tram-stunbis-08
o Packets discarded in a reliable or unreliable transaction triggers o Packets discarded in a reliable or unreliable transaction triggers
an attack error instead of a timeout error. An attack error on a an attack error instead of a timeout error. An attack error on a
reliable transport is signaled immediately instead of waiting for reliable transport is signaled immediately instead of waiting for
the timeout. the timeout.
o Explicitly state that a received 400 response without o Explicitly state that a received 400 response without
authentication will be dropped until timeout. authentication will be dropped until timeout.
skipping to change at page 61, line 4 skipping to change at page 61, line 43
o Clarify the SHOULD omit/include rules in LTCM. o Clarify the SHOULD omit/include rules in LTCM.
o If the nonce and the hmac are both invalid, then a 401 is sent o If the nonce and the hmac are both invalid, then a 401 is sent
instead of a 438. instead of a 438.
o The 401 and 438 error response to subsequent requests may use the o The 401 and 438 error response to subsequent requests may use the
previous NONCE/password to authenticate, if they are still previous NONCE/password to authenticate, if they are still
available. available.
o Change "401 Unauthorized" to "401 Unauthenticated" o Change "401 Unauthorized" to "401 Unauthenticated"
o Make clear that in some cases it is impossible to add a MI or MI2 o Make clear that in some cases it is impossible to add a MI or MI2
even if the text says SHOULD NOT. even if the text says SHOULD NOT.
C.3. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf- C.5. Modifications between draft-ietf-tram-stunbis-08 and draft-ietf-
tram-stunbis-07 tram-stunbis-07
o Updated list of changes since RFC 5389. o Updated list of changes since RFC 5389.
o More examples are automatically generated. o More examples are automatically generated.
o Message integrity truncation is fixed at a multiple of 4 bytes, o Message integrity truncation is fixed at a multiple of 4 bytes,
because the padding will not decrease by more than this. because the padding will not decrease by more than this.
o USERHASH contains the 32 bytes of the hash, not a character o USERHASH contains the 32 bytes of the hash, not a character
string. string.
o Updated the example to use the USERHASH attribuet and the modified o Updated the example to use the USERHASH attribuet and the modified
NONCE attribute. NONCE attribute.
o Updated ICEbis reference. o Updated ICEbis reference.
C.4. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf- C.6. 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.5. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf- C.7. 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.6. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- C.8. 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.7. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- C.9. 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.8. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- C.10. 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.9. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- C.11. 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
different IP address and/or different port. This prevent sharing different IP address and/or different port. This prevent sharing
skipping to change at page 63, line 18 skipping to change at page 64, line 5
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.10. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- C.12. 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 64, line 5 skipping to change at page 64, line 40
* 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.11. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.13. 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.12. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.14. Modifications between draft-salgueiro-tram-stunbis-02 and draft-
salgueiro-tram-stunbis-01 salgueiro-tram-stunbis-01
o Add definition of MESSAGE-INTEGRITY2. o Add definition of MESSAGE-INTEGRITY2.
o Update text and reference from RFC 2988 to RFC 6298. o Update text and reference from RFC 2988 to RFC 6298.
o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o s/The IAB has mandated/The IAB has suggested/ (Errata #3737).
o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972).
skipping to change at page 64, line 39 skipping to change at page 65, line 25
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.13. Modifications between draft-salgueiro-tram-stunbis-01 and draft- C.15. 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,
Jonathan Lennox, Brandon Williams, Olle Johansson, and Martin Thomson Jonathan Lennox, Brandon Williams, Olle Johansson, Martin Thomson,
for the comments, suggestions, and questions that helped improve this and Mihaly Meszaros for the comments, suggestions, and questions that
document. helped improve this document.
The authors of RFC 5389 would like to thank Cedric Aoun, Pete The authors of RFC 5389 would like to thank Cedric Aoun, Pete
Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus
Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for
their comments, and Baruch Sterman and Alan Hawrylyshen for initial their comments, and Baruch Sterman and Alan Hawrylyshen for initial
implementations. Thanks for Leslie Daigle, Allison Mankin, Eric implementations. Thanks for Leslie Daigle, Allison Mankin, Eric
Rescorla, and Henning Schulzrinne for IESG and IAB input on this Rescorla, and Henning Schulzrinne for IESG and IAB input on this
work. work.
Contributors Contributors
skipping to change at page 65, line 42 skipping to change at page 66, line 29
Jonathan Rosenberg Jonathan Rosenberg
Cisco Cisco
Edison, NJ Edison, NJ
US US
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Dan Wing Dan Wing
Cisco
771 Alder Drive
San Jose, CA 95035
US
Email: dwing@cisco.com Email: dwing-ietf@fuggles.com
Rohan Mahy Rohan Mahy
Plantronics Plantronics
345 Encinal Street 345 Encinal Street
Santa Cruz, CA 95060 Santa Cruz, CA 95060
US US
Email: rohan@ekabal.com Email: rohan@ekabal.com
Philip Matthews Philip Matthews
Avaya Avaya
 End of changes. 41 change blocks. 
80 lines changed or deleted 117 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/