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. Support for realm crossover is included through realm name negotiation.

Introduction

Kerberos lends itself well to infrastructure-supported mutual authentication, and can even be used to crossover between realms. A downside in such uses may be the lack of Perfect Forward Secrecy, as a result of Kerberos' reliance on symmetric key operations. Diffie-Hellman key exchange can be used to incorporate this desirable property, but its lack of authentication 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 with realm-crossover facilities and Perfect Forward Secrecy.

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.

Relations to Prior Work

Prior work exists for Kerberos authentication within TLS [RFC 2712]. 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 [RFC 4559] 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 limitation of TLS-KDH to Kerberos 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 more secure mechanism for encryption and mutual authentication, which also lends itself for 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. In installations that use SASL, the EXTERNAL mechanism [RFC 4422] can be used to extract the remote identity from TLS and make it available to the application layer; SASL EXTERNAL is also used when TLS authenticates peers through X.509 certificates.

The identity communicated through the SASL EXTERNAL mechanism is local to the TLS endpoint, but the best alignment with X.509 certificates seems to arise when the aim is to derive a Network Access Identifier [RFC 4282] and/or a domain name. In the case of a Kerberos principal name, this would involve translation between case-sensitive realm names to case-insensitive DNS names; this is usually done by ignoring or lowering the case of the realm name while requiring that no two realm names may differ only in their case [Section 7.2.3.1 of RFC 4120]. However, since this falls outside the scope of this specification, this is purely an informational suggestion.

CipherSuites for Kerberos with Perfect Forward Secrecy

This specification extends TLS [RFC 5246] 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_KRB5 and ECDHE_KRB5 variants; their names start with TLS_DHE_KRB5_ and TLS_ECDHE_KRB5_, 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.

ClientHello: Offering 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.

Mentioning the Server Name (Recommended)

If the ClientHello includes the server_name extension [RFC 6066], and if that extension includes the HostName variant, then this will be the name that the client would use when looking for a service ticket. The Kerberos protocol name is considered to be known to the client. The realm name used should either be clear from the context (perhaps the login realm) or can be found in secure DNS records [draft-vanrein-dnstxt-krb1].

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

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 MAY be less functional when insufficient information is available for full-blown support of the client.

ServerHello: Selecting a TLS-KDH CipherSuite

After the client has offered one or more TLS-KDH CipherSuites, the 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.

No ServerCertificate

The ServerCertificate message MUST NOT be included in TLS-exchanges following a TLS-KDH CipherSuite.

The Kerberos exchanges implemented by TLS-KDH CipherSuites provide mutual authentication. As a result, there is no need for additional proof of server authenticity through X.509 certificates.

ServerKeyExchange: Offering 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:

struct {
          select (KeyExchangeAlgorithm) {
              /* existing cases defined elsewhere */
              case dhe_krb5:
                  TicketRequest ticket_request;
                  ServerDHParams params;
              case ecdhe_krb5:
                  TicketRequest ec_ticket_request;
                  ServerECDHParams ec_params;
          };
      } ServerKeyExchange;

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 or ec_ticket_request field perform the same function for different key exchange algorithms. They express flags that hint at properties for acceptable service tickets.

TicketRequest

TODO: 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. This flag indicates that the well-known anonymous realm name WELLKNOWN:ANONYMOUS [Section 3 of RFC6112] is unacceptable to the service.

  • LocalRealmService (flag number 1) indicates that realm crossover is not supported for this service. TODO: This usually means that the KDC of the client and of the service must be the same, and perhaps even the realm name. But there may also be KDC policies under which statically configured realm crossover is permitted. This is independent from the VisibleClientRealm flag, as this may be a KDC-enforced policy.

  • UniqueClientIdentity (flag number 2) requests that the client presents a unique identity, even if it is a pseudonym that is specific to this service. Note however, that some services can make good use of identities that are also presented over other protocols; the choice to share such an identity however, is made by the client. Even the choice to provide a short-lived or long-lived unique client identity is up the client. This flag indicates that the client principal name WELLKNOWN/ANONYMOUS of type KRB_NT_WELLKNOWN [Section 3 of RFC 6112] is not acceptable to the service.

  • HostingServerName (flag number 3) indicates that the service should be named as the host pointed to by SRV records [RFC2782] rather than the domain under which SRV records for the service are looked up. Note that this influences the principal name, but not the way the service's realm name is found.

  • DISCUSS:FUTURE:AssertionStatement indicates that the service ticket should contain a SAML Assertion Statement as part of a typed hole in the authenticator. The future extension defining this may expand IANA's "TLS Authorization Data Formats Registry" (as introduced by RFC 5878) with identifiers for an AttributeQuery, presented either inline or as a URL-and-hash combo. This enables the server to pass an AttributeQuery to the client in the ServerHello. The client can use this to ask the client what to do, to select a client identity / pseudonym to use for this service, and subsequently to request the KDC to supply an agreed-upon set of attributes. Without this passing of an AttributeQuery, the client would need to guess or manually setup a set of attributes that the server requests or requires. Note that the server is free to accept a not-so-informative SAML statement and provide feedback through the application protocol on what it might be missing.

