[Docs] [txt|pdf|xml] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06

Network Working Group                                        R. Van Rein
Internet-Draft                                                 ARPA2.net
Intended status: Standards Track                         October 1, 2015
Expires: April 3, 2016


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

Abstract

   This specification extends TLS with a Kerberos-based method of mutual
   authentication, and binds in Diffie-Hellman to achieve Perfect
   Forward Secrecy for the session.

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 April 3, 2016.

Copyright Notice

   Copyright (c) 2015 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 April 3, 2016                 [Page 1]


Internet-Draft                   TLS-KDH                    October 2015


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Relations to Prior Work . . . . . . . . . . . . . . . . . . .   3
   3.  CipherSuites for Kerberos with Forward Secrecy  . . . . . . .   4
   4.  ClientHello: TLS-KDH CipherSuites . . . . . . . . . . . . . .   4
     4.1.  Indicating the Server Name  . . . . . . . . . . . . . . .   5
   5.  ServerHello: Selecting a TLS-KDH CipherSuite  . . . . . . . .   6
   6.  No ServerCertificate  . . . . . . . . . . . . . . . . . . . .   6
   7.  ServerKeyExchange: Ephemeral Diffie-Hellman . . . . . . . . .   6
     7.1.  TicketRequestFlags  . . . . . . . . . . . . . . . . . . .   7
   8.  Obtaining a Service Ticket on the Client  . . . . . . . . . .   9
   9.  ClientKeyExchange: Kerberos ticket with Diffie-Hellman  . . .  10
     9.1.  Impact of Anonymous Client Tickets  . . . . . . . . . . .  11
   10. Master Secret Calculation . . . . . . . . . . . . . . . . . .  12
   11. Finished: Mutual Validation . . . . . . . . . . . . . . . . .  12
   12. Freshness of Diffie-Hellman Keys  . . . . . . . . . . . . . .  13
     12.1.  Managing a Pool of Fresh Keys  . . . . . . . . . . . . .  14
     12.2.  Impact on Replay Attacks . . . . . . . . . . . . . . . .  15
     12.3.  Impact on Denial-Of-Service Attacks  . . . . . . . . . .  16
   13. TLS Connection Expiration . . . . . . . . . . . . . . . . . .  17
   14. Mandatody CipherSuites  . . . . . . . . . . . . . . . . . . .  18
   15. Comparison to Earlier Work  . . . . . . . . . . . . . . . . .  18
   16. Efficiency Considerations . . . . . . . . . . . . . . . . . .  19
   17. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  20
   18. Security Considerations . . . . . . . . . . . . . . . . . . .  20
   19. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22
   20. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     20.1.  Normative References . . . . . . . . . . . . . . . . . .  24
     20.2.  Informative References . . . . . . . . . . . . . . . . .  25
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  26
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  26

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
   can be used to incorporate the desirable property of Perfect Forward
   Secrecy, but its vulnerability for man-in-the-middle attacks must
   then be overcome by cryptographically binding it to an authentication
   mechanism.

   The protocol described in this specification forms a cryptographic
   binding between Kerberos and Diffie-Hellman, leading to the combined
   advantages of infrastructure-supported mutual authentication and
   Perfect Forward Secrecy.



Van Rein                  Expires April 3, 2016                 [Page 2]


Internet-Draft                   TLS-KDH                    October 2015


   The flow of the TLS-KDH protocol is informally presented in the
   following chart:

       Client                                               Server

       ClientHello                  -------->
                                                       ServerHello
                                                 ServerKeyExchange
                                    <--------      ServerHelloDone
       ClientKeyExchange
       [ChangeCipherSpec]
       Finished                     -------->
                                                [ChangeCipherSpec]
                                    <--------             Finished
       Application Data             <------->     Application Data

   * Indicates optional or situation-dependent messages that are not
   always sent.

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

2.  Relations to Prior Work

   Prior work exists for Kerberos authentication within TLS [RFC2712].
   This work has a few drawbacks that are addressed in this new
   specification.  Specifically, it is useful to combine Kerberos mutual
   authentication with the Perfect Forward Secrecy of Diffie-Hellman.

   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 by moving 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 limited number of message exchanges
   available within TLS.

   Many other protocols incorporate Kerberos through GSS-API, usually
   via SASL.  This is considered secure, but has the 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 for non-SASL
   applications.  Specifically useful in this respect is that there is



Van Rein                  Expires April 3, 2016                 [Page 3]


Internet-Draft                   TLS-KDH                    October 2015


   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 be
   used to extract the remote identity from a Kerberos ticket, and make
   it available to the application layer; SASL EXTERNAL is also used
   when TLS authenticates peers through X.509 certificates.

   The following paragraph is an informational suggestion: 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 a Network Access
   Identifier [RFC4282] and/or a domain 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 [Section 4.1 of
   [RFC4343]] reproduced; this may be done by ignoring or lowering the
   case of the realm name while upholding the requirement that no two
   realm names may differ only in their case [Section 7.2.3.1 of
   [RFC4120]].

3.  CipherSuites for Kerberos with Forward Secrecy

   This specification extends TLS [RFC5246] with a number of CiperSuites
   that subject ephemeral Diffie-Hellman key exchange to Kerberos mutual
   authentication.  The names of the new CipherSuites are listed under
   IANA Considerations, and will collectively be referred to as TLS-KDH
   CipherSuites in this specification.  The variants of the TLS protocol
   variants following one of these CipherSuites will be informally
   referred to as TLS-KDH in this specification.

   The names of the TLS-KDH CipherSuites can be split into DHE_KRB and
   ECDHE_KRB variants; their names start with TLS_DHE_KRB_ and
   TLS_ECDHE_KRB_, respectively; the corresponding KeyExchangeAlgorithm
   tags will be dhe_krb and ecdhe_krb, respectively.

   The cipher and hash algorithm for each of the TLS-KDH CipherSuites
   are easily determined by examining the name; this follows the same
   regime that is commonly used in other TLS specifications.  The only
   thing that this specification adds to the CipherSuites is a new
   authenticated key exchange mechanism.

