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