Additional flag bit values are reserved through the publication of an RFC. TODO: IANA's Kerberos registry?

The structure of a TicketRequest 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>
} TicketRequest;

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 TicketRequest MAY be an array of zero integers as the canonical representation when all flag values are 0.

TODO: It may be helpful to include SAML query information!!!

Optional CertificateRequest: Requesting Client Identity

TODO: Drop this

The server may choose to request a client identity. It does not need to do this in order to receive a Kerberos ticket from the client, but it can use this to hint that an anonymous ticket [RFC 6112] may be rejected. Note that some anonymous tickets mention a realm name while others conceal it; and that all anonymous tickets conceal the principal name of the client.

In general, when no CertificateRequest is sent by the server, the client MAY assume that an anonymous ticket can be sent, and the server MUST then accept such anonymous tickets. When a CertificateRequest is sent by the server, the client MUST NOT assume with certainty that an anonymous ticket can be sent, as the server MAY reject such anonymous tickets.

TODO: Contents?!? certificate_types may not be empty! the supported_signature_algorithms can be empty (I think, check). the certificate_authorities can be empty but might actually hint at KDC's with fields that specify krbtgt/* or krbtgt/REALM but it MUST NOT be treated as a secure realm list; a hint seems to add nothing to KREALM records (but possibly confused security).

TODO: Add a remark about external sources for finding the realm, and point to draft-vanrein-dnstxt-krb1

Obtaining a Service Ticket on the Client

The client may have locally configured realms, and/or it may lookup realm specifications in secure DNS [draft-vanrein-dnstxt-krb1]. 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:

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

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

  • A realm name match with a principal ticket’s realm could suggest using that;

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

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

  • 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 standard mechanism is actually recommended, namely to request an anonymous ticket [RFC 6112] when the server has not sent a CertificateRequest to the client.

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. It may reconnect at a later time, perhaps without offering TLS-KDH CipherSuites due to temporary local caching of the negative result on a prior attempt.

ClientKeyExchange: Offering a 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_krb5:
            opaque krb5_ticket<0..2^16-1>;
            opaque authenticator_with_dh_ad<0..2^16-1>;
        case ecdhe_krb5:
            opaque krb5_ticket<0..2^16-1>;
            opaque authenticator_with_ecdh_ad<0..2^16-1>;
    } exchange_keys;
} ClientKeyExchange;

The selected krb5_ticket byte string field MUST hold the literal bytes of a Kerberos Ticket structure [RFC 4120, Section 5.3].

When selected, the authenticator_with_dh_ad field MUST contain an Authenticator [RFC 4120, Section 5.5.1] encrypted with the session key that is presented to the service through the ticket in the krb5_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 [RFC 5246] as part of other CipherSuites whose names start with TLS_DHE_.

When selected, the authenticator_with_ecdh_ad field MUST contain an Authenticator [RFC 4120, Section 5.5.1] encrypted with the session key that is presented to the service through the ticket in the krb5_ticket field. This Authenticator's AuthorizationData MUST 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 [RFC 4492] 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)

Impact of Anonymous Client Tickets

