This site reflects work in progress.

Read the TLS-KDH specification (a precursor to an Internet Draft) and the related DNSTXT-KRB1 specification.

As discussed on the introduction page, Kerberos5 is an attractive authentication solution with somewhat weak encryption properties, whereas Diffie-Hellman is an attractive encryption solution without authentication properties. When the two can be cryptographically bound together, their powers enhance each other, and we can have the best of both worlds.

Although it might be possible to use orthogonal components in TLS for Anonymous Diffie-Hellman and Kerberos5, this does not lead to the desired cryptographic binding without modifications to the workings of a TLS stack, which is highly undesirable. Alternatively, generic support for protocols such as GSS-API or SASL could be sought, but would make the cryptographic binding incredibly difficult, or subject to parameters and uncertainties. This is the reason to devise a dedicated TLS variation for Kerberos5 with built-in Diffie-Hellman key exchange. More on this under related work.

The conceptual protocol describes a method of achieving this cryptographic binding. This has elsewhere been defined for Kerberos5 in general. The trick when mapping the concept to TLS' limited number of exchanges is to wrap at least one freshly generated Diffie-Hellman key exchange message with Kerberos5; the sending side authenticates by demonstrating knowledge of the session key during encryption, and the receiving side authenticates by demonstration knowledge of the session key during decryption.

Passing the Diffie-Hellman key exchange can be done through a subkey in the authenticator attached to the ticket passed; this subkey is meant to pass a replacement for the session key that is shared by the KDC. We only need to define a format for sharing Diffie-Hellman key exchange and leave an option open for the other half to travel out-of-band, in this case even before the ticket is passed.

The exchange between a TLS client and server is not a strict AP_REQ / AP_REP combination, because TLS cannot construct the latter; the information contained in it will instead be passed in an earlier phase under the assumption of future success, and error reporting is left to TLS messaging.

The shared secret determined with the Diffie-Hellman key exchange is not passed on to the Kerberos5 infrastructure, but instead remains in the realm of TLS, where it is processed in the same manner as for other TLS_DHE_ or TLS_ECDHE_ cipher suites.

The TLS implementation incorporates an extension that simplifies resolution of Kerberos tickets, especially when crossing realms. This extension contains one or more realms that are acceptable, in preferred order. The TLS client might present this option if it has been explicitly setup to do this, and probably only for the given site; the TLS server interprets this as a list of realms that it can check against the server name pursued (in a Server Name Indication). The TLS server is likely to present this option to indicate the realms with which it has been configured, to help the client obtain a suitable realm-crossing principal name for the service when combining it with the service name and hostname for the service, which are assumed to be known to the TLS client.

Finally, support has been specified for the conceptual protocol, especially the ability of using Diffie-Hellman key exchange messages in AP_REQ and AP_REP messages, as well as authenticated denial facilities for its support in a general service principle.