4.  ClientHello: TLS-KDH CipherSuites

   A client willing to employ Kerberos authentication offers one or more
   of the TLS-KDH CipherSuites in its ClientHello message.  Offering
   these is no guarantee that a token has already been found for the
   server, but it expresses a willingness to look for one.




Van Rein                  Expires April 3, 2016                 [Page 4]


Internet-Draft                   TLS-KDH                    October 2015


   Whether a client is willing to employ Kerberos authentication MAY
   depend on its context.  Following is an informative example of
   situations that could be considered, with a rising level of
   willingness:

   1.  Kerberos software is available on the client system

   2.  The client context holds a Ticket Granting Ticket that is
       currently valid

   3.  The client context holds a Ticket Granting Ticket that may have
       expired

   4.  The client context will go through Kerberos signup if need be

   The last two options may require interaction with the user, and are
   not suitable for all kinds of applications.  The first and last
   options are too extreme to be defaults, but depending on the ability
   to interact, the middle two can be useful as defaults that may be
   modified by users if they want to.

   TLS defines a gmt_unix_time field in the Random substructure of a
   ClientHello.  This field is not always used.  With Kerberos however,
   time is very important and upfront hints of a peer's time can be
   helpful.  For this reason, the gmt_unix_time field in a ClientHello
   MUST always be filled if TLS-KDH is being requested.

4.1.  Indicating the Server Name

   If the ClientHello includes the server_name extension [RFC6066], and
   if that extension includes the HostName variant, then this will be
   the default domain or host name that the client would use when
   requesting for a service ticket.  The Kerberos protocol name is
   considered to be provided by the application level.  The realm name
   used should either be clear from the context (such as the login realm
   or static configuration) or it can be found in secure DNS records
   [KREALM] by either the Kerberos client or its KDC.

   The server_name extension is optional, but recommended for all uses
   of TLS-KDH because it provides useful hints to the server about
   assumptions made in the client.

   Aside from its current use in other parts of TLS, the server_name
   extension can be used by the server as a hint towards desired
   Kerberos configuration settings; such settings can then be different
   for different host names, as per the server-side configuration.  A
   server MAY fall back to a default Kerberos configuration for clients
   that provide no server_name extension, and this default configuration



Van Rein                  Expires April 3, 2016                 [Page 5]


Internet-Draft                   TLS-KDH                    October 2015


   MAY be less functional when insufficient information is available for
   optimal support of the client.

5.  ServerHello: Selecting a TLS-KDH CipherSuite

   After the client has offered one or more TLS-KDH CipherSuites, the
   TLS-KDH server configures its schemas of authentication and
   encryption by choosing one of these CipherSuites.  The server MUST
   NOT choose a TLS-KDH CipherSuite if it knows that it cannot process a
   Kerberos principal ticket for the requested service under any realm.
   When the service_name is processed to select a Kerberos
   configuration, then this specialised information MUST be taken into
   account in making this decision.

   When constructing the ServerHello, the TLS-KDH server fills the
   gmt_unix_time field in the Random substructure.  When the difference
   between the client and server time setting digresses to far, a server
   MAY also choose to reject a client's proposed TLS-KDH CipherSuites.

   There are more subtle possibilities too; a server may queue clients
   in a way that gradually disadvantages clients more as their
   gmt_unix_time digresses farther from that of the server.
   Specifically, sending a Diffie-Hellman public key may get deferred by
   such a policy.  Section Section 12.2 describes a use case that could
   benefit from this approach.

6.  No ServerCertificate

   The ServerCertificate message MUST NOT be included in TLS-KDH.  The
   Kerberos exchanges implemented by TLS-KDH provide mutual
   authentication.  As a result, there is no need for additional proof
   of server authenticity through X.509 certificates.

7.  ServerKeyExchange: Ephemeral Diffie-Hellman

   When one of the TLS-KDH CipherSuites is selected, the
   ServerKeyExchange MUST include an ephemeral Diffie-Hellman offer.
   This is done through an extension of the ServerKeyExchange structure:













Van Rein                  Expires April 3, 2016                 [Page 6]


Internet-Draft                   TLS-KDH                    October 2015


   struct {
       select (KeyExchangeAlgorithm) {
           /* existing cases defined elsewhere */
           case dhe_krb:
               TicketRequestFlags ticket_request_flags;
               ServerDHParams params;
           case ecdhe_krb:
               TicketRequestFlags ec_ticket_request_flags;
               ServerECDHParams ec_params;
       };
   } ServerKeyExchange;

   DISCUSS: Consider removing the dhe_krb case, leaving just ecdhe_krb

   Note that the new structure variations are not signed; instead of
   using an X.509 server certificate the Kerberos extension relies on
   the session key that Kerberos establishes for a session between a
   client and server, and from which a proof of authenticity will be
   derived.

   The ticket_request_flags and ec_ticket_request_flags field perform
   the same function for different key exchange algorithms.  They
   express flags that hint at properties for acceptable service tickets.

