https://k5wiki.kerberos.org/wiki?action=history&feed=atom&title=Projects%2FTLS-KDH 2026-04-27T03:56:30Z Revision history for this page on the wiki MediaWiki 1.27.4 https://k5wiki.kerberos.org/wiki?title=Projects/TLS-KDH&diff=5532&oldid=prev 2015-09-03T11:42:48Z

<p>New page: &#039;&#039;This project introduces Kerberos tickets with Forward Secrecy as TLS CipherSuites.&#039;&#039; {{project-early}} External project links: * [http://tls-kdh.arpa2.net/tls-kdh.html Project working ...</p> <p><b>New page</b></p><div>''This project introduces Kerberos tickets with Forward Secrecy as TLS CipherSuites.''<br /> <br /> {{project-early}}<br /> <br /> External project links:<br /> * [http://tls-kdh.arpa2.net/tls-kdh.html Project working pages]<br /> * [http://tls-kdh.arpa2.net/spec/tls-kdh-ID.html Specification]<br /> * [http://lists.arpa2.org/mailman/listinfo/tls-kdh Discussion list]<br /> <br /> We use '''TLS-KDH''' as a name for the protocol proposed on this page.<br /> <br /> ==Mechanics of the Project==<br /> <br /> The TLS-KDH CipherSuite is a special way of using TLS:<br /> <br /> # The TLS client offers TLS-KDH CipherSuites in its ClientHello<br /> # The TLS server selects a TLS-KDH CipherSuite in its ServerHello<br /> # The TLS server sends no ServerCertificate<br /> # The TLS server sends a ServerKeyExchange with a suitable Diffie-Hellman public key<br /> # The TLS server may send a CertificateRequest to request a client identity (which the client may still refuse to supply)<br /> # The TLS client chooses whether it will release its identity, or remain anonymous<br /> # The TLS client looks for a service ticket in its local Kerberos infrastructure<br /> # The TLS client sends a ClientKeyExchange holding a service ticket and a Diffie-Hellman public key response, encrypted to that ticket<br /> # The TLS server accepts the service ticket and uses it to decrypt the Diffie-Hellman response<br /> # Both now construct the shared secret, following normal Diffie-Hellman procedures for TLS<br /> # Both now construct a proof of knowing the secret, thereby authentication to the other side<br /> # Both now validate the other side before proceeding<br /> <br /> ==Policy Choices for this Mechanism==<br /> <br /> * The server may or may not be equiped with a service ticket; this may depend on the server name<br /> * The client may be willing to obtain a service ticket for all, some or no remote servers<br /> * The client may be willing to provide its identity to all, some or no remote servers<br /> * The KDC may be willing to provide service tickets for remote realms<br /> <br /> ==Changes to Kerberos==<br /> <br /> * None. Although independent work on [Realm Crossover in the KDC] is bound to be useful.<br /> <br /> ==Changes to TLS==<br /> <br /> * The changes to TLS do not disturb older TLS implementations<br /> * The TLS-KDH CipherSuites require TLS version 1.2 or later<br /> * Both TLS clients and servers must be extended to support the TLS-KDH CipherSuites<br /> <br /> We expect to offer early support to [http://www.gnutls.org GnuTLS] soon. The [http://tlspool.arpa2.net TLS Pool] will also support TLS-KDH.<br /> <br /> ==Comparison to Other Work==<br /> <br /> See [http://tls-kdh.arpa2.net/related.html http://tls-kdh.arpa2.net/related.html]<br /> <br /> ==Related Projects==<br /> <br /> See KREALM-XOVER.<br /> <br /> ==Specifications==<br /> <br /> * [https://tools.ietf.org/html/rfc6112 RFC 6112] defines anonymous client tickets</div>

Vanrein