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

Versions: 00 01 02 03 04

Network Working Group                                        R. Van Rein
Internet-Draft                                                 ARPA2.net
Intended status: Standards Track                           June 13, 2016
Expires: December 15, 2016


               TLS-KDH: Kerberos + Diffie-Hellman in TLS
                        draft-vanrein-tls-kdh-04

Abstract

   This specification defines a TLS message flow with Kerberos-based
   (mutual) authentication, binding in Elliptic-Curve Diffie-Hellman to
   achieve Forward Secrecy for the session.

   TODO: Deprecates RFC2712

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 December 15, 2016.

Copyright Notice

   Copyright (c) 2016 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.



Van Rein                Expires December 15, 2016               [Page 1]


Internet-Draft                   TLS-KDH                       June 2016


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Extending Kerberos to support TLS . . . . . . . . . . . . . .   4
     2.1.  Checksum Types for use with TLS . . . . . . . . . . . . .   4
     2.2.  Authenticators as Signatures  . . . . . . . . . . . . . .   4
     2.3.  Tickets in the TLS Certificate flow . . . . . . . . . . .   5
     2.4.  AuthorizationData for Backend Services  . . . . . . . . .   6
   3.  Extending TLS to support Kerberos . . . . . . . . . . . . . .   7
     3.1.  Conceptual Data Model Extensions  . . . . . . . . . . . .   7
     3.2.  Certificate Type KerberosTicket . . . . . . . . . . . . .   7
     3.3.  Signature Algorithms  . . . . . . . . . . . . . . . . . .   7
     3.4.  KDH-only CipherSuites . . . . . . . . . . . . . . . . . .   8
     3.5.  TicketRequestFlags Extension  . . . . . . . . . . . . . .   9
     3.6.  TLS Connection Expiration . . . . . . . . . . . . . . . .  11
     3.7.  Interaction with Applications . . . . . . . . . . . . . .  11
     3.8.  Kerberos-Only TLS Application Profile . . . . . . . . . .  11
   4.  The Message Flow of TLS-KDH . . . . . . . . . . . . . . . . .  12
     4.1.  ClientHello . . . . . . . . . . . . . . . . . . . . . . .  13
     4.2.  ServerHello . . . . . . . . . . . . . . . . . . . . . . .  13
     4.3.  Server Certificate  . . . . . . . . . . . . . . . . . . .  14
     4.4.  ServerKeyExchange . . . . . . . . . . . . . . . . . . . .  14
     4.5.  CertificateRequest  . . . . . . . . . . . . . . . . . . .  14
     4.6.  Client Certificate  . . . . . . . . . . . . . . . . . . .  15
     4.7.  ClientKeyExhange  . . . . . . . . . . . . . . . . . . . .  16
     4.8.  CertificateVerify . . . . . . . . . . . . . . . . . . . .  16
     4.9.  Finished  . . . . . . . . . . . . . . . . . . . . . . . .  17
   5.  Comparison to Earlier Work  . . . . . . . . . . . . . . . . .  17
   6.  Efficiency Considerations . . . . . . . . . . . . . . . . . .  18
   7.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  19
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  20
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  23
     10.2.  Informative References . . . . . . . . . . . . . . . . .  24
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  25
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Introduction

   Kerberos lends itself well to infrastructure-supported mutual
   authentication, and can even be used to crossover between realms.  A
   downside of this infrastructure is that a crack of one key can lead
   to a cascade of reverse-engineered keys.  Diffie-Hellman key
   exchange, nowadays primarily in its Elliptic-Curve variation, can be
   used to incorporate the desirable property of Forward Secrecy, but
   its vulnerability to man-in-the-middle attacks must then be overcome
   by cryptographically binding it to an authentication mechanism.



Van Rein                Expires December 15, 2016               [Page 2]


Internet-Draft                   TLS-KDH                       June 2016


   This specification describes how Kerberos data structures can be used
   for TLS client authentication, by introducing a new certificate type
   for use with TLS.  The server can choose to provide a Certificate
   with a traditional signing mechanism such as RSA for authentication,
   in which case this specification speaks of a KDH-enhanced exchange;
   even when presenting no server certificate at all, a client-side
   Kerberos ticket can be used for mutual authentication in what will
   then be called a KDH-only exchange.  The KDH-enhanced variety uses
   existing CipherSuite, and KDH-only defines new CipherSuites.  Both
   KDH-enhanced and KDH-only message flows will be referred to as TLS-
   KDH.

   A variation of the KDH-only flow does incorporate a server-side
   ticket; this can be used for user-to-user authentication, perhaps to
   be used in peer-to-peer protocols that use TLS-KDH as their security
   foundation.

   Both TLS-KDH variations form a cryptographic binding between Kerberos
   and Elliptic-Curve Diffie-Hellman (ECDH), leading to the combined
   advantages of infrastructure-supported mutual authentication and
   Forward Secrecy.

   The normal flow of TLS-KDH messages is basically a standard
   interaction with a modified form of client Certificate and
   CertificateVerify:

       Client                                               Server

       ClientHello                  -------->
                                                       ServerHello
                                                Server Certificate*
                                                 ServerKeyExchange
                                                CertificateRequest
                                    <--------      ServerHelloDone
       Client Certificate
       ClientKeyExchange
       CertificateVerify
      [ChangeCipherSpec]
       Finished                     -------->
                                                 [ChangeCipherSpec]
                                    <--------             Finished
       Application Data             <------->     Application Data

   * Indicates that Server Certificate may be empty; it is present in
   KDH-enhanced message flows, and usually empty in KDH-only message
   flows.





Van Rein                Expires December 15, 2016               [Page 3]


Internet-Draft                   TLS-KDH                       June 2016


   [] Indicates that ChangeCipherSpec is an independent TLS protocol
   content type; it is not actually a TLS handshake message.

2.  Extending Kerberos to support TLS

   This section specifies individual extensions to Kerberos that make it
   possible to use TLS.

2.1.  Checksum Types for use with TLS

   The IANA registry of Kerberos Parameters defines a number of Checksum
   Types.  This includes keyed and non-keyed checksums.  We introduce
   checksum types to match the secure hash algorithms that are used in
   TLS.

   There already are two values to represent SHA1.  An implementation
   that processes Checksum Types MAY send either and MUST accept both as
   equivalent indications.

   The following additional Checksum Types are introduced for use with
   TLS [Section 7.4.1.4.1 of [RFC5246]]:

   o  SHA224

   o  SHA256

   o  SHA384

   o  SHA512

