idnits 2.17.1 draft-huque-tls-dane-clientid-06.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: '... this specification MUST 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 (14 February 2022) is 796 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: 18 August 2022 Two Sigma 6 A. Wilson 7 Valimail 8 14 February 2022 10 TLS Extension for DANE Client Identity 11 draft-huque-tls-dane-clientid-06 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 18 August 2022. 37 Copyright Notice 39 Copyright (c) 2022 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 Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised 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 MUST 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. Additionally, in 136 TLS 1.3, the client is only permitted to send the extension if it 137 sees the corresponding empty extension in the server's 138 CertificateRequest message. 140 4. Security Considerations 142 In TLS 1.3, this extension is sent in the CertificateRequest and 143 Certificate messages, which are encrypted. 145 In TLS 1.2, this extension cannot be encrypted. When used with TLS 146 1.2, to prevent unnecessary privacy leakage of the client's name in 147 cleartext, a TLS client implementing this specification should be 148 configured to only send this extension to TLS servers it intends to 149 perform client authentication with. 151 5. IANA Considerations 153 This extension requires the registration of a new value in the TLS 154 ExtensionsType registry. 156 6. Normative References 158 [DANECLIENT] 159 Huque, S., Dukhovni, V., and A. Wilson, "TLS Client 160 Authentication via DANE TLSA Records", 2 May 2021, 161 . 164 [RFC1035] Mockapetris, P., "Domain names - implementation and 165 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 166 November 1987, . 168 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 169 (TLS) Protocol Version 1.2", RFC 5246, 170 DOI 10.17487/RFC5246, August 2008, 171 . 173 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 174 Extensions: Extension Definitions", RFC 6066, 175 DOI 10.17487/RFC6066, January 2011, 176 . 178 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 179 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 180 January 2012, . 182 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 183 of Named Entities (DANE) Transport Layer Security (TLS) 184 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 185 2012, . 187 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 188 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 189 Transport Layer Security (TLS) and Datagram Transport 190 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 191 June 2014, . 193 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 194 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 195 . 197 Authors' Addresses 199 Shumon Huque 200 Salesforce 202 Email: shuque@gmail.com 204 Viktor Dukhovni 205 Two Sigma 207 Email: ietf-dane@dukhovni.org 209 Ash Wilson 210 Valimail 212 Email: ash.wilson@valimail.com