draft-ietf-tram-stunbis-08.txt   draft-ietf-tram-stunbis-09.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: December 17, 2016 D. Wing Expires: June 17, 2017 D. Wing
Cisco Cisco
R. Mahy R. Mahy
Plantronics Plantronics
P. Matthews P. Matthews
Avaya Avaya
June 15, 2016 December 14, 2016
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-08 draft-ietf-tram-stunbis-09
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 December 17, 2016. This Internet-Draft will expire on June 17, 2017.
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 2, line 49 skipping to change at page 2, line 49
6.3.4. Processing an Error Response . . . . . . . . . . . . 20 6.3.4. Processing an Error Response . . . . . . . . . . . . 20
7. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 21 7. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 21
8. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 21 8. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . . . . . 27
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 . . . . . . . . . . . . . . . . . . 28
9.2.3.2. Subsequent Requests . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . . . . . 32 10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 33
11. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 33 11. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 34
12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 33 12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 34
13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 34 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 35
14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 35 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 36
14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 36 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 37
14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 36 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 37
14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 37 14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 38
14.4. USERHASH . . . . . . . . . . . . . . . . . . . . . . . . 38 14.4. USERHASH . . . . . . . . . . . . . . . . . . . . . . . . 39
14.5. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 38 14.5. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 39
14.6. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 39 14.6. MESSAGE-INTEGRITY-SHA256 . . . . . . . . . . . . . . . . 40
14.7. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 40 14.7. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 41
14.8. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 40 14.8. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 41
14.9. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 42 14.9. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 43
14.10. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 42 14.10. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 43
14.11. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 42 14.11. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 43
14.12. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 43 14.12. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 44
14.13. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 44 14.13. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 45
14.14. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 44 14.14. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 45
14.15. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 44 14.15. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 45
14.16. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 44 14.16. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 45
15. Security Considerations . . . . . . . . . . . . . . . . . . . 45 15. Security Considerations . . . . . . . . . . . . . . . . . . . 46
15.1. Attacks against the Protocol . . . . . . . . . . . . . . 45 15.1. Attacks against the Protocol . . . . . . . . . . . . . . 46
15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 45 15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 46
15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 46 15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 47
15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 46 15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 47
15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 47 15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 48
15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 47 15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 48
15.2.3. Attack III: Assuming the Identity of a Client . . . 47 15.2.3. Attack III: Assuming the Identity of a Client . . . 48
15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 47 15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 48
15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 48 15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 49
16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 48 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 49
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
17.1. STUN Security Features Registry . . . . . . . . . . . . 49 17.1. STUN Security Features Registry . . . . . . . . . . . . 50
17.2. STUN Methods Registry . . . . . . . . . . . . . . . . . 49 17.2. STUN Methods Registry . . . . . . . . . . . . . . . . . 50
17.3. STUN Attribute Registry . . . . . . . . . . . . . . . . 49 17.3. STUN Attribute Registry . . . . . . . . . . . . . . . . 50
17.3.1. Updated Attributes . . . . . . . . . . . . . . . . . 49 17.3.1. Updated Attributes . . . . . . . . . . . . . . . . . 50
17.3.2. New Attributes . . . . . . . . . . . . . . . . . . . 50 17.3.2. New Attributes . . . . . . . . . . . . . . . . . . . 51
17.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 50 17.4. STUN Error Code Registry . . . . . . . . . . . . . . . . 51
17.5. Password Algorithm Registry . . . . . . . . . . . . . . 50 17.5. Password Algorithm Registry . . . . . . . . . . . . . . 51
17.5.1. Password Algorithms . . . . . . . . . . . . . . . . 51 17.5.1. Password Algorithms . . . . . . . . . . . . . . . . 52
17.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 51 17.5.1.1. MD5 . . . . . . . . . . . . . . . . . . . . . . 52
17.5.1.2. SHA256 . . . . . . . . . . . . . . . . . . . . . 51 17.5.1.2. SHA256 . . . . . . . . . . . . . . . . . . . . . 52
17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 51 17.6. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 52
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 51 18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 52
19. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
19.1. Normative References . . . . . . . . . . . . . . . . . . 52 19.1. Normative References . . . . . . . . . . . . . . . . . . 53
19.2. Informative References . . . . . . . . . . . . . . . . . 54 19.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. C Snippet to Determine STUN Message Types . . . . . 56 Appendix A. C Snippet to Determine STUN Message Types . . . . . 57
Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 56 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 57
B.1. Sample Request with Long-Term Authentication with B.1. Sample Request with Long-Term Authentication with
MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 57 MESSAGE-INTEGRITY-SHA256 and USERHASH . . . . . . . . . . 58
Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 59 Appendix C. Release notes . . . . . . . . . . . . . . . . . . . 60
C.1. Modifications between draft-ietf-tram-stunbis-08 and C.1. Modifications between draft-ietf-tram-stunbis-09 and
draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 59 draft-ietf-tram-stunbis-08 . . . . . . . . . . . . . . . 60
C.2. Modifications between draft-ietf-tram-stunbis-07 and C.2. Modifications between draft-ietf-tram-stunbis-08 and
draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 59 draft-ietf-tram-stunbis-07 . . . . . . . . . . . . . . . 60
C.3. Modifications between draft-ietf-tram-stunbis-06 and C.3. Modifications between draft-ietf-tram-stunbis-07 and
draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 59 draft-ietf-tram-stunbis-06 . . . . . . . . . . . . . . . 60
C.4. Modifications between draft-ietf-tram-stunbis-05 and C.4. Modifications between draft-ietf-tram-stunbis-06 and
draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-05 . . . . . . . . . . . . . . . 61
C.5. Modifications between draft-ietf-tram-stunbis-04 and C.5. Modifications between draft-ietf-tram-stunbis-05 and
draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-04 . . . . . . . . . . . . . . . 61
C.6. Modifications between draft-ietf-tram-stunbis-03 and C.6. Modifications between draft-ietf-tram-stunbis-04 and
draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-03 . . . . . . . . . . . . . . . 61
C.7. Modifications between draft-ietf-tram-stunbis-02 and C.7. Modifications between draft-ietf-tram-stunbis-03 and
draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 60 draft-ietf-tram-stunbis-02 . . . . . . . . . . . . . . . 61
C.8. Modifications between draft-ietf-tram-stunbis-01 and C.8. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 61 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 62
C.9. Modifications between draft-salgueiro-tram-stunbis-02 and C.9. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 62
C.10. Modifications between draft-salgueiro-tram-stunbis-02 and C.10. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 62 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 63
C.11. Modifications between draft-salgueiro-tram-stunbis-01 and C.11. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 62 draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 63
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 62 C.12. Modifications between draft-salgueiro-tram-stunbis-01 and
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 63 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 64
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
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 24, line 38 skipping to change at page 24, line 38
of 400 (Bad Request). of 400 (Bad Request).
* If the message is an indication, the agent MUST silently * If the message is an indication, the agent MUST silently
discard the indication. discard the indication.
o If the USERNAME does not contain a username value currently valid o If the USERNAME does not contain a username value currently valid
within the server: within the server:
* If the message is a request, the server MUST reject the request * If the message is a request, the server MUST reject the request
with an error response. This response MUST use an error code with an error response. This response MUST use an error code
of 401 (Unauthorized). of 401 (Unauthenticated).
* If the message is an indication, the agent MUST silently * If the message is an indication, the agent MUST silently
discard the indication. discard the indication.
o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the
value for the message integrity as described in Section 14.6, value for the message integrity as described in Section 14.6,
using the password associated with the username. If the MESSAGE- using the password associated with the username. If the MESSAGE-
INTEGRITY-SHA256 attribute is not present, and using the same INTEGRITY-SHA256 attribute is not present, and using the same
password, compute the value for the message integrity as described password, compute the value for the message integrity as described
in Section 14.5. If the resulting value does not match the in Section 14.5. If the resulting value does not match the
contents of the corresponding attribute (MESSAGE-INTEGRITY-SHA256 contents of the corresponding attribute (MESSAGE-INTEGRITY-SHA256
or MESSAGE-INTEGRITY): or MESSAGE-INTEGRITY):
* If the message is a request, the server MUST reject the request * If the message is a request, the server MUST reject the request
with an error response. This response MUST use an error code with an error response. This response MUST use an error code
of 401 (Unauthorized). of 401 (Unauthenticated).
* If the message is an indication, the agent MUST silently * If the message is an indication, the agent MUST silently
discard the indication. discard the indication.
If these checks pass, the agent continues to process the request or If these checks pass, the agent continues to process the request or
indication. Any response generated by a server to a request that indication. Any response generated by a server to a request that
contains a MESSAGE-INTEGRITY-SHA256 attribute MUST include the contains a MESSAGE-INTEGRITY-SHA256 attribute MUST include the
MESSAGE-INTEGRITY-SHA256 attribute, computed using the password MESSAGE-INTEGRITY-SHA256 attribute, computed using the password
utilized to authenticate the request. Any response generated by a utilized to authenticate the request. Any response generated by a
server to a request that contains only a MESSAGE-INTEGRITY attribute server to a request that contains only a MESSAGE-INTEGRITY attribute
skipping to change at page 25, line 39 skipping to change at page 25, line 39
9.1.4. Receiving a Response 9.1.4. Receiving a Response
The client looks for the MESSAGE-INTEGRITY or the MESSAGE-INTEGRITY- The client looks for the MESSAGE-INTEGRITY or the MESSAGE-INTEGRITY-
SHA256 attribute in the response. If present, the client computes SHA256 attribute in the response. If present, the client computes
the message integrity over the response as defined in Section 14.5 or the message integrity over the response as defined in Section 14.5 or
Section 14.6, respectively, using the same password it utilized for Section 14.6, respectively, using the same password it utilized for
the request. If the resulting value matches the contents of the the request. If the resulting value matches the contents of the
MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute,
respectively, the response is considered authenticated. If the value respectively, the response is considered authenticated. If the value
does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY- does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-
SHA256 were absent, the response MUST be discarded, as if it was SHA256 were absent, the processing depends on the request been sent
never received. This means that retransmits, if applicable, will over a reliable or an unreliable transport.
continue.
If the request was sent over an unreliable transport, the response
MUST be discarded, as if it was never received. This means that
retransmits, if applicable, will continue. If all the reponses
received are discarded then instead of signalling a timeout after
ending the transaction the layer MUST signal that an attack took
place.
If the request was sent over a reliable transport, the response MUST
be discarded and the layer MUST immediately end the transaction and
signal that an attack took place.
If the client only sent one algorithm in the request (because of the If the client only sent one algorithm in the request (because of the
external indication in section Section 9.2.3, or this being a external indication in section Section 9.2.3, or this being a
subsequent request as defined in Section 9.1.5) the algorithm in the subsequent request as defined in Section 9.1.5) the algorithm in the
response has to match otherwise the response MUST be discarded. response has to match otherwise the response MUST be discarded.
9.1.5. Sending Subsequent Requests 9.1.5. Sending Subsequent Requests
A client sending subsequent requests to the same server MAY choose to A client sending subsequent requests to the same server MAY choose to
send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY send only the MESSAGE-INTEGRITY-SHA256 or the MESSAGE-INTEGRITY
skipping to change at page 28, line 30 skipping to change at page 28, line 42
There are two cases when forming a request. In the first case, this There are two cases when forming a request. In the first case, this
is the first request from the client to the server (as identified by is the first request from the client to the server (as identified by
its IP address and port). In the second case, the client is its IP address and port). In the second case, the client is
submitting a subsequent request once a previous request/response submitting a subsequent request once a previous request/response
transaction has completed successfully. Forming a request as a transaction has completed successfully. Forming a request as a
consequence of a 401 or 438 error response is covered in consequence of a 401 or 438 error response is covered in
Section 9.2.5 and is not considered a "subsequent request" and thus Section 9.2.5 and is not considered a "subsequent request" and thus
does not utilize the rules described in Section 9.2.3.2. does not utilize the rules described in Section 9.2.3.2.
The difference between a first request and a subsequent request is
the presence or absence of some attributes, so omitting or including
them is a MUST.
9.2.3.1. First Request 9.2.3.1. First Request
If the client has not completed a successful request/response If the client has not completed a successful request/response
transaction with the server (as identified by hostname, if the DNS transaction with the server (as identified by hostname, if the DNS
procedures of Section 8 are used, else IP address if not), it SHOULD procedures of Section 8 are used, else IP address if not), it MUST
omit the USERNAME, USERHASH, MESSAGE-INTEGRITY, MESSAGE-INTEGRITY- omit the USERNAME, USERHASH, MESSAGE-INTEGRITY, MESSAGE-INTEGRITY-
SHA256, REALM, NONCE, PASSWORD-ALGORITHMS, and PASSWORD-ALGORITHM SHA256, REALM, NONCE, PASSWORD-ALGORITHMS, and PASSWORD-ALGORITHM
attributes. In other words, the very first request is sent as if attributes. In other words, the very first request is sent as if
there were no authentication or message integrity applied. there were no authentication or message integrity applied.
9.2.3.2. Subsequent Requests 9.2.3.2. Subsequent Requests
Once a request/response transaction has completed successfully, the Once a request/response transaction has completed successfully, the
client will have been presented a realm and nonce by the server, and client will have been presented a realm and nonce by the server, and
selected a username and password with which it authenticated. The selected a username and password with which it authenticated. The
client SHOULD cache the username, password, realm, and nonce for client SHOULD cache the username, password, realm, and nonce for
subsequent communications with the server. When the client sends a subsequent communications with the server. When the client sends a
subsequent request, it SHOULD include either the USERNAME or subsequent request, it MUST include either the USERNAME or USERHASH,
USERHASH, REALM, NONCE, and PASSWORD-ALGORITHM attributes with these REALM, NONCE, and PASSWORD-ALGORITHM attributes with these cached
cached values. It SHOULD include a MESSAGE-INTEGRITY attribute or a values. It MUST include a MESSAGE-INTEGRITY attribute or a MESSAGE-
MESSAGE-INTEGRITY-SHA256 attribute, computed as described in INTEGRITY-SHA256 attribute, computed as described in Section 14.5 and
Section 14.5 and Section 14.6 using the cached password. The choice Section 14.6 using the cached password. The choice between the two
between the two attributes depends on the attribute received in the attributes depends on the attribute received in the response to the
response to the first request. first request.
9.2.4. Receiving a Request 9.2.4. Receiving a Request
After the server has done the basic processing of a request, it After the server has done the basic processing of a request, it
performs the checks listed below in the order specified: performs the checks listed below in the order specified:
o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE- o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE-
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 (Unauthorized). This response response with an error code of 401 (Unauthenticated). This
MUST include a REALM value. It is RECOMMENDED that the REALM response MUST include a REALM value. It is RECOMMENDED that the
value be the domain name of the provider of the STUN server. The REALM value be the domain name of the provider of the STUN server.
response MUST include a NONCE, selected by the server. The server The response MUST include a NONCE, selected by the server. The
MUST ensure that the same NONCE cannot be selected for clients server MUST ensure that the same NONCE cannot be selected for
that use different IP addresses and/or different ports. The clients that use different IP addresses and/or different ports.
server MAY support alternate password algorithms, in which case it The server MAY support alternate password algorithms, in which
can list them in preferential order in a PASSWORD-ALGORITHMS case it can list them in preferential order in a PASSWORD-
attribute. If the server adds a PASSWORD-ALGORITHMS attribute it ALGORITHMS attribute. If the server adds a PASSWORD-ALGORITHMS
MUST prepend the NONCE attribute value with the "nonce cookie". attribute it MUST prepend the NONCE attribute value with the
The server MAY support anonymous username, in which case it can "nonce cookie". The server MAY support anonymous username, in
prepend the NONCE attribute value with the "nonce cookie" that has which case it can prepend the NONCE attribute value with the
the STUN Security Feature "Anonymous username" bit set to 1. The "nonce cookie" that has the STUN Security Feature "Anonymous
response SHOULD NOT contain a USERNAME, USERHASH, MESSAGE- username" bit set to 1. The response SHOULD NOT contain a
INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute. USERNAME, USERHASH, MESSAGE-INTEGRITY or MESSAGE-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
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, or REALM.
MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute. The response cannot contain a MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY-SHA256 attribute, as the attributes required to generate
them are missing.
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
PASSWORD-ALGORITHMS does not match the value sent in the response PASSWORD-ALGORITHMS does not match the value sent in the response
that sent this NONCE, then the server MUST generate an error that sent this NONCE, then the server MUST generate an error
response with an error code of 400 (Bad Request). response with an error code of 400 (Bad Request).
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 the STUN Security Feature "Password algorithm" bit set to 1 but the
request contains neither PASSWORD-ALGORITHMS nor PASSWORD- request contains neither PASSWORD-ALGORITHMS nor PASSWORD-
skipping to change at page 30, line 19 skipping to change at page 30, line 36
one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is present, then one of PASSWORD-ALGORITHM or PASSWORD-ALGORITHMS is present, then
the server MUST generate an error response with an error code of the server MUST generate an error response with an error code of
400 (Bad Request). 400 (Bad Request).
o If the NONCE attribute starts with the "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
PASSWORD-ALGORITHM does not match one of the entries in PASSWORD- PASSWORD-ALGORITHM does not match one of the entries in PASSWORD-
ALGORITHMS, then the server MUST generate an error response with ALGORITHMS, then the server MUST generate an error response with
an error code of 400 (Bad Request). an error code of 400 (Bad Request).
o If the NONCE is no longer valid and at the same time the MESSAGE-
INTEGRITY or a MESSAGE-INTEGRITY-SHA256 attribute is invalid, the
server MUST generate an error response with an error code of 401.
This response MUST include NONCE, REALM, and PASSWORD-ALGORITHMS
attributes and SHOULD NOT include the USERNAME or USERHASH
attribute. The response MAY include a MESSAGE-INTEGRITY or
MESSAGE-INTEGRITY-SHA256 attribute, using the previous NONCE to
calculate it.
o If the NONCE is no longer valid, the server MUST generate an error o If the NONCE is no longer valid, the server MUST generate an error
response with an error code of 438 (Stale Nonce). This response response with an error code of 438 (Stale Nonce). This response
MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and MUST include NONCE, REALM, and PASSWORD-ALGORITHMS attributes and
SHOULD NOT include the USERNAME, USERHASH, MESSAGE-INTEGRITY, or SHOULD NOT include the USERNAME, USERHASH attribute, The response
MESSAGE-INTEGRITY-SHA256 attribute. Servers can invalidate nonces MAY include a MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
in order to provide additional security. See Section 4.3 of attribute, using the previous NONCE to calculate it. Servers can
[RFC2617] for guidelines. invalidate nonces in order to provide additional security. See
Section 4.3 of [RFC2617] for guidelines.
o If the username in the USERNAME or USERHASH attribute is not o If the username in the USERNAME or USERHASH attribute is not
valid, the server MUST generate an error response with an error valid, the server MUST generate an error response with an error
code of 401 (Unauthorized). This response MUST include a REALM code of 401 (Unauthenticated). This response MUST include a REALM
value. It is RECOMMENDED that the REALM value be the domain name value. It is RECOMMENDED that the REALM value be the domain name
of the provider of the STUN server. The response MUST include a of the provider of the STUN server. The response MUST include a
NONCE, selected by the server. The response MUST include a NONCE, selected by the server. The response MUST include a
PASSWORD-ALGORITHMS attribute. The response SHOULD NOT contain a PASSWORD-ALGORITHMS attribute. The response SHOULD NOT contain a
USERNAME, USERHASH, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 USERNAME, USERHASH attribute. The response MAY include a MESSAGE-
attribute. INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, using the
previous password to calculate it.
o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the o If the MESSAGE-INTEGRITY-SHA256 attribute is present compute the
value for the message integrity as described in Section 14.6, value for the message integrity as described in Section 14.6,
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 (Unauthorized). 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- For the responses sent by the steps above, the MESSAGE-INTEGRITY-
SHA256 attribute cannot be added. 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.
9.2.5. Receiving a Response 9.2.5. Receiving a Response
If the response is an error response with an error code of 401 If the response is an error response with an error code of 401
(Unauthorized) or 438 (Stale Nonce), the client MUST test if the (Unauthenticated) or 438 (Stale Nonce), the client MUST test if the
NONCE attribute value starts with the "nonce cookie". If the test NONCE attribute value starts with the "nonce cookie". If the test
succeeds and the "nonce cookie" has the STUN Security Feature succeeds and the "nonce cookie" has the STUN Security Feature
"Password algorithm" bit set to 1 but no PASSWORD-ALGORITHMS "Password algorithm" bit set to 1 but no PASSWORD-ALGORITHMS
attribute is present, then the client MUST NOT retry the request with attribute is present, then the client MUST NOT retry the request with
a new transaction. If the test succeeds and the "nonce cookie" has a new transaction. If the test succeeds and the "nonce cookie" has
the STUN Security Feature "Username anonymity" bit set to 1 but no the STUN Security Feature "Username anonymity" bit set to 1 but no
USERHASH attribute is present, then the client MUST NOT retry the USERHASH attribute is present, then the client MUST NOT retry the
request with a new transaction. request with a new transaction.
If the response is an error response with an error code of 401 If the response is an error response with an error code of 401
(Unauthorized), the client SHOULD retry the request with a new (Unauthenticated), the client SHOULD retry the request with a new
transaction. This request MUST contain a USERNAME or a USERHASH, transaction. This request MUST contain a USERNAME or a USERHASH,
determined by the client as the appropriate username for the REALM determined by the client as the appropriate username for the REALM
from the error response. If the "nonce cookie" was present and had from the error response. If the "nonce cookie" was present and had
the STUN Security Feature "Username anonymity" bit set to 1 then the the STUN Security Feature "Username anonymity" bit set to 1 then the
USERHASH attribute MUST be used, else the USERNAME attribute MUST be USERHASH attribute MUST be used, else the USERNAME attribute MUST be
used. The request MUST contain the REALM, copied from the error used. The request MUST contain the REALM, copied from the error
response. The request MUST contain the NONCE, copied from the error response. The request MUST contain the NONCE, copied from the error
response. If the response contains a PASSWORD-ALGORITHMS attribute, response. If the response contains a PASSWORD-ALGORITHMS attribute,
the request MUST contain the PASSWORD-ALGORITHMS attribute with the the request MUST contain the PASSWORD-ALGORITHMS attribute with the
same content. If the response contains a PASSWORD-ALGORITHMS same content. If the response contains a PASSWORD-ALGORITHMS
skipping to change at page 32, line 15 skipping to change at page 32, line 44
the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attributes. the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attributes.
For all other responses, if the NONCE attribute starts with the For all other responses, if the NONCE attribute starts with the
"nonce cookie" with the STUN Security Feature "Password algorithm" "nonce cookie" with the STUN Security Feature "Password algorithm"
bit set to 1 but PASSWORD-ALGORITHMS is not present, the response bit set to 1 but PASSWORD-ALGORITHMS is not present, the response
MUST be ignored. For all other responses, if the NONCE attribute MUST be ignored. For all other responses, if the NONCE attribute
starts with the "nonce cookie" with the STUN Security Feature "User starts with the "nonce cookie" with the STUN Security Feature "User
anonymity" bit set to 1 but USERHASH is not present, the response anonymity" bit set to 1 but USERHASH is not present, the response
MUST be ignored. MUST be ignored.
If the response is an error response with an error code of 400, and
does not contains either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-
SHA256 attribute then the response MUST be discarded, as if it was
never received. This means that retransmits, if applicable, will
continue.
The client looks for the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY- The client looks for the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-
SHA256 attribute in the response (either success or failure). If SHA256 attribute in the response (either success or failure). If
present, the client computes the message integrity over the response present, the client computes the message integrity over the response
as defined in Section 14.5 or Section 14.6, using the same password as defined in Section 14.5 or Section 14.6, using the same password
it utilized for the request. If the resulting value matches the it utilized for the request. If the resulting value matches the
contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 contents of the MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
attribute, the response is considered authenticated. If the value attribute, the response is considered authenticated. If the value
does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY- does not match, or if both MESSAGE-INTEGRITY and MESSAGE-INTEGRITY-
SHA256 were absent, the response MUST be discarded, as if it was SHA256 were absent, the processing depends on the request been sent
never received. This means that retransmits, if applicable, will over a reliable or an unreliable transport.
continue.
If the request was sent over an unreliable transport, the response
MUST be discarded, as if it was never received. This means that
retransmits, if applicable, will continue. If all the reponses
received are discarded then instead of signalling a timeout after
ending the transaction the layer MUST signal that an attack took
place.
If the request was sent over a reliable transport, the response MUST
be discarded and the layer MUST immediately end the transaction and
signal that an attack took place.
If the response contains a PASSWORD-ALGORITHMS attribute, the If the response contains a PASSWORD-ALGORITHMS attribute, the
subsequent request MUST be authenticated using MESSAGE-INTEGRITY- subsequent request MUST be authenticated using MESSAGE-INTEGRITY-
SHA256 only. SHA256 only.
10. ALTERNATE-SERVER Mechanism 10. ALTERNATE-SERVER Mechanism
This section describes a mechanism in STUN that allows a server to This section describes a mechanism in STUN that allows a server to
redirect a client to another server. This extension is optional, and redirect a client to another server. This extension is optional, and
a usage must define if and when this extension is used. a usage must define if and when this extension is used.
skipping to change at page 41, line 47 skipping to change at page 42, line 47
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 Unauthenticated: 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.
skipping to change at page 59, 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-08 and draft-ietf- C.1. Modifications between draft-ietf-tram-stunbis-09 and draft-ietf-
tram-stunbis-08
o Packets discarded in a reliable or unreliable transaction triggers
an attack error instead of a timeout error. An attack error on a
reliable transport is signalled immediately instead of waiting for
the timeout.
o Explicitly state that a received 400 response without
authentication will be dropped until timeout.
o Clarify the SHOULD omit/include rule sin LTCM.
o If the nonce and the hmac are both invlid, then a 401 is sent
instead of a 438.
o The 401 and 438 error response to subsequent requests may use the
previous NONCE/password to authenticate, if they are still
available.
C.2. 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.2. Modifications between draft-ietf-tram-stunbis-07 and draft-ietf- C.3. 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.3. Modifications between draft-ietf-tram-stunbis-06 and draft-ietf- C.4. 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.4. Modifications between draft-ietf-tram-stunbis-05 and draft-ietf- C.5. 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.5. Modifications between draft-ietf-tram-stunbis-04 and draft-ietf- C.6. 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.6. Modifications between draft-ietf-tram-stunbis-03 and draft-ietf- C.7. 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.7. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf- C.8. 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 61, line 18 skipping to change at page 62, line 38
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.8. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- C.9. 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 62, line 5 skipping to change at page 63, line 25
* 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.9. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.10. 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.10. Modifications between draft-salgueiro-tram-stunbis-02 and draft- C.11. 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 62, line 39 skipping to change at page 64, line 11
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.11. Modifications between draft-salgueiro-tram-stunbis-01 and draft- C.12. 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. 39 change blocks. 
137 lines changed or deleted 203 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/