idnits 2.17.1 draft-huque-dane-client-cert-00.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]), 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 227: '...is specification MUST have a signed DN...' RFC 2119 keyword, line 230: '... The presented client certificate MUST...' RFC 2119 keyword, line 251: '...cord in the DNS. The response MUST be...' (1 more instance...) -- The draft header indicates that this document updates RFC6698, but the abstract doesn't seem to directly say this. It does mention RFC6698 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2015) is 3219 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 332, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 372, 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) Summary: 5 errors (**), 0 flaws (~~), 3 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 (if approved) D. James 5 Intended status: Standards Track Verisign, Inc. 6 Expires: December 29, 2015 V. Dukhovni 7 Two Sigma 8 June 27, 2015 10 Client Certificates in DANE TLSA Records 11 draft-huque-dane-client-cert-00 13 Abstract 15 The current DNS TLSA record format [RFC6698] describes how to specify 16 TLS server certificates or their public keys in the DNS. This 17 document makes a narrowly focused update to RFC 6698. It describes 18 how to additionally use the TLSA record to specify TLS client 19 certificates and the rules and considerations for using them. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 29, 2015. 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 2 56 2. Associating Client Identities in TLSA Records . . . . . . . . 2 57 3. Authentication Model . . . . . . . . . . . . . . . . . . . . 3 58 4. Client Identifiers in X.509 certificates . . . . . . . . . . 3 59 5. Signaling the Client's DANE Identity in TLS . . . . . . . . . 4 60 6. Example TLSA records for clients . . . . . . . . . . . . . . 4 61 7. Changes to Client and Server behavior . . . . . . . . . . . . 5 62 8. Raw Public Keys . . . . . . . . . . . . . . . . . . . . . . . 7 63 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 12. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 13.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 13.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]. TLS Applications currently employing DANE authentication 77 of servers using TLSA records may also desire to authenticate clients 78 using the same mechanism, especially if the client identity is in the 79 form of or can be represented by a DNS domain name. Some design 80 patterns from the Internet of Things (IoT) make use of this form of 81 authentication, where large networks of physical objects identified 82 by DNS names may authenticate themselves using TLS to centralized 83 device management and control platforms. 85 In this document, the term TLS is used generically to describe both 86 the TLS and DTLS (Datagram Transport Layer Security) [RFC6347] 87 protocols. 89 2. Associating Client Identities in TLSA Records 91 When specifying client identities (i.e. client domain names) in TLSA 92 records, the owner name of the TLSA record is proposed to have one of 93 the two formats described below: 95 Format 1: The first label identifies the application service, and the 96 second identifies the transport protocol. The remaining labels are 97 composed of the client domain name. So the form looks like 98 _service._transport.[client-domain-name]. 100 Format 2: The first label is the constant string "_client" and the 101 second label identifies the application service. The remaining 102 labels are composed of the client domain name. So the form looks 103 like _client._service.[client-domain-name]. This form is transport 104 protocol agnostic, and has a constant string that can be used to 105 easily identify TLSA records for client certificates. 107 Encoding the application service name into the owner name allows the 108 same client domain name to have different authentication credentials 109 for different application services. 111 The _service label could be a custom string for an application, but 112 more commonly is expected to be service name registered in the IANA 113 Service Name Registry [SRVREG]. 115 Note: The final version of this document will specify only one format 116 for the owner name, based on IETF working group consensus. 118 The RDATA or data field portion of the TLSA record is formed exactly 119 as specified in RFC 6698, and carries the same meaning. 121 3. Authentication Model 123 The authentication model assumed in this document is the following: 124 The client is assigned an identity corresponding to a DNS domain name 125 (which does not necessarily have any relation to its network layer 126 addresses). The client generates (or has generated for it) a private 127 and public key pair, and a certificate binding the name to its public 128 key. This certificate has a corresponding TLSA record published in 129 the DNS, which allows it to be authenticated directly via the DNS 130 (using the DANE-TA or DANE-EE usage modes) or via a PKIX public CA 131 system constraint (using the PKIX-TA or PKIX-EE usage modes). 133 4. Client Identifiers in X.509 certificates 135 The client certificate MUST have have the client's DNS name specified 136 in 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 The initial revision of this document talks mainly about dNSName 144 identifiers, because SRV-ID has not seen much adoption in the 145 Internet to date. However, with TLSA usage modes except for DANE-EE, 146 there may be a problem separating different client credentials with 147 the same underlying domain name, but distinct services unless SRV-ID 148 is employed. 150 5. Signaling the Client's DANE Identity in TLS 152 The protocol described in the initial version of this document 153 assumes either that client authentication is mandatory, or that where 154 it is optional, clients can handle a Client Certificate Request 155 message from the server without issues if they are not equipped with 156 client certificates. Technically, the TLS protocol specification 157 states that the client may respond with a Client Certificate message 158 with no certificate, and that the server may at its discretion 159 continue the handshake without client authentication. However in 160 practice, problems may arise. There are deployed client software 161 implementations that do not react gracefully when encountering a 162 certificate request that they did not expect. 164 Furthermore, a server may want an explicit indication from the client 165 that it has a DANE record, so as to avoid unnecessary DNS queries in- 166 band with the TLS handshake for clients that don't support this. 168 Hence, to address this issue generally, a client identity signaling 169 solution will need to be devised, whereby the client indicates its 170 DANE identity (i.e. its domain name identity and the fact that this 171 identity has an associated TLSA record) to the server. Application 172 specific protocol enhancements are one way to achieve this, e.g. a 173 new SMTP command. A more general way would be to develop a new TLS 174 extension to convey this information. 176 [Another internet draft is currently being written to define such a 177 TLS extension to convey DANE client identity.] 179 6. Example TLSA records for clients 181 The following examples are provided in the textual presentation 182 format of the TLSA record. 184 An example TLSA record for the client "device1.example.com." and the 185 application "smtp-client" on transport "tcp". This record record 186 specifies the use of TLS, and specifies the SHA-256 hash of a PKIX CA 187 certificate to authenticate the client's certificate. 189 Format 1: 190 _smtp-client._tcp.device1.example.com. IN TLSA ( 191 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9 192 7983a1d16e8a410e4561cb106618e971 ) 194 Format 2: 195 _client._smtp-client.device1.example.com. IN TLSA ( 196 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9 197 7983a1d16e8a410e4561cb106618e971 ) 199 An example TLSA record for the client "device2.example.com." and the 200 application "localsvc" on transport "udp". This record specifies the 201 use of DTLS, and specifies the SHA-512 hash of the subject public key 202 component of the client's certificate. The usage mode for this 203 record is 3 (DANE-EE) and hence no PKIX validation for this 204 certificate should be performed. 206 Format 1: 207 _localsvc._udp.device2.example.com. IN TLSA ( 208 3 1 2 0f8b48ff5fd94117f21b6550aaee89c8 209 d8adbc3f433c8e587a85a14e54667b25 210 f4dcd8c4ae6162121ea9166984831b57 211 b408534451fd1b9702f8de0532ecd03c ) 213 Format 2: 214 _client._localsvc.device2.example.com. IN TLSA ( 215 3 1 2 0f8b48ff5fd94117f21b6550aaee89c8 216 d8adbc3f433c8e587a85a14e54667b25 217 f4dcd8c4ae6162121ea9166984831b57 218 b408534451fd1b9702f8de0532ecd03c ) 220 7. Changes to Client and Server behavior 222 [Note: As the client identity signaling solution is developed, this 223 section will undergo enhancements to use it. A future revision of 224 this document will also explicitly address the use case of raw public 225 keys instead of X.509 certificates.] 227 A TLS Client conforming to this specification MUST have a signed DNS 228 TLSA record published corresponding to its DNS name and X.509 229 certificate. The client presents this certificate in the TLS 230 handshake with the server. The presented client certificate MUST 231 have have the client's DNS name specified either in the Subject 232 Alternative Name extension's dNSName type, or the SRVName type. 234 A TLS Server implementing this specification performs the following 235 steps: 237 S1 Request a client certificate in the TLS handshake (the "Client 238 Certificate Request" message). 240 S2 Extract the client identity from the Subject Alternative Name 241 extension's dNSName or SRVName type in the client certificate. 242 (If no client certificate is provided, then the server may 243 terminate the connection, or at its discretion may continue the 244 handshake without client authentication.) 246 S3 Construct the DNS query name for the corresponding TLSA record, 247 by prepending the application service, transport protocol, and 248 "_client" labels according to which format is being used. See 249 Section 2 for the proposed owner name formats. 251 S4 Look up the TLSA record in the DNS. The response MUST be 252 cryptographically validated using DNSSEC. The server could 253 perform the DNSSEC validation itself. It could also be 254 configured to trust responses obtained via a validating resolver 255 to which it has a secure connection. 257 S5 Extract the RDATA of the TLSA record and match it to the 258 presented client certificate according to the rules specified in 259 the DANE TLS protocol [RFC6698]. If successfully matched, the 260 client is authenticated and the TLS session proceeds. If not, 261 the session is terminated with a "bad_certificate" alert message. 263 S6 If there are multiple records in the TLSA record set, then the 264 client is authenticated as long as at least one of the TLSA 265 records matches. 267 Specific applications may be designed to require more detailed 268 validation steps. For example, a server might want to verify the 269 client's IP address is associated with the certificate in some 270 manner, e.g. by confirming that a secure reverse DNS lookup of that 271 address ties it back to the same domain name, or by requiring an 272 iPAddress component to be included in the certificate. Such details 273 are outside the scope of this document, and should be outlined in 274 other application specific documents. 276 Servers may have their own whitelisting and authorization rules for 277 which certificates they accept. For example a TLS server may be 278 configured to only allow TLS sessions from clients with certificate 279 identities within a specific domain or set of domains. 281 If the presented client certificate has multiple distinct reference 282 identifier types (e.g. a dNSName, and an rfc822Name) then TLS servers 283 configured to perform DANE authentication according to this 284 specification should only examine and authenticate the dNSName or 285 SRVName identity. See [RFC6125] for a description of reference 286 identifiers and matching rules. 288 If the presented client certificate has multiple dNSName or SRVName 289 identities, then the client MUST use an identity signalling mechanism 290 to indicate the intended name to the server. 292 8. Raw Public Keys 294 This specification can also support the use of raw public keys in TLS 295 [RFC7250]. This use case employs only usage mode 3 (DANE-EE) and a 296 selector value of 1 (SPKI) in the DANE TLSA record, as described in 297 [DANERAW]. It requires the use of the new client identity signaling 298 solution discussed previously. 300 9. Open Issues 302 Should this document also consider client identities in the form of 303 e-mail addresses? The use case might be an SMTP client talking to an 304 SMTP submission server. In that case, the email address of a user 305 would most likely be conveyed in the certificate in a subject alt 306 name rfc822Name type. The corresponding TLSA record would have to 307 then have an owner name format similar to the OPENPGPKEY or SMIMEA 308 records. This use case might be best left to the SMIMEA 309 specification to consider. 311 10. Acknowledgements 313 This document benefited from discussions with the following people: 314 Duane Wessels, Allison Mankin, Casey Deccio, and Warren Kumari. 316 11. IANA Considerations 318 This document includes no request to IANA. 320 12. Security Considerations 322 This document makes a narrow update to RFC 6698 by defining the usage 323 of the TLSA record for client TLS certificates. There are no 324 security considerations for this document beyond those described in 325 RFC 6698 and in the specifications for TLS and DTLS [RFC5246], 326 [RFC6347]. 328 13. References 330 13.1. Normative References 332 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 333 Rose, "Protocol Modifications for the DNS Security 334 Extensions", RFC 4035, March 2005. 336 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure 337 Subject Alternative Name for Expression of Service Name", 338 RFC 4985, August 2007. 340 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 341 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 343 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 344 Housley, R., and W. Polk, "Internet X.509 Public Key 345 Infrastructure Certificate and Certificate Revocation List 346 (CRL) Profile", RFC 5280, May 2008. 348 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 349 Verification of Domain-Based Application Service Identity 350 within Internet Public Key Infrastructure Using X.509 351 (PKIX) Certificates in the Context of Transport Layer 352 Security (TLS)", RFC 6125, March 2011. 354 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 355 Security Version 1.2", RFC 6347, January 2012. 357 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 358 of Named Entities (DANE) Transport Layer Security (TLS) 359 Protocol: TLSA", RFC 6698, August 2012. 361 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 362 T. Kivinen, "Using Raw Public Keys in Transport Layer 363 Security (TLS) and Datagram Transport Layer Security 364 (DTLS)", RFC 7250, June 2014. 366 13.2. Informative References 368 [DANERAW] Gilmore, J., "Authenticating Raw Public Keys with DANE 369 TLSA", , . 372 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 373 Text on Security Considerations", BCP 72, RFC 3552, July 374 2003. 376 [SRVREG] IANA, ., "Service Name and Transport Protocol Port Number 377 Registry", , . 380 Authors' Addresses 382 Shumon Huque 383 Verisign Labs 384 12061 Bluemont Way 385 Reston, VA 20190 386 US 388 Email: shuque@verisign.com 390 Dan James 391 Verisign, Inc. 392 12061 Bluemont Way 393 Reston, VA 20190 394 US 396 Email: djames@verisign.com 398 Viktor Dukhovni 399 Two Sigma 401 Email: ietf-dane@dukhovni.org