idnits 2.17.1 draft-huque-dane-client-cert-02.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 abstract seems to contain references ([RFC6698], [RFC7671]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 135: '...ient certificate MUST have have the cl...' RFC 2119 keyword, line 138: '...herName SRVName) MUST be used to speci...' RFC 2119 keyword, line 148: '...eral, the client SHOULD explicitly sig...' RFC 2119 keyword, line 176: '... SHOULD use this extension. This ex...' RFC 2119 keyword, line 207: '...is specification MUST have a signed DN...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 05, 2016) is 3024 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: 'RFC4035' is defined on line 319, but no explicit reference was found in the text == Unused Reference: 'RFC7218' is defined on line 348, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 369, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLSCLIENTID' Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Huque 3 Internet-Draft Verisign Labs 4 Updates: 6698,7671 (if approved) D. James 5 Intended status: Standards Track Verisign, Inc. 6 Expires: July 08, 2016 V. Dukhovni 7 Two Sigma 8 January 05, 2016 10 TLS Client Authentication via DANE TLSA records 11 draft-huque-dane-client-cert-02 13 Abstract 15 The DANE TLSA protocol [RFC6698] [RFC7671] describes how to publish 16 Transport Layer Security (TLS) server certificates or public keys in 17 the DNS. This document updates RFC 6698 and RFC 7671. It describes 18 how to additionally use the TLSA record to publish client 19 certificates or public keys, and also the rules and considerations 20 for using them with TLS. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 08, 2016. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 57 2. Associating Client Identities in TLSA Records . . . . . . . . 2 58 3. Authentication Model . . . . . . . . . . . . . . . . . . . . 3 59 4. Client Identifiers in X.509 certificates . . . . . . . . . . 3 60 5. Signaling the Client's DANE Identity in TLS . . . . . . . . . 4 61 6. Example TLSA records for clients . . . . . . . . . . . . . . 4 62 7. Changes to Client and Server behavior . . . . . . . . . . . . 5 63 8. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . . . 7 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 12.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction and Motivation 74 The Transport Layer Security (TLS) protocol [RFC5246] optionally 75 supports the authentication of clients using X.509 certificates 76 [RFC5280] or raw public keys [RFC7250]. TLS applications that 77 perform DANE authentication of servers using TLSA records may also 78 desire to authenticate clients using the same mechanism, especially 79 if the client identity is in the form of or can be represented by a 80 DNS domain name. Some design patterns from the Internet of Things 81 (IoT) make use of this form of authentication, where large networks 82 of physical objects identified by DNS names may authenticate 83 themselves using TLS to centralized device management and control 84 platforms. 86 In this document, the term TLS is used generically to describe both 87 the TLS and DTLS (Datagram Transport Layer Security) [RFC6347] 88 protocols. 90 2. Associating Client Identities in TLSA Records 92 When specifying client identities (i.e. client domain names) in TLSA 93 records, the owner name of the TLSA record has the following format: 95 _service.[client-domain-name] 97 The first label identifies the application service name. The 98 remaining labels are composed of the client domain name. 100 Encoding the application service name into the owner name allows the 101 same client domain name to have different authentication credentials 102 for different application services. There is no need to encode the 103 transport label - the same name form is usable with both TLS and 104 DTLS. 106 The _service label could be a custom string for an application, but 107 more commonly is expected to be a service name registered in the IANA 108 Service Name Registry [SRVREG]. 110 The RDATA or data field portion of the TLSA record is formed exactly 111 as specified in RFC 6698 and RFC 7671, and carries the same meaning. 113 3. Authentication Model 115 The authentication model assumed in this document is the following: 117 The client is assigned an identity corresponding to a DNS domain 118 name. This domain name doesn't necessarily have any relation to its 119 network layer addresses. Clients often have dynamic or unpredictable 120 addresses, and may move around the network, so tying their identity 121 to network addresses is not feasible or wise in the general case. 123 The client generates (or has generated for it) a private and public 124 key pair. Where client certificates are being used, the client also 125 has a certificate binding the name to its public key. The 126 certificate or public key has a corresponding TLSA record published 127 in the DNS, which allows it to be authenticated directly via the DNS 128 (using the DANE-TA or DANE-EE certificate usage modes) or via a PKIX 129 public CA system constraint (using the PKIX-TA or PKIX-EE certificate 130 usage modes). 132 4. Client Identifiers in X.509 certificates 134 If the TLS DANE Client Identity extension is not being used, the 135 client certificate MUST have have the client's DNS name specified in 136 the Subject Alternative Name extension's dNSName type. Or, if an 137 application specific identity is preferred or needed, the SRV-ID 138 (PKIX OtherName SRVName) MUST be used to specify the application 139 service and the client's name, e.g. "_smtp- 140 client.device1.example.com". See [RFC6125] and [RFC4985] for a 141 discussion of application specific identifiers in X.509 certificates. 143 If the TLS DANE Client Identity extension is in use, then with DANE- 144 EE(3), the subject name need not be present in the certificate. 146 5. Signaling the Client's DANE Identity in TLS 148 In general, the client SHOULD explicitly signal its DANE identity via 149 the TLS protocol. 151 The most important reason is that the server may want an explicit 152 indication from the client that it has a DANE record, so as to avoid 153 unnecessary DNS queries in-band with the TLS handshake for clients 154 that don't support this. In principle, this indication could come in 155 the form of a new X.509 certificate extension but there are a number 156 of additional scenarios where this would not work. 158 Where client certificate authentication is optional, in response to 159 the server's Certificate Request message, the client can respond with 160 a Client Certificate message with no certificate, and the server may 161 at its discretion continue the handshake without client 162 authentication. However, in practice, problems may arise. There are 163 deployed client software implementations that do not react gracefully 164 when encountering a certificate request message from the TLS server 165 that they did not expect. 167 DANE client authentication using raw public keys needs a separate 168 mechanism to convey the domain name identity to the TLS server. 170 Hence, to address this issue generally, a new client identity 171 signaling solution is needed, whereby the client indicates its DANE 172 identity (i.e. its domain name identity and the fact that this 173 identity has an associated TLSA record) to the server. A new TLS 174 extension to convey such an identity [TLSCLIENTID] has been developed 175 for this purpose. Client implementations of this specification 176 SHOULD use this extension. This extension SHOULD also elicit a 177 "Certificate Request" from servers that implement this protocol, and 178 don't require client certificates otherwise. 180 6. Example TLSA records for clients 182 The following examples are provided in the textual presentation 183 format of the TLSA record. 185 An example TLSA record for the client "device1.example.com." and the 186 application "smtp-client". This record specifies the SHA-256 hash of 187 a PKIX CA certificate to authenticate the client's certificate. 189 _smtp-client.device1.example.com. IN TLSA ( 190 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9 191 7983a1d16e8a410e4561cb106618e971 ) 193 An example TLSA record for the client "client2.example.com." and the 194 application "localsvc". This record specifies the SHA-512 hash of 195 the subject public key component of the client's certificate. The 196 certificate usage for this record is 3 (DANE-EE) and thus is 197 validated in accordance with section 5.1 of RFC 7671. 199 _localsvc.client2.example.com. IN TLSA ( 200 3 1 2 0f8b48ff5fd94117f21b6550aaee89c8 201 d8adbc3f433c8e587a85a14e54667b25 202 f4dcd8c4ae6162121ea9166984831b57 203 b408534451fd1b9702f8de0532ecd03c ) 205 7. Changes to Client and Server behavior 207 A TLS Client conforming to this specification MUST have a signed DNS 208 TLSA record published corresponding to its DNS name and X.509 209 certificate or public key. The client presents this certificate or 210 public key in the TLS handshake with the server. The client should 211 not offer ciphersuites that are incompatible with its certificate or 212 public key. If the client's certificate has a DANE record with a 213 certificate usage other than DANE-EE, then the presented client 214 certificate MUST have have the client's DNS name specified either in 215 the Subject Alternative Name extension's dNSName type, or the SRVName 216 type. 218 Additionally the client SHOULD use the TLS DANE Client Identity 219 extension [TLSCLIENTID] to explicitly indicate its DNS name. 221 A TLS Server implementing this specification performs the following 222 steps: 224 o Request a client certificate in the TLS handshake (the "Client 225 Certificate Request" message). This could be done 226 unconditionally, or only when it receives the TLS DANE Client 227 Identity extension from the client. 229 o If the client has sent the DANE Client Identity extension, then 230 extract the client's domain name from the extension. Otherwise, 231 extract the client identity from the Subject Alternative Name 232 extension's dNSName or SRVName type in the client certificate. 234 o Construct the DNS query name for the corresponding TLSA record. 235 If the TLS DANE client identity extension was present, then this 236 name should be used. Otherwise, identities from the client 237 certificate are used. For dNSName, the underscored application 238 service label is prepended to the domain name, corresponding to 239 the application in use. For SRVName, the DNS query name is 240 identical to the content of the SRVName identifier. See Section 2 241 for the proposed owner name format. 243 o Look up the TLSA record set in the DNS. The response MUST be 244 cryptographically validated using DNSSEC. The server could 245 perform the DNSSEC validation itself. It could also be configured 246 to trust responses obtained via a validating resolver to which it 247 has a secure connection. 249 o Extract the RDATA of the TLSA record and match it to the presented 250 client certificate according to the rules specified in the DANE 251 TLS protocol [RFC6698] [RFC7671]. If successfully matched, the 252 client is authenticated and the TLS session proceeds. If 253 unsuccessful, the server MUST treat the client as unauthenticated 254 (e.g. it could terminate the session, or proceed with the session 255 giving the client access to resources as a generic unauthenticated 256 user). 258 o If there are multiple records in the TLSA record set, then the 259 client is authenticated as long as at least one of the TLSA 260 records matches, subject to RFC7671 digest agility, which SHOULD 261 be implemented. 263 If the DANE Client Identity extension is not present, and the 264 presented client certificate has multiple distinct reference 265 identifier types (e.g. a dNSName, and an rfc822Name) then TLS servers 266 configured to perform DANE authentication according to this 267 specification should only examine and authenticate the dNSName or 268 SRVName identity. If the certificate contains both dNSName and 269 SRVName identities, SRVName should be preferred. See [RFC6125] for a 270 description of reference identifiers and matching rules. 272 If the presented client certificate has multiple dNSName or SRVName 273 identities, then the client MUST use the TLS DANE client identity 274 extension to unambiguously indicate its intended name to the server. 276 Specific applications may be designed to require additional 277 validation steps. For example, a server might want to verify the 278 client's IP address is associated with the certificate in some 279 manner, e.g. by confirming that a secure reverse DNS lookup of that 280 address ties it back to the same domain name, or by requiring an 281 iPAddress component to be included in the certificate. Such details 282 are outside the scope of this document, and should be outlined in 283 other documents specific to the applications that require this 284 behavior. 286 Servers may have their own whitelisting and authorization rules for 287 which certificates they accept. For example a TLS server may be 288 configured to only allow TLS sessions from clients with certificate 289 identities within a specific domain or set of domains. 291 8. Raw Public Keys 293 When using raw public keys in TLS [RFC7250], this specification 294 requires the use of the TLS DANE Client Identity extension. The 295 associated DANE TLSA records employ only certificate usage 3 (DANE- 296 EE) and a selector value of 1 (SPKI), as described in [RFC7671]. 298 9. Acknowledgements 300 This document benefited from discussions with the following people: 301 Duane Wessels, Allison Mankin, Casey Deccio, and Warren Kumari. 303 10. IANA Considerations 305 This document includes no request to IANA. 307 11. Security Considerations 309 This document makes a narrow update to RFC 6698 by defining the use 310 of the TLSA record for client TLS certificates. There are no 311 security considerations for this document beyond those described in 312 RFC 6698 and RFC 7671 and in the specifications for TLS and DTLS 313 [RFC5246], [RFC6347]. 315 12. References 317 12.1. Normative References 319 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 320 Rose, "Protocol Modifications for the DNS Security 321 Extensions", RFC 4035, March 2005. 323 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 324 Subject Alternative Name for Expression of Service Name", 325 RFC 4985, August 2007. 327 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 328 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 330 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 331 Housley, R., and W. Polk, "Internet X.509 Public Key 332 Infrastructure Certificate and Certificate Revocation List 333 (CRL) Profile", RFC 5280, May 2008. 335 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 336 Verification of Domain-Based Application Service Identity 337 within Internet Public Key Infrastructure Using X.509 338 (PKIX) Certificates in the Context of Transport Layer 339 Security (TLS)", RFC 6125, March 2011. 341 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 342 Security Version 1.2", RFC 6347, January 2012. 344 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 345 of Named Entities (DANE) Transport Layer Security (TLS) 346 Protocol: TLSA", RFC 6698, August 2012. 348 [RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify 349 Conversations about DNS-Based Authentication of Named 350 Entities (DANE)", RFC 7218, April 2014. 352 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 353 T. Kivinen, "Using Raw Public Keys in Transport Layer 354 Security (TLS) and Datagram Transport Layer Security 355 (DTLS)", RFC 7250, June 2014. 357 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 358 Authentication of Named Entities (DANE) Protocol: Updates 359 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 360 October 2015, . 362 [TLSCLIENTID] 363 Huque, S. and V. Dukhovni, "TLS Extension for DANE Client 364 Identity", , . 367 12.2. Informative References 369 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 370 Text on Security Considerations", BCP 72, RFC 3552, July 371 2003. 373 [SRVREG] IANA, ., "Service Name and Transport Protocol Port Number 374 Registry", , . 377 Authors' Addresses 379 Shumon Huque 380 Verisign Labs 382 Email: shuque@verisign.com 384 Dan James 385 Verisign, Inc. 387 Email: djames@verisign.com 389 Viktor Dukhovni 390 Two Sigma 392 Email: ietf-dane@dukhovni.org