When sending the ClientKeyExchange, a ticket is always provided. It is possible however, to use a so-called anonymous ticket [RFC 6112, 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 when the server does not send the CertificateRequest to the client.

The impact of using an anonymous ticket aer 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. Since the customary interpretation of not sending the CertificateRequest is that the server does not care for the client identity, this would be the Kerberos way of achieving the same.

The one thing the server can conclude from the presence of a ticket is that the client has actually managed to obtain a ticket through the formal pathways of Kerberos; the reason this can be assumed is that the ticket holds a 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 someone checked the client. As a result, the rest of the exchange, most notably the Diffie-Hellman exchange, is known to be protected by the ticket.

Briefly put, we still 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.

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 [RFC 5246, Section 8.1.2] [RFC 4492, Section 5.10], 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.

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 part of the Diffie-Hellman key exchange, namely the part sent during ServerKeyExchange, has not been authenticated yet. The use of the master secret based on the outcome of the key exchange, plus the ability to decode the client-sent for the same process, constitute the proof that the client needs, and it is part of 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_KRB5_WITH_ARIA_256_GCM_SHA384 it would be 64 bytes and for TLS_DHE_KRB5_WITH_3DES_EDE_CBC_SHA it would be 42 bytes.

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 implicitly set to the "good size" of the previous paragraph, although it is still possible to explicitly negotiate another value. In general, implementations SHOULD NOT accept less than the "good size" for the verify_data_length. 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.

Generation and Reuse of Diffie-Hellman Public Keys

As part of a Diffie-Hellman key exchange, each party supplies its share of entropy for the shared secret. The result is that each party can enforce a fresh shared secret by offering a fresh Diffie-Hellman public key. This effect is put to use by the server, which MUST NOT reuse a public key when there is a risk of replay attacks. An example where this risk is not present is when switching a TLS connection protected with a freshly generated Diffie-Hellman public key to TLS-KDH through secure renegotiation [RFC 5746]; in this situation, the server MAY reuse a Diffie-Hellman public key. The same does not hold for the client.

The client submits its Diffie-Hellman public key under encryption with the KDC-supplied session key, as part of the mutual authentication procedure. Whenever the client could be dealing with a new server principal the client MUST enforce a fresh shared secret by offering a fresh Diffie-Hellman public key. This is certainly true when switching from an unauthenticated CipherSuite to an authenticated CipherSuite. The determining factor is whether a KDC-supplied session keys matches one defined for the client-side public key that might be reused; only when such a key is available and the same KDC-supplied session key is known to be used MAY the client reuse a Diffie-Hellman public key. Note that ticket renewal [RFC 4120, Section 2.3] generates a fresh KDC-supplied session key, thus ensuring a regular replacement of the Diffie-Hellman public key with a timing determined by KDC policy.

Notwithstanding the above, it is possible for TLS servers (and, perhaps to a lesser degree, TLS clients) to pre-generate Diffie-Hellman public keys. Where the above speaks of "fresh" keys, this refers to keys that have not been used before, rather than to the fact that their creation for any particular connection. Therefore, pre-generated public keys can be pooled for later use, but will still be subject to the constraints that limit reuse of such public keys.

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 and TLS_ECDHE 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 up) as the number of bytes (rounded up) in the symmetric key of the selected CipherSuite.

TLS-KDH 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 [RFC 4120, Section 2.3] may provide some relief from such user interaction.

When the TLS-KDH connection expires, it will not send any further data records, and upon receiving any data records it 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 [RFC 6347] 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.

Mandatory CipherSuites

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

TLS-KDH defines a manner to integrate the security mechanisms of TLS and Kerberos, which currently live more or less in separate worlds. That does not mean, however, that all Kerberos applications are prepared to process the broad potential of TLS, especially 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 that can allow such applications to stand on their own:

  • Based on TLS 1.2 or newer;
  • Negotiating a verify_data_size as suggested above;
  • Supporting the TLS-KDH CipherSuites;
  • Not necessarily supporting the TLS_RSA_WITH_AES_128_CBC_SHA CipherSuite that is mandatory in the default TLS application profile [RFC 5246].
  • 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.

Comparison to Earlier Work

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

  • 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;
  • 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;
  • The mutual authentication of TLS client and TLS server is established by TLS-KDH CipherSuites that implicitly enlarge the Finished message size;
  • 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;
  • 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;
  • 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.

Efficiency Considerations

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

The Kerberos mechanism is founded in 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 considered to replace the need for withdrawal mechanisms based on chains of trust, CRLs [RFC 3280], OCSP [RFC 6960], DANE [RFC 6698] and perhaps other mechanisms. As a result, the validity of a Kerberos ticket can be checked with relatively modest software.