2.2.  Authenticators as Signatures

   Kerberos has a symmetric analogue to a signature, in the form of an
   Authenticator [Section 5.5.1 of [RFC4120]].  When used in TLS-KDH,
   the Authenticator MUST have a secure hash embedded in the cksum
   field.  The checksum type used in the context of TLS MUST be taken to
   match one of the entries in IANA's TLS HashAlgorithm Registry.

   The Authenticator is not sent in the plain, but encrypted with a
   Kerberos session key as EncryptedData [Section 5.2.9 of [RFC4120]]
   and this is how Kerberos derives authenticity: only the client and
   the service can pack and unpack the EncryptedData and process the
   Authenticator.

   A standard part of an Authenticator is a timestamp with microsecond
   accuracy.  This is validated within a small window around the
   independently sycnchronised time of the TLS client and server.  It is




Van Rein                Expires December 15, 2016               [Page 4]


Internet-Draft                   TLS-KDH                       June 2016


   customary to allow a time window of about 5 minutes around the server
   time.

   To avoid replay attacks, Kerberos solutions sometimes need to
   remember received Authenticators, or their time stamps, until the
   time window has passed.  This complicates servers, especially for
   redundant deployments.  As used in TLS-KDH, with entropy from both
   end in the hello exchange and with session-specific keys agreed
   through ephemeral ECDH, there is no need for such infrastructure to
   avoid replay attacks.  Notwithstanding that it is not as strong a
   requirement as under other Kerberos applications, the cusec and ctime
   fields are present in the Authenticator and MUST be filled with the
   current time by the TLS-KDH client, and SHOULD be verified to fall
   within a reasonable time frame on the TLS-KDH server.

   In KDH-Enhanced mode an Authenticator MUST NOT contain a subkey
   field.  In KDH-only mode, such a field MUST be supplied as input to
   the premaster secret computation.

   Other fields in the Authenticator than specified above SHOULD NOT be
   produced and MUST be ignored by the recipient.

   The representation on the wire matches the DigitallySigned structure
   [Section 4.7 of [RFC5246]] with the signature algorithm set to
   kerberos, the hash set as desired for the TLS flow.  The opaque
   contents of the signature are filled with the literal bytes of the
   Authenticator, which MUST NOT be an empty string.

2.3.  Tickets in the TLS Certificate flow

   This specification defines a new certificate type [RFC7250] named
   KerberosTicket, to be negotiated for the client and, though only in
   special circumstances, for the server.

   The Kerberos Ticket is included in certificate messages following
   this syntax:

   struct {
       select(certificate_type){

            // certificate type defined in this document.
            case KerberosTicket: opaque Ticket<0..2^24-1>;

           // Additional certificate type based on
           // "TLS Certificate Types" subregistry
       };
   } Certificate;




Van Rein                Expires December 15, 2016               [Page 5]


Internet-Draft                   TLS-KDH                       June 2016


   In this syntax, Ticket holds the DER-encoded form of a Kerberos
   Ticket [Section 5.3 of [RFC4120]].  The special case where the Ticket
   field has length 0 marks an invalid ticket representation, and is
   treated by TLS-KDH as a refusal to send the requested ticket.

2.4.  AuthorizationData for Backend Services

   The TLS server may depend on additional Kerberos-protected services,
   generally referred to as "backend services".  As an example, a
   webmail service may need to access IMAP and SMTP backend services,
   possibly under independent administrative control.  This section
   describes an OPTIONAL Kerberos mechanism in support of such backend
   services.  It is designed to even work when the client and server
   reside in independently administered realms.

   In addition to the main Ticket supplied in the client Certificate's
   public key field, the TLS server MAY be sent additional Tickets for
   access to backend services, and in some cases these additional
   Tickets can define where these backend services are located and under
   what client identity they are accessed.  The client needs to provide
   these additional Tickets in an AuthorizationData element whose ad-
   type is AD-BACKEND-TICKETS (TBD) and whose ad-data holds a KRB-CRED
   message [Section 5.8 of [RFC4120]] with an enc-part that uses NULL
   encryption [Section 6.3.1 of [RFC1510]].

   AuthorizationData elements with additional Tickets MAY be part of the
   service Ticket and/or Authenticator; supporting TLS servers MUST
   collect them from both these locations, such that they prefer the
   former in cases of service name clashes.  Just like a KDC could store
   additional Tickets in the main Ticket, an explicitly configured
   client could store them in the Authenticator.  To remain secure,
   clients MUST NOT be open to servers requesting arbitrary additional
   Tickets in any way.

   Additional Tickets MUST NOT be renewable, but the main Ticket MAY be;
   when the main Ticket is renewed it SHOULD be resent with the backend
   extension as they are setup at that time.  Additional Tickets SHOULD
   have neither the FORWARDABLE nor the PROXIABLE flag set.

   Additional Tickets should normally be supplied every time the main
   Ticket is supplied for TLS-KDH.  As a result, both the main and
   additional Tickets MAY be forgotten by the server whenever a TLS-KDH
   session ends.  However, when needed for longer-lasting or deferred
   backend processing, the server MAY hold the Tickets longer.

   It is possible for backend services to rely on backend services
   themselves; this can be facilitated by a an AD-BACKEND-TICKETS
   element contained in the additional Ticket for the respective backend



Van Rein                Expires December 15, 2016               [Page 6]


Internet-Draft                   TLS-KDH                       June 2016


   Ticket or, in more complex situations requiring more coordinated
   configuration, in an Authenticator whose additional Tickets get
   passed on selectively in Authenticators or other protocol elements
   sent to the backend service.

   The inclusion of additional Tickets in an Authenticator is not
   further described in this specification.  The inclusion of additional
   Tickets in a main Ticket usually involves requesting the TLS-KDH
   service Ticket directly from the client's KDC.  TODO: To facilitate
   this, the server desiring additional Tickets SHOULD set the
   LocalRealmService flag Section 3.5; without this flag, the client MAY
   choose not to supply additional Tickets.  The use of this flag may
   imply that the server needs to be flexible in the identity that the
   client uses for its service.

3.  Extending TLS to support Kerberos

   This section describes changes to TLS in support of Kerberos.

