Difference between revisions of "Project/TLS-KDH"
From K5Wiki
(Removing all content from page) |
|||
| Line 1: | Line 1: | ||
| − | ''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 pages] |
||
| − | * [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. |
||
| − | |||
| − | ==Mechanics of the Project== |
||
| − | |||
| − | The TLS-KDH CipherSuite is a special way of using TLS: |
||
| − | |||
| − | # The TLS client offers TLS-KDH CipherSuites in its ClientHello |
||
| − | # The TLS server selects a TLS-KDH CipherSuite in its ServerHello |
||
| − | # The TLS server sends no ServerCertificate |
||
| − | # The TLS server sends a ServerKeyExchange with a suitable Diffie-Hellman public key |
||
| − | # The TLS server may send a CertificateRequest to request a client identity (which the client may still refuse to supply) |
||
| − | # The TLS client chooses whether it will release its identity, or remain anonymous |
||
| − | # The TLS client looks for a service ticket in its local Kerberos infrastructure |
||
| − | # The TLS client sends a ClientKeyExchange holding a service ticket and a Diffie-Hellman public key response, encrypted to that ticket |
||
| − | # The TLS server accepts the service ticket and uses it to decrypt the Diffie-Hellman response |
||
| − | # Both now construct the shared secret, following normal Diffie-Hellman procedures for TLS |
||
| − | # Both now construct a proof of knowing the secret, thereby authentication to the other side |
||
| − | # 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 [http://www.gnutls.org GnuTLS] soon. The [http://tlspool.arpa2.net TLS Pool] will also support TLS-KDH. |
||
| − | |||
| − | ==Comparison to Other Work== |
||
| − | |||
| − | See [http://tls-kdh.arpa2.net/related.html http://tls-kdh.arpa2.net/related.html] |
||
| − | |||
| − | ==Related Projects== |
||
| − | |||
| − | See KREALM-XOVER. |
||
| − | |||
| − | ==Specifications== |
||
| − | |||
| − | * [https://tools.ietf.org/html/rfc6112 RFC 6112] defines anonymous client tickets |
||
