idnits 2.17.00 (12 Aug 2021) /tmp/idnits24877/draft-petithuguenin-tram-stun-dane-04.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 (October 19, 2015) is 2399 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) == Unused Reference: 'RFC2616' is defined on line 150, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 2818 ** 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: draft-ietf-dane-srv has been published as RFC 7673 Summary: 5 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 Impedance Mismatch 4 Intended status: Standards Track O. Johansson 5 Expires: April 21, 2016 Edvina AB 6 G. Salgueiro 7 Cisco Systems 8 October 19, 2015 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-04 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 April 21, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 61 6.2. Informative References . . . . . . . . . . . . . . . . . 5 62 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 5 63 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 6 64 B.1. Modifications between draft-petithuguenin-tram-stun- 65 dane-01 and draft-petithuguenin-tram-stun-dane-02 . . . . 6 66 B.2. Modifications between draft-petithuguenin-tram-stun- 67 dane-00 and draft-petithuguenin-tram-stun-dane-01 . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 This document defines how DNS-based Authentication of Named Entities 73 [RFC6698] (DANE) can be used to validate TLS certificates with the 74 Session Traversal Utilities for NAT [RFC5389] (STUN) protocol. 76 STUN [RFC5389] uses Transport Layer Security [RFC5246] (TLS) as a 77 secure transport and [RFC7350] subsequently added Datagram Transport 78 Layer Security [RFC6347] (DTLS) as a secure transport more suited for 79 the originally intended purpose of STUN, which is to support 80 multimedia sessions. Both transports require to have the certificate 81 presented by the server validated following the rules established by 82 [RFC2818]. Additionally [RFC5389] provides rules on how to use DNS 83 SRV Resource Records [RFC2782] to resolve a domain name to a list of 84 host name for the purpose of load balancing and increased 85 reliability. These rules were subsequently enhanced to support 86 S-NAPTR Resource Records [RFC5928] to add the possibility of 87 selecting the preferred transport and redirect between domains. 89 DANE [RFC6698] improves the mechanism established by [RFC2818] by 90 enabling the administrators of domain names to specify the public 91 keys (either in an X.509 certificate or in a SubjectPublicKeyInfo 92 structure [RFC5280]) used by the secure servers in their domains. 93 The benefits of this approach encompass increasing flexibility, 94 getting less reliance on trust anchors, enabling Perfect Forward 95 Secrecy (PFS) and much more. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" 100 in this document are to be interpreted as described in [RFC2119] when 101 they appear in ALL CAPS. When these words are not in ALL CAPS (such 102 as "must" or "Must"), they have their usual English meanings, and are 103 not to be interpreted as RFC 2119 key words. 105 "Source Domain" and "Host Name" are defined in [I-D.ietf-dane-srv]. 107 3. Operations 109 STUN clients that are conform with this specification, and that are 110 using one or more DNS lookups to find the server, and that have 111 established that all DNS Resource Records from the Source Domain to 112 the Host Name are secure according to DNSsec [RFC4033] (i.e. that the 113 AD bit is set in all the DNS answers), and that have selected a 114 secure protocol (e.g. TLS or DTLS) MUST lookup for a TLSA Resource 115 Record for the protocol, port and Host Name selected. If the TLSA 116 Resource Record is secure then the STUN client MUST use it to 117 validate the certificate presented by the STUN server. If there is 118 no TLSA Resource Record or if the Resource Record is not secure, then 119 the client MUST fallback to the validation process defined in 120 [RFC5389] and [RFC7350]. 122 Note that only STUN Usages where the connection is the result of a 123 DNS lookup are to be used with DANE which, for the list of STUN 124 Usages listed in [RFC7350], means these: 126 NAT Discovery Usage 128 NAT Behavior Discovery Usage 130 TURN Usage 132 4. Security Considerations 134 Using DANE as (D)TLS certificate validation mechanism does not 135 introduce any specific security considerations beyond those for STUN 136 over TLS detailed in [RFC5389] and those for STUN over DTLS detailed 137 in [RFC7350]. 139 5. IANA Considerations 141 This document has no IANA actions. 143 6. References 145 6.1. Normative References 147 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 148 Requirement Levels", BCP 14, RFC 2119, March 1997. 150 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 151 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 152 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 154 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 155 specifying the location of services (DNS SRV)", RFC 2782, 156 February 2000. 158 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 160 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 161 Rose, "DNS Security Introduction and Requirements", 162 RFC 4033, March 2005. 164 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 165 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 167 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 168 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 169 October 2008. 171 [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT 172 (TURN) Resolution Mechanism", RFC 5928, August 2010. 174 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 175 Security Version 1.2", RFC 6347, January 2012. 177 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 178 of Named Entities (DANE) Transport Layer Security (TLS) 179 Protocol: TLSA", RFC 6698, August 2012. 181 [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport 182 Layer Security (DTLS) as Transport for Session Traversal 183 Utilities for NAT (STUN)", RFC 7350, August 2014. 185 [I-D.ietf-dane-srv] 186 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 187 Based Authentication of Named Entities (DANE) TLSA Records 188 with SRV Records", draft-ietf-dane-srv-07 (work in 189 progress), July 2014. 191 6.2. Informative References 193 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 194 Housley, R., and W. Polk, "Internet X.509 Public Key 195 Infrastructure Certificate and Certificate Revocation List 196 (CRL) Profile", RFC 5280, May 2008. 198 [RFC7065] Petit-Huguenin, M., Nandakumar, S., Salgueiro, G., and P. 199 Jones, "Traversal Using Relays around NAT (TURN) Uniform 200 Resource Identifiers", RFC 7065, November 2013. 202 Appendix A. Examples 204 With the DNS RRs in Figure 1 and an ordered TURN transport list of 205 {DTLS, TLS, TCP, UDP}, a TURN client conform to this specification 206 and using the TURN URI [RFC7065] "turns:example.com" will try first 207 to connect to the TURN server at address 192.0.2.1:5389 using DTLS 208 and using DANE to verify the certificate subsequently presented by 209 the server. 211 If this connection does not succeed, the client will then try to 212 connect to the TURN server at 192.0.2.1:5000 but will not use DANE 213 for the certificate verification even as a TLSA RR is available, 214 because the DNSsec validation chain is broken in this case. 216 Using a TURN URI of "turns:example.com;transport=udp" bypasses the 217 NAPTR lookup, but at the expense of preventing the TLS fallback. 219 example.com. 220 IN NAPTR 100 10 "" RELAY:turn.tls:turn.dtls "" example.net. 221 IN RRSIG NAPTR ... 223 _turns._tcp.example.com. 224 IN SRV 0 0 5000 a.example.net. 226 _turns._udp.example.com. 227 IN SRV 0 0 5349 a.example.net. 228 IN RRSIG SRV ... 230 example.net. 231 IN NAPTR 200 10 "" RELAY:turn.tcp:turn.tls "" stream.example.net. 232 IN NAPTR 100 10 "" RELAY:turn.udp:turn.dtls "" datagram.example.net. 233 IN RRSIG NAPTR ... 235 datagram.example.net. 236 IN NAPTR 100 10 S RELAY:turn.udp "" _turn._udp.example.net. 237 IN NAPTR 100 10 S RELAY:turn.dtls "" _turns._udp.example.net. 238 IN RRSIG NAPTR ... 240 stream.example.net. 241 IN NAPTR 200 10 S RELAY:turn.tcp "" _turn._tcp.example.net. 242 IN NAPTR 200 10 S RELAY:turn.tls "" _turns._tcp.example.net. 243 IN RRSIG NAPTR ... 245 _turn._udp.example.net. 246 IN SRV 0 0 3478 a.example.net. 248 _turn._tcp.example.net. 249 IN SRV 0 0 5000 a.example.net. 251 _turns._udp.example.net. 252 IN SRV 0 0 5349 a.example.net. 253 IN RRSIG SRV ... 255 _turns._tcp.example.net. 256 IN SRV 0 0 5000 a.example.net. 258 a.example.net. 259 IN A 192.0.2.1 260 IN RRSIG A ... 262 _5389._udp.a.example.net. 263 IN TLSA ... 264 IN RRSIG TLSA ... 266 _5000._tcp.a.example.net. 267 IN TLSA ... 268 IN RRSIG TLSA ... 270 Figure 1 272 Appendix B. Release notes 274 This section must be removed before publication as an RFC. 276 B.1. Modifications between draft-petithuguenin-tram-stun-dane-01 and 277 draft-petithuguenin-tram-stun-dane-02 279 o DANE can store public keys or certificates. 281 B.2. Modifications between draft-petithuguenin-tram-stun-dane-00 and 282 draft-petithuguenin-tram-stun-dane-01 284 o Change affiliation. 286 o Update STUN-DTLS reference. 288 o Nits 290 Authors' Addresses 292 Marc Petit-Huguenin 293 Impedance Mismatch 295 Email: marc@petit-huguenin.org 297 Olle E. Johansson 298 Edvina AB 299 Runbovaegen 10 300 Sollentuna SE-192 48 301 SE 303 Email: oej@edvina.net 305 Gonzalo Salgueiro 306 Cisco Systems 307 7200-12 Kit Creek Road 308 Research Triangle Park, NC 27709 309 US 311 Email: gsalguei@cisco.com