[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                                 S. Huque
Internet-Draft                                                Salesforce
Intended status: Standards Track                             V. Dukhovni
Expires: August 23, 2017                                       Two Sigma
                                                       February 19, 2017


                 TLS Extension for DANE Client Identity
                    draft-huque-tls-dane-clientid-01

Abstract

   This document specifies a TLS and DTLS extension to convey a DNS-
   Based Authentication of Named Entities (DANE) Client Identity to a
   TLS or DTLS server.  This is useful for applications that perform TLS
   client authentication via DANE TLSA records.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 23, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Huque & Dukhovni         Expires August 23, 2017                [Page 1]


Internet-Draft         TLS DANE ClientID Extension         February 2017


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  DANE Client Identity Extension  . . . . . . . . . . . . . . .   3
   4.  Open Questions  . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   This document specifies a Transport Layer Security (TLS) extension
   [RFC6066] to convey a DANE [RFC6698] Client Identity to the TLS
   server.  This is useful for applications that perform TLS client
   authentication via DANE TLSA records, as described in [DANECLIENT].
   The conveyed identity is in the form of a domain name associated with
   the client that is expected to have a corresponding DANE TLSA record
   published in the DNS.

   This extension supports both TLS and DTLS [RFC6347], and the term TLS
   in this document is used generically to describe both protocols.

2.  Overview

   When TLS clients use X.509 client certificates or raw public keys
   that are authenticated via DANE TLSA records, they need a mechanism
   to convey their DANE identity to the server.  The TLS extension
   defined in this document is used to accomplish this.  Upon receipt of
   this extension, a TLS server learns the client's identity and the
   fact that the client expects that the server can authenticate it via
   a corresponding DNSSEC-validated TLSA record.
















Huque & Dukhovni         Expires August 23, 2017                [Page 2]


Internet-Draft         TLS DANE ClientID Extension         February 2017


   In the case of X.509 client certificates, a TLS server can learn the
   client's identity by examining subject alternative names included in
   the certificate itself.  However, without a mechanism such as the one
   defined in this extension, the TLS server cannot know apriori that
   the client has a published TLSA record, and thus may unnecessarily
   issue DNS queries for DANE TLSA records in-band with the TLS
   handshake even in cases where the client has no TLSA record
   associated with it.  When multiple identities are present in the
   certificate, a client can use this extension to specify exactly which
   one the server should use.  An additional situation in which this
   extension helps is where some TLS servers may need to selectively
   prompt for client certificate credentials only for clients that are
   equipped to provide certificates.

   When TLS raw public keys [RFC7250] are being used to authenticate the
   client, the client uses this extension to explicitly indicate to the
   server what its domain name identity is.

   Detailed protocol behavior of TLS clients and servers is described in
   [DANECLIENT].

3.  DANE Client Identity Extension

   The DANE Client Identity Extension type, "dane_clientid", will have a
   value assigned and registered in the IANA TLS Extensions registry.

   A TLS client implementing this specification SHOULD send an extension
   of type "dane_clientid" in the ClientHello handshake message to TLS
   servers it intends to perform DANE client authentication with.

   The "extension_data" field of the extension MUST contain a
   "DaneClientName" data structure defined in the following format:



















Huque & Dukhovni         Expires August 23, 2017                [Page 3]


Internet-Draft         TLS DANE ClientID Extension         February 2017


   enum {
       dns_name(0), srv_name(1), (255)
   } NameType;

   opaque dNSName<1..2^16-1>;
   opaque SRVName<1..2^16-1>;

   struct {
       NameType name_type;
       select (name_type) {
           case dns_name: dNSName;
           case srv_name: SRVName;
       } name;
   } DaneClientName;


   The opaque dNSName or SRVName field contains the domain name of the
   client in textual presentation format, as described in RFC 1035
   [RFC1035].

4.  Open Questions

   Should multiple client names be supported in the extension?

   Is the dNSName/SRVName distinction useful, or can we just simplify
   and use only dNSName?  These two name forms are analogous to the two
   recommended for use in X.509 certificates in the DANE client
   authentication draft, so the server could use this to additionally
   check against the corresponding certificate fields (but does it need
   to?).  If the server needs a hint of whether to construct an
   application specific ID, then this might be useful, but this could
   also be inferred from the structure of the name and the client could
   just specify an application specific identity in the dNSName type.

   The extension is defined in terms of a DANE specific identity.  Is
   there a need for a more general purpose client name indication
   extension?  If so, this extension could be renamed and augmented to
   have an additional usage field containing values denoting DANE or
   alternative application usages.

5.  Security Considerations

   To prevent unnecessary privacy leakage of the client's name in
   cleartext, a TLS client implementing this specification should be
   configured to only send this extension to TLS servers it intends to
   perform client authentication with.





Huque & Dukhovni         Expires August 23, 2017                [Page 4]


Internet-Draft         TLS DANE ClientID Extension         February 2017


6.  IANA Considerations

   This extension requires the registration of a new value in the TLS
   ExtensionsType registry.  If the draft is adopted by the WG, the
   authors expect to make an early allocation request as specified in
   [RFC7120]

7.  References

7.1.  Normative References

   [DANECLIENT]
              Huque, S. and V. Dukhovni, "TLS Client Authentication via
              DANE TLSA Records", , <https://tools.ietf.org/html/draft-
              huque-dane-client-cert>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
              Extension Definitions", RFC 6066, January 2011.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, August 2012.

   [RFC7250]  Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
              T. Kivinen, "Using Raw Public Keys in Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", RFC 7250, June 2014.

7.2.  Informative References

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552, July
              2003.









Huque & Dukhovni         Expires August 23, 2017                [Page 5]


Internet-Draft         TLS DANE ClientID Extension         February 2017


Authors' Addresses

   Shumon Huque
   Salesforce

   Email: shuque@gmail.com


   Viktor Dukhovni
   Two Sigma

   Email: ietf-dane@dukhovni.org







































Huque & Dukhovni         Expires August 23, 2017                [Page 6]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/