| Network Working Group | R. Van Rein |
| Internet-Draft | ARPA2.net |
| Intended status: Standards Track | June 13, 2016 |
| Expires: December 15, 2016 |
TLS-KDH: Kerberos + Diffie-Hellman in TLS
draft-vanrein-tls-kdh-04
This specification defines a TLS message flow with Kerberos-based (mutual) authentication, binding in Elliptic-Curve Diffie-Hellman to achieve Forward Secrecy for the session.
TODO: Deprecates RFC2712
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 15, 2016.
Copyright (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 introducing a new certificate type for use with TLS. The server can choose to provide a Certificate with a traditional signing mechanism such as RSA for authentication, in which case this specification speaks of a KDH-enhanced exchange; even when presenting no server certificate at all, a client-side Kerberos ticket can be used for mutual authentication in what will then be called a KDH-only exchange. The KDH-enhanced variety uses existing CipherSuite, and KDH-only defines new CipherSuites. Both KDH-enhanced and KDH-only message flows will be referred to as TLS-KDH.
A variation of the KDH-only flow does incorporate a server-side ticket; this can be used for user-to-user authentication, perhaps to be used in peer-to-peer protocols that use TLS-KDH as their security foundation.
Both TLS-KDH variations form a cryptographic binding between Kerberos and Elliptic-Curve Diffie-Hellman (ECDH), leading to the combined advantages of infrastructure-supported mutual authentication and Forward Secrecy.
The normal flow of TLS-KDH messages is basically a standard interaction with a modified form of client Certificate and CertificateVerify:
Client Server
ClientHello -------->
ServerHello
Server Certificate*
ServerKeyExchange
CertificateRequest
<-------- ServerHelloDone
Client Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* Indicates that Server Certificate may be empty; it is present in KDH-enhanced message flows, and usually empty in KDH-only message flows.
[] Indicates that ChangeCipherSpec is an independent TLS protocol content type; it is not actually a TLS handshake message.
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 analogue to a signature, in the form of an Authenticator [Section 5.5.1 of [RFC4120]]. When used in TLS-KDH, the Authenticator MUST have a secure hash embedded in the cksum field. The checksum type used in the context of TLS MUST be taken to match one of the entries in IANA's TLS HashAlgorithm Registry.
The Authenticator is not sent in the plain, but encrypted with a Kerberos session key as EncryptedData [Section 5.2.9 of [RFC4120]] and this is how Kerberos derives authenticity: only the client and the service can pack and unpack the EncryptedData and process the Authenticator.
A standard part of an Authenticator is a timestamp with microsecond accuracy. This is validated within a small window around the independently sycnchronised time of the TLS client and server. It is customary to allow a time window of about 5 minutes around the server time.
To avoid replay attacks, Kerberos solutions sometimes need to remember received Authenticators, or their time stamps, until the time window has passed. This complicates servers, especially for redundant deployments. As used in TLS-KDH, with entropy from both end in the hello exchange and with session-specific keys agreed through ephemeral ECDH, there is no need for such infrastructure to avoid replay attacks. Notwithstanding that it is not as strong a requirement as under other Kerberos applications, the cusec and ctime fields are present in the Authenticator and MUST be filled with the current time by the TLS-KDH client, and SHOULD be verified to fall within a reasonable time frame on the TLS-KDH server.
In KDH-Enhanced mode an Authenticator MUST NOT contain a subkey field. In KDH-only mode, such a field MUST be supplied as input to the premaster secret computation.
Other fields in the Authenticator than specified above SHOULD NOT be produced and MUST be ignored by the recipient.
The representation on the wire matches the DigitallySigned structure [Section 4.7 of [RFC5246]] with the signature algorithm set to kerberos, the hash set as desired for the TLS flow. The opaque contents of the signature are filled with the literal bytes of the Authenticator, which MUST NOT be an empty string.
This specification defines a new certificate type [RFC7250] named KerberosTicket, to be negotiated for the client and, though only in special circumstances, for the server.
The Kerberos Ticket is included in certificate messages following this syntax:
struct {
select(certificate_type){
// certificate type defined in this document.
case KerberosTicket: opaque Ticket<0..2^24-1>;
// Additional certificate type based on
// "TLS Certificate Types" subregistry
};
} Certificate;
In this syntax, Ticket holds the DER-encoded form of a Kerberos Ticket [Section 5.3 of [RFC4120]]. The special case where the Ticket field has length 0 marks an invalid ticket representation, and is treated by TLS-KDH as a refusal to send the requested ticket.
The TLS server may depend on additional Kerberos-protected services, generally referred to as "backend services". As an example, a webmail service may need to access IMAP and SMTP backend services, possibly under independent administrative control. This section describes an OPTIONAL Kerberos mechanism in support of such backend services. It is designed to even work when the client and server reside in independently administered realms.
In addition to the main Ticket supplied in the client Certificate's public key field, the TLS server MAY be sent additional Tickets for access to backend services, and in some cases these additional Tickets can define where these backend services are located and under what client identity they are accessed. The client needs to provide these additional Tickets in an AuthorizationData element whose ad-type is AD-BACKEND-TICKETS (TBD) and whose ad-data holds a KRB-CRED message [Section 5.8 of [RFC4120]] with an enc-part that uses NULL encryption [Section 6.3.1 of [RFC1510]].
AuthorizationData elements with additional Tickets MAY be part of the service Ticket and/or Authenticator; supporting TLS servers MUST collect them from both these locations, such that they prefer the former in cases of service name clashes. Just like a KDC could store additional Tickets in the main Ticket, an explicitly configured client could store them in the Authenticator. To remain secure, clients MUST NOT be open to servers requesting arbitrary additional Tickets in any way.
Additional Tickets MUST NOT be renewable, but the main Ticket MAY be; when the main Ticket is renewed it SHOULD be resent with the backend extension as they are setup at that time. Additional Tickets SHOULD have neither the FORWARDABLE nor the PROXIABLE flag set.
Additional Tickets should normally be supplied every time the main Ticket is supplied for TLS-KDH. As a result, both the main and additional Tickets MAY be forgotten by the server whenever a TLS-KDH session ends. However, when needed for longer-lasting or deferred backend processing, the server MAY hold the Tickets longer.
It is possible for backend services to rely on backend services themselves; this can be facilitated by a an AD-BACKEND-TICKETS element contained in the additional Ticket for the respective backend Ticket or, in more complex situations requiring more coordinated configuration, in an Authenticator whose additional Tickets get passed on selectively in Authenticators or other protocol elements sent to the backend service.
The inclusion of additional Tickets in an Authenticator is not further described in this specification. The inclusion of additional Tickets in a main Ticket usually involves requesting the TLS-KDH service Ticket directly from the client's KDC. TODO: To facilitate this, the server desiring additional Tickets SHOULD set the LocalRealmService flag Section 3.5; without this flag, the client MAY choose not to supply additional Tickets. The use of this flag may imply that the server needs to be flexible in the identity that the client uses for its service.
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 also adds a new entry named KerberosTicket in IANA's TLS Certificate Types" subregistry of the "Transport Layer Security (TLS) Extensions" registry.
This specification introduces a mechanism for signatures under Kerberos Section 2.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 form a SignatureAndHashAlgorithm. The digitally-signed structure [Section 4.7 of [RFC5246]] uses this structure, followed by a variable-sized opaque byte sequence, which should hold the EncryptedData holding an Authenticator Section 2.2.
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 A to refer to the DER representation of the Authenticator in the ClientVerify message. Perform the ECDH computation in the normal manner [RFC4492] and let Z be the value produced by this computation (with leading zero bytes kept as they are). The premaster secret is the concatenation of an uint16 containing the length of Z (in octets), Z itself, an uint16 containing the length of A (in octets) and A itself.
The master secret is derived from the premaster secret using the extended master secret computation [Section 4 of [RFC7627].
Some clients may be able to offer more facilities in Tickets than others, and some servers need more than others. To communicate this, a TLS Extension known as TicketRequestFlags is hereby defined. This extension is optional; when absent, all flags are considered to be cleared. The client uses the Extension to specify the flags that it understands and may be able to fulfil. The server uses the Extension to indicate the flags that it would like to be fulfilled.
The Extension's structure is an extensible list of flag values that indicate constraints on the ticket that the client should try to supply. These should be seen as hints how the client should present its identity, as the server can always decide to reject a client on grounds that are or are not expressible in this form.
Flag values defined in this specification are:
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, offered/requested TicketRequestFlags, and a key for use with the local identity.
When a SASL EXTERNAL mechanism is used to communicate an identity between the application and the TLS stack, then a good alignment with X.509 certificates is possible when both aim to derive or match a Network Access Identifier [RFC7542] and/or a DNS name. In the case of a Kerberos principal name, this would involve translation between case-sensitive realm names to DNS names whose case is not reliably reproduced [Section 4.1 of [RFC4343]]; this may be handled by ignoring or lowering the case of the realm name while being aware of the requirement that no two realm names may differ only in their case [Section 7.2.3.1 of [RFC4120]].
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 3.1], guides the use of the extensions defined in this specification.
TLS endpoints that find that the other side of the TLS connection only implements some of the TLS-KDH constraints MUST NOT continue the connection with the TLS-KDH extensions of this specification (unless future specifications assign a meaningful procedure for such situations). If the remote endpoint does not implement all requirements for TLS-KDH but also enforces it, for instance by sending required information that can only be interpreted under this specification, then it MUST send a suitable TLS Alert and close the connection.
To support TLS-KDH, a client's ClientHello MUST mention the kerberos SignatureAlgorithm in at least one of the supported_signature_algorithms, and it also MUST include KerberosTicket in a client_certificate_type extension [RFC7250]. The client MAY include the TicketRequestFlags extension if it is interested on providing more than a generally available ticket to the service.
Furthermore, the client MAY offer to process KerberosTicket in a server_certificate_type extension [RFC7250], and the client MAY include the TicketRequestFlags extension.
In addition, the ClientHello MAY include one or more KDH-only CipherSuites in the list of cipher_suites, but if that is done the protocol used MUST be TLS 1.2 or later, indicated on the record layer with ProtocolVersion 3,3 or later. Without at least one of the KDH-only CipherSuites, the connection cannot be KDH-only, but it may still proceed as KDH-enhanced. With at least one of the KDH-only CipherSuites, the client MAY offer to process KerberosTicket in a server_certificate_type extension [RFC7250] through the ENC-TKT-IN-SKEY [Section 2.9.2 of [RFC4120]] Kerberos extension.
The client MUST NOT send TicketRequestFlags that it does not understand and it MUST NOT offer all the TicketFlags that are defined for Kerberos, but instead SHOULD limit itself to what would be acceptable from a security perspective.
To support TLS-KDH, a ServerHello message MUST mention the kerberos SignatureAlgorithm in at least one of the supported_signature_algorithms, and it MUST include the KerberosTicket value in the client_certificate_type extension [RFC7250]. Furthermore, the server MUST select a cipher_suite with ephemeral ECDH key exchange; aside from generally available CipherSuites, the server MAY select a KDH-only cipher_suite. When it does not select a KDH-only CipherSuite, the connection cannot be a KDH-only connection, but it may still proceed as KDH-enhanced.
When the server selects a KDH-enhanced CipherSuite, it MUST choose another means of authenticating its identity than through Kerberos, following the customary flow of TLS and only using Kerberos for client authentication.
When the server selects a KDH-only CipherSuite and when the ClientHello message includes the KerberosTicket in a server_certificate_type extension [RFC7250], then the server MAY choose to send back a server_certificate_type extension selecting KerberosTicket, in which case it MUST send the corresponding Server Certificate later in the process. This may be used to facilitate user-to-user negotiation of TLS.
The server MAY include the TicketRequestFlags extension in the ServerHello message if the client included it in the ClientHello message. The server MUST ignore TicketRequestFlags from the client that it does not understand; it MUST NOT send TicketRequestFlags that it does not understand and it MUST NOT set TicketRequestFlags that were not set in the ClientHello.
Note that none of the Anonymous CipherSuites can be made to work with TLS-KDH, because then it is not permitted [Section 2.5 of [RFC4492]] to send a CertificateRequest, client Certificate or CertificateVerify message. Although the KDH-only CipherSuites do not use a server Certificate this does not constitute Anonymous server authentication, because Kerberos provides mutual authentication.
For KDH-enhanced CipherSuites, the server Certificate message MUST be sent, following the definitions of the server-selected cipher_suite.
Under KDH-only, when the server has not selected the KerberosTicket as the server_certificate_type, then it MUST send an Certificate message with a certificate_list of 0 bytes length.
Under KDH-only, when the server did select the KerberosTicket as the server_certificate_type, then it MUST include the corresponding ticket in the Server Certificate.
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. Any SignatureAndHashAlogorithm with the SignatureAlgorithm set to kerberos MUST use a HashAlgorithm for which IANA's Kerberos Parameters registry holds a compatible Kerberos Checksum Type. The CertificateRequest MUST also list the kerberos_sign CertificateType. Having selected the KerberosTicket value for the client_certificate_type, other CertificateTypes and SignatureAndHashAlgorithms SHOULD NOT be sent. The list of certificate_authorities is not used by TLS-KDH and MUST be empty.
TLS-KDH clients MUST fill the ClientCertificate message with a KerberosTicket. In doing so, it SHOULD take any negotiated TicketRequestFlags into consideration; it is not required however to implement all, because some flags may be forbidden by policy that was concealed from the ClientHello-supplied TicketRequestFlags, or their implementation may turn out to be unavailable while requesting the Ticket. In such cases, the client MAY simply continue without fulfilling the request flags, or it MAY choose to divert from a KDH-enhanced message flow by authenticating with another kind of Certificate, or not to present one at all.
When the server has not set the UniqueClientIdentity flag, then the RECOMMENDED client Certificate under TLS-KDH would be based on an anonymous Ticket [RFC6112]; however, when the server has set the UniqueClientIdentity flag, then an anonymous Ticket that uses the anonymous realm MUST NOT be sent. A Ticket that is not anonymous may still be pseudonymous, including names based on NT-UID principal names [Section 6.2 of [RFC4120]] when the server has sent the UniqueClientIdentity flag; the LastingClientIdentity flag indicates the server's perspecitve on longevity of any such pseudonyms, but the client MAY choose to ignore that wish.
The impact of using an anonymous ticket is that the server cannot establish the identity of the client, except perhaps that the same service ticket may be used repeatedly during its short period of validity. This means that the ability to trace the client is limited for both server and client. Under customary X.509 authentication, the interpretation of not sending the CertificateRequest is that the server should not care for the client identity; anonymous tickets provide a mechanism for achieving a similar pattern under TLS-KDH, although it has some benefits of short-term session protection.
When the server has selected the KerberosTicket as the server_certificate_type, then the client SHOULD pass it along with its attempt to obtain a ticket for the server name, using the KDC option ENC-TKT-IN-SKEY [Section 2.9.2 of [RFC4120]] and supplying an additional ticket in the TGS request [Section 3.3.1 of [RFC4120]]; this Ticket is supplied completely by the KerberosTicket certificate-type, and although it includes a server-side realm name, this MUST NOT be trusted by the client before it has been confirmed by the client's attempts to reach the server by its host name; this is because a man-in-the-middle attack is still possible through a forged service realm. Customary processing rules for finding a server's realm MUST therefore be followed by the client.
The presence of the client's Ticket in the ClientCertificate message enables the server to ascertain that the client has procured a Ticket through the formal pathways of Kerberos, ending in the server-side realm; the reason this can be assumed is that the ticket holds an encrypted part that the server can decrypt and thereby validate with its own key, as setup in its KDC for sharing in service tickets. In other words, even an anonymous Ticket establishes that the server may trust that the client was checked along the way to the service. As a result, the ECDH key exchange is known to be protected from a man-in-the-middle attack.
Briefly put, we can speak of mutual authentication in this specification, even when the client supplies an anonymous ticket. The only thing that is missing under an anonymous ticket is the visibility of the client's validated identity.
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.
Under TLS-KDH, the CertificateVerify was preceded by a client's Ticket, and the CertificateVerify MUST follow as a proof of posession of the corresponding key material on the client. This means that the CertificateVerify message MUST follow the descriptions of a Kerberos Authenticator Section 2.2 for use with TLS.
The Authenticator MUST be set to the client's cusec and ctime values, and the server SHOULD validate these to fall within a reasonable margin around the current time.
The subkey field MUST NOT be included in KDH-enhanced message flows. In KDH-only message flows, the Authenticator MUST introduce a new client-generated key in the subkey field, and the client MUST supply at least the amount of entropy in the subkey that is expected in the symmetric key produced by TLS under the selected CipherSuite; the server SHOULD validate this subkey size to provide, assuming optimal compression, at least the amount of entropy that is desired for the CipherSuite's symmetric key.
For KDH-Only, the subkey is needed to form the pre-master secret on both ends, which in turn influences the master secret. Through the Finished messages, the KDH-Only mode of operation performs mutual validation between the client and server.
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:
Specifically for the HTTP and HTTPS protocols, the Negotiate header [RFC4559] can provide Kerberos authentication, but its use is not considered a strong security practice. Applications that currently rely on this mechanism can strengthen their security if they migrate to HTTP over TLS-KDH. Note that this provides an alternative for Kerberos, not to SPNEGO and not for general GSS-API protocols. This restriction of TLS-KDH to Kerberos, rather than a more general GSS-API protocol, is a result of the fixed number of message exchanges available within TLS.
Many other protocols incorporate Kerberos through GSS-API, usually via SASL. This is considered secure, but has an arguable disadvantage of separating encryption and authentication layers, and quite possibly also the identities involved in these layers. Furthermore, encryption through SASL is not commonly used. In situations where Kerberos is used for GSS-API over SASL, TLS-KDH offers a comparable but more efficient and tighter-coupled mechanism for encryption and mutual authentication, in a way that also lends itself to non-SASL applications. Specifically useful in this respect is that there is no longer a requirement to setup X.509 certificates plus infrastructure and validation mechanisms, just to satisfy encryption requirements with their own authentication infrastructure. In applications that use SASL, the EXTERNAL mechanism [RFC4422] can use the client identity in a Kerberos ticket, and make it available to the application layer; SASL EXTERNAL is also commonly used when TLS authenticates peers through X.509 certificates.
The use of additional Tickets for Backend Services Section 2.4 replaces the paired practices "S4U2Self" and "S4U2Proxy", which were not designed to crossover to hitherto unknown realms; they rely on the service realm to constrain the use of rights granted over the client realm. Furthermore, said practices make use of hard-coded cryptographic algorithms, which makes it impossible to assure their long-term security.
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.
IANA adds the following Kerberos Checksum Type Numbers to the Kerberos Parameters registry, to match the hash algorithms available to TLS:
| sumtype value | Checksum type | checksum size |
|---|---|---|
| TBD | sha224 (unkeyed) | 28 |
| TBD | sha256 (unkeyed) | 32 |
| TBD | sha384 (unkeyed) | 48 |
| TBD | sha512 (unkeyed) | 64 |
Through the IETF Kitten WG, the Kerberos community assigns the following value for the AuthorizationData type for backend tickets, as defined in this specification:
| Value | Name |
|---|---|
| TBD | AD-BACKEND-TICKETS |
IANA adds the following entries to the TLS Cipher Suite Registry underneath the TLS Paramters registry, to enable KDH-only negotiation and the Kerberos-Only profile that relies on it:
| Value | Description (verify_data_length) | DTLS-OK |
|---|---|---|
| TBD | TLS_ECDHE_KDH_WITH_AES_128_GCM_SHA256 (32) | Y |
| TBD | TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA384 (48) | Y |
| TBD | TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA512 (64) | Y |
| TBD | TLS_ECDHE_KDH_WITH_AES_128_CCM (32) | Y |
| TBD | TLS_ECDHE_KDH_WITH_AES_256_CCM (48) | Y |
| TBD | TLS_ECDHE_KDH_WITH_AES_128_CCM_8 (32) | Y |
| TBD | TLS_ECDHE_KDH_WITH_AES_256_CCM_8 (48) | Y |
IANA adds the following ClientCertificateType Identifier to the TLS Parameters registry, to be able to formule certificate requests under TLS-KDH as described in this document:
| Value | Description | DTLS-OK |
|---|---|---|
| TBD | kerberos_sign | Y |
IANA adds the following TLS SignatureAlgorithm to the TLS Parameters registry, to permit the Kerberos-based signatures described in this document:
| Value | Description | DTLS-OK |
|---|---|---|
| TBD | kerberos | Y |
IANA adds the following TLS Certificate Type to the TLS Extensions registry, to support negotiating it as a client_certificate_type and possibly as a server_certificate_type:
| Value | Description | DTLS-OK |
|---|---|---|
| TBD | KerberosTicket | Y |
IANA adds the following ExtensionType Value to the TLS Extensions registry, to support the negotiation of TicketRequestFlags as described in this specification:
| Value | Extension Name |
|---|---|
| TBD | TicketRequestFlags |
IANA appends a new "TLS-KDH Ticket Request Flags" sub-register to the TLS Extensions register, to support the allocation of TicketRequestFlags by other specifications. New entries to this table can be made under the named Assignment Policy [RFC5226]. The initial entries to this registry are:
| Value(s) | Name | Reference | Assignment Policy |
|---|---|---|---|
| 0..31 | TicketFlags | TBD:THISSPEC | RFC Required |
| 32 | VisibleClientRealm | TBD:THISSPEC | RFC Required |
| 33 | UniqueClientIdentity | TBD:THISSPEC | RFC Required |
| 34 | LastingClientIdentity | TBD:THISSPEC | RFC Required |
| 35..63 | Unassigned | RFC Required | |
| 64..79 | Private Use | N/A | Private Use |
| 80..95 | Experimental | N/A | Experimental Use |
| 96.. | Reserved | RFC Required |
This specification could not have matured without the insights of various commenters. In order of appearance, we owe thanks to Simo Sorce, Ilari Liusvaara, Watson Ladd, Benjamin Kaduk, Nikos Mavragiannopoulos. Special thanks go to Tom Vrancken for tracking the development of the specification, commenting on it and implementing it in GnuTLS.
This work was conducted under a grant from the programme "[veilig] door innovatie" from the government of the Netherlands. It has also been liberally supported by the NLnet Foundation.