draft-ietf-tram-stun-dtls-00.txt   draft-ietf-tram-stun-dtls-01.txt 
TRAM M. Petit-Huguenin TRAM M. Petit-Huguenin
Internet-Draft Jive Communications Internet-Draft Jive Communications
Intended status: Standards Track G. Salgueiro Intended status: Standards Track G. Salgueiro
Expires: September 25, 2014 Cisco Systems Expires: September 25, 2014 Cisco Systems
March 24, 2014 March 24, 2014
Datagram Transport Layer Security (DTLS) as Transport for Session Datagram Transport Layer Security (DTLS) as Transport for Session
Traversal Utilities for NAT (STUN) Traversal Utilities for NAT (STUN)
draft-ietf-tram-stun-dtls-00 draft-ietf-tram-stun-dtls-01
Abstract Abstract
This document specifies the usage of Datagram Transport Layer This document specifies the usage of Datagram Transport Layer
Security (DTLS) as a transport protocol for Session Traversal Security (DTLS) as a transport protocol for Session Traversal
Utilities for NAT (STUN). It provides guidances on when and how to Utilities for NAT (STUN). It provides guidances on when and how to
use DTLS with the currently standardized STUN Usages. It also use DTLS with the currently standardized STUN Usages. It also
specifies modifications to the STUN URIs and TURN URIs and to the specifies modifications to the STUN URIs and TURN URIs and to the
TURN resolution mechanism to facilitate the resolution of STUN URIs TURN resolution mechanism to facilitate the resolution of STUN URIs
and TURN URIs into the IP address and port of STUN and TURN servers and TURN URIs into the IP address and port of STUN and TURN servers
skipping to change at page 2, line 12 skipping to change at page 2, line 12
(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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DTLS as Transport for STUN . . . . . . . . . . . . . . . . . 3 3. DTLS as Transport for STUN . . . . . . . . . . . . . . . . . 3
4. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. NAT Discovery Usage . . . . . . . . . . . . . . . . . . . 4 4.1. NAT Discovery Usage . . . . . . . . . . . . . . . . . . . 4
4.1.1. DTLS Support in STUN URIs . . . . . . . . . . . . . . 4 4.1.1. DTLS Support in STUN URIs . . . . . . . . . . . . . . 4
4.2. Connectivity Check Usage . . . . . . . . . . . . . . . . 4 4.2. Connectivity Check Usage . . . . . . . . . . . . . . . . 5
4.3. Media Keep-Alive Usage . . . . . . . . . . . . . . . . . 5 4.3. Media Keep-Alive Usage . . . . . . . . . . . . . . . . . 5
4.4. SIP Keep-Alive Usage . . . . . . . . . . . . . . . . . . 5 4.4. SIP Keep-Alive Usage . . . . . . . . . . . . . . . . . . 5
4.5. NAT Behavior Discovery Usage . . . . . . . . . . . . . . 5 4.5. NAT Behavior Discovery Usage . . . . . . . . . . . . . . 5
4.6. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . 5 4.6. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . 6
4.6.1. DTLS Support in TURN URIs . . . . . . . . . . . . . . 6 4.6.1. DTLS Support in TURN URIs . . . . . . . . . . . . . . 6
4.6.2. Resolution Mechanism for TURN over DTLS . . . . . . . 6 4.6.2. Resolution Mechanism for TURN over DTLS . . . . . . . 6
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 7
5.1. turnuri . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. turnuri . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. rfc5766-turn-server . . . . . . . . . . . . . . . . . . . 8 5.2. rfc5766-turn-server . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7.1. S-NAPTR application protocol tag . . . . . . . . . . . . 9 7.1. S-NAPTR application protocol tag . . . . . . . . . . . . 9
7.2. Service Name and Transport Protocol Port Number . . . . . 10 7.2. Service Name and Transport Protocol Port Number . . . . . 10
7.2.1. The stuns Service Name . . . . . . . . . . . . . . . 10 7.2.1. The stuns Service Name . . . . . . . . . . . . . . . 10
7.2.2. The turns Service Name . . . . . . . . . . . . . . . 10 7.2.2. The turns Service Name . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12
Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 13 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 13
B.1. Modifications between petithuguenin-tram-stun-dtls-00 and B.1. Modifications between ietf-tram-stun-dtls-00 and ietf-
ietf-tram-stun-dtls-00 . . . . . . . . . . . . . . . . . 13 tram-stun-dtls-01 . . . . . . . . . . . . . . . . . . . . 13
B.2. Modifications between petithuguenin-tram-turn-dtls-00 and B.2. Modifications between petithuguenin-tram-stun-dtls-00 and
ietf-tram-stun-dtls-00 . . . . . . . . . . . . . . . . . 14
B.3. Modifications between petithuguenin-tram-turn-dtls-00 and
petithuguenin-tram-stun-dtls-00 . . . . . . . . . . . . . 14 petithuguenin-tram-stun-dtls-00 . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
STUN [RFC5389] defines Transport Layer Security (TLS) over TCP STUN [RFC5389] defines Transport Layer Security (TLS) over TCP
(simply referred to as TLS [RFC5246]) as the transport for STUN due (simply referred to as TLS [RFC5246]) as the transport for STUN due
to additional security advantages it offers over plain UDP or TCP to additional security advantages it offers over plain UDP or TCP
transport. But TLS-over-TCP is not an optimal transport when STUN is transport. But TLS-over-TCP is not an optimal transport when STUN is
used for its originally intended purpose, which is to support used for its originally intended purpose, which is to support
skipping to change at page 3, line 32 skipping to change at page 3, line 39
3. DTLS as Transport for STUN 3. DTLS as Transport for STUN
STUN [RFC5389] defines three transports: UDP, TCP, and TLS. This STUN [RFC5389] defines three transports: UDP, TCP, and TLS. This
document adds DTLS as a valid transport for STUN. document adds DTLS as a valid transport for STUN.
STUN over DTLS MUST use the same retransmission rules as STUN over STUN over DTLS MUST use the same retransmission rules as STUN over
UDP (as described in Section 7.2.1 of [RFC5389]). It MUST also use UDP (as described in Section 7.2.1 of [RFC5389]). It MUST also use
the same rules that are described in Section 7.2.2 of [RFC5389] to the same rules that are described in Section 7.2.2 of [RFC5389] to
verify the server identity. STUN over DTLS MUST, at a minimum, verify the server identity. STUN over DTLS MUST, at a minimum,
support TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [[TODO: What is the support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support
recommendation these days?]]. The same rules established in TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. [[TODO: Do we want to specify
Section 7.2.2 of [RFC5389] for keeping open and closing TCP/TLS that implementations MUST favor cipher suites which support PFS over
connections MUST be used as well for DTLS associations. non-PFS cipher suites]]. The same rules established in Section 7.2.2
of [RFC5389] for keeping open and closing TCP/TLS connections MUST be
used as well for DTLS associations.
In addition to the path MTU rules described in Section 7.1 of In addition to the path MTU rules described in Section 7.1 of
[RFC5389], if the path MTU is unknown, the actual STUN message needs [RFC5389], if the path MTU is unknown, the actual STUN message needs
to be adjusted to take into account the size of the (13-byte) DTLS to be adjusted to take into account the size of the (13-byte) DTLS
Record header, the MAC size, the padding size and the eventual Record header, the MAC size, the padding size and the eventual
compression applied to the payload. compression applied to the payload.
By default, STUN over DTLS MUST use port 5349, the same port as STUN By default, STUN over DTLS MUST use port 5349, the same port as STUN
over TLS. However, the SRV procedures can be implemented to use a over TLS. However, the SRV procedures can be implemented to use a
different port (as described in Section 9 of [RFC5389]). When using different port (as described in Section 9 of [RFC5389]). When using
SRV records, the service name MUST be set to "stuns" and the SRV records, the service name MUST be set to "stuns" and the
application name to "udp". application name to "udp".
Classic STUN [RFC3489] defines only UDP as a transport and DTLS MUST Classic STUN [RFC3489] defines only UDP as a transport and DTLS MUST
NOT be used. Any STUN request or indication without the magic cookie NOT be used. Any STUN request or indication without the magic cookie
over DTLS MUST always result in an error. [[TODO: Note that it is a over DTLS MUST always result in an error.
departure from RFC 5389, which does not explicitly state what to do
in that case. Are we OK with this?]]
4. STUN Usages 4. STUN Usages
[RFC5389] Section 7.2 states that STUN usages must specify which [RFC5389] Section 7.2 states that STUN usages must specify which
transport protocol is used. The following sections discuss if and transport protocol is used. The following sections discuss if and
how the existing STUN usages are used with DTLS as the transport. how the existing STUN usages are used with DTLS as the transport.
Future STUN usages MUST take into account DTLS as a transport and Future STUN usages MUST take into account DTLS as a transport and
discuss its applicability. [[TODO: Note that Section 14 of RFC 5389 discuss its applicability.
ommitted to say that transport applicability MUST be discussed. Is
this a reasonable addition?]].
4.1. NAT Discovery Usage 4.1. NAT Discovery Usage
As stated by Section 13 of [RFC5389], "...TLS provides minimal As stated by Section 13 of [RFC5389], "...TLS provides minimal
security benefits..." for this particular STUN usage. DTLS will also security benefits..." for this particular STUN usage. DTLS will also
similarly offer only limited benefit. This is because the only similarly offer only limited benefit. This is because the only
mandatory attribute that is TLS/DTLS protected is the XOR-MAPPED- mandatory attribute that is TLS/DTLS protected is the XOR-MAPPED-
ADDRESS, which is already known by an on-path attacker, since it is ADDRESS, which is already known by an on-path attacker, since it is
the same as the source address and port of the STUN request. On the the same as the source address and port of the STUN request. On the
other hand, using TLS/DTLS will prevent an active attacker to inject other hand, using TLS/DTLS will prevent an active attacker to inject
skipping to change at page 13, line 44 skipping to change at page 13, line 44
| 1 | DTLS | 192.0.2.1 | 5349 | | 1 | DTLS | 192.0.2.1 | 5349 |
| 2 | TLS | 192.0.2.1 | 5349 | | 2 | TLS | 192.0.2.1 | 5349 |
+-------+----------+------------+------+ +-------+----------+------------+------+
Table 2 Table 2
Appendix B. Release notes Appendix B. Release notes
This section must be removed before publication as an RFC. This section must be removed before publication as an RFC.
B.1. Modifications between petithuguenin-tram-stun-dtls-00 and ietf- B.1. Modifications between ietf-tram-stun-dtls-00 and ietf-tram-stun-
dtls-01
o Updated the mandatory cipher suites.
o Added a new open item to determine if we want to specify favoring
cipher suites which support PFS over non-PFS cipher suites.
o Closed remaining opening items from previous draft.
B.2. Modifications between petithuguenin-tram-stun-dtls-00 and ietf-
tram-stun-dtls-00 tram-stun-dtls-00
o Draft renamed after WG adoption. o Draft renamed after WG adoption.
B.2. Modifications between petithuguenin-tram-turn-dtls-00 and B.3. Modifications between petithuguenin-tram-turn-dtls-00 and
petithuguenin-tram-stun-dtls-00 petithuguenin-tram-stun-dtls-00
o Add RFC 6982 information for rfc5766-turn-server project. o Add RFC 6982 information for rfc5766-turn-server project.
o Rename the draft as TURN is now just one of the usages. o Rename the draft as TURN is now just one of the usages.
o Remove the references in the abstract to make idnits happy. o Remove the references in the abstract to make idnits happy.
o No longer updates other standard drafts. o No longer updates other standard drafts.
 End of changes. 10 change blocks. 
19 lines changed or deleted 29 lines changed or added

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