| Network Working Group | R. Van Rein |
| Internet-Draft | ARPA2.net |
| Intended status: Standards Track | March 11, 2016 |
| Expires: September 12, 2016 |
TLS-KDH: Kerberos + Diffie-Hellman in TLS
draft-vanrein-tls-kdh-02
This specification defines a TLS message flow with Kerberos-based (mutual) authentication, binding in Elliptic-Curve Diffie-Hellman to achieve Forward Secrecy for the session.
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 September 12, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Kerberos lends itself well to infrastructure-supported mutual authentication, and can even be used to crossover between realms. A downside of this infrastructure is that a crack of one key can lead to a cascade of reverse-engineered keys. Diffie-Hellman key exchange, nowadays primarily in its Elliptic-Curve variation, can be used to incorporate the desirable property of Forward Secrecy, but its vulnerability to man-in-the-middle attacks must then be overcome by cryptographically binding it to an authentication mechanism.
This specification describes how Kerberos data structures can be used for TLS client authentication, by embedding Kerberos data in X.509 client certificates and signatures. The server can still present a Certificate with a traditional signing mechanism such as RSA for authentication, in which case this specification speaks of a KDH-enhanced exchange; in absense of a server Certificate the Kerberos-based X.509 format can be used for mutual authentication in what will then be called a KDH-only exchange. The KDH-enhanced variety uses existing CipherSuite, and KDH-only defines new CipherSuites. Both KDH-enhanced and KDH-only message flows will be referred to as TLS-KDH.
Both TLS-KDH variations form a cryptographic binding between Kerberos and Elliptic-Curve Diffie-Hellman (ECDH), leading to the combined advantages of infrastructure-supported mutual authentication and Forward Secrecy.
The normal flow of TLS-KDH messages is basically a standard interaction with a modified form of client Certificate and CertificateVerify:
Client Server
ClientHello -------->
ServerHello
ServerCertificate*
ServerKeyExchange
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* Indicates that ServerCertificate is an optional message; it is present for KDH-enhanced message flows, and absent for KDH-only message flows.
[] Indicates that ChangeCipherSpec is an independent TLS protocol content type; it is not actually a TLS handshake message.
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 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 if they migrate to HTTP over TLS-KDH. Note that this provides an alternative for Kerberos, not to SPNEGO and not for general GSS-API protocols. This restriction of TLS-KDH to Kerberos, rather than a more general GSS-API protocol, is a result of the fixed number of message exchanges available within TLS.
Many other protocols incorporate Kerberos through GSS-API, usually via SASL. This is considered secure, but has an aguable disadvantage of separating encryption and authentication layers, and quite possibly also the identities involved in these layers. Furthermore, encryption through SASL is not commonly used. In situations where Kerberos is used for GSS-API over SASL, TLS-KDH offers a comparable but more efficient and tighter-coupled mechanism for encryption and mutual authentication, in a way that also lends itself to non-SASL applications. Specifically useful in this respect is that there is no longer a requirement to setup X.509 certificates plus infrastructure and validation mechanisms, just to satisfy encryption requirements with their own authentication infrastructure. In applications that use SASL, the EXTERNAL mechanism [RFC4422] can use the client identity in a Kerberos ticket, and make it available to the application layer; SASL EXTERNAL is also used when TLS authenticates peers through X.509 certificates.
This section specifies individual extensions to Kerberos that make it possible to use TLS.
The IANA registry of Kerberos Parameters defines a number of Checksum Types. This includes keyed and non-keyed checksums. We introduce checksum types to match the secure hash algorithms that are used in TLS.
There already are two values to represent SHA1. An implementation that processes Checksum Types MAY send either and MUST accept both as equivalent indications.
The following additional Checksum Types are introduced for use with TLS [Section 7.4.1.4.1 of [RFC5246]]:
Kerberos has a symmetric analogon to a signature, namely an Authenticator [Section 5.5.1 of [RFC4120]]. When used in TLS-KDH, the Authenticator MUST have a secure hash embedded in the cksum field. The checksum type used in the context of TLS MUST be taken to match one of the entries in IANA's TLS HashAlgorithm Registry.
The Authenticator is not sent in the plain, but encrypted with a Kerberos session key as EncryptedData [Section 5.2.9 of [RFC4120]] and this is how it provides authenticity: only the client and the service can unpack the EncryptedData and process the Authenticator.
A standard part of an Authenticator is a timestamp with microsecond accuracy. This is validated within a small window around the independently sycnchronised time of the TLS client and server. It is customary to allow a time window of about 5 minutes around the server time.
To avoid replay attacks, Kerberos solutions need to remember received Authenticators, or their time stamps, until the time window has passed. This can complicate servers, especially for redundant deployments. When combined with ephemeral ECDH, there is no need for such infrastructure to avoid replay attacks.
Other fields in the Authenticator than specified above MUST be ignored by the recipient.
This specification leaves the certification possibilities for servers in tact, even if it extends the client certification side. This is why it is not desirable to define a new certificate type [RFC5801] for Kerberos, as that would impact the server certificate. Instead, we define a method to encapsulate Kerberos credentials in the general X.509 certificate format on the client side.
Kerberos is based on symmetric keys, but its infrastructure is similar to a public-key cryptosystem. The main difference is that its cryptographic claims can only be verified by a targeted service, but within the scope of TLS this does not present any problems. Embedding a Kerberos Ticket into an X.509 certificate is akin to tunneling, where a message is packed into a message with a similar purpose.
The X.509 client certificate is constructed from Kerberos by building a TBSCertificate [Section 4.1 of [RFC5280]] as follows:
The Certificate built from the TBSCertificate adds the following fields:
The OIDs referred to above are defined below Section 4.3.
DISCUSSION: This is an alternative to S4U2Proxy, which relies on the server realm to care for the provisioned rights. If TLS-KDH is to scale up to more loose collaborations, without implied mutual trust, then it needs a new method for backend service support. This is defined below.
The TLS server may depend on additional Kerberos-protected services, generally referred to as "backend services". As an example, a webmail service may need to access IMAP and SMTP backend services, possibly under independent administrative control. This section describes an OPTIONAL Kerberos mechanism in support of such backend services.
In addition to the main Ticket supplied in the client Certificate's public key field, the TLS server would need Tickets to gain access to any backend services, and in fact these Tickets can help to define where these backend services are located and under what client identity they are accessed. The client needs to provide these additional Tickets in an AuthorizationData element whose ad-type is AD-BACKEND-TICKETS (TBD) and whose ad-data holds a KRB-CRED message [Section 5.8 of [RFC4120]] with an enc-part that uses NULL encryption [Section 6.3.1 of [RFC1510]]. The element may be carried in the authorization-data field of either the service Ticket or an Authenticator.
Additional Tickets MUST NOT be renewable, but the main Ticket MAY be; when this first Ticket is renewed it SHOULD be resent with the backend extension as they are setup at that time. Additional Tickets SHOULD have neither the FORWARDABLE nor the PROXIABLE flag set.
Additional Tickets should be supplied every time the main Ticket is supplied for TLS-KDH. As a result, both the main and additional Tickets MAY be forgotten by the server whenever a TLS-KDH session ends. However, when needed for longer-lasting or deferred backend processing, the server MAY hold the Tickets longer.
It is possible for backend services to have backend services themselves; this can be facilitated by a an AD-BACKEND-TICKETS element contained in the respective backend service Ticket.
The generation of AD-BACKEND-TICKETS at the client falls outside the scope of this document, but it usually involves requesting the TLS-KDH service Ticket from the client's KDC. To facilitate that, the server desiring additional Tickets SHOULD set the LocalRealmService flag Section 4.5; without this flag, the client MAY choose not to supply additional Tickets. The use of this flag may imply that the server needs to be flexible in the identity that the client uses for its service.
The client MUST NOT take hints from the server or any non-local KDC about required backend Tickets; this might make the client's identity vulnerable.
This section describes changes to TLS in support of Kerberos.
The following conceptual data should be available while the TLS-KDH message flows evolve:
This specification adds a new entry named kerberos_sign in IANA's TLS ClientCertificateType Identifiers Registry, with the value TBD.
This specification introduces a mechanism for signatures under Kerberos Section 3.2. This mechanism is represented in two places.
In TLS, a new SignatureAlgorithm named kerberos is allocated with value TBD in IANA's TLS Parameters Registry. This Kerberos SignatureAlgorithm is usually combined with a HashAlgorithm that is in common use with TLS, to for a SignatureAndHashAlgorithm. The digitally-signed structure [Section 4.7 of [RFC5246]] uses this structure, followed by a variable-sized opaque byte sequence, which should hold the EncryptedData holding an Authenticator Section 3.2.
In X.509 certificates, an AlgorithmIdentifier is used to represent the combination of a signature and hash algorithm. This consists of an OID and optional parameters. For the Kerberos signature algorithm, the parameters are absent, and the OID is (TBD -- for now, 1.3.6.1.4.1.44469.666.509.88.1.1.2) concatenated with the OID of a secure hash algorithm from IANA's Hash Function Textual Names registry. For example, the SHA-1 hash with OID 1.3.14.3.2.26 would combine to form (TBD -- now it is 1.3.6.1.4.1.44469.666.509.88.1.1.2.1.3.14.3.2.26).
KDH-enhanced message flows can use existing ECDHE CipherSuites using server certificates that may be signed with RSA or other common algorithms. In addition, this specification introduces a number of KDH-only CipherSuites with names that start with TLS_ECDHE_KDH_. These new CipherSuites rely on Kerberos' mutual authentication plus ECDHE but not on a server Certificate. They may be used starting from TLS 1.2. They default to a higher verify_data_length than the default 12.
The following Kerberos-only CipherSuites are entered into the IANA TLS Cipher Suite Registry; the list below provides their names and their desired verify_data_lengths between brackets:
Neither server nor client should accept lower values for verify_data_length than given here. TODO: the list follows http://www.keylength.com/en/4/ and the hash algorithm sizes -- is this agreed?
The premaster secret for KDH-only CipherSuites is composed from an ECDHE shared secret and a client-sent, connection-specific Kerberos key. Use S to refer to the DER representation of the EncryptionKey [Section 5.2.9 of [RFC4120]] in the key contained in the Ticket in the client's Certificate. Use E to refer to the DER representation of the EncryptionKey in the subkey field of the Authentication in the ClientVerify message, which MUST be present. Perform the ECDH computation in the common manner [RFC4492] and let Z be the value produced by this computation (with leading zero bytes kept as they are). The premaster secret is the concatenation of an uint16 containing the length of Z (in octets), Z itself, an uint16 containing the lenght of S (in octets), S itself, the length of E (in octets) and E itself. TODO: DER already has lengths, why prefix with uint16t (adds no entropy, but adds info relations)
The master secret is derived from the premaster secret using the extended master secret computation [Section 4 of [RFC7627].
Some clients may be able to offer more facilities in Tickets than others, and some servers need more than others. To communicate this, a TLS Extension known as TicketRequestFlags is hereby defined. This extension is optional for TLS in general, but it is required for TLS-KDH. The client uses the Extension to specify the flags that it understands and may be able to fulfil. The server uses the Extension to indicate the flags that it requires to be fulfilled.
The Extension's 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:
requests that the client presents an identity that it will use on recurring visits. Client software is advised to confer with their users on this, and so this request should only be used for subscription services that would be agreeable to their users. Without this flag, the client is free to use a short-lived identity that is unlikely to survive to its across its next Authentication Service request.
The flags are chosen such that their default values may be set to 0 as a safe default; safe in the sense that they do not lead to privacy problems, do not impair the peer and do not offer something that could block progress of TLS at a later point. Servers MUST NOT respond with TicketRequestFlags set that the client left cleared. Senders MUST NOT include flags that they don't know and recipients MUST NOT accept flags they cannot interpret.
Flag values are registered by IANA in a newly created "TLS-KDH Ticket Request Flag Registry", whose initial values are as defined above. Future specifications of flag values may state that a flag is an alternative to another flag, including to the ones specified above. When flag A is an alternative to flag B then the fulfillment of the requirements for A suffices to ignore flag B. It is possible for flags to cyclically refer to each other as alternatives; since being-an-alternative is not defined as a transitive property, this need not distract from this definition. This is explicitly permitted to enhance expressiveness of this principle.
The wire format representing TicketRequestFlags is a sequence of bytes, where the byte at index i (starting from 0) represents the flags numbered 8*i (in its least-significat bit) through 8*i+7 (in its most-significant bit). The last byte MUST NOT be 0, meaning that it is possible for the TicketRequestFlags to be a sequence of no bytes if all flags are cleared.
TLS-KDH connections expire when their authenticating Kerberos tickets expire. This is not a reason for termination of the TLS connection, but instead it is a trigger for refreshing the ticket. Such a refresh should be executed by the TLS-KDH client, where it may trigger user interaction. Note that Kerberos' facility of ticket renewal [Section 2.3 of [RFC4120]] may provide some relief from such user interaction.
When the TLS-KDH connection expires, neither side will send any further data records, and both sides will, upon receiving any data records, trigger a TLS Alert. The other records are still accepted, to permit a TLS handshake for re-issuance of session keys. Implementations MAY choose to initiate and permit re-authentication some time before the actual expiration. This can remedy clock skew between the TLS-KDH client and server, which might otherwise lead to undesired connection reset.
To be able to use Kerberos, application protocols that run over TLS must exchange some configuration information with the TLS stack. This includes communication about Kerberos properties such as service name and realm, requested/accepted TicketRequestFlags, and a key for use with the local identity.
When a SASL EXTERNAL mechanism is used to communicate an identity between the application and the TLS stack, then a good alignment with X.509 certificates is possible when both aim to derive or match a Network Access Identifier [RFC7542] and/or a 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 reproduced [Section 4.1 of [RFC4343]]; this may be handled 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]].
TLS and Kerberos have long been independent infrastructures for secure connectivity; with the introduction of the KDH-only CipherSuites in this specification, the worlds can merge elegantly. The newly introduced CipherSuites are expected to integrate relatively straightforwardly with any TLS stack.
Just like the TLS-KDH CipherSuites are optimal to implement in TLS stacks, TLS-KDH should not force all Kerberos applications to process 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:
The Kerberos-only CipherSuites can be used with any TLS application profile; that includes, but is not limited to, the one specified above and the default application profile.
This specification introduces the name TLS-KDH to certain message flows within the TLS framework. There are two distinct variations, called KDH-only and KDH-enhanced. This section defines constraints to the message flow for it to be a TLS-KDH message flow. This, together with the flags in the conceptual data model [Section 4.1], guides the use of the extensions defined in this specification.
TLS endpoints that find that the other side of the TLS connection only implements some of the TLS-KDH constraints MUST NOT continue the connection with the TLS-KDH extensions of this specification (unless future specifications assign a meaningful procedure for such situations). If the remote endpoint does not implement all requirements for TLS-KDH but also enforces it, for instance by sending required information that can only be interpreted under this specification, then it MUST send a suitable TLS Alert and close the connection.
To support TLS-KDH, a client's ClientHello message MUST include the TicketRequestFlags extension, and it MUST mention the kerberos SignatureAlgorithm in at least one of the supported_signature_algorithms.
In addition, the ClientHello MAY include one or more KDH-only CipherSuites in the list of cipher_suites, but if that is done the protocol used MUST be TLS 1.2 or later, indicated on the record layer with ProtocolVersion 3,3 or later. Without at least one of the KDH-only CipherSuites, the connection cannot be KDH-only, but it may still proceed as KDH-enhanced.
The client MUST NOT send TicketRequestFlags that it does not understand and it MUST NOT offer all the TicketFlags that are defined for Kerberos, but instead SHOULD limit itself to what would be acceptable from a security perspective.
To support TLS-KDH, a ServerHello message MUST include the TicketRequestFlags extension, and it MUST mention the kerberos SignatureAlgorithm in at least one of the supported_signature_algorithms. To continue the message flow as TLS-KDH, the server MUST select a cipher_suite with ephemeral ECDH key exchange; aside from generally available CipherSuites, the server MAY select a KDH-only cipher_suite. When it does not select a KDH-only CipherSuite, the connection cannot be a KDH-only connection, but it may still proceed as KDH-enhanced.
The server MUST ignore TicketRequestFlags from the client that it does not understand; it MUST NOT send TicketRequestFlags that it does not understand and it MUST NOT set TicketRequestFlags that were not set in the ClientHello.
Note that none of the Anonymous CipherSuites can be made to work with TLS-KDH, because then it is not permitted [Section 2.5 of [RFC4492]] to send a CertificateRequest, client Certificate or CertificateVerify message. Although the KDH-only CipherSuites do not use a server Certificate this does not constitute Anonymous server authentication, because Kerberos provides mutual authentication.
When a KDH-only CipherSuite was selected in the ServerHello, then the server MUST NOT send a Certificate message. For KDH-enhanced CipherSuites, the server Certificate message MUST be sent, following the definitions of the server-selected cipher_suite.
All TLS-KDH connections MUST use ephemeral ECDH. Under KDH-enhanced CipherSuites, this implies the case ec_diffie_hellman [Section 5.4 of [RFC4492]]. Under KDH-only CipherSuites, the same case is used, but without signatures, formatted in the same way as for ECDH_anon CipherSuites.
Under TLS-KDH, a CertificateRequest MUST be sent by the server, and it MUST include at least one SignatureAndHashAlgorithm based on the kerberos SignatureAlgorithm, and it MUST list the kerberos_sign CertificateType. For KDH-only CipherSuites, no other CertificateTypes and SignatureAndHashAlgorithms are permitted. The list of certificate_authorities is not used by TLS-KDH and MUST be empty for KDH-only CipherSuites.
When sending a CertificateRequest under TLS-KDH, the TLS server MUST be prepared to accept the X.509 certificate form for Kerberos [Section 3.3] using any of the corresponding signature algorithm OIDs [Section 4.3].
A client MAY choose any of the certificate and signature types to fulfil the CertificateRequest. In order to continue the TLS-KDH message flow, it MUST select the kerberos_sign CertificateType and a SignatureAndHashAlgorithm with the kerberos SignatureAlgorithm. Under TLS-KDH the client MUST supply a Certificate based on these algorithms.
When continuing with the TLS-KDH flow, the client SHOULD take the TicketRequestFlags into consideration; it is not required however to implement all, because some flags may be forbidden by policy that was concealed from the ClientHello-supplied TicketRequestFlags, or that turn out to be unavailable while requesting the Ticket. In such cases, the client MAY simply continue without fulfilling the request flags, or it MAY choose to divert from a KDH-enhanced message flow by authenticating with another kind of Certificate, or not to present one at all.
When the server has not set the UniqueClientIdentity flag, then the RECOMMENDED client Certificate under TLS-KDH would be based on an anonymous Ticket [RFC6112]; however, when the server has set the UniqueClientIdentity flag, then an anonymous Ticket that uses the anonymous realm MUST NOT be sent. A Ticket that is not anonymous may still be pseudonymous, including names based on NT-UID principal names [Section 6.2 of [RFC4120]] when the server has sent the UniqueClientIdentity flag; the LastingClientIdentity flag indicates the server's perspecitve on longevity of any such pseudonyms, but the client MAY choose to ignore that wish.
Under the present specification, the kerberos_sign CertificateType and the kerberos SignatureAlgorithm SHOULD NOT be used independently, but always in combination [Section 3.3]. If any of the messages preceding the client's Certificate deviated from the specifications for TLS-KDH, then these choices MUST NOT be made. Only when these two choices are made do we continue to speak of a TLS-KDH message flow.
The impact of using an anonymous ticket is that the server cannot establish the identity of the client, except perhaps that the same service ticket may be used repeatedly during its short period of validity. This means that the ability to trace the client is limited for both server and client. Under customary X.509 authentication, the interpretation of not sending the CertificateRequest is that the server should not care for the client identity; anonymous tickets provide a mechanism for achieving a similar pattern under TLS-KDH, although it has some benefits of short-term session protection.
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 ECDH key exchange is known to be protected from a man-in-the-middle attack.
Briefly put, we can speak of mutual authentication in this specification, even when the client uses an anonymous ticket. The only thing that is missing under an anonymous ticket is the visibility of the client's validated identity.
Every TLS-KDH message flow MUST use ECDH, and since the keys MUST be ephemeral, the explicit form of the ClientECDiffieHellmanPublic for the case ec_diffie_hellman [Section 5.7 of [RFC4492]] MUST be used.
If CertificateVerify was preceded by a client Certificate with the kerberos SignatureAlgorithm, then the CertificateVerify MUST follow up accordingly. This means that the CertificateVerify message MUST follow the descriptions of a Kerberos Authenticator Section 3.2 for use with TLS.
In KDH-only message flows, the Authenticator MUST introduce a new client-generated key in the subkey field, to be used in the formation of the premaster secret. The subkey field SHOULD NOT be included in KDH-enhanced message flows.
For KDH-enhanced flows, the server can be authenticated through its Certificate, so that the usual Finished messages suffice, and TLS versions preceding 1.2 may still suffice.
For KDH-only flows, the Finished message is the first place where the server identity can be validated, prior to reporting successful authentication to the application running atop TLS. As a result, the KDH-only CipherSuites have been defined with an elongated Finished message, for improved security. This is possible since TLS 1.2. The desired minimum length is defined with the introduction of the KDH-only CipherSuite.
An older specification [RFC2712] introduces Kerberos into TLS. That specification is hereby deprecated because this new specification improves on it work in a number of ways:
The efficiency of the mechanism described here compares favourably with the more common approach of authentication through X.509 certificates based on public-key algorithms.
The Kerberos architecture is founded on symmetric cryptography, which makes it more efficient than the asymmetric architectures around X.509 public-key certificates. Furthermore, Kerberos' identity statements are short-lived, which is generally accepted to evade the need for withdrawal mechanisms based on chains of trust, CRLs [RFC3280], OCSP [RFC6960], DANE [RFC6698] and perhaps other mechanisms. As a result, the validity of a Kerberos ticket can be checked with relatively modest computational effort.
The inclusion of ephemeral ECDH is a relatively expensive asymmetric operation, but the same introduction is needed when Forward Secrecy is introduced alongside public-key authentication.
The one thing that is costly about Kerberos is its reliance on a replay cache. Such caches store recent authentication attempts to avoid that they are being replayed; an accurate clock helps to release entries, but some care for clock skew between TLS-KDH client and server must be resolved with these caches. Their volatile nature makes them a particularly difficult problem in highly active and/or replicated and/or distributed Kerberos services.
A replay cache is not required for any of the TLS-KDH protocol flows, because this specification requires an ephemeral ECDH key exchange. This is of particular use to redundant (and possibly distributed) server farms, where sharing the time-critical information of the replay cache is a performance bottle neck. Since this is a new specification, there is no need to implement backward compatibility with older mechanisms for which a replay cache might be needed.
The information that is publicly shown in the TLS-KDH protocol flows consists of:
A Kerberos ticket transmits less information in plaintext than a public-key X.509 client certificate; furthermore, DNS may have to reveal the realm name(s) of server-trusted KDC(s) but neither the TLS-KDH server nor any KDC publishes long-lasting key material for TLS or Kerberos, so parties looking for a cracking challenge are constrained to a brief period of attack on keys.
The TicketRequestFlags may provide information about Tickets present in the client, but that would take the risk of leaking information prior to authentication of the server, and in plaintext.
For KDH-enhanced message flows, the server can be authenticated through its public-key X.509 Certificate. For KDH-onnly message flows this is not possible, which is why a longer verify_data_size in the Finished messages is required; the ability to generate these messages properly proves that the other side has succeeded in decrypting the Kerberos-encrypted materials, and so, that it is the intended remote party.
In Kerberos, all key material is supplied by the KDC. This is a central point in each realm that is usually guarded well enough, but it is nonetheless a critical point in any infrastructure founded on Kerberos. When client and server are in different realms, but have cross-signed directly or through a chain of KDC’s, then all intermediate KDC’s are potential places where the session key could be detected. The weakest KDC in the chain then defines the security of the entire chain.
Kerberos requires accurate clocks in order to operate securely; without them, once-used and since-forgotten credentials could be replayed by an attacker that has been able to recover an old service ticket’s session key. This problem is worsened in cross-realm scenario’s where clock synchronisation is hard to realise. This is however resolved in all TLS-KDH flows by using ephemeral Elliptic-Curve Diffie-Hellman keys, thus forcing new master secrets on each connection and removing the need for a replay buffer. Note however, that ticket validity times must still be checked.
Basic Kerberos security hinges on the secrecy of the user's password; if this password is guessed, then all captured traffic can be decoded, even in retrospect. This means that it is highly advisable to combine Kerberos with Diffie-Hellman for Forward Secrecy. TLS-KDH implies this desirable property in all its CipherSuites.
TODO - for Kerberos:
TODO - for TLS: