Projects/TLS-KDH

This project introduces Kerberos tickets with Forward Secrecy as TLS CipherSuites.

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

External project links:

• Project working pages
• Specification
• Discussion list

We use TLS-KDH as a name for the protocol proposed on this page.

Mechanics of the Project

The TLS-KDH CipherSuite is a special way of using TLS:

1. The TLS client offers TLS-KDH CipherSuites in its ClientHello
2. The TLS server selects a TLS-KDH CipherSuite in its ServerHello
3. The TLS server sends no ServerCertificate
4. The TLS server sends a ServerKeyExchange with a suitable Diffie-Hellman public key
5. The TLS server may send a CertificateRequest to request a client identity (which the client may still refuse to supply)
6. The TLS client chooses whether it will release its identity, or remain anonymous
7. The TLS client looks for a service ticket in its local Kerberos infrastructure
8. The TLS client sends a ClientKeyExchange holding a service ticket and a Diffie-Hellman public key response, encrypted to that ticket
9. The TLS server accepts the service ticket and uses it to decrypt the Diffie-Hellman response
10. Both now construct the shared secret, following normal Diffie-Hellman procedures for TLS
11. Both now construct a proof of knowing the secret, thereby authentication to the other side
12. Both now validate the other side before proceeding

Policy Choices for this Mechanism

• The server may or may not be equiped with a service ticket; this may depend on the server name
• The client may be willing to obtain a service ticket for all, some or no remote servers
• The client may be willing to provide its identity to all, some or no remote servers
• The KDC may be willing to provide service tickets for remote realms

Changes to Kerberos

• None. Although independent work on [Realm Crossover in the KDC] is bound to be useful.

Changes to TLS

• The changes to TLS do not disturb older TLS implementations
• The TLS-KDH CipherSuites require TLS version 1.2 or later
• Both TLS clients and servers must be extended to support the TLS-KDH CipherSuites

We expect to offer early support to GnuTLS soon. The TLS Pool will also support TLS-KDH.

Comparison to Other Work

See http://tls-kdh.arpa2.net/related.html

Related Projects

See KREALM-XOVER.

Specifications

• RFC 6112 defines anonymous client tickets