idnits 2.17.1 draft-miller-xmpp-dnssec-prooftype-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2013) is 4074 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) ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0220' == Outdated reference: A later version (-02) exists of draft-saintandre-xmpp-dna-01 -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Miller 3 Internet-Draft P. Saint-Andre 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 26, 2013 February 22, 2013 7 Using DNS Security Extensions (DNSSEC) and DNS-based Authentication of 8 Named Entities (DANE) as a Prooftype for XMPP Domain Name Associations 9 draft-miller-xmpp-dnssec-prooftype-04 11 Abstract 13 This document defines a prooftype that uses DNS-based Authentication 14 of Named Entities (DANE) for associating a domain name with an XML 15 stream in the Extensible Messaging and Presence Protocol (XMPP). It 16 also defines a method that uses DNS Security (DNSSEC) for securely 17 delegating a source domain to a derived domain in XMPP. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 26, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Secure Delegation using DNS SRV . . . . . . . . . . . . . . . 3 57 5. DANE Prooftype . . . . . . . . . . . . . . . . . . . . . . . 4 58 5.1. No Service Records . . . . . . . . . . . . . . . . . . . 4 59 5.2. Insecure Delegation . . . . . . . . . . . . . . . . . . . 4 60 5.3. Secure Delegation . . . . . . . . . . . . . . . . . . . . 4 61 6. Order of Operations . . . . . . . . . . . . . . . . . . . . . 5 62 7. Internationalization Considerations . . . . . . . . . . . . . 5 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 10.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 The [XMPP-DNA] specification defines a framework for secure 73 delegation and strong domain name associations (DNA) in the 74 Extensible Messaging and Presence Protocol (XMPP). This document 75 defines a secure delegation method that uses DNS Security (DNSSEC) 76 [RFC4033] in conjuction with the standard DNS SRV records [RFC2782] 77 employed in domain name resolution in XMPP, with the result that a 78 client or peer server that inititates an XMPP stream can legitimately 79 treat a derived domain as a reference identifier during stream 80 negotiation. This document also defines a DNA prooftype that uses 81 DNS-based Authentication of Named Entities [RFC6698] (DANE) to verify 82 TLS certificates containing source domains or derived domains during 83 stream negotiation. 85 2. Terminology 87 This document inherits XMPP terminology from [RFC6120], DNS 88 terminology from [RFC1034], [RFC1035], [RFC2782] and [RFC4033], and 89 security terminology from [RFC4949] and [RFC5280]. The terms "source 90 domain", "derived domain", "reference identifier", and "presented 91 identifier" are used as defined in the "CertID" specification 92 [RFC6125]. 94 This document is applicable to connections made from an XMPP client 95 to an XMPP server ("_xmpp-client._tcp") or between XMPP servers 96 ("_xmpp-server._tcp"). In both cases, the XMPP initiating entity 97 acts as a TLS client and the XMPP receiving entity acts as a TLS 98 server. Therefore, to simplify discussion this document uses "_xmpp- 99 client._tcp" to describe to both cases, unless otherwise indicated. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 [RFC2119]. 106 3. Requirements 108 An XMPP initiating entity (TLS client) that wishes to use the DNSSEC 109 prooftype MUST do so before exchanging stanzas addressed to the 110 source domain. In general, this means that the proof MUST be 111 completed before the XMPP stream is restarted following STARTTLS 112 negotiation (as specified in [RFC6120]). However, connections 113 between XMPP servers MAY also use this prooftype to verify the 114 addition of new source domains onto an existing connection, such as 115 multiplexing or "piggybacking" via [XEP-0220]. 117 4. Secure Delegation using DNS SRV 119 In order to determine if delegation using DNS SRV records is secure, 120 an XMPP initiating entity (TLS client) performs the following 121 actions: 123 1. Query for the appropriate SRV resource record for the source 124 domain (e.g., "_xmpp-client._tcp.im.example.com"). 126 2. If there is no SRV resource record, pursue the fallback methods 127 described in [RFC6120]. 129 3. If there is an SRV resource record, validate that the SRV record 130 answer is secure according to [RFC4033]. If the answer is 131 insecure, then delegation to the derived domain(s), as indicated 132 by the "target host" field, is insecure and the TLS client MUST 133 treat only the source domain as a reference identifier during 134 certificate verification, as described in [RFC6120]; if the 135 answer is bogus, the TLS client MUST abort. 137 4. If the answer is secure, the TLS client SHOULD consider any 138 derived domain(s) in the answer as securely delegated; during 139 certificate verification, the TLS client MUST treat both the 140 source domain and the derived domain to which it has connected as 141 reference identifiers. 143 The foregoing secure delegation method can be used with the DANE 144 prooftype defined below, or with the PKIX prooftype specified in 145 [RFC6120]. 147 5. DANE Prooftype 149 DANE provides additional tools to verify the keys used in TLS 150 connections. A TLS client MAY use DANE for TLS certificate 151 verification; its use depends on the delegation status of the source 152 domain, as described in the following sections. 154 5.1. No Service Records 156 If no SRV records are found for the source domain, then the TLS 157 client MUST query for a TLSA resource record as described in 158 [RFC6698], where the prepared domain name MUST contain the source 159 domain and the IANA-registered port 5222 for client-to-server streams 160 (e.g., "_5222._tcp.im.example.com") or the IANA-registered port 5269 161 for server-to-server streams (e.g., "_5269._tcp.im.example.com"). 163 In this case, the TLS client MUST treat only the source domain as its 164 reference identifier during certificate verification, as described in 165 [RFC6120]. 167 5.2. Insecure Delegation 169 If the delegation of a source domain to a derived domain is not 170 secure, then the TLS client MUST NOT make a TLSA record query to the 171 derived domain as described in [RFC6698]. Instead, the TLS client 172 MUST treat only the source domain as its reference identifier during 173 certificate verification, as described in [RFC6120], and MUST NOT use 174 DANE. 176 5.3. Secure Delegation 178 If the source domain has been delegated to a derived domain in a 179 secure manner as described under Section 4, then the TLS client MUST 180 query for a TLSA resource record as described in [RFC6698], where the 181 prepared domain name MUST contain the derived domain and a port 182 obtained from the SRV answer (e.g., "_5555._tcp/hosting.example.net" 183 for an SRV record such as "_xmpp-client._tcp.im.example.com IN TLSA 1 184 1 5555 hosting.example.net"). 186 If no TLSA resource records exist for the specified service, then the 187 TLS client MUST perform certificate verification as described under 188 Section 4. 190 If TLSA resource records exist for the specified service, then the 191 TLS client MUST treat the derived domain(s) as its reference 192 identifier during certificate verification, using the information 193 from the TLSA answer as the basis for verification as described in 194 [RFC6698]. 196 6. Order of Operations 198 The processes for the DANE prooftype MUST be complete before the TLS 199 handshake over the XMPP connection finishes, so that the client can 200 perform verification of reference identities. To that end, a TLS 201 client SHOULD perform the processes for this prooftype as part of its 202 normal DNS resolution of the source domain into a socket address. 203 Validating secure delegation ought to be done immediately upon 204 receiving the answers to the SRV and follow-up A/AAAA queries; 205 queries for TLSA records ought to be done once the target service is 206 determined (whether the source domain and IANA-registered port, or 207 delegated domain and port). 209 Ideally a TLS client will perform the DNSSEC and DANE processes in 210 parallel with other XMPP session establishment processes where 211 possible (e.g., perform the TLSA resource queries as the socket 212 connection is made to the server); this is sometimes called the 213 "happy eyeballs" approach, similar to [RFC6555] for IPv4 and IPv6. 214 However, a TLS client might delay as much of the XMPP session 215 establishment as it needs to in order to gather all of the DNSSEC- 216 and DANE-based verification material. For instance, a TLS client 217 might not open the socket connection until it has validated the 218 secure delegation, or it might delay beginning the TLS handshake 219 until it has obtained the TLSA certificate verification material. 221 7. Internationalization Considerations 223 If the SRV, A/AAAA, and TLSA record queries are for an 224 internationalized domain name, then they need to use the A-label form 225 as defined in [RFC5890]. 227 8. Security Considerations 229 This document supplements but does not supersede the security 230 considerations provided in [RFC4033], [RFC6120], [RFC6125], and 231 [RFC6698]. 233 9. IANA Considerations 235 This document has no actions for the IANA. 237 10. References 239 10.1. Normative References 241 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 242 STD 13, RFC 1034, November 1987. 244 [RFC1035] Mockapetris, P., "Domain names - implementation and 245 specification", STD 13, RFC 1035, November 1987. 247 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 248 Requirement Levels", BCP 14, RFC 2119, March 1997. 250 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 251 specifying the location of services (DNS SRV)", RFC 2782, 252 February 2000. 254 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 255 Rose, "DNS Security Introduction and Requirements", RFC 256 4033, May 2005. 258 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 259 4949, August 2007. 261 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 262 Housley, R., and W. Polk, "Internet X.509 Public Key 263 Infrastructure Certificate and Certificate Revocation List 264 (CRL) Profile", RFC 5280, May 2008. 266 [RFC5890] Klensin, J., "Internationalized Domain Names for 267 Applications (IDNA): Definitions and Document Framework", 268 RFC 5890, August 2010. 270 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 271 Protocol (XMPP): Core", RFC 6120, March 2011. 273 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 274 Verification of Domain-Based Application Service Identity 275 within Internet Public Key Infrastructure Using X.509 276 (PKIX) Certificates in the Context of Transport Layer 277 Security (TLS)", RFC 6125, March 2011. 279 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 280 of Named Entities (DANE) Transport Layer Security (TLS) 281 Protocol: TLSA", RFC 6698, August 2012. 283 [XEP-0220] 284 Miller, J., Saint-Andre, P., and P. Hancke, "Server 285 Dialback", XSF XEP 0220, August 2011. 287 [XMPP-DNA] 288 Saint-Andre, P. and M. Miller, "Domain Name Associations 289 (DNA) in the Extensible Messaging and Presence Protocol 290 (XMPP)", draft-saintandre-xmpp-dna-01 (work in progress), 291 February 2013. 293 10.2. Informative References 295 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 296 Dual-Stack Hosts", RFC 6555, April 2012. 298 Authors' Addresses 300 Matthew Miller 301 Cisco Systems, Inc. 302 1899 Wynkoop Street, Suite 600 303 Denver, CO 80202 304 USA 306 Email: mamille2@cisco.com 308 Peter Saint-Andre 309 Cisco Systems, Inc. 310 1899 Wynkoop Street, Suite 600 311 Denver, CO 80202 312 USA 314 Email: psaintan@cisco.com