The inclusion of ephemeral Diffie-Hellman is a relatively expensive asymmetric operation, but the same introduction is advised 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 generates a fresh Diffie-Hellman public key for every new connection. 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.

Privacy Considerations

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

  • Supported protocol versions, TLS extensions and CipherSuites
  • The server's principal name, hostname 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 names of server-trusted KDCs but neither the TLS-KDH server nor any KDC publishes any long-lasting key material for TLS or Kerberos, so parties looking for a cracking challenge are put out of work.

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, it should not pose a privacy problem if only the server reused a freshly generated Diffie-Hellman public key from an unauthenticated CipherSuite during the renegotiation within the same TLS connection into a TLS-KDH connection.

Security Considerations

To mutually prove authenticity, the client and server must encrypt and 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 decrypt. 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 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 vital 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 ticket with the client's authenticated name. Such provisions are usually limited in the KDC through Constrained Delegation, but it nonetheless introduces an extra degree of freedom for attackers. Especially interesting 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 it, 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 generates fresh Diffie-Hellman keys for every new conncetion, 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.

Kerberos security sometimes 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.

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:

  • TLS_DHE_KRB5_WITH_3DES_EDE_CBC_SHA
  • TLS_DHE_KRB5_WITH_IDEA_CBC_SHA
  • TLS_DHE_KRB5_WITH_AES_128_CBC_SHA
  • TLS_DHE_KRB5_WITH_AES_256_CBC_SHA
  • TLS_DHE_KRB5_WITH_AES_128_CBC_SHA256
  • TLS_DHE_KRB5_WITH_AES_256_CBC_SHA384
  • TLS_DHE_KRB5_WITH_AES_256_CBC_SHA256
  • TLS_DHE_KRB5_WITH_AES_128_GCM_SHA256
  • TLS_DHE_KRB5_WITH_AES_256_GCM_SHA384
  • TLS_DHE_KRB5_WITH_CAMELLIA_128_CBC_SHA
  • TLS_DHE_KRB5_WITH_CAMELLIA_256_CBC_SHA
  • TLS_DHE_KRB5_WITH_CAMELLIA_128_CBC_SHA256
  • TLS_DHE_KRB5_WITH_CAMELLIA_256_CBC_SHA256
  • TLS_DHE_KRB5_WITH_SEED_CBC_SHA
  • TLS_DHE_KRB5_WITH_ARIA_128_CBC_SHA256
  • TLS_DHE_KRB5_WITH_ARIA_256_CBC_SHA384
  • TLS_DHE_KRB5_WITH_ARIA_128_GCM_SHA256
  • TLS_DHE_KRB5_WITH_ARIA_256_GCM_SHA384
  • TLS_DHE_KRB5_WITH_AES_128_CCM
  • TLS_DHE_KRB5_WITH_AES_256_CCM
  • TLS_DHE_KRB5_WITH_AES_128_CCM_8
  • TLS_DHE_KRB5_WITH_AES_256_CCM_8
  • TLS_ECDHE_KRB5_WITH_CAMELLIA_128_GCM_SHA256
  • TLS_ECDHE_KRB5_WITH_CAMELLIA_256_GCM_SHA384
  • TLS_ECDHE_KRB5_WITH_AES_128_CCM
  • TLS_ECDHE_KRB5_WITH_AES_256_CCM
  • TLS_ECDHE_KRB5_WITH_AES_128_CCM_8
  • TLS_ECDHE_KRB5_WITH_AES_256_CCM_8
  • TLS_ECDHE_KRB5_WITH_CAMELLIA_128_CBC_SHA
  • TLS_ECDHE_KRB5_WITH_CAMELLIA_256_CBC_SHA
  • TLS_ECDHE_KRB5_WITH_CAMELLIA_128_CBC_SHA256
  • TLS_ECDHE_KRB5_WITH_CAMELLIA_256_CBC_SHA256
  • TLS_ECDHE_KRB5_WITH_ARIA_128_CBC_SHA256
  • TLS_ECDHE_KRB5_WITH_ARIA_256_CBC_SHA384
  • TLS_ECDHE_KRB5_WITH_ARIA_128_GCM_SHA256
  • TLS_ECDHE_KRB5_WITH_ARIA_256_GCM_SHA384

