Using DNS-based Authentication of Named Entities (DANE) to validate TLS certificates for the Session Traversal Utilities for NAT (STUN) protocol
draft-petithuguenin-tram-stun-dane-03

Abstract

This document defines how DNS-based Authentication of Named Entities (DANE) can be used to validate TLS certificates with the Session Traversal Utilities for NAT (STUN) protocol.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 25, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Operations
• 4. Security Considerations
• 5. IANA Considerations
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Appendix A. Examples
• Appendix B. Release notes
• B.1. Modifications between draft-petithuguenin-tram-stun-dane-01 and draft-petithuguenin-tram-stun-dane-02
• B.2. Modifications between draft-petithuguenin-tram-stun-dane-00 and draft-petithuguenin-tram-stun-dane-01
• Authors' Addresses

1. Introduction

This document defines how DNS-based Authentication of Named Entities [RFC6698] (DANE) can be used to validate TLS certificates with the Session Traversal Utilities for NAT [RFC5389] (STUN) protocol.

STUN [RFC5389] uses Transport Layer Security [RFC5246] (TLS) as a secure transport and [RFC7350] subsequently added Datagram Transport Layer Security [RFC6347] (DTLS) as a secure transport more suited for the originally intended purpose of STUN, which is to support multimedia sessions. Both transports require to have the certificate presented by the server validated following the rules established by [RFC2818]. Additionally [RFC5389] provides rules on how to use DNS SRV Resource Records [RFC2782] to resolve a domain name to a list of host name for the purpose of load balancing and increased reliability. These rules were subsequently enhanced to support S-NAPTR Resource Records [RFC5928] to add the possibility of selecting the preferred transport and redirect between domains.

DANE [RFC6698] improves the mechanism established by [RFC2818] by enabling the administrators of domain names to specify the public keys (either in an X.509 certificate or in a SubjectPublicKeyInfo structure [RFC5280]) used by the secure servers in their domains. The benefits of this approach encompass increasing flexibility, getting less reliance on trust anchors, enabling Perfect Forward Secrecy (PFS) and much more.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "must" or "Must"), they have their usual English meanings, and are not to be interpreted as RFC 2119 key words.

"Source Domain" and "Host Name" are defined in [I-D.ietf-dane-srv].

3. Operations

STUN clients that are conform with this specification, and that are using one or more DNS lookups to find the server, and that have established that all DNS Resource Records from the Source Domain to the Host Name are secure according to DNSsec [RFC4033] (i.e. that the AD bit is set in all the DNS answers), and that have selected a secure protocol (e.g. TLS or DTLS) MUST lookup for a TLSA Resource Record for the protocol, port and Host Name selected. If the TLSA Resource Record is secure then the STUN client MUST use it to validate the certificate presented by the STUN server. If there is no TLSA Resource Record or if the Resource Record is not secure, then the client MUST fallback to the validation process defined in [RFC5389] and [RFC7350].

Note that only STUN Usages where the connection is the result of a DNS lookup are to be used with DANE which, for the list of STUN Usages listed in [RFC7350], means these:

• NAT Discovery Usage
• NAT Behavior Discovery Usage
• TURN Usage

4. Security Considerations

Using DANE as (D)TLS certificate validation mechanism does not introduce any specific security considerations beyond those for STUN over TLS detailed in [RFC5389] and those for STUN over DTLS detailed in [RFC7350].

5. IANA Considerations

This document has no IANA actions.

6. References

6.1. Normative References

6.2. Informative References

Appendix A. Examples

With the DNS RRs in Figure 1 and an ordered TURN transport list of {DTLS, TLS, TCP, UDP}, a TURN client conform to this specification and using the TURN URI [RFC7065] "turns:example.com" will try first to connect to the TURN server at address 192.0.2.1:5389 using DTLS and using DANE to verify the certificate subsequently presented by the server.

If this connection does not succeed, the client will then try to connect to the TURN server at 192.0.2.1:5000 but will not use DANE for the certificate verification even as a TLSA RR is available, because the DNSsec validation chain is broken in this case.

Using a TURN URI of "turns:example.com;transport=udp" bypasses the NAPTR lookup, but at the expense of preventing the TLS fallback.

example.com.
IN NAPTR 100 10 "" RELAY:turn.tls:turn.dtls "" example.net.
IN RRSIG NAPTR ...

_turns._tcp.example.com.
IN SRV   0 0 5000 a.example.net.

_turns._udp.example.com.
IN SRV   0 0 5349 a.example.net.
IN RRSIG SRV ...

example.net.
IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net.
IN NAPTR 100 10 "" RELAY:turn.udp:turn.dtls "" datagram.example.net.
IN RRSIG NAPTR ...

datagram.example.net.
IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net.
IN NAPTR 100 10 S RELAY:turn.dtls "" _turns._udp.example.net.
IN RRSIG NAPTR ...

stream.example.net.
IN NAPTR 200 10 S RELAY:turn.tcp "" _turn._tcp.example.net.
IN NAPTR 200 10 S RELAY:turn.tls "" _turns._tcp.example.net.
IN RRSIG NAPTR ...

_turn._udp.example.net.
IN SRV   0 0 3478 a.example.net.

_turn._tcp.example.net.
IN SRV   0 0 5000 a.example.net.

_turns._udp.example.net.
IN SRV   0 0 5349 a.example.net.
IN RRSIG SRV ...

_turns._tcp.example.net.
IN SRV   0 0 5000 a.example.net.

a.example.net.
IN A     192.0.2.1
IN RRSIG A ...

_5389._udp.a.example.net.
IN TLSA ...
IN RRSIG TLSA ...

_5000._tcp.a.example.net.
IN TLSA ...
IN RRSIG TLSA ...