idnits 2.17.1 draft-huque-tls-dane-clientid-01.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 112: '...is specification SHOULD send an extens...' RFC 2119 keyword, line 116: '... 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 (February 19, 2017) is 2622 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) == Missing Reference: 'RFC7120' is mentioned on line 170, but not defined == Unused Reference: 'RFC5246' is defined on line 184, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 204, but no explicit reference was found in the text -- 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 (~~), 4 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 Salesforce 4 Intended status: Standards Track V. Dukhovni 5 Expires: August 23, 2017 Two Sigma 6 February 19, 2017 8 TLS Extension for DANE Client Identity 9 draft-huque-tls-dane-clientid-01 11 Abstract 13 This document specifies a TLS and DTLS extension to convey a DNS- 14 Based Authentication of Named Entities (DANE) Client Identity to a 15 TLS or DTLS server. This is useful for applications that perform TLS 16 client authentication via DANE TLSA records. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 23, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. DANE Client Identity Extension . . . . . . . . . . . . . . . 3 55 4. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 7.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 This document specifies a Transport Layer Security (TLS) extension 66 [RFC6066] to convey a DANE [RFC6698] Client Identity to the TLS 67 server. This is useful for applications that perform TLS client 68 authentication via DANE TLSA records, as described in [DANECLIENT]. 69 The conveyed identity is in the form of a domain name associated with 70 the client that is expected to have a corresponding DANE TLSA record 71 published in the DNS. 73 This extension supports both TLS and DTLS [RFC6347], and the term TLS 74 in this document is used generically to describe both protocols. 76 2. Overview 78 When TLS clients use X.509 client certificates or raw public keys 79 that are authenticated via DANE TLSA records, they need a mechanism 80 to convey their DANE identity to the server. The TLS extension 81 defined in this document is used to accomplish this. Upon receipt of 82 this extension, a TLS server learns the client's identity and the 83 fact that the client expects that the server can authenticate it via 84 a corresponding DNSSEC-validated TLSA record. 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 can use this extension to specify exactly which 95 one the server should use. An additional situation in which this 96 extension helps is where some TLS servers may need to selectively 97 prompt for client certificate credentials only for clients that are 98 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. 104 Detailed protocol behavior of TLS clients and servers is described in 105 [DANECLIENT]. 107 3. DANE Client Identity Extension 109 The DANE Client Identity Extension type, "dane_clientid", will have a 110 value assigned and registered in the IANA TLS Extensions registry. 112 A TLS client implementing this specification SHOULD send an extension 113 of type "dane_clientid" in the ClientHello handshake message to TLS 114 servers it intends to perform DANE client authentication with. 116 The "extension_data" field of the extension MUST contain a 117 "DaneClientName" data structure defined in the following format: 119 enum { 120 dns_name(0), srv_name(1), (255) 121 } NameType; 123 opaque dNSName<1..2^16-1>; 124 opaque SRVName<1..2^16-1>; 126 struct { 127 NameType name_type; 128 select (name_type) { 129 case dns_name: dNSName; 130 case srv_name: SRVName; 131 } name; 132 } DaneClientName; 134 The opaque dNSName or SRVName field contains the domain name of the 135 client in textual presentation format, as described in RFC 1035 136 [RFC1035]. 138 4. Open Questions 140 Should multiple client names be supported in the extension? 142 Is the dNSName/SRVName distinction useful, or can we just simplify 143 and use only dNSName? These two name forms are analogous to the two 144 recommended for use in X.509 certificates in the DANE client 145 authentication draft, so the server could use this to additionally 146 check against the corresponding certificate fields (but does it need 147 to?). If the server needs a hint of whether to construct an 148 application specific ID, then this might be useful, but this could 149 also be inferred from the structure of the name and the client could 150 just specify an application specific identity in the dNSName type. 152 The extension is defined in terms of a DANE specific identity. Is 153 there a need for a more general purpose client name indication 154 extension? If so, this extension could be renamed and augmented to 155 have an additional usage field containing values denoting DANE or 156 alternative application usages. 158 5. Security Considerations 160 To prevent unnecessary privacy leakage of the client's name in 161 cleartext, a TLS client implementing this specification should be 162 configured to only send this extension to TLS servers it intends to 163 perform client authentication with. 165 6. IANA Considerations 167 This extension requires the registration of a new value in the TLS 168 ExtensionsType registry. If the draft is adopted by the WG, the 169 authors expect to make an early allocation request as specified in 170 [RFC7120] 172 7. References 174 7.1. Normative References 176 [DANECLIENT] 177 Huque, S. and V. Dukhovni, "TLS Client Authentication via 178 DANE TLSA Records", , . 181 [RFC1035] Mockapetris, P., "Domain names - implementation and 182 specification", STD 13, RFC 1035, November 1987. 184 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 185 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 187 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 188 Extension Definitions", RFC 6066, January 2011. 190 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 191 Security Version 1.2", RFC 6347, January 2012. 193 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 194 of Named Entities (DANE) Transport Layer Security (TLS) 195 Protocol: TLSA", RFC 6698, August 2012. 197 [RFC7250] Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 198 T. Kivinen, "Using Raw Public Keys in Transport Layer 199 Security (TLS) and Datagram Transport Layer Security 200 (DTLS)", RFC 7250, June 2014. 202 7.2. Informative References 204 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 205 Text on Security Considerations", BCP 72, RFC 3552, July 206 2003. 208 Authors' Addresses 210 Shumon Huque 211 Salesforce 213 Email: shuque@gmail.com 215 Viktor Dukhovni 216 Two Sigma 218 Email: ietf-dane@dukhovni.org