BEGIN.NOTES

  • TODO: Has SEED been deprecated? It is not up to date!
  • Perhaps pipe the IANA list through grep | sed | sort | uniq?

cat /tmp/ciphersuites.txt | grep 'TLS_(EC)\?DHE_' | grep -v 'KRB5' | sed -e 's/RSA/KRB5/' -e 's/DSS/KRB5/' -e 's/PSK/KRB5/' -e 's/ECDSA/KRB5/' | grep 'KRB5' | sort | uniq | grep -v NULL | grep -v EXPORT | grep -v 'RC4' | grep -v 'DES'

  • TLS_DHE_KRB5_WITH_3DES_EDE_CBC_SHA
  • TLS_DHE_KRB5_WITH_AES_128_CBC_SHA
  • TLS_DHE_KRB5_WITH_AES_128_CBC_SHA256
  • TLS_DHE_KRB5_WITH_AES_128_CCM
  • TLS_DHE_KRB5_WITH_AES_128_CCM_8
  • TLS_DHE_KRB5_WITH_AES_128_GCM_SHA256
  • TLS_DHE_KRB5_WITH_AES_256_CBC_SHA
  • TLS_DHE_KRB5_WITH_AES_256_CBC_SHA256
  • TLS_DHE_KRB5_WITH_AES_256_CBC_SHA384
  • TLS_DHE_KRB5_WITH_AES_256_CCM
  • TLS_DHE_KRB5_WITH_AES_256_CCM_8
  • TLS_DHE_KRB5_WITH_AES_256_GCM_SHA384
  • TLS_DHE_KRB5_WITH_ARIA_128_CBC_SHA256
  • TLS_DHE_KRB5_WITH_ARIA_128_GCM_SHA256
  • TLS_DHE_KRB5_WITH_ARIA_256_CBC_SHA384
  • TLS_DHE_KRB5_WITH_ARIA_256_GCM_SHA384
  • TLS_DHE_KRB5_WITH_CAMELLIA_128_CBC_SHA
  • TLS_DHE_KRB5_WITH_CAMELLIA_128_CBC_SHA256
  • TLS_DHE_KRB5_WITH_CAMELLIA_128_GCM_SHA256
  • TLS_DHE_KRB5_WITH_CAMELLIA_256_CBC_SHA
  • TLS_DHE_KRB5_WITH_CAMELLIA_256_CBC_SHA256
  • TLS_DHE_KRB5_WITH_CAMELLIA_256_CBC_SHA384
  • TLS_DHE_KRB5_WITH_CAMELLIA_256_GCM_SHA384
  • TLS_DHE_KRB5_WITH_SEED_CBC_SHA
  • TLS_ECDHE_KRB5_WITH_3DES_EDE_CBC_SHA
  • TLS_ECDHE_KRB5_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_KRB5_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_KRB5_WITH_AES_128_CCM
  • TLS_ECDHE_KRB5_WITH_AES_128_CCM_8
  • TLS_ECDHE_KRB5_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_KRB5_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_KRB5_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_KRB5_WITH_AES_256_CCM
  • TLS_ECDHE_KRB5_WITH_AES_256_CCM_8
  • TLS_ECDHE_KRB5_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_KRB5_WITH_ARIA_128_CBC_SHA256
  • TLS_ECDHE_KRB5_WITH_ARIA_128_GCM_SHA256
  • TLS_ECDHE_KRB5_WITH_ARIA_256_CBC_SHA384
  • TLS_ECDHE_KRB5_WITH_ARIA_256_GCM_SHA384
  • TLS_ECDHE_KRB5_WITH_CAMELLIA_128_CBC_SHA256
  • TLS_ECDHE_KRB5_WITH_CAMELLIA_128_GCM_SHA256
  • TLS_ECDHE_KRB5_WITH_CAMELLIA_256_CBC_SHA384
  • TLS_ECDHE_KRB5_WITH_CAMELLIA_256_GCM_SHA384

END.NOTES

This specification defines a TLS extension named “krb5_realm_name_list”, which lists Kerberos realm names. This extension should be entered into the Transport Layer Security Extensions registry and be assigned an Extension Type Value.