This site reflects work in progress.

The following protocol describes the idea of mixing Kerberos with Diffie-Hellman irrespective of TLS; this demonstrates how DH improves the encryption of Kerberos to PFS between the client and server, and how Kerberos enhances the security with DH. PFS is especially interesting for Kerberos, because the entire system security hinges on passwords set by end users.

Although some of the discovery is done in parallel below, this is under the assumption that the KDH protocol will be available; in applications such as TLS-KDH this may need testing to see if it is actually possible, thus delaying the initial connection.

Take note that the lookups in DNSSEC and KDC will be cached, so future lookups are going to be much faster than the initial ones. Note that the actual exchange can be done very fast.

Note the absense of an explicit challenge/responses; this is in style with the Kerberos5 design, where the peers' ability to encrypt and decrypt the AP_REQ and AP_REP messages says it all. The DH offers are encrypted with the KDC-supplied session key, and are blindly assumed to have been generated locally by the client and server, and for this session alone. The inclusion as a subkey would otherwise be downright silly, making this a reasonable assumption under the security model for KDH.

Relaxed alternative: It suffices if only one of the DH Key Exchange messages is wrapped in a Kerberos message. Replacing just one side of the exchange is insufficient to mount a MITM attack, or to degrade the PFS property. At the Kerberos level, mutual authentication is still effective. The rule is that if a DH Key Exchange is sent in plaintext, then the DH Key Exchange in the opposite direction must be wrapped, to avoid showing both DH Key Exchanges to a potential offender.

Replay protection: This is taken care on each of the end points, by generating a fresh DH Key for each connection. There is no need to exchange challenge/response messages, nor is there a need to maintain a replay cache based on accurate timekeeping. This does rely on the design property that the actual data is being protected by the DH Shared Secret.

To add this to Kerberos5, please see the actual KRB5-KDH proposal. A relatively small number of things must be arranged:

• There must be a new encryption type for Diffie-Hellman key exchanges in subkey fields. It would be a topic of some discussion whether references to DH Key Exchanges from the context would be welcomed, but if they are they are likely to require inclusion anyway, so as to provide the assurance of Kerberos wrapping for bidirectional authentication.
• There must be a new ticket flag for the KDC exchange, signaling if DH subkey communication is supported by the server; the main purpose for this is to get authenticated denial of this facility, so it is something that can be insisted on.

To add this to TLS, please see the actual TLS-KDH proposal for a work-in-progress or look at related work in this area. TLS is a work of art, full of unexpected nooks and crannies, and integrating Kerberos5 has often been tried, but nothing has really caught major attention so far. Which is sad, because it is frightfully useful.

Possibly related, is krb5_admin by elric1, which has support for setting keys via a multi-party DH exchange, and gets cluster key update atomicity right. (TODO: Tip from Nico Williams)