What is this project about?

An incredible number of network protocols support Kerberos as an authentication mechanism, sometimes in a protocol-specific manner and sometimes as part of the more generic SASL framework, using its GSSAPI mechanism. Kerberos is liked for its integration with centrally managed infrastructure, and its ability to cross-over to remote security realms.

Unfortunately, the privacy of Kerberos does not involve Perfect Forward Secrecy, and as a result the result of all its interactions may be tapped when the initial password used by an end user is cracked. In fact, this may be used to undo the encryption of prior traffic that may have been captured and stored in encrypted form.

The KDH mechanism adds Perfect Forward Secrecy to Kerberos, by incorporating Diffie-Hellman key exchange. This is done for two important protocols, namely Kerberos5 as it may be used directly or through the GSS-API or SASL interfaces; and it builds the KDH mechanism into the TLS. The former is called KRB5-KDH and the latter is named TLS-KDH. A byproduct named TLS-DH presents a method for anonymous encryption of a connection before revealing identities of clients and servers.

TLS however, is a very popular Internet protocol for secure connections across a potentially unreliable network, and it arranges a few important properties:

• To establish a server's identity and, where needed, a client's identity
• To encrypt the connection so only the TLS endpoints can review it
• To avoid abuse of access privileges now as well as in the future

TLS-KDH is a project that supports Kerberos tickets as an authentication mechanism for the TLS protocol, with Diffie-Hellman support for encryption with Perfect Forward Secrecy. The pairing is important; they are like opposite sides of a coin, which could not exist without each side being constructed properly. The two parts do what they do best, without overlap or conflict in functionality.

Why are KRB5-KDH and TLS-KDH useful?

Many organisations implement Kerberos as their major authentication mechanism; based on Kerberos5-proven identities, authorisation decisions can be taken and so, access to resources can be granted or rejected. Not everyone realises they are using Kerberos5; it may come in a disguise and be called Active Directory, Samba4 or FreeIPA, all products that use the Kerberos system as their in-house mechanism to supply authenticated identities to users.

Users appreciate Kerberos because it is a single sign-on system; they often need only logon to the network once a day, and be granted access to all the resources for which they have been authorised by local administrators.

Kerberos integration with Internet protocols is sometimes arranged through the SASL mechanism GSSAPI, but its integration with HTTP is both important to have and a very poor technical choice! Just imagine:

1. Submit a form; receive a "please authenticate with Kerberos" back;
2. Submit the form with your ticket; receive a "looks good, please respond to challenge";
3. Submit the form with a response; this time, the submission is accepted.

This means three submissions of the same data, which may include the upload of large files. But that is not even the worst problem; the security of GSSAPI over HTTP is especially weak:

• There is no linkage between authentication and the context it runs in;
• As a result, credentials are easily taken out and (ab)used elsewhere;
• The last step (challenge/response) is often skipped, simplifying such abuse;
• The ticket submitted in the 2nd step is a plain Kerberos ticket, which travels to you in plaintext;

In short, there is no realistic solution for large-scale, generic applications of Kerberos for authentication, and specifically for the web there is only a highly dissatisfactory technique. Furthermore, proper integration between encryption and authentication is usually absent, or requires a secondary technique. The introduction of TLS-KDH is meant to resolve all that.

Of course, similar results can be achieved with X.509 certifications, or even OpenPGP keys, for client/server authentication and encryption in TLS. These solutions are available now, but these have their own problems:

• The keys and certificates for OpenPGP and X.509 are long-lived, introducing a need for additional verification;
• Additional verification is complex, and prone to errors and easy-ways-out that hamper the security levels reached;
• Additional verification takes long because it involves network lookups and multiple chains of public-key signature checks.

Kerberos simplifies all this by using short-lived tickets for potentially long-lasting identities, instead of long-lived identities for potentially short-lived certainties.

The mechanism of TLS-KDH is also of use to general Kerberos5 applications, especially when crossing over to other realms; in light of this, there is an accompanying specification KRB5-KDH.

How is TLS-KDH realised?

Doing "just" Kerberos over TLS is known work but it fails to implement the desirable property of Perfect Forward Secrecy. Specifically, once a user's credential would be guessed, all his past TLS interactions would be at risk of decrypting. This may mean that the security of the system hinges on end-user password policies, and that is far from ideal.

The vital trick of TLS-KDH is to combine both the Kerberos5 and Diffie-Hellman mechanisms and make them one whole; specifically, Kerberos authentication mitigates the man-in-the-middle risk that would otherwise endanger Diffie-Hellman; and Diffie-Hellman can be used to encrypt the Kerberos ticket from being overseen and perhaps be used to authenticate over another, weaker access channel. The conceptual protocol gives a proper introduction into how this is done, and the pages on KRB5-KDH and TLS-KDH work it out to concrete protocol definitions.

Who is working on TLS-KDH?

TLS-KDH is a project run by OpenFortress and NLnet as part of the InternetWide project. Its practical project is hosted as an ARPA2.net project.