7.1.  TicketRequestFlags

   DISCUSS: Do we want this?  Not having it would mean that a client can
   have a local policy that defaults to anonymous credentials, and leave
   it to the server how to deal with it.  OTOH, a flag indicating a
   unique identity for the client, perhaps in a service-specific
   pseudonymic identity, could be useful to all parties involved.

   This structure is an extensible list of flag values that indicate
   constraints on the ticket that the client should 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:

   VisibleClientRealm (flag number 0)  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.

   LocalRealmService (flag number 1)  indicates that the client SHOULD
         NOT perform realm crossover, but instead look for a service



Van Rein                  Expires April 3, 2016                 [Page 7]


Internet-Draft                   TLS-KDH                    October 2015


         ticket in its local realm.  When this flag is set, the client
         may choose whether canonicalization [RFC6806] is useful; when
         this flag is not set, the client SHOULD use canonicalization to
         help it crossover to all realms that the KDC can reach.  When
         this flag is not set, the server MUST NOT expect the client
         realm to match one of the server realms.

   UniqueClientIdentity (flag number 2)  requests that the client
         presents a unique identity, even if it is a pseudonym that is
         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.

   Additional flag bit values are reserved through the publication of an
   RFC.  (TODO: IANA's Kerberos registry?)  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 suffice to
   ignore flag B.  It is possible for flags to cyclically refer to each
   other as alternatives; also in this case one flag's requirements can
   be fulfilled to skip the responsibilities for the flags to which it
   is an alternative.  What that means precisely depends on the pattern
   of reference.

   The structure holding TicketRequestFlags is a sequence of 32-bit
   integers.  The lower 5 bits of a flag number indicate the bit within
   a 32-bit integer, and the higher bits indicate the integer's index in
   the list.  Servers MUST send unknown flags with value 0 and clients
   MUST NOT act on flags they don't know.

   struct {
       uint32 flags<0..2^16-1>
   } TicketRequestFlags;

   Integers that are not present in the flags array MUST be considered
   to have value 0.  The last 32-bit integer MUST NOT contain all 0
   bits.  Note that this implies that the TicketRequestFlags can be an
   array of zero integers, namely when all flag values are 0.






Van Rein                  Expires April 3, 2016                 [Page 8]


Internet-Draft                   TLS-KDH                    October 2015


8.  Obtaining a Service Ticket on the Client

   The client may have locally configured realms, and/or it may lookup
   realm specifications in secure DNS [KREALM].  Combined with the
   service protocol and server name, this helps the client to form one
   or more service principal names.  These can be used in ticket
   requests.

   Before obtaining a Kerberos ticket, several considerations could be
   taken into account by the TLS-KDH client to select and/or order
   suitability of principal names for a desired ticket:

   o  Local policy could specify a service principal name to always use
      for a particular service protocol and/or server name and/or realm
      name;

   o  Local policy could specify a client principal name to always use
      for a particular service protocol and/or server name and/or realm
      name;

   o  A realm name match with a principal ticket's realm could suggest
      using that;

   o  Prior availability of a service ticket could suggest using the
      service principal name in that ticket;

   o  Prior availability of a service ticket could suggest using the
      client principal name in that ticket;

   o  Prior availability of a ticket granting ticket could suggest using
      that.

   In addition to this choice in service name to request, the client may
   wish to modify its own name, perhaps to a group name or a pseudonym,
   according to local policy and/or historic choices made.  Such
   mechanisms need not be standardised, as they are a local matter to
   the client-side Kerberos solution.  One default procedure is however
   RECOMMENDED, namely to send an anonymous ticket [RFC6112] when the
   server has not sent the UniqueClientIdentity flag; but to instead use
   a non-anonymous ticket when the anonymous ticket includes the
   anonymous realm name while the sever has sent the VisibleClientRealm
   flag.  The client SHOULD interact with the user to request permission
   for releasing the identifying information if possible, but the
   mechanism MAY store choices for future use in similar situations.
   Finally, the client-side Kerberos solution MAY obtain a pseudonymous
   name such as one based on NT-UID principal names [Section 6.2 of
   [RFC4120]] when the server has sent the UniqueClientIdentity flag; it




Van Rein                  Expires April 3, 2016                 [Page 9]


Internet-Draft                   TLS-KDH                    October 2015


   is up the client whether this is a short-lived or long-lived
   identity.

   Given the options that are now available, the TLS client SHOULD
   proceed in attempts to obtain a service ticket, until either a ticket
   is assigned or all options for obtaining one have been exhausted.
   When no ticket can be obtained, the TLS client MUST send a TLS Alert
   and shut down the connection.  The client might reconnect without
   offering TLS-KDH CipherSuites in response to a temporary local cache
   holding the negative result on a prior attempt.

9.  ClientKeyExchange: Kerberos ticket with Diffie-Hellman

   When the TLS-KDH client finds a suitable Kerberos service ticket, it
   sends a ClientKeyExchange messaging holding both that ticket and a
   Kerberos-styled authenticator constructed by the TLS-KDH client.
   This authenticator is freshly created for each submission.  The
   message format holding these two parts is formally specified as:

   struct {
       select (KeyExchangeAlgorithm) {
           /* definitions from other RFCs */
           case dhe_krb:
               opaque krb_ticket<0..2^16-1>;
               opaque authenticator_with_dh_ad<0..2^16-1>;
           case ecdhe_krb:
               opaque krb_ticket<0..2^16-1>;
               opaque authenticator_with_ecdh_ad<0..2^16-1>;
       } exchange_keys;
   } ClientKeyExchange;

   The selected krb_ticket byte string field MUST hold the literal bytes
   of a Kerberos Ticket structure [Section 5.3 of [RFC4120]].

   When selected, the authenticator_with_dh_ad field MUST contain an
   Authenticator [Section 5.5.1 of [RFC4120] encrypted with the session
   key that is presented to the service through the ticket in the
   krb_ticket field.  This Authenticator's AuthorizationData MUST
   contain an element with ad-type AD-DH-PUBKEY [KRB5-KDH] and ad-data
   holding a BITSTRING containing a DHPubkey [KRB5-KDH].  This supplies
   the same dh_Yc value that is supplied in the
   ClientDiffieHellmanPublic structure [RFC5246] as part of other
   CipherSuites whose names start with TLS_DHE_.

   When selected, the authenticator_with_ecdh_ad field MUST contain an
   Authenticator [Section 5.5.1 of [RFC4120]] encrypted with the session
   key that is presented to the service through the ticket in the
   krb_ticket field.  This Authenticator's AuthorizationData MUST



Van Rein                  Expires April 3, 2016                [Page 10]


Internet-Draft                   TLS-KDH                    October 2015


   contain an element with ad-type AD-ECDH-PUBKEY [KRB5-KDH] and ad-data
   holding a BITSTRING containing an ECDHPubkey [KRB5-KDH].  This
   supplies the same ecdh_Yc value that is supplied in the
   ClientECDiffieHellmanPublic structure [RFC4492] as part of other
   CipherSuites whose name starts with TLS_ECDHE_.

   The values of the authorization data types are:

   AD-DH-PUBKEY    (TBD)
   AD-ECDH-PUBKEY  (TBD)

9.1.  Impact of Anonymous Client Tickets

   When sending the ClientKeyExchange, a ticket is always provided.  It
   is possible however, to use an anonymous ticket [Section 3 of
   [RFC6112]], Section 3] that conceals the client principal name (the
   cname field in the ticket) and possibly also the client realm name
   (the crealm field in the ticket).  It is RECOMMENDED to use this kind
   of service ticket inasfar as it is permitted by the
   TicketRequestFlags that the server sent.

   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 X.509 authentication, the
   customary interpretation of not sending the CertificateRequest is
   that the server does not care for the client identity; anonymous
   tickets provide a mechanism for achieving a similar pattern under
   TLS-KDH.

   The presence of a ticket enables the server to conclude 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 Diffie-Hellman key
   exchange to follow, is known to be protected by a suitable ticket.

   Briefly put, we can speak of mutual authentication in this
   specification, even when the client uses an anonymous ticket.  The
   thing that is missing under an anonymous ticket is simply a validated
   (unique) identity for the client.






Van Rein                  Expires April 3, 2016                [Page 11]


Internet-Draft                   TLS-KDH                    October 2015


10.  Master Secret Calculation

   The Kerberos ticket holds a session key, which the KDC only makes
   available to a pair of authentic principals; we follow the Kerberos
   assumption of trust in the KDC (or path of KDCs) connecting the TLS-
   KDH client and the TLS-KDH server.

   Using the standard Diffie-Hellman procedures for TLS [Section 8.1.2
   of [RFC5246]] [Section 5.10 of [RFC4492]], a shared secret SHALL be
   calculated independently on the TLS-KDH client and the TLS-KDH
   server.  The shared secret value (Z) is used as the pre-master
   secret, after stripping all leading bytes that contain only zero
   bits.  The master secret is then determined as is customary for TLS.

11.  Finished: Mutual Validation

   The security of TLS-KDH relies more heavily on the Finished messages
   than Diffie-Hellman under Kerberos [KRB5-KDH]; TLS-KDH has an
   analogue for AP-REQ but not for AP-REP, so the client must still
   verify the server's proper use of the session key, or something
   decoded with it, as a proof of its authenticity.  Furthermore, the
   server-sent Diffie-Hellman public key, as sent in the
   ServerKeyExchange, has not been authenticated yet.  The use of the
   master secret based on the outcome of the key exchange, hashed
   together with the preceding handshake that includes the server-sent
   public key, and relying on the server's ability to decode the client-
   sent public key, together prove the server's authenticity to the
   client, and all this is arranged by the Finished message in TLS-KDH.

   The security of TLS-KDH also relies more heavily on the Finished
   messages than other TLS CipherSuites; the lack of a server signature
   on the ServerKeyExchange means that its authenticity can only be
   established once it has proven its ability to decrypt the
   authenticator holding the other half of the key exchange, and this
   verification is taken care of in the Finished exchange.

   The TLS specification is strict about verification of the verify_data
   contained in Finished messages, but leaves room for shorter
   verification data than cryptographically desirable for TLS-KDH.

   A "good size" for the verify_data_length is twice the bitsize of the
   key used in the symmetric algorithm, rounded up to an integer number
   of bytes; in the case of TLS-KDH, that would be based on the
   symmetric key algorithm specified as part of the CipherSuite.  For
   TLS_DHE_KRB_WITH_ARIA_256_GCM_SHA384 it would be 64 bytes and for
   TLS_DHE_KRB_WITH_3DES_EDE_CBC_SHA it would be 42 bytes.





Van Rein                  Expires April 3, 2016                [Page 12]


Internet-Draft                   TLS-KDH                    October 2015


   TODO: twice follows http://www.keylength.com/en/4/ -- is it necessary
   here?

   Negotiable values for verify_data_length were introduced in TLS 1.2;
   in earlier versions, the value was fixed to 12 bytes and TLS 1.2
   still uses 12 bytes as a default size.  Because of this, TLS-KDH
   authentication SHOULD NOT be implemented for any SSL version, nor for
   TLS versions up to and including TLS 1.1.

   When a TLS-KDH CipherSuite is selected on TLS 1.2 and later versions,
   the value of verify_data_length is defined to be the CipherSuite-
   dependent "good size" of the previous paragraph, although it is still
   possible to explicitly negotiate another value.  In general,
   implementations SHOULD NOT accept values of verify_data_length below
   the "good size" for the applicable CipherSuite.  Furthermore,
   specific mechanisms may fall under a lowest threshold that an
   administrator would like to enforce in their software; a client could
   prevent rejection on those grounds by proposing a higher
   verify_data_length and a server could enforce it while selecting the
   CipherSuite to use.  Both parties SHOULD be willing to support twice
   the "good size" for the given CipherSuite.

12.  Freshness of Diffie-Hellman Keys

   This specification refers to the use of "fresh" Diffie-Hellman keys.
   This section defines when such keys are considered fresh, and what
   operational impact this definition has.

   In some cases, there is no need to use a fresh Diffie-Hellman key;
   servers may reuse a Diffie-Hellman key use in the same TLS connection
   when it undergoes secure renegotation [RFC5746].  Diffie-Hellman keys
   MUST NOT be reused by TLS-KDH clients.

   In line with commonly accepted TLS procedures, the server dictates
   the Diffie-Hellman key parameters, without negotiation options for
   the client, except the choice between TLS_DHE_KRB_ and TLS_ECDHE_KRB_
   variations.  The client's sole prerogative is to reject an offered
   Diffie-Hellman public key if something about it (size,
   blacklistedness) is not considered agreeable.  It is generally
   assumed that a TLS server is setup to provide sufficiently secure
   Diffie-Hellman exchanges.  It should be noted that the security is
   additionally protected by the KDC-supplied session key, and that the
   only danger is that this is replaced with a Diffie-Hellman key of a
   lesser size.  For that reason, servers MUST supply Diffie-Hellman
   public keys that generate session keys of at least the number of
   bytes (rounded down) as the number of bytes (rounded up) in the
   symmetric key of the selected CipherSuite.




Van Rein                  Expires April 3, 2016                [Page 13]


Internet-Draft                   TLS-KDH                    October 2015


12.1.  Managing a Pool of Fresh Keys

   Any newly generated Diffie-Hellman key is considered fresh; this
   includes pregenerated keys that may have been stored in a pool of
   fresh keys.  The remainder of this section details when half-used
   keys may be recycled to this pool.

   It is quite possible for such a pool of fresh keys to be shared
   between application instances (such as virtual hosts) and even
   between different application protocols that rely on TLS for
   security.  It is not recommended however, to share the pool of fresh
   keys between redundant or even distributed server machines, as that
   would introduce communication delays and usually not have any
   benefit.

   For a client, a key can never become fresh after it has been used in
   a ClientKeyExchange.  Had this been any different, then two servers
   might get hold of the same Diffie-Hellman public key, in which case
   they might be in a position to tap traffic, or mount a man-in-the-
   middle attack.

   For a server, some reuse of keys is possible.  This is largely due to
   the fact that the Diffie-Hellman public key is visible in plaintext,
   and should therefore be considered something that is easily shared
   with any players, rogue ones included.

   TLS connections might terminate before the handshake is complete,
   including as a result of time-outs caused by unresponsive clients.
   When no ClientKeyExchange has been received over such a connection,
   then the server's Diffie-Hellman public key can be returned to the
   pool of fresh keys after the connection has been completely shut
   down.

   When a ClientKeyExchange has been received, but the contained
   Kerberos ticket failed on account of authentication, access control
   or anything else that avoids completing the Diffie-Hellman key
   exchange, then the server's public key has not been put to use, and
   there is no risk of reuse.  The one thing to care for is that
   Kerberos authentication uses a time stamp, which the server accepts
   within a certain time window.  Upon failure to authenticate a ticket,
   the server's public key must not be returned to the pool of fresh
   keys until the full duration of this server-side time window has
   passed.

   Anytime this specification calls for a fresh Diffie-Hellman key, it
   may be taken from this pool of fresh keys, even if that involves
   reuse of previously failed keys.




Van Rein                  Expires April 3, 2016                [Page 14]


Internet-Draft                   TLS-KDH                    October 2015


12.2.  Impact on Replay Attacks

   Kerberos authentication is valid over a certain period starting and
   ending at a time stamp embedded in the Authenticator that is attached
   to the ticket.  The server verifies these times, usually tolerating a
   small time window to deal with clock skew.  This is the normal
   procedure for handling a ticket in a successful TLS-KDH flow.

   One of the attacks of which a Kerberos system must be aware, is
   replay.  This is the situation where a rogue party taps the ticket
   and authenticator, and resends it as part of its own communication.
   It is especially useful in protocols that only check the Kerberos
   login but make no further use of the keys contained in it, or in
   protocols that are susceptible to other clever attacks.

   The traditional solution to this is to permit a time window around
   the server's current time, to compensate for clock skew between
   machines, and demand that the timestamp in the Authenticator falls
   within that window.  During this period, the server must not accept
   the same Authenticator, which is usually arranged by caching it
   during the window time.  In TLS-KDH however, the Authenticator
   contains a Diffie-Hellman public key which is paired with that of the
   server to form the master secret used in all of TLS, so as long as
   the server sends another Diffie-Hellman public key the result will be
   another master secret.

   This is why it is not good to reinsert a server's public key in the
   pool of fresh keys until the entire window period has passed; which
   never applies when authentication succeeds, but it might when it
   fails.  The client's timestamp might have been in the beginning of
   the clock skew window, leaving room for rogue resubmissions until the
   end of the window.  By keeping the server's public key out of
   circulation until the entire clock skew window has passed, this has
   been mitigated with certainty.

   The previous paragraph assumed that the Authenticator does not
   contain a timestamp that lies (far) in the future, which was assumed
   because it is not in the client's interest to lie.

   It is possible to tighten the signature check beyond the clock skew
   window, by observing the difference between the gmt_unix_time fields
   in ClientHello and ServerHello.  After correcting for this initial
   skew, the remaining clock skew is limited to the effects of
   communication delays, clock drift and relativistic effects.  The
   check on the remaining clock skew can be made within a much tighter
   time window than before, without disadvantaging clients that function
   normally.




Van Rein                  Expires April 3, 2016                [Page 15]


Internet-Draft                   TLS-KDH                    October 2015


   When applying this tighter check, the total window period to
   compensate for clock skew still includes the acceptable time
   difference between the gmt_unix_time fields, so this does not get
   tighter.  What this tighter check does however, is that it forces
   attackers to modify the gmt_unix_time that they send in a
   ClientHello, and as explained in Section Section 5, this can be used
   to the disadvantage of such clients.

12.3.  Impact on Denial-Of-Service Attacks

   The TLS-KDH CipherSuites enable fast authentication of clients, based
   on symmetric key cryptography.  Only for the assurance of Perfect
   Forward Secrecy is there a need to use some public key cryptography.
   Since public key operations impose a higher computational load on a
   system than symmetric key operations, they are attractive targets for
   denial-of-service attacks.  Within TLS-KDH, the willingness to
   provide different Diffie-Hellman public keys to each client, without
   having authenticated them, opens an opportunity of attack.

   The suggested use of a pool of fresh keys can help to thwart this
   attack.  Especially the ability to recycle keys into fresh keys
   drastically limits the impact of a denial-of-service attack through
   the computational complexity of public-key operations.  Note that
   recycling is always possible for clients that failed to authenticate;
   which is a suitable criterium to distinguish rogue clients from
   normal ones.

   The pool size may either prepare for denial-of-service attacks by
   filling up to a size that can withstand the constant bashing of the
   attack, and doing little more than the Kerberos authentication
   computations; or a pool may be adaptively sized and fill up, thus
   reducing the responsiveness of the server in the beginning of an
   attack, but returning to full service soon after the start of the
   attack.  Note that it is helpful in this respect that the pool can be
   shared among the various application instances and application
   protocols on a system.

   Furhter concerns that help with the mitigation of an attack including
   reduction of the timeout after which a client connection is torn
   down.  This may be approached through timing, or by timing out the
   most stagnated client connections when the pool of fresh keys runs
   empty.  One of the ways to implement this operationally could be to
   sidetrack traffic with the patterns of an attack to a service that is
   setup especially to deal with denial-of-service attacks.

   Based on normal behaviour, and especially focussing on successful
   authentications, it should be possible to find a probability
   distribution for timeouts that can help to separate proper clients



Van Rein                  Expires April 3, 2016                [Page 16]


Internet-Draft                   TLS-KDH                    October 2015


   from those who are trying to drain the pool of fresh keys.  It is
   very likely that a cut-off of the slow tail of proper authentications
   would only disadvantage clients that need to interact with their KDC
   or human user, while it would drastically reduce the effect of pool
   drainage.  The clients that are cut off because they need interaction
   time are setting up a new connection to a new service, and a simple
   reconnection attempt should help them to quickly use the information
   that would be cached by then.  Under a denial-of-service attack, this
   appears to be an acceptable condition.

   As explained in Section Section 12.2, it is possible to force a rogue
   client to offset its time in the ClientHello message, and this can be
   used to delay such rogue servers as explained in Section Section 5;
   this is especially important when an attack is mounted on the
   capacity for producing fresh Diffie-Hellman public keys, and the
   ability to immediately have a suspicion of which clients might be
   rogue really helps in getting proper traffic to pass through.

13.  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 upon receiving any data records, each side
   will trigger a TLS Alert.  The other records are still accepted, to
   permit re-issuance of session keys.  This mode of operation is
   intended to block data communication until authentication has been
   refreshed.  Implementations MAY choose to initiate 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.

   Note that this facility can form a potent combination with DTLS
   [RFC6347] by using UDP or SCTP to carry sessions that are dormant for
   long periods, with occasional bursts of data.  Such sessions are pre-
   validated, carrying data bursts that share the same credentials, that
   behave as though they were cached.  Only for reasons of session key
   expiration must such credentials be occasionally refreshed.







Van Rein                  Expires April 3, 2016                [Page 17]


Internet-Draft                   TLS-KDH                    October 2015


14.  Mandatody CipherSuites

   TLS and Kerberos have long been independent infrastructures for
   secure connectivity; with the introduction of the TLS-KDH
   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
   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  Negotiating a verify_data_size as suggested above;

   o  Supporting the TLS-KDH CipherSuites;

   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 "TLS-KDH Application
      Profile".

   The TLS-KDH 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.

15.  Comparison to Earlier Work

   An older specification [RFC2712] introduces Kerberos into TLS.  This
   specification improves on that work in a number of ways:

   o  The pre-master secret is no longer sent to the server under
      encryption with the KDC-provided session key; instead, Perfect
      Forward Secrecy is supported through a Diffie-Hellman key
      exchange;

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



Van Rein                  Expires April 3, 2016                [Page 18]


Internet-Draft                   TLS-KDH                    October 2015


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

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

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

   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.

16.  Efficiency Considerations

   The efficiency of the mechanism described here compares favourably
   with the more common approach of authentication through X.509
   certificates.

   The Kerberos mechanism is founded on symmetric cryptography, making
   it much more efficient than the asymmetric algorithms that are used
   with X.509 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 Diffie-Hellman is a relatively expensive
   asymmetric operation, but the same introduction is needed when
   Perfect Forward Secrecy is introduced alongside X.509-based
   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 TLS-KDH, because this
   specification requires that the server uses a fresh Diffie-Hellman
   public key for every connection.  This is of particular use to
   redundant (and possibly distributed) server farms, where sharing the



Van Rein                  Expires April 3, 2016                [Page 19]


Internet-Draft                   TLS-KDH                    October 2015


   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.

17.  Privacy Considerations

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

   o  Supported protocol versions, TLS extensions and CipherSuites

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

   A Kerberos ticket transmits less information in plaintext than an
   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 very
   brief period of attack on keys.

   TODO: In classical Kerberos setups, the ticket must provide a few
   handles in plaintext to be able to locate the service key for
   decrypting the KDC-encrypted ticket parts.  However, given that we
   usually provide a Server Name Indiction, it might be possible to
   remove the realm and sname parts from the ticket.  That data, or
   other ways to reference the service key, could be incorporated into
   the server configuration.  This does not bring much, since
   (specifically) the realm will often be configured in DNS.  However,
   for access to local services using the client's own realm, this might
   be useful.  Note that the protocol is somewhat linked to the port
   being accessed, so that too isn't much of a leak.

   When it is done within the same TLS connection and uses secure
   renegotiation [RFC5746], it should not pose a privacy problem if only
   the server reuses a Diffie-Hellman public key during the
   renegotiation within the same TLS connection into a TLS-KDH
   connection.

18.  Security Considerations

   To mutually prove authenticity, the client and server must encrypt
   respectively decrypt the authenticator attached to the Kerberos
   ticket.  These operations require access to the session key that is
   provided to client and server in a form that only they can unpack.
   The Finished messages verify that the two parties have performed the
   same derivations, which is only possible when it is based on the same
   Diffie-Hellman shared secret, which in turn can only be found when



Van Rein                  Expires April 3, 2016                [Page 20]


Internet-Draft                   TLS-KDH                    October 2015


   they were provided with the same session key by the KDC.  In terms of
   Kerberos, this implements mutual authentication.  Note that TLS-KDH
   uses the KDC-supplied session key only for encryption on the client,
   and only for decryption on the server, but since the encryption
   algorithms are symmetric, these are comparable and there is no need
   to also encrypt on the server or to decrypt on the client as part of
   the mutual authentication procedure.

   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 has introduced numerous refinements that are highly
   practical in daily use.  One worth noting is S4U2Proxy, under which a
   service can upgrade a received ticket to one with which it can be a
   client using a new service ticket in the client's name.  Such
   provisions are usually limited in the KDC through Constrained
   Delegation, but nonetheless it introduces an extra degree of freedom
   for attackers.  Especially dangerous is the combination with
   S4U2Self, which allows a service to obtain a client ticket without
   proving (in the Kerberos sense) that the client has actually
   authenticated to, or even contacted the server.

   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 by TLS-KDH, which uses fresh Diffie-Hellman keys for
   every connection, 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, and the use of accurate clocks
   reduces problems as a result of clock skew.

   TLS makes use of cryptographic algorithms that tend to be efficient
   to exploit in a denial-of-service attack.  This is indeed a known
   problem in the operation of TLS.  With TLS-KDH, the most-used
   algorithms are much lighter in weight, and when using a pool of fresh
   keys, it is possible to recycle the most computationally expensive
   keys and be left with only relatively lightweight, symmetric
   computations.





Van Rein                  Expires April 3, 2016                [Page 21]


Internet-Draft                   TLS-KDH                    October 2015


   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 Perfect Forward Secrecy.
   TLS-KDH implies this desirable property in all its CipherSuites.

19.  IANA Considerations

   This specification defines a number of CipherSuites that use Kerberos
   with Diffie-Hellman subkeys as their authentication mechanism.  These
   define the initial list of what is referred to as "TLS-KDH
   CipherSuites" in this specification:

   +------+----------------------------------+----------------+--------+
   | Valu | CipherSuite description          | verify_data_le | DTLS-  |
   | e    |                                  | ngth           | OK     |
   +------+----------------------------------+----------------+--------+
   | TBD  | TLS_DHE_KRB_WITH_IDEA_CBC_SHA    | 16             | Y      |
   | TBD  | TLS_DHE_KRB_WITH_AES_128_CBC_SHA | 16             | Y      |
   | TBD  | TLS_DHE_KRB_WITH_AES_256_CBC_SHA | 32             | Y      |
   | TBD  | TLS_DHE_KRB_WITH_AES_128_CBC_SHA | 16             | Y      |
   |      | 256                              |                |        |
   | TBD  | TLS_DHE_KRB_WITH_AES_256_CBC_SHA | 32             | Y      |
   |      | 384                              |                |        |
   | TBD  | TLS_DHE_KRB_WITH_AES_256_CBC_SHA | 32             | Y      |
   |      | 256                              |                |        |
   | TBD  | TLS_DHE_KRB_WITH_AES_128_GCM_SHA | 16             | Y      |
   |      | 256                              |                |        |
   | TBD  | TLS_DHE_KRB_WITH_AES_256_GCM_SHA | 32             | Y      |
   |      | 384                              |                |        |
   | TBD  | TLS_DHE_KRB_WITH_CAMELLIA_128_CB | 16             | Y      |
   |      | C_SHA                            |                |        |
   | TBD  | TLS_DHE_KRB_WITH_CAMELLIA_256_CB | 32             | Y      |
   |      | C_SHA                            |                |        |
   | TBD  | TLS_DHE_KRB_WITH_CAMELLIA_128_CB | 16             | Y      |
   |      | C_SHA256                         |                |        |
   | TBD  | TLS_DHE_KRB_WITH_CAMELLIA_256_CB | 32             | Y      |
   |      | C_SHA256                         |                |        |
   | TBD  | TLS_DHE_KRB_WITH_ARIA_128_CBC_SH | 16             | Y      |
   |      | A256                             |                |        |
   | TBD  | TLS_DHE_KRB_WITH_ARIA_256_CBC_SH | 32             | Y      |
   |      | A384                             |                |        |
   | TBD  | TLS_DHE_KRB_WITH_ARIA_128_GCM_SH | 16             | Y      |
   |      | A256                             |                |        |
   | TBD  | TLS_DHE_KRB_WITH_ARIA_256_GCM_SH | 32             | Y      |
   |      | A384                             |                |        |
   | TBD  | TLS_DHE_KRB_WITH_AES_128_CCM     | 16             | Y      |
   | TBD  | TLS_DHE_KRB_WITH_AES_256_CCM     | 32             | Y      |



Van Rein                  Expires April 3, 2016                [Page 22]


Internet-Draft                   TLS-KDH                    October 2015


   | TBD  | TLS_DHE_KRB_WITH_AES_128_CCM_8   | 16             | Y      |
   | TBD  | TLS_DHE_KRB_WITH_AES_256_CCM_8   | 32             | Y      |
   | TBD  | TLS_ECDHE_KRB_WITH_CAMELLIA_128_ | 16             | Y      |
   |      | GCM_SHA256                       |                |        |
   | TBD  | TLS_ECDHE_KRB_WITH_CAMELLIA_256_ | 32             | Y      |
   |      | GCM_SHA384                       |                |        |
   | TBD  | TLS_ECDHE_KRB_WITH_AES_128_CCM   | 16             | Y      |
   | TBD  | TLS_ECDHE_KRB_WITH_AES_256_CCM   | 32             | Y      |
   | TBD  | TLS_ECDHE_KRB_WITH_AES_128_CCM_8 | 16             | Y      |
   | TBD  | TLS_ECDHE_KRB_WITH_AES_256_CCM_8 | 32             | Y      |
   | TBD  | TLS_ECDHE_KRB_WITH_AES_128_GCM_S | 16             | Y      |
   |      | HA256                            |                |        |
   | TBD  | TLS_ECDHE_KRB_WITH_AES_256_GCM_S | 32             | Y      |
   |      | HA384                            |                |        |
   | TBD  | TLS_ECDHE_KRB_WITH_CAMELLIA_128_ | 16             | Y      |
   |      | CBC_SHA                          |                |        |
   | TBD  | TLS_ECDHE_KRB_WITH_CAMELLIA_256_ | 32             | Y      |
   |      | CBC_SHA                          |                |        |
   | TBD  | TLS_ECDHE_KRB_WITH_CAMELLIA_128_ | 16             | Y      |
   |      | CBC_SHA256                       |                |        |
   | TBD  | TLS_ECDHE_KRB_WITH_CAMELLIA_256_ | 32             | Y      |
   |      | CBC_SHA256                       |                |        |
   | TBD  | TLS_ECDHE_KRB_WITH_ARIA_128_CBC_ | 16             | Y      |
   |      | SHA256                           |                |        |
   | TBD  | TLS_ECDHE_KRB_WITH_ARIA_256_CBC_ | 32             | Y      |
   |      | SHA384                           |                |        |
   | TBD  | TLS_ECDHE_KRB_WITH_ARIA_128_GCM_ | 16             | Y      |
   |      | SHA256                           |                |        |
   | TBD  | TLS_ECDHE_KRB_WITH_ARIA_256_GCM_ | 32             | Y      |
   |      | SHA384                           |                |        |
   +------+----------------------------------+----------------+--------+

   [TODO: 3DES_EDE_CBC is not included anymore]

   [TODO: SEED does not seem to get updates, so it is not included here]

   [TODO: Should we still define 160-bit _SHA CipherSuites?]

   [TODO: Should we still define CBC encryption modes?  They'll probably
   be removed in TLS 1.3 anyway.  BEAST attacks TLS < 1.1 so that is not
   an issue here; Lucky 13 probably applies.]

   [TODO: MIT suggests dropping DHE and just to support ECDHE in
   [KRB5-KDH]; the same would apply here.]







Van Rein                  Expires April 3, 2016                [Page 23]


Internet-Draft                   TLS-KDH                    October 2015


20.  References

20.1.  Normative References

   [KRB5-KDH]
              Van Rein, R., "KRB5-KDH: Cryptographically binding
              Kerberos with Diffie-Hellman", October 2014.

   [KREALM]   Van Rein, R., "Kerberos Realm Descriptors in DNS
              (KREALM)", September 2015.

   [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>.

   [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>.

   [RFC5746]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
              "Transport Layer Security (TLS) Renegotiation Indication
              Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,
              <http://www.rfc-editor.org/info/rfc5746>.

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066, DOI
              10.17487/RFC6066, January 2011,
              <http://www.rfc-editor.org/info/rfc6066>.

   [RFC6806]  Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos
              Principal Name Canonicalization and Cross-Realm
              Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012,
              <http://www.rfc-editor.org/info/rfc6806>.





Van Rein                  Expires April 3, 2016                [Page 24]


Internet-Draft                   TLS-KDH                    October 2015


   [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>.

20.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>.

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, DOI 10.17487/
              RFC4282, December 2005,
              <http://www.rfc-editor.org/info/rfc4282>.

   [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>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [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>.





Van Rein                  Expires April 3, 2016                [Page 25]


Internet-Draft                   TLS-KDH                    October 2015


Appendix A.  Acknowledgements

   Thanks go to Simo Sorce for useful discussions during the creation of
   this document.

Author's Address

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

   Email: rick@openfortress.nl





































Van Rein                  Expires April 3, 2016                [Page 26]


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