idnits 2.17.1 draft-huque-tls-dane-clientid-05.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 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 120: '...g this specification MAY send an empty...' RFC 2119 keyword, line 126: '...is specification SHOULD send an extens...' RFC 2119 keyword, line 131: '... field of the extension MUST contain a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (5 July 2021) is 1025 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'DANECLIENT' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 3 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 Intended status: Standards Track V. Dukhovni 5 Expires: 6 January 2022 Two Sigma 6 A. Wilson 7 Valimail 8 5 July 2021 10 TLS Extension for DANE Client Identity 11 draft-huque-tls-dane-clientid-05 13 Abstract 15 This document specifies a TLS and DTLS extension to convey a DNS- 16 Based Authentication of Named Entities (DANE) Client Identity to a 17 TLS or DTLS server. This is useful for applications that perform TLS 18 client authentication via DANE TLSA records. 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 6 January 2022. 37 Copyright Notice 39 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. DANE Client Identity Extension . . . . . . . . . . . . . . . 3 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 58 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 61 1. Introduction 63 This document specifies a Transport Layer Security (TLS) extension 64 [RFC6066] to convey a DANE [RFC6698] Client Identity to the TLS 65 server. This is useful for applications that perform TLS client 66 authentication via DANE TLSA records, as described in [DANECLIENT]. 67 The extension could be empty to indicate to the server that the 68 client has a DANE record and that the server can perform DANE 69 authentication of the client with the identity extracted from the 70 client certificate. Or the extension can contain the full client 71 identity, in the form of the DNS domain name that is expected to have 72 a DANE TLSA record published for it. 74 This extension supports both TLS [RFC5246] [RFC8446] and DTLS 75 [RFC6347], and the term TLS in this document is used generically to 76 describe both protocols. 78 2. Overview 80 When TLS clients use X.509 client certificates or raw public keys 81 that are authenticated via DANE TLSA records, it is useful for them 82 to convey their intent to be authenticated via DANE, or even to 83 convey their complete DANE identity to the server. The TLS extension 84 defined in this document is used to accomplish this. 86 In the case of X.509 client certificates, a TLS server can learn the 87 client's identity by examining subject alternative names included in 88 the certificate itself. However, without a mechanism such as the one 89 defined in this extension, the TLS server cannot know apriori that 90 the client has a published TLSA record, and thus may unnecessarily 91 issue DNS queries for DANE TLSA records in-band with the TLS 92 handshake even in cases where the client has no TLSA record 93 associated with it. When multiple identities are present in the 94 certificate, a client must use this extension to specify exactly 95 which one the server should use. An additional situation in which 96 this extension helps is where some TLS servers may need to 97 selectively prompt for client certificate credentials only for 98 clients that are equipped to provide certificates. 100 When TLS raw public keys [RFC7250] are being used to authenticate the 101 client, the client uses this extension to explicitly indicate to the 102 server what its domain name identity is (since there is no X.509 103 certificate from which the identity can be extracted). 105 Detailed protocol behavior of TLS clients and servers is described in 106 [DANECLIENT]. 108 3. DANE Client Identity Extension 110 The DANE Client Identity Extension type, "dane_clientid", will have a 111 value assigned and registered in the IANA TLS Extensions registry. 112 Its extension data (if not empty) has the following format: 114 opaque ClientName<1..2^8-1>; 116 The ClientName field contains the single domain name of the client in 117 textual presentation format, as described in RFC 1035 [RFC1035], 118 omitting the trailing dot. 120 A TLS server implementing this specification MAY send an empty 121 extension of type "dane_clientid" to indicate that it understands the 122 extension and is capable of performing DANE client authentication. 123 In TLS 1.2, the empty extension is sent in the ServerHello message. 124 In TLS 1.3, it is sent in the CertificateRequest message. 126 A TLS client implementing this specification SHOULD send an extension 127 of type "dane_clientid". If the client only needs to indicate that 128 it has a DANE record and that the client's domain name identity can 129 be obtained from its certificate, then the extension sent can be 130 empty. If the client needs to send its domain name identity, then 131 the "extension_data" field of the extension MUST contain a 132 "ClientName" data structure populated with the domain name. 134 In TLS 1.2, the client extension is sent in the ClientHello message. 135 In TLS 1.3, it is sent in the Certificate message. 137 4. Security Considerations 139 In TLS 1.3, this extension is sent in the CertificateRequest and 140 Certificate messages, which are encrypted. 142 In TLS 1.2, this extension cannot be encrypted. When used with TLS 143 1.2, to prevent unnecessary privacy leakage of the client's name in 144 cleartext, a TLS client implementing this specification should be 145 configured to only send this extension to TLS servers it intends to 146 perform client authentication with. 148 5. IANA Considerations 150 This extension requires the registration of a new value in the TLS 151 ExtensionsType registry. 153 6. Normative References 155 [DANECLIENT] 156 Huque, S., Dukhovni, V., and A. Wilson, "TLS Client 157 Authentication via DANE TLSA Records", 2 May 2021, 158 . 161 [RFC1035] Mockapetris, P., "Domain names - implementation and 162 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 163 November 1987, . 165 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 166 (TLS) Protocol Version 1.2", RFC 5246, 167 DOI 10.17487/RFC5246, August 2008, 168 . 170 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 171 Extensions: Extension Definitions", RFC 6066, 172 DOI 10.17487/RFC6066, January 2011, 173 . 175 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 176 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 177 January 2012, . 179 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 180 of Named Entities (DANE) Transport Layer Security (TLS) 181 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 182 2012, . 184 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 185 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 186 Transport Layer Security (TLS) and Datagram Transport 187 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 188 June 2014, . 190 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 191 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 192 . 194 Authors' Addresses 196 Shumon Huque 197 Salesforce 199 Email: shuque@gmail.com 201 Viktor Dukhovni 202 Two Sigma 204 Email: ietf-dane@dukhovni.org 206 Ash Wilson 207 Valimail 209 Email: ash.wilson@valimail.com