logo_kerberos.gif

Difference between revisions of "Project/TLS-KDH"

From K5Wiki
Jump to: navigation, search
(New page: ''This project introduces Kerberos tickets with Forward Secrecy as TLS CipherSuites.'' {{project-early}} External project links: * [http://tls-kdh.arpa2.net/tls-kdh.html Project working ...)
 
Line 6: Line 6:
 
* [http://tls-kdh.arpa2.net/tls-kdh.html Project working pages]
  
* [http://tls-kdh.arpa2.net/tls-kdh.html Project working pages]
 
* [http://tls-kdh.arpa2.net/spec/tls-kdh-ID.html Specification]
  
* [http://tls-kdh.arpa2.net/spec/tls-kdh-ID.html Specification]
  +
* [http://lists.arpa2.org/mailman/listinfo/tls-kdh Discussion list]
   
 
We use '''TLS-KDH''' as a name for the protocol proposed on this page.
  
We use '''TLS-KDH''' as a name for the protocol proposed on this page.

Revision as of 06:39, 3 September 2015

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:

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
Retrieved from "https://k5wiki.kerberos.org/wiki?title=Project/TLS-KDH&oldid=5531"