idnits 2.17.1 draft-huque-dane-client-cert-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 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 157: '...ient certificate MUST have have the cl...' RFC 2119 keyword, line 166: '... The client SHOULD explicitly signal...' RFC 2119 keyword, line 221: '...is specification MUST have a signed DN...' RFC 2119 keyword, line 228: '... certificate MUST have have the clie...' RFC 2119 keyword, line 232: '... MUST send the TLS DANE Client Identity extension [TLSCLIENTID] in its...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 October 2020) is 1295 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 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLSCLIENTID' Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 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 Salesforce 4 Updates: 6698, 7671 (if approved) V. Dukhovni 5 Intended status: Standards Track Two Sigma 6 Expires: 11 April 2021 8 October 2020 8 TLS Client Authentication via DANE TLSA records 9 draft-huque-dane-client-cert-04 11 Abstract 13 The DANE TLSA protocol [RFC6698] [RFC7671] describes how to publish 14 Transport Layer Security (TLS) server certificates or public keys in 15 the DNS. This document updates RFC 6698 and RFC 7671. It describes 16 how to additionally use the TLSA record to publish client 17 certificates or public keys, and also the rules and considerations 18 for using them with TLS. 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 https://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 11 April 2021. 37 Copyright Notice 39 Copyright (c) 2020 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 (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 54 2. Associating Client Identities in TLSA Records . . . . . . . . 3 55 2.1. Format 1: Service specific client identity . . . . . . . 3 56 2.2. Format 2: DevId: IOT Device Identity . . . . . . . . . . 3 57 3. Authentication Model . . . . . . . . . . . . . . . . . . . . 3 58 4. Client Identifiers in X.509 certificates . . . . . . . . . . 4 59 5. Signaling the Client's DANE Identity in TLS . . . . . . . . . 4 60 6. Example TLSA records for clients . . . . . . . . . . . . . . 5 61 6.1. Format 1: Service Specific Client Identity . . . . . . . 5 62 6.2. Format 2: DevID . . . . . . . . . . . . . . . . . . . . . 5 63 7. Changes to Client and Server behavior . . . . . . . . . . . . 5 64 8. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . . . 7 65 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 11. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 12.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 12.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction and Motivation 75 The Transport Layer Security (TLS) protocol [RFC5246] [RFC8446] 76 optionally supports the authentication of clients using X.509 77 certificates [RFC5280] or raw public keys [RFC7250]. TLS 78 applications that perform DANE authentication of servers using TLSA 79 records may also desire to authenticate clients using the same 80 mechanism, especially if the client identity is in the form of or can 81 be represented by a DNS domain name. Some design patterns from the 82 Internet of Things (IoT) plan to make use of this form of 83 authentication, where large networks of physical objects identified 84 by DNS names may authenticate themselves using TLS to centralized 85 device management and control platforms. 87 In this document, the term TLS is used generically to describe both 88 the TLS and DTLS (Datagram Transport Layer Security) [RFC6347] 89 protocols. 91 2. Associating Client Identities in TLSA Records 93 Different applications may have quite different conventions for 94 naming clients via domain names. This document thus does not 95 proscribe a single format, but mentions a few that may have wide 96 applicability. 98 2.1. Format 1: Service specific client identity 100 In this format, the owner name of the client TLSA record has the 101 following structure: 103 _service.[client-domain-name] 105 The first label identifies the application service name. The 106 remaining labels are composed of the client domain name. 108 Encoding the application service name into the owner name allows the 109 same client domain name to have different authentication credentials 110 for different application services. There is no need to encode the 111 transport label - the same name form is usable with both TLS and 112 DTLS. 114 The _service label could be a custom string for an application, but 115 more commonly is expected to be a service name registered in the IANA 116 Service Name Registry [SRVREG]. 118 The RDATA or data field portion of the TLSA record is formed exactly 119 as specified in RFC 6698 and RFC 7671, and carries the same meaning. 121 2.2. Format 2: DevId: IOT Device Identity 123 The DevID form of the TLSA record has the following structure: 125 [devicename]._device.[org-domain-name] 127 It is loosely based on the proposed PKI Certificate Identifier Format 128 for Devices [CERTDEVID], but is simpler in form. It makes no 129 distinction between manufacturer issued and locally issued 130 certificates, and does away with the "serial" and "type" labels. The 131 "_device" label that precedes the organization domain name allows all 132 the device identities to be delegated to a subzone or to another 133 party. 135 3. Authentication Model 137 The authentication model assumed in this document is the following: 139 The client is assigned an identity corresponding to a DNS domain 140 name. This domain name doesn't necessarily have any relation to its 141 network layer addresses. Clients often have dynamic or unpredictable 142 addresses, and may move around the network, so tying their identity 143 to network addresses is not feasible or wise in the general case. 145 The client generates (or has generated for it) a private and public 146 key pair. Where client certificates are being used, the client also 147 has a certificate binding the name to its public key. The 148 certificate or public key has a corresponding TLSA record published 149 in the DNS, which allows it to be authenticated directly via the DNS 150 (using the DANE-TA or DANE-EE certificate usage modes) or via a PKIX 151 public CA system constraint if the client's certificate was issued by 152 a public CA (using the PKIX-TA or PKIX-EE DANE usage modes). 154 4. Client Identifiers in X.509 certificates 156 If the TLS DANE Client Identity extension (see Section 5) is not 157 being used, the client certificate MUST have have the client's DNS 158 name specified in the Subject Alternative Name extension's dNSName 159 type. 161 If the TLS DANE Client Identity extension is in use, then with DANE- 162 EE(3), the subject name need not be present in the certificate. 164 5. Signaling the Client's DANE Identity in TLS 166 The client SHOULD explicitly signal that it has a DANE identity. The 167 most important reason is that the server may want an explicit 168 indication from the client that it has a DANE record, so as to avoid 169 unnecessary DNS queries in-band with the TLS handshake. 171 The DANE Client Identity TLS extension [TLSCLIENTID] is used for this 172 purpose. This extension can also be used to convey the actual DANE 173 client identity (i.e. domain name) that the TLS server should attempt 174 to authenticate. This is required when using TLS raw public key 175 authentication, since there is no client certificate from which to 176 extract the client's DNS identity. It is also helpful when the 177 client certificate contains multiple identities, and only a specific 178 one has a DANE record. 180 An additional case where such client signaling is helpful, is one 181 where DANE client authentication is optional, and there is a 182 population of buggy client software that does not react gracefully to 183 receipt of a Certificate Request message from the TLS server. This 184 extension allows TLS servers to deal with this situation by 185 selectively sending a Certificate Request message only to clients 186 that have sent this extension. 188 6. Example TLSA records for clients 190 The following examples are provided in the textual presentation 191 format of the TLSA record. 193 6.1. Format 1: Service Specific Client Identity 195 An example TLSA record for the client "device1.example.com." and the 196 application "smtp-client". This record specifies the SHA-256 hash of 197 the subject public key component of the end-entity certificate 198 corresponding to the client. The certificate usage for this record 199 is 3 (DANE-EE) and thus is validated in accordance with section 5.1 200 of RFC 7671. 202 _smtp-client.device1.example.com. IN TLSA ( 203 3 1 1 d2abde240d7cd3ee6b4b28c54df034b9 204 7983a1d16e8a410e4561cb106618e971 ) 206 6.2. Format 2: DevID 208 An example TLSA record for the device named "sensor7" managed by the 209 organization "example.com" This record specifies the SHA-512 hash of 210 the subject public key component of an EE certificate corresponding 211 to the client. 213 sensor7._device.example.com. IN TLSA ( 214 3 1 2 0f8b48ff5fd94117f21b6550aaee89c8 215 d8adbc3f433c8e587a85a14e54667b25 216 f4dcd8c4ae6162121ea9166984831b57 217 b408534451fd1b9702f8de0532ecd03c ) 219 7. Changes to Client and Server behavior 221 A TLS Client conforming to this specification MUST have a signed DNS 222 TLSA record published corresponding to its DNS name and X.509 223 certificate or public key. The client presents this certificate or 224 public key in the TLS handshake with the server. The client should 225 not offer ciphersuites that are incompatible with its certificate or 226 public key. If the client's certificate has a DANE record with a 227 certificate usage other than DANE-EE, then the presented client 228 certificate MUST have have the client's DNS name specified in the 229 Subject Alternative Name extension's dNSName type. 231 Additionally, when using raw public key authentication, the client 232 MUST send the TLS DANE Client Identity extension [TLSCLIENTID] in its 233 Client Hello message. When using X.509 certificate authentication, 234 it SHOULD send this extension. 236 A TLS Server implementing this specification performs the following 237 steps: 239 * Request a client certificate in the TLS handshake (the "Client 240 Certificate Request" message). This could be done 241 unconditionally, or only when it receives the TLS DANE Client 242 Identity extension from the client. 244 * If the client has sent a non-empty DANE Client Identity extension, 245 then extract the client's domain name from the extension. 246 Otherwise, extract the client identity from the Subject 247 Alternative Name extension's dNSName type. 249 * Construct the DNS query name for the corresponding TLSA record. 250 If the TLS DANE client identity extension was present, then this 251 name should be used. Otherwise, identities from the client 252 certificate are used. 254 * Look up the TLSA record set in the DNS. The response MUST be 255 cryptographically validated using DNSSEC. The server could 256 perform the DNSSEC validation itself. It could also be configured 257 to trust responses obtained via a validating resolver to which it 258 has a secure connection. 260 * Extract the RDATA of the TLSA records and match them to the 261 presented client certificate according to the rules specified in 262 the DANE TLS protocol [RFC6698] [RFC7671]. If successfully 263 matched, the client is authenticated and the TLS session proceeds. 264 If unsuccessful, the server MUST treat the client as 265 unauthenticated (e.g. it could terminate the session, or proceed 266 with the session giving the client access to resources as a 267 generic unauthenticated user). 269 * If there are multiple records in the TLSA record set, then the 270 client is authenticated as long as at least one of the TLSA 271 records matches, subject to RFC7671 digest agility, which SHOULD 272 be implemented. 274 If the DANE Client Identity extension is not present, and the 275 presented client certificate has multiple distinct reference 276 identifier types (e.g. a dNSName, and an rfc822Name) then TLS servers 277 configured to perform DANE authentication according to this 278 specification should only examine and authenticate the dNSName. 280 If the presented client certificate has multiple dNSName identities, 281 then the client MUST use the TLS DANE client identity extension to 282 unambiguously indicate its intended name to the server. 284 Specific applications may be designed to require additional 285 validation steps. For example, a server might want to verify the 286 client's IP address is associated with the certificate in some 287 manner, e.g. by confirming that a secure reverse DNS lookup of that 288 address ties it back to the same domain name, or by requiring an 289 iPAddress component to be included in the certificate. Such details 290 are outside the scope of this document, and should be outlined in 291 other documents specific to the applications that require this 292 behavior. 294 Servers may have their own whitelisting and authorization rules for 295 which certificates they accept. For example a TLS server may be 296 configured to only allow TLS sessions from clients with certificate 297 identities within a specific domain or set of domains. 299 8. Raw Public Keys 301 When using raw public keys in TLS [RFC7250], this specification 302 requires the use of the TLS DANE Client Identity extension. The 303 associated DANE TLSA records employ only certificate usage 3 (DANE- 304 EE) and a selector value of 1 (SPKI), as described in [RFC7671]. 306 9. Acknowledgements 308 TBD. 310 10. IANA Considerations 312 This document includes no request to IANA. 314 11. Security Considerations 316 This document updates RFC 6698 by defining the use of the TLSA record 317 for client TLS certificates. There are no security considerations 318 for this document beyond those described in RFC 6698 and RFC 7671 and 319 in the specifications for TLS and DTLS [RFC8446], [RFC5246], 320 [RFC6347]. 322 12. References 324 12.1. Normative References 326 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 327 (TLS) Protocol Version 1.2", RFC 5246, 328 DOI 10.17487/RFC5246, August 2008, 329 . 331 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 332 Housley, R., and W. Polk, "Internet X.509 Public Key 333 Infrastructure Certificate and Certificate Revocation List 334 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 335 . 337 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 338 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 339 January 2012, . 341 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 342 of Named Entities (DANE) Transport Layer Security (TLS) 343 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 344 2012, . 346 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 347 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 348 Transport Layer Security (TLS) and Datagram Transport 349 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 350 June 2014, . 352 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 353 Authentication of Named Entities (DANE) Protocol: Updates 354 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 355 October 2015, . 357 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 358 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 359 . 361 [TLSCLIENTID] 362 Huque, S. and V. Dukhovni, "TLS Extension for DANE Client 363 Identity", . 366 12.2. Informative References 368 [CERTDEVID] 369 Friel, O. and R. Barnes, "PKI Certificate Identifier 370 Format for Devices", . 373 [SRVREG] IANA, "Service Name and Transport Protocol Port Number 374 Registry", . 377 Authors' Addresses 378 Shumon Huque 379 Salesforce 381 Email: shuque@gmail.com 383 Viktor Dukhovni 384 Two Sigma 386 Email: ietf-dane@dukhovni.org