idnits 2.17.1 draft-petithuguenin-tram-stun-dane-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 19, 2014) is 3629 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-05) exists of draft-ietf-tram-stun-dtls-02 == Outdated reference: A later version (-14) exists of draft-ietf-dane-srv-05 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM M. Petit-Huguenin 3 Internet-Draft Jive Communications 4 Intended status: Standards Track O. Johansson 5 Expires: November 20, 2014 Edvina AB 6 G. Salgueiro 7 Cisco Systems 8 May 19, 2014 10 Using DNS-based Authentication of Named Entities (DANE) to validate TLS 11 certificates for the Session Traversal Utilities for NAT (STUN) protocol 12 draft-petithuguenin-tram-stun-dane-00 14 Abstract 16 This document defines how DNS-based Authentication of Named Entities 17 (DANE) can be used to validate TLS certificates with the Session 18 Traversal Utilities for NAT (STUN) protocol. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 20, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 6.1. Normative References . . . . . . . . . . . . . . . . . . 3 61 6.2. Informative References . . . . . . . . . . . . . . . . . 4 62 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 This document defines how DNS-based Authentication of Named Entities 68 [RFC6698] (DANE) can be used to validate TLS certificates with the 69 Session Traversal Utilities for NAT [RFC5389] (STUN) protocol. 71 STUN [RFC5389] uses Transport Layer Security [RFC5246] (TLS) as a 72 secure transport and [I-D.ietf-tram-stun-dtls] subsequently added 73 Datagram Transport Layer Security [RFC6347] as a secure transport 74 more suited for the originally intended purpose of STUN, which is to 75 support multimedia sessions. Both transports require to have the 76 certificate presented by the server validated following the rules 77 established by [RFC2818]. Additionaly [RFC5389] provides rules on 78 how to use DNS SRV Resource Records [RFC2782] to resolve a domain 79 name to a list of host name for the purpose of load balancing and 80 increased reliability. These rules were subsequently enhanced to 81 support S-NAPTR Resource Records [RFC5928] to add the possibility of 82 selecting the preferred transport and redirect between domains. 84 DANE [RFC6698] improves the mechanism established by [RFC2818] by 85 enabling the administrators of domain names to specify the keys used 86 the secure servers in their domains. The benefits of this approach 87 emcompass increasing flexibility, getting less reliance on trust 88 anchors, enabling Perfect Forward Secrecy (PFS) and much more. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 93 in this document are to be interpreted as described in [RFC2119] when 94 they appear in ALL CAPS. When these words are not in ALL CAPS (such 95 as "must" or "Must"), they have their usual English meanings, and are 96 not to be interpreted as RFC 2119 key words. 98 "Source Domain" and "Host Name" are defined in [I-D.ietf-dane-srv]. 100 3. Operations 102 STUN clients that are conform with this specification, and that are 103 using one or more DNS lookups to find the server, and that have 104 established that all DNS Resource Records from the Source Domain to 105 the Host Name are secure according to DNSsec [RFC4033] (i.e. that the 106 AD bit is set in all the DNS answers), and that have selected a 107 secure protocol (e.g. TLS or DTLS) MUST lookup for a TLSA Resource 108 Record for the protocol, port and Host Name selected. If the TLSA 109 Resource Record is secure then the STUN client MUST use it to 110 validate the certificate presented by the STUN server. If there is 111 no TLSA Resource Record or if the Resource Record is not secure, then 112 the client MUST fallback to the validation process defined in 113 [RFC5389] and [I-D.ietf-tram-stun-dtls]. 115 Note that only STUN Usages where the connection is the result of a 116 DNS lookup are to be used with DANE which, for the list of STUN 117 Usages listed in [I-D.ietf-tram-stun-dtls], means these: 119 NAT Discovery Usage 121 NAT Behavior Discovery Usage 123 TURN Usage 125 4. Security Considerations 127 Using DANE as (D)TLS certificate validation mechanism does not 128 introduce any specific security considerations beyond those for STUN 129 over TLS detailed in [RFC5389] and those for STUN over DTLS detailed 130 in [I-D.ietf-tram-stun-dtls]. 132 5. IANA Considerations 134 This document has no IANA actions. 136 6. References 138 6.1. Normative References 140 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 141 Requirement Levels", BCP 14, RFC 2119, March 1997. 143 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 144 specifying the location of services (DNS SRV)", RFC 2782, 145 February 2000. 147 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 149 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 150 Rose, "DNS Security Introduction and Requirements", RFC 151 4033, March 2005. 153 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 154 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 156 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 157 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 158 October 2008. 160 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 161 (TURN) Resolution Mechanism", RFC 5928, August 2010. 163 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 164 Security Version 1.2", RFC 6347, January 2012. 166 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 167 of Named Entities (DANE) Transport Layer Security (TLS) 168 Protocol: TLSA", RFC 6698, August 2012. 170 [I-D.ietf-tram-stun-dtls] 171 Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 172 Layer Security (DTLS) as Transport for Session Traversal 173 Utilities for NAT (STUN)", draft-ietf-tram-stun-dtls-02 174 (work in progress), May 2014. 176 [I-D.ietf-dane-srv] 177 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 178 Based Authentication of Named Entities (DANE) TLSA records 179 with SRV and MX records.", draft-ietf-dane-srv-05 (work in 180 progress), February 2014. 182 6.2. Informative References 184 [RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P. 185 Jones, "Traversal Using Relays around NAT (TURN) Uniform 186 Resource Identifiers", RFC 7065, November 2013. 188 Appendix A. Examples 189 With the DNS RRs in Figure 1 and an ordered TURN transport list of 190 {DTLS, TLS, TCP, UDP}, a TURN client conform to this specification 191 and using the TURN URI [RFC7065] "turns:example.com" will try first 192 to connect to the TURN server at address 192.0.2.1:5389 using DTLS 193 and using DANE to verify the certificate subsequently presented by 194 the server. 196 If this connection does not succeed, the client will then try to 197 connect to the TURN server at 192.0.2.1:5000 but will not use DANE 198 for the certificate verification even as a TLSA RR is available, 199 because the DNSsec validation chain is broken in this case. 201 Using a TURN URI of "turns:example.com;transport=udp" bypasses the 202 NAPTR lookup, but at the expense of preventing the TLS fallback. 204 example.com. 205 IN NAPTR 100 10 "" RELAY:turn.tls:turn.dtls "" example.net. 206 IN RRSIG NAPTR ... 208 _turns._tcp.example.com. 209 IN SRV 0 0 5000 a.example.net. 211 _turns._udp.example.com. 212 IN SRV 0 0 5349 a.example.net. 213 IN RRSIG SRV ... 215 example.net. 216 IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net. 217 IN NAPTR 100 10 "" RELAY:turn.udp:turn.dtls "" datagram.example.net. 218 IN RRSIG NAPTR ... 220 datagram.example.net. 221 IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. 222 IN NAPTR 100 10 S RELAY:turn.dtls "" _turns._udp.example.net. 223 IN RRSIG NAPTR ... 225 stream.example.net. 226 IN NAPTR 200 10 S RELAY:turn.tcp "" _turn._tcp.example.net. 227 IN NAPTR 200 10 S RELAY:turn.tls "" _turns._tcp.example.net. 228 IN RRSIG NAPTR ... 230 _turn._udp.example.net. 231 IN SRV 0 0 3478 a.example.net. 233 _turn._tcp.example.net. 234 IN SRV 0 0 5000 a.example.net. 236 _turns._udp.example.net. 238 IN SRV 0 0 5349 a.example.net. 239 IN RRSIG SRV ... 241 _turns._tcp.example.net. 242 IN SRV 0 0 5000 a.example.net. 244 a.example.net. 245 IN A 192.0.2.1 246 IN RRSIG A ... 248 _5389._udp.a.example.net. 249 IN TLSA ... 250 IN RRSIG TLSA ... 252 _5000._tcp.a.example.net. 253 IN TLSA ... 254 IN RRSIG TLSA ... 256 Figure 1 258 Authors' Addresses 260 Marc Petit-Huguenin 261 Jive Communications 262 1275 West 1600 North, Suite 100 263 Orem, UT 84057 264 USA 266 Email: marcph@getjive.com 268 Olle E. Johansson 269 Edvina AB 270 Runbovaegen 10 271 Sollentuna SE-192 48 272 SE 274 Email: oej@edvina.net 276 Gonzalo Salgueiro 277 Cisco Systems 278 7200-12 Kit Creek Road 279 Research Triangle Park, NC 27709 280 US 282 Email: gsalguei@cisco.com