3.1.  Conceptual Data Model Extensions

   The following conceptual data should be available while the TLS-KDH
   message flows evolve:

   o  A flag that is initially set, indicating that the connection could
      be a KDH-enhanced connection;

   o  A flag that is initially set, indicating that the connection could
      be a KDH-only connection;

   o  A series of TicketRequestFlags that can be requested when the
      client obtains a Ticket for this service.

3.2.  Certificate Type KerberosTicket

   This specification adds a new entry named kerberos_sign in IANA's TLS
   ClientCertificateType Identifiers Registry, with the value TBD.

   This specification also adds a new entry named KerberosTicket in
   IANA's TLS Certificate Types" subregistry of the "Transport Layer
   Security (TLS) Extensions" registry.

3.3.  Signature Algorithms

   This specification introduces a mechanism for signatures under
   Kerberos Section 2.2.  This mechanism is represented in two places.





Van Rein                Expires December 15, 2016               [Page 7]


Internet-Draft                   TLS-KDH                       June 2016


   In TLS, a new SignatureAlgorithm named kerberos is allocated with
   value TBD in IANA's TLS Parameters Registry.  This Kerberos
   SignatureAlgorithm is usually combined with a HashAlgorithm that is
   in common use with TLS, to form a SignatureAndHashAlgorithm.  The
   digitally-signed structure [Section 4.7 of [RFC5246]] uses this
   structure, followed by a variable-sized opaque byte sequence, which
   should hold the EncryptedData holding an Authenticator Section 2.2.

3.4.  KDH-only CipherSuites

   KDH-enhanced message flows can use existing ECDHE CipherSuites using
   server certificates that may be signed with RSA or other common
   algorithms.  In addition, this specification introduces a number of
   KDH-only CipherSuites with names that start with TLS_ECDHE_KDH_.
   These new CipherSuites rely on Kerberos' mutual authentication plus
   ECDHE but not on a server Certificate.  They may be used starting
   from TLS 1.2.  They default to a higher verify_data_length than the
   default 12.

   The following Kerberos-only CipherSuites are entered into the IANA
   TLS Cipher Suite Registry; the list below provides their names and
   their desired verify_data_lengths between brackets:

   o  TLS_ECDHE_KDH_WITH_AES_128_GCM_SHA256 (32)

   o  TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA384 (48)

   o  TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA512 (64)

   o  TLS_ECDHE_KDH_WITH_AES_128_CCM (32)

   o  TLS_ECDHE_KDH_WITH_AES_256_CCM (48)

   o  TLS_ECDHE_KDH_WITH_AES_128_CCM_8 (32)

   o  TLS_ECDHE_KDH_WITH_AES_256_CCM_8 (48)

   o  TLS_ECDHE_KDH_WITH_CAMELLIA_128_GCM_SHA256 (32)

   o  TLS_ECDHE_KDH_WITH_CAMELLIA_256_GCM_SHA384 (48)

   o  TLS_ECDHE_KDH_WITH_CAMELLIA_256_GCM_SHA512 (64)

   Neither server nor client should accept lower values for
   verify_data_length than given here.  TODO: the list follows
   http://www.keylength.com/en/4/ and the hash algorithm sizes -- is
   this agreed?




Van Rein                Expires December 15, 2016               [Page 8]


Internet-Draft                   TLS-KDH                       June 2016


   The premaster secret for KDH-only CipherSuites is composed from an
   ECDHE shared secret and a client-sent, connection-specific Kerberos
   key.  Use A to refer to the DER representation of the Authenticator
   in the ClientVerify message.  Perform the ECDH computation in the
   normal manner [RFC4492] and let Z be the value produced by this
   computation (with leading zero bytes kept as they are).  The
   premaster secret is the concatenation of an uint16 containing the
   length of Z (in octets), Z itself, an uint16 containing the length of
   A (in octets) and A itself.

   The master secret is derived from the premaster secret using the
   extended master secret computation [Section 4 of [RFC7627].

3.5.  TicketRequestFlags Extension

   Some clients may be able to offer more facilities in Tickets than
   others, and some servers need more than others.  To communicate this,
   a TLS Extension known as TicketRequestFlags is hereby defined.  This
   extension is optional; when absent, all flags are considered to be
   cleared.  The client uses the Extension to specify the flags that it
   understands and may be able to fulfil.  The server uses the Extension
   to indicate the flags that it would like to be fulfilled.

   The Extension's structure is an extensible list of flag values that
   indicate constraints on the ticket that the client should try to
   supply.  These should be seen as hints how the client should present
   its identity, as the server can always decide to reject a client on
   grounds that are or are not expressible in this form.

   Flag values defined in this specification are:

   TicketFlags (flags number 0..31)  are taken from Kerberos'
         TicketFlags definitions [[RFC4120] and updates]; clients MUST
         NOT accept requested TicketFlags without scrutinising their
         security impact; servers SHOULD NOT assume that their requested
         TicketFlags will actually be provided.  Only TicketFlags 0
         through 31 are included in this definition; when Kerberos is
         extended with more TicketFlags then they will be assigned a new
         range of values as TicketRequestFlags.

   VisibleClientRealm (flag number 32)  requests that the client's realm
         name is revealed in the service ticket.  With the flag not set,
         the server MUST NOT reject the well-known anonymous realm name
         WELLKNOWN:ANONYMOUS [Section 3 of [RFC6112]] in the client
         realm name.

   UniqueClientIdentity (flag number 33)  requests that the client
         presents a unique identity, even if it is a pseudonym that is



Van Rein                Expires December 15, 2016               [Page 9]


Internet-Draft                   TLS-KDH                       June 2016


         specific to this service.  Some services can make good use of
         identities that are also presented over other protocols, which
         is why the choice to share such an identity SHOULD be made
         during an interaction with the user, if possible.  The user MAY
         determine to use only a short-lived identity.  When this flag
         is not set, the server MUST NOT reject the client principal
         name WELLKNOWN/ANONYMOUS of type KRB_NT_WELLKNOWN [Section 3 of
         [RFC6112]].  Regardless of this flag, it is RECOMMENDED for the
         server to be open to as many forms of client principal name
         [Section 6.2 of [RFC4120]] as possible.

   LastingClientIdentity (flag number 34)  requests that the client
         presents an identity that it will use on recurring visits.
         Client software is advised to confer with their users on this,
         and so this request should only be used for subscription
         services that would be agreeable to their users.  Without this
         flag, the client is free to use a short-lived identity that is
         unlikely to survive after the ticket's endtime or renew-till
         time.

   The flags are chosen such that their default values may be set to 0
   as a safe default; safe in the sense that they do not lead to privacy
   problems, do not impair the peer and do not offer something that
   could block progress of TLS at a later point.  Servers MUST NOT
   respond with TicketRequestFlags set that the client left cleared.
   Senders MUST NOT include flags that they don't know and recipients
   MUST NOT accept flags they cannot interpret.

   Flag values are registered by IANA in a newly created "TLS-KDH Ticket
   Request Flag Registry", whose initial values are as defined above.
   Future specifications of flag values may state that a flag is an
   alternative to another flag, including to the ones specified above.
   When flag A is an alternative to flag B then the fulfillment of the
   requirements for A suffices to ignore flag B.  It is possible for
   flags to cyclically refer to each other as alternatives; since being-
   an-alternative is not defined as a transitive property, this need not
   distract from this definition.  This is explicitly permitted to
   enhance expressiveness of this principle.

   The wire format representing TicketRequestFlags is a sequence of
   bytes, where the byte at index i (starting from 0) represents the
   flags numbered 8*i (in its least-significat bit) through 8*i+7 (in
   its most-significant bit).  The last byte MUST NOT be 0, meaning that
   it is possible for the TicketRequestFlags to be a sequence of no
   bytes if all flags are cleared.






Van Rein                Expires December 15, 2016              [Page 10]


Internet-Draft                   TLS-KDH                       June 2016


3.6.  TLS Connection Expiration

   TLS-KDH connections expire when their authenticating Kerberos tickets
   expire.  This is not a reason for termination of the TLS connection,
   but instead it is a trigger for refreshing the ticket.  Such a
   refresh should be executed by the TLS-KDH client, where it may
   trigger user interaction.  Note that Kerberos' facility of ticket
   renewal [Section 2.3 of [RFC4120]] may provide some relief from such
   user interaction.

   When the TLS-KDH connection expires, neither side will send any
   further data records, and both sides will, upon receiving any data
   records, trigger a TLS Alert.  The other records are still accepted,
   to permit a TLS handshake for re-issuance of session keys.
   Implementations MAY choose to initiate and permit re-authentication
   some time before the actual expiration.  This can remedy clock skew
   between the TLS-KDH client and server, which might otherwise lead to
   undesired connection reset.

3.7.  Interaction with Applications

   To be able to use Kerberos, application protocols that run over TLS
   must exchange some configuration information with the TLS stack.
   This includes communication about Kerberos properties such as service
   name and realm, offered/requested TicketRequestFlags, and a key for
   use with the local identity.

   When a SASL EXTERNAL mechanism is used to communicate an identity
   between the application and the TLS stack, then a good alignment with
   X.509 certificates is possible when both aim to derive or match a
   Network Access Identifier [RFC7542] and/or a DNS name.  In the case
   of a Kerberos principal name, this would involve translation between
   case-sensitive realm names to DNS names whose case is not reliably
   reproduced [Section 4.1 of [RFC4343]]; this may be handled by
   ignoring or lowering the case of the realm name while being aware of
   the requirement that no two realm names may differ only in their case
   [Section 7.2.3.1 of [RFC4120]].

3.8.  Kerberos-Only TLS Application Profile

   TLS and Kerberos have long been independent infrastructures for
   secure connectivity; with the introduction of the KDH-only
   CipherSuites in this specification, the worlds can merge elegantly.
   The newly introduced CipherSuites are expected to integrate
   relatively straightforwardly with any TLS stack.

   Just like the TLS-KDH CipherSuites are optimal to implement in TLS
   stacks, TLS-KDH should not force all Kerberos applications to process



Van Rein                Expires December 15, 2016              [Page 11]


Internet-Draft                   TLS-KDH                       June 2016


   the full potential of TLS, especially not public key cryptography and
   the complexity of proper validation of X.509 certificates.  Some
   applications simply want to use Kerberos in a standardised protocol,
   without any added CipherSuites.  For such applications, we hereby
   introduce a TLS application profile under which such applications can
   stand on their own:

   o  Based on TLS 1.2 or newer;

   o  Setting a default verify_data_size dependent on the CipherSuite;

   o  Supporting the TLS-KDH CipherSuite
      TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA512;

   o  Not necessarily supporting the TLS_RSA_WITH_AES_128_CBC_SHA
      CipherSuite that is mandatory in the default TLS application
      profile [Section 9 of [RFC5246]];

   o  This application profile will be known as the "Kerberos-Only TLS
      Application Profile".

   The Kerberos-only CipherSuites can be used with any TLS application
   profile; that includes, but is not limited to, the one specified
   above and the default application profile.

4.  The Message Flow of TLS-KDH

   This specification introduces the name TLS-KDH to certain message
   flows within the TLS framework.  There are two distinct variations,
   called KDH-only and KDH-enhanced.  This section defines constraints
   to the message flow for it to be a TLS-KDH message flow.  This,
   together with the flags in the conceptual data model [Section 3.1],
   guides the use of the extensions defined in this specification.

   TLS endpoints that find that the other side of the TLS connection
   only implements some of the TLS-KDH constraints MUST NOT continue the
   connection with the TLS-KDH extensions of this specification (unless
   future specifications assign a meaningful procedure for such
   situations).  If the remote endpoint does not implement all
   requirements for TLS-KDH but also enforces it, for instance by
   sending required information that can only be interpreted under this
   specification, then it MUST send a suitable TLS Alert and close the
   connection.








Van Rein                Expires December 15, 2016              [Page 12]


Internet-Draft                   TLS-KDH                       June 2016


4.1.  ClientHello

   To support TLS-KDH, a client's ClientHello MUST mention the kerberos
   SignatureAlgorithm in at least one of the
   supported_signature_algorithms, and it also MUST include
   KerberosTicket in a client_certificate_type extension [RFC7250].  The
   client MAY include the TicketRequestFlags extension if it is
   interested on providing more than a generally available ticket to the
   service.

   Furthermore, the client MAY offer to process KerberosTicket in a
   server_certificate_type extension [RFC7250], and the client MAY
   include the TicketRequestFlags extension.

   In addition, the ClientHello MAY include one or more KDH-only
   CipherSuites in the list of cipher_suites, but if that is done the
   protocol used MUST be TLS 1.2 or later, indicated on the record layer
   with ProtocolVersion 3,3 or later.  Without at least one of the KDH-
   only CipherSuites, the connection cannot be KDH-only, but it may
   still proceed as KDH-enhanced.  With at least one of the KDH-only
   CipherSuites, the client MAY offer to process KerberosTicket in a
   server_certificate_type extension [RFC7250] through the ENC-TKT-IN-
   SKEY [Section 2.9.2 of [RFC4120]] Kerberos extension.

   The client MUST NOT send TicketRequestFlags that it does not
   understand and it MUST NOT offer all the TicketFlags that are defined
   for Kerberos, but instead SHOULD limit itself to what would be
   acceptable from a security perspective.

4.2.  ServerHello

   To support TLS-KDH, a ServerHello message MUST mention the kerberos
   SignatureAlgorithm in at least one of the
   supported_signature_algorithms, and it MUST include the
   KerberosTicket value in the client_certificate_type extension
   [RFC7250].  Furthermore, the server MUST select a cipher_suite with
   ephemeral ECDH key exchange; aside from generally available
   CipherSuites, the server MAY select a KDH-only cipher_suite.  When it
   does not select a KDH-only CipherSuite, the connection cannot be a
   KDH-only connection, but it may still proceed as KDH-enhanced.

   When the server selects a KDH-enhanced CipherSuite, it MUST choose
   another means of authenticating its identity than through Kerberos,
   following the customary flow of TLS and only using Kerberos for
   client authentication.

   When the server selects a KDH-only CipherSuite and when the
   ClientHello message includes the KerberosTicket in a



Van Rein                Expires December 15, 2016              [Page 13]


Internet-Draft                   TLS-KDH                       June 2016


   server_certificate_type extension [RFC7250], then the server MAY
   choose to send back a server_certificate_type extension selecting
   KerberosTicket, in which case it MUST send the corresponding Server
   Certificate later in the process.  This may be used to facilitate
   user-to-user negotiation of TLS.

   The server MAY include the TicketRequestFlags extension in the
   ServerHello message if the client included it in the ClientHello
   message.  The server MUST ignore TicketRequestFlags from the client
   that it does not understand; it MUST NOT send TicketRequestFlags that
   it does not understand and it MUST NOT set TicketRequestFlags that
   were not set in the ClientHello.

   Note that none of the Anonymous CipherSuites can be made to work with
   TLS-KDH, because then it is not permitted [Section 2.5 of [RFC4492]]
   to send a CertificateRequest, client Certificate or CertificateVerify
   message.  Although the KDH-only CipherSuites do not use a server
   Certificate this does not constitute Anonymous server authentication,
   because Kerberos provides mutual authentication.

4.3.  Server Certificate

   For KDH-enhanced CipherSuites, the server Certificate message MUST be
   sent, following the definitions of the server-selected cipher_suite.

   Under KDH-only, when the server has not selected the KerberosTicket
   as the server_certificate_type, then it MUST send an Certificate
   message with a certificate_list of 0 bytes length.

   Under KDH-only, when the server did select the KerberosTicket as the
   server_certificate_type, then it MUST include the corresponding
   ticket in the Server Certificate.

4.4.  ServerKeyExchange

   All TLS-KDH connections MUST use ephemeral ECDH.  Under KDH-enhanced
   CipherSuites, this implies the case ec_diffie_hellman [Section 5.4 of
   [RFC4492]].  Under KDH-only CipherSuites, the same case is used, but
   without signatures, formatted in the same way as for ECDH_anon
   CipherSuites.

4.5.  CertificateRequest

   Under TLS-KDH, a CertificateRequest MUST be sent by the server, and
   it MUST include at least one SignatureAndHashAlgorithm based on the
   kerberos SignatureAlgorithm.  Any SignatureAndHashAlogorithm with the
   SignatureAlgorithm set to kerberos MUST use a HashAlgorithm for which
   IANA's Kerberos Parameters registry holds a compatible Kerberos



Van Rein                Expires December 15, 2016              [Page 14]


Internet-Draft                   TLS-KDH                       June 2016


   Checksum Type.  The CertificateRequest MUST also list the
   kerberos_sign CertificateType.  Having selected the KerberosTicket
   value for the client_certificate_type, other CertificateTypes and
   SignatureAndHashAlgorithms SHOULD NOT be sent.  The list of
   certificate_authorities is not used by TLS-KDH and MUST be empty.

4.6.  Client Certificate

   TLS-KDH clients MUST fill the ClientCertificate message with a
   KerberosTicket.  In doing so, it SHOULD take any negotiated
   TicketRequestFlags into consideration; it is not required however to
   implement all, because some flags may be forbidden by policy that was
   concealed from the ClientHello-supplied TicketRequestFlags, or their
   implementation may turn out to be unavailable while requesting the
   Ticket.  In such cases, the client MAY simply continue without
   fulfilling the request flags, or it MAY choose to divert from a KDH-
   enhanced message flow by authenticating with another kind of
   Certificate, or not to present one at all.

   When the server has not set the UniqueClientIdentity flag, then the
   RECOMMENDED client Certificate under TLS-KDH would be based on an
   anonymous Ticket [RFC6112]; however, when the server has set the
   UniqueClientIdentity flag, then an anonymous Ticket that uses the
   anonymous realm MUST NOT be sent.  A Ticket that is not anonymous may
   still be pseudonymous, including names based on NT-UID principal
   names [Section 6.2 of [RFC4120]] when the server has sent the
   UniqueClientIdentity flag; the LastingClientIdentity flag indicates
   the server's perspecitve on longevity of any such pseudonyms, but the
   client MAY choose to ignore that wish.

   The impact of using an anonymous ticket is that the server cannot
   establish the identity of the client, except perhaps that the same
   service ticket may be used repeatedly during its short period of
   validity.  This means that the ability to trace the client is limited
   for both server and client.  Under customary X.509 authentication,
   the interpretation of not sending the CertificateRequest is that the
   server should not care for the client identity; anonymous tickets
   provide a mechanism for achieving a similar pattern under TLS-KDH,
   although it has some benefits of short-term session protection.

   When the server has selected the KerberosTicket as the
   server_certificate_type, then the client SHOULD pass it along with
   its attempt to obtain a ticket for the server name, using the KDC
   option ENC-TKT-IN-SKEY [Section 2.9.2 of [RFC4120]] and supplying an
   additional ticket in the TGS request [Section 3.3.1 of [RFC4120]];
   this Ticket is supplied completely by the KerberosTicket certificate-
   type, and although it includes a server-side realm name, this MUST
   NOT be trusted by the client before it has been confirmed by the



Van Rein                Expires December 15, 2016              [Page 15]


Internet-Draft                   TLS-KDH                       June 2016


   client's attempts to reach the server by its host name; this is
   because a man-in-the-middle attack is still possible through a forged
   service realm.  Customary processing rules for finding a server's
   realm MUST therefore be followed by the client.

   The presence of the client's Ticket in the ClientCertificate message
   enables the server to ascertain that the client has procured a Ticket
   through the formal pathways of Kerberos, ending in the server-side
   realm; the reason this can be assumed is that the ticket holds an
   encrypted part that the server can decrypt and thereby validate with
   its own key, as setup in its KDC for sharing in service tickets.  In
   other words, even an anonymous Ticket establishes that the server may
   trust that the client was checked along the way to the service.  As a
   result, the ECDH key exchange is known to be protected from a man-in-
   the-middle attack.

   Briefly put, we can speak of mutual authentication in this
   specification, even when the client supplies an anonymous ticket.
   The only thing that is missing under an anonymous ticket is the
   visibility of the client's validated identity.

4.7.  ClientKeyExhange

   Every TLS-KDH message flow MUST use ECDH, and since the keys MUST be
   ephemeral, the explicit form of the ClientECDiffieHellmanPublic for
   the case ec_diffie_hellman [Section 5.7 of [RFC4492]] MUST be used.

4.8.  CertificateVerify

   Under TLS-KDH, the CertificateVerify was preceded by a client's
   Ticket, and the CertificateVerify MUST follow as a proof of posession
   of the corresponding key material on the client.  This means that the
   CertificateVerify message MUST follow the descriptions of a Kerberos
   Authenticator Section 2.2 for use with TLS.

   The Authenticator MUST be set to the client's cusec and ctime values,
   and the server SHOULD validate these to fall within a reasonable
   margin around the current time.

   The subkey field MUST NOT be included in KDH-enhanced message flows.
   In KDH-only message flows, the Authenticator MUST introduce a new
   client-generated key in the subkey field, and the client MUST supply
   at least the amount of entropy in the subkey that is expected in the
   symmetric key produced by TLS under the selected CipherSuite; the
   server SHOULD validate this subkey size to provide, assuming optimal
   compression, at least the amount of entropy that is desired for the
   CipherSuite's symmetric key.




Van Rein                Expires December 15, 2016              [Page 16]


Internet-Draft                   TLS-KDH                       June 2016


   For KDH-Only, the subkey is needed to form the pre-master secret on
   both ends, which in turn influences the master secret.  Through the
   Finished messages, the KDH-Only mode of operation performs mutual
   validation between the client and server.

4.9.  Finished

   For KDH-enhanced flows, the server can be authenticated through its
   Certificate, so that the usual Finished messages suffice, and TLS
   versions preceding 1.2 may still suffice.

   For KDH-only flows, the Finished message is the first place where the
   server identity can be validated, prior to reporting successful
   authentication to the application running atop TLS.  As a result, the
   KDH-only CipherSuites have been defined with an elongated Finished
   message, for improved security.  This is possible since TLS 1.2.  The
   desired minimum length is defined with the introduction of the KDH-
   only CipherSuite.

5.  Comparison to Earlier Work

   An older specification [RFC2712] introduces Kerberos into TLS.  That
   specification is hereby deprecated because this new specification
   improves on it work in a number of ways:

   o  The premaster secret is no longer sent to the server under
      encryption with the KDC-provided session key; instead, Forward
      Secrecy is supported through ECDHE;

   o  The authenticator following the Kerberos ticket is made
      obligatory, as an intrinsic part of replay protection and the
      mutual authentication between TLS client and TLS server to protect
      all in-transit application data;

   o  There is no need to implement a replay cache, which means that
      more efficient implementation is possible, certainly on highly
      active and/or replicated TLS-KDH server systems;

   o  The mutual authentication of TLS client and TLS server is
      established with Kerberos-only CipherSuites that define a stronger
      Finished message size;

   o  The service name is not statically set to the literal "host", but
      both the client and server TLS stacks assume an application
      context to provide the service name to be used;

   o  The lack of forward secrecy in Kerberos is resolved by enforcing
      ECDH with any use of TLS-KDH;



Van Rein                Expires December 15, 2016              [Page 17]


Internet-Draft                   TLS-KDH                       June 2016


   o  The KDH-enhanced variation can be used with another mode of server
      authentication.

   o  Support for modern TLS CipherSuites is added, and support for ones
      that are currently considered deprecated or insecure have been
      removed;

   Specifically for the HTTP and HTTPS protocols, the Negotiate header
   [RFC4559] can provide Kerberos authentication, but its use is not
   considered a strong security practice.  Applications that currently
   rely on this mechanism can strengthen their security if they migrate
   to HTTP over TLS-KDH.  Note that this provides an alternative for
   Kerberos, not to SPNEGO and not for general GSS-API protocols.  This
   restriction of TLS-KDH to Kerberos, rather than a more general GSS-
   API protocol, is a result of the fixed number of message exchanges
   available within TLS.

   Many other protocols incorporate Kerberos through GSS-API, usually
   via SASL.  This is considered secure, but has an arguable
   disadvantage of separating encryption and authentication layers, and
   quite possibly also the identities involved in these layers.
   Furthermore, encryption through SASL is not commonly used.  In
   situations where Kerberos is used for GSS-API over SASL, TLS-KDH
   offers a comparable but more efficient and tighter-coupled mechanism
   for encryption and mutual authentication, in a way that also lends
   itself to non-SASL applications.  Specifically useful in this respect
   is that there is no longer a requirement to setup X.509 certificates
   plus infrastructure and validation mechanisms, just to satisfy
   encryption requirements with their own authentication infrastructure.
   In applications that use SASL, the EXTERNAL mechanism [RFC4422] can
   use the client identity in a Kerberos ticket, and make it available
   to the application layer; SASL EXTERNAL is also commonly used when
   TLS authenticates peers through X.509 certificates.

   The use of additional Tickets for Backend Services Section 2.4
   replaces the paired practices "S4U2Self" and "S4U2Proxy", which were
   not designed to crossover to hitherto unknown realms; they rely on
   the service realm to constrain the use of rights granted over the
   client realm.  Furthermore, said practices make use of hard-coded
   cryptographic algorithms, which makes it impossible to assure their
   long-term security.

6.  Efficiency Considerations

   The efficiency of the mechanism described here compares favourably
   with the more common approach of authentication through X.509
   certificates based on public-key algorithms.




Van Rein                Expires December 15, 2016              [Page 18]


Internet-Draft                   TLS-KDH                       June 2016


   The Kerberos architecture is founded on symmetric cryptography, which
   makes it more efficient than the asymmetric architectures around
   X.509 public-key certificates.  Furthermore, Kerberos' identity
   statements are short-lived, which is generally accepted to evade the
   need for withdrawal mechanisms based on chains of trust, CRLs
   [RFC3280], OCSP [RFC6960], DANE [RFC6698] and perhaps other
   mechanisms.  As a result, the validity of a Kerberos ticket can be
   checked with relatively modest computational effort.

   The inclusion of ephemeral ECDH is a relatively expensive asymmetric
   operation, but the same introduction is needed when Forward Secrecy
   is introduced alongside public-key authentication.

   The one thing that is costly about Kerberos is its reliance on a
   replay cache.  Such caches store recent authentication attempts to
   avoid that they are being replayed; an accurate clock helps to
   release entries, but some care for clock skew between TLS-KDH client
   and server must be resolved with these caches.  Their volatile nature
   makes them a particularly difficult problem in highly active and/or
   replicated and/or distributed Kerberos services.

   A replay cache is not required for any of the TLS-KDH protocol flows,
   because this specification requires an ephemeral ECDH key exchange.
   This is of particular use to redundant (and possibly distributed)
   server farms, where sharing the time-critical information of the
   replay cache is a performance bottle neck.  Since this is a new
   specification, there is no need to implement backward compatibility
   with older mechanisms for which a replay cache might be needed.

7.  Privacy Considerations

   The information that is publicly shown in the TLS-KDH protocol flows
   consists of:

   o  Supported protocol versions, TLS extensions and CipherSuites

   o  For other than Kerberos-only CipherSuites, the server's
      Certificate

   o  The server's principal name, host name and service name

   A Kerberos ticket transmits less information in plaintext than a
   public-key X.509 client certificate; furthermore, DNS may have to
   reveal the realm name(s) of server-trusted KDC(s) but neither the
   TLS-KDH server nor any KDC publishes long-lasting key material for
   TLS or Kerberos, so parties looking for a cracking challenge are
   constrained to a brief period of attack on keys.




Van Rein                Expires December 15, 2016              [Page 19]


Internet-Draft                   TLS-KDH                       June 2016


   The TicketRequestFlags may provide information about Tickets present
   in the client, but that would take the risk of leaking information
   prior to authentication of the server, and in plaintext.

8.  Security Considerations

   For KDH-enhanced message flows, the server can be authenticated
   through its public-key X.509 Certificate.  For KDH-onnly message
   flows this is not possible, which is why a longer verify_data_size in
   the Finished messages is required; the ability to generate these
   messages properly proves that the other side has succeeded in
   decrypting the Kerberos-encrypted materials, and so, that it is the
   intended remote party.

   In Kerberos, all key material is supplied by the KDC.  This is a
   central point in each realm that is usually guarded well enough, but
   it is nonetheless a critical point in any infrastructure founded on
   Kerberos.  When client and server are in different realms, but have
   cross-signed directly or through a chain of KDC's, then all
   intermediate KDC's are potential places where the session key could
   be detected.  The weakest KDC in the chain then defines the security
   of the entire chain.

   Kerberos requires accurate clocks in order to operate securely;
   without them, once-used and since-forgotten credentials could be
   replayed by an attacker that has been able to recover an old service
   ticket's session key.  This problem is worsened in cross-realm
   scenario's where clock synchronisation is hard to realise.  This is
   however resolved in all TLS-KDH flows by using ephemeral Elliptic-
   Curve Diffie-Hellman keys, thus forcing new master secrets on each
   connection and removing the need for a replay buffer.  Note however,
   that ticket validity times must still be checked.

   Basic Kerberos security hinges on the secrecy of the user's password;
   if this password is guessed, then all captured traffic can be
   decoded, even in retrospect.  This means that it is highly advisable
   to combine Kerberos with Diffie-Hellman for Forward Secrecy.  TLS-KDH
   implies this desirable property in all its CipherSuites.

9.  IANA Considerations

   IANA adds the following Kerberos Checksum Type Numbers to the
   Kerberos Parameters registry, to match the hash algorithms available
   to TLS:







Van Rein                Expires December 15, 2016              [Page 20]


Internet-Draft                   TLS-KDH                       June 2016


           +---------------+------------------+---------------+
           | sumtype value | Checksum type    | checksum size |
           +---------------+------------------+---------------+
           | TBD           | sha224 (unkeyed) | 28            |
           | TBD           | sha256 (unkeyed) | 32            |
           | TBD           | sha384 (unkeyed) | 48            |
           | TBD           | sha512 (unkeyed) | 64            |
           +---------------+------------------+---------------+

   Through the IETF Kitten WG, the Kerberos community assigns the
   following value for the AuthorizationData type for backend tickets,
   as defined in this specification:

                      +-------+--------------------+
                      | Value | Name               |
                      +-------+--------------------+
                      | TBD   | AD-BACKEND-TICKETS |
                      +-------+--------------------+

   IANA adds the following entries to the TLS Cipher Suite Registry
   underneath the TLS Paramters registry, to enable KDH-only negotiation
   and the Kerberos-Only profile that relies on it:

     +-------+--------------------------------------------+---------+
     | Value | Description (verify_data_length)           | DTLS-OK |
     +-------+--------------------------------------------+---------+
     | TBD   | TLS_ECDHE_KDH_WITH_AES_128_GCM_SHA256 (32) | Y       |
     | TBD   | TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA384 (48) | Y       |
     | TBD   | TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA512 (64) | Y       |
     | TBD   | TLS_ECDHE_KDH_WITH_AES_128_CCM (32)        | Y       |
     | TBD   | TLS_ECDHE_KDH_WITH_AES_256_CCM (48)        | Y       |
     | TBD   | TLS_ECDHE_KDH_WITH_AES_128_CCM_8 (32)      | Y       |
     | TBD   | TLS_ECDHE_KDH_WITH_AES_256_CCM_8 (48)      | Y       |
     +-------+--------------------------------------------+---------+

   IANA adds the following ClientCertificateType Identifier to the TLS
   Parameters registry, to be able to formule certificate requests under
   TLS-KDH as described in this document:

                    +-------+---------------+---------+
                    | Value | Description   | DTLS-OK |
                    +-------+---------------+---------+
                    | TBD   | kerberos_sign | Y       |
                    +-------+---------------+---------+

   IANA adds the following TLS SignatureAlgorithm to the TLS Parameters
   registry, to permit the Kerberos-based signatures described in this
   document:



Van Rein                Expires December 15, 2016              [Page 21]


Internet-Draft                   TLS-KDH                       June 2016


                     +-------+-------------+---------+
                     | Value | Description | DTLS-OK |
                     +-------+-------------+---------+
                     | TBD   | kerberos    | Y       |
                     +-------+-------------+---------+

   IANA adds the following TLS Certificate Type to the TLS Extensions
   registry, to support negotiating it as a client_certificate_type and
   possibly as a server_certificate_type:

                   +-------+----------------+---------+
                   | Value | Description    | DTLS-OK |
                   +-------+----------------+---------+
                   | TBD   | KerberosTicket | Y       |
                   +-------+----------------+---------+

   IANA adds the following ExtensionType Value to the TLS Extensions
   registry, to support the negotiation of TicketRequestFlags as
   described in this specification:

                      +-------+--------------------+
                      | Value | Extension Name     |
                      +-------+--------------------+
                      | TBD   | TicketRequestFlags |
                      +-------+--------------------+

   IANA appends a new "TLS-KDH Ticket Request Flags" sub-register to the
   TLS Extensions register, to support the allocation of
   TicketRequestFlags by other specifications.  New entries to this
   table can be made under the named Assignment Policy [RFC5226].  The
   initial entries to this registry are:

   +----------+-----------------------+--------------+-----------------+
   | Value(s) | Name                  | Reference    | Assignment      |
   |          |                       |              | Policy          |
   +----------+-----------------------+--------------+-----------------+
   | 0..31    | TicketFlags           | TBD:THISSPEC | RFC Required    |
   | 32       | VisibleClientRealm    | TBD:THISSPEC | RFC Required    |
   | 33       | UniqueClientIdentity  | TBD:THISSPEC | RFC Required    |
   | 34       | LastingClientIdentity | TBD:THISSPEC | RFC Required    |
   | 35..63   | Unassigned            |              | RFC Required    |
   | 64..79   | Private Use           | N/A          | Private Use     |
   | 80..95   | Experimental          | N/A          | Experimental    |
   |          |                       |              | Use             |
   | 96..     | Reserved              |              | RFC Required    |
   +----------+-----------------------+--------------+-----------------+





Van Rein                Expires December 15, 2016              [Page 22]


Internet-Draft                   TLS-KDH                       June 2016


10.  References

10.1.  Normative References

   [RFC1510]  Kohl, J. and C. Neuman, "The Kerberos Network
              Authentication Service (V5)", RFC 1510,
              DOI 10.17487/RFC1510, September 1993,
              <http://www.rfc-editor.org/info/rfc1510>.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              DOI 10.17487/RFC4120, July 2005,
              <http://www.rfc-editor.org/info/rfc4120>.

   [RFC4343]  Eastlake 3rd, D., "Domain Name System (DNS) Case
              Insensitivity Clarification", RFC 4343,
              DOI 10.17487/RFC4343, January 2006,
              <http://www.rfc-editor.org/info/rfc4343>.

   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492,
              DOI 10.17487/RFC4492, May 2006,
              <http://www.rfc-editor.org/info/rfc4492>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.

   [RFC6112]  Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for
              Kerberos", RFC 6112, DOI 10.17487/RFC6112, April 2011,
              <http://www.rfc-editor.org/info/rfc6112>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <http://www.rfc-editor.org/info/rfc7250>.







Van Rein                Expires December 15, 2016              [Page 23]


Internet-Draft                   TLS-KDH                       June 2016


   [RFC7627]  Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
              Langley, A., and M. Ray, "Transport Layer Security (TLS)
              Session Hash and Extended Master Secret Extension",
              RFC 7627, DOI 10.17487/RFC7627, September 2015,
              <http://www.rfc-editor.org/info/rfc7627>.

10.2.  Informative References

   [RFC2712]  Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
              Suites to Transport Layer Security (TLS)", RFC 2712,
              DOI 10.17487/RFC2712, October 1999,
              <http://www.rfc-editor.org/info/rfc2712>.

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              DOI 10.17487/RFC3280, April 2002,
              <http://www.rfc-editor.org/info/rfc3280>.

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422,
              DOI 10.17487/RFC4422, June 2006,
              <http://www.rfc-editor.org/info/rfc4422>.

   [RFC4559]  Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
              Kerberos and NTLM HTTP Authentication in Microsoft
              Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
              <http://www.rfc-editor.org/info/rfc4559>.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <http://www.rfc-editor.org/info/rfc6698>.

   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
              Galperin, S., and C. Adams, "X.509 Internet Public Key
              Infrastructure Online Certificate Status Protocol - OCSP",
              RFC 6960, DOI 10.17487/RFC6960, June 2013,
              <http://www.rfc-editor.org/info/rfc6960>.

   [RFC7542]  DeKok, A., "The Network Access Identifier", RFC 7542,
              DOI 10.17487/RFC7542, May 2015,
              <http://www.rfc-editor.org/info/rfc7542>.








Van Rein                Expires December 15, 2016              [Page 24]


Internet-Draft                   TLS-KDH                       June 2016


Appendix A.  Acknowledgements

   This specification could not have matured without the insights of
   various commenters.  In order of appearance, we owe thanks to Simo
   Sorce, Ilari Liusvaara, Watson Ladd, Benjamin Kaduk, Nikos
   Mavragiannopoulos.  Special thanks go to Tom Vrancken for tracking
   the development of the specification, commenting on it and
   implementing it in GnuTLS.

   This work was conducted under a grant from the programme "[veilig]
   door innovatie" from the government of the Netherlands.  It has also
   been liberally supported by the NLnet Foundation.

Author's Address

   Rick van Rein
   ARPA2.net
   Haarlebrink 5
   Enschede, Overijssel  7544 WP
   The Netherlands

   Email: rick@openfortress.nl





























Van Rein                Expires December 15, 2016              [Page 25]


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