TLS-KDH
Combined Kerberos and Diffie-Hellman as an authentication mechanism for TLS
This project develops a number of additions to the open source TLS library GnuTLS. Based on the prototype for TLS-KDH (http://tls-kdh.arpa2.net) that was developed as a branch of GnuTLS, we now need to do a full implementation that incorporate the features from this development branch into GnuTLS’ main branch. By doing so our TLS-KDH mechanism becomes automatically available for the general public worldwide. However, additional work needs to be done for these two branches to be merged. Compatibility issues need to be checked and resolved and test cases need to be written to ensure proper functioning of the library, now and in the future.
Additionally, TLS-KDH relies on RFC7250 (https://tools.ietf.org/html/rfc7250). The functionality described in this RFC is not yet implemented in any TLS library and concerns Raw public keys. As part of our TLS-KDH implementation we have implemented RFC7250 partially (what was needed for TLS-KDH). However, we have noticed the interest of the GnuTLS community in the complete RFC7250 functionality. Therefore, in order to deliver a complete ‘product’ we also want to implement the rest of RFC7250 and incorporate it into GnuTLS. Thereby creating the first TLS library that support Raw public keys.
This enables a more light-weight mechanism for transmitting public key material between peers. Finally, to ease adoption of the TLS-KDH mechanism and to provide in a default Kerberos binding for TLS, we want to implement a gnutls - krb5 library (similar to the already existing gnutls-dane library).
The current TLS-KDH implementation separates the TLS and Kerberos layers by design. While this is good design practice and offers the user great flexibility for choosing its own Kerberos implementation, it also requires (a lot) more work to be done in order to get the TLS-KDH mechanism going. By introducing a gnutls - krb5 library ( choosing MIT Krb5 ) users can benefit from a default TLS Kerberos binding thereby relieving themselves from having to implement such a binding. It therefore eases adoption and use of the TLS-KDH mechanism. At the same time, keeping the TLS and Kerberos layers separated still enables different Kerberos libraries to be used when desired. Also a layered architecture works in favor of code acceptance.
- The project's own website: http://tls-kdh.arpa2.net/
Why does this actually matter to end users?
ARPA2 is a coherent, longer term open source project from Internet-Wide Organisation. It is thoughtfully engineering towards an overall architecture scalable to run the future internet which is secure by design. It brings together proven technologies, new insights and talented people to solve the hard challenges.
The TLS-KDH specification describes how Kerberos data structures can be used for TLS client authentication, by introducing a new certificate type for use with TLS. The server can choose to provide a Certificate with a traditional signing mechanism such as RSA for authentication, in which case this specification speaks of a KDH-enhanced exchange; even when presenting no server certificate at all, a client-side Kerberos ticket can be used for mutual authentication in what will then be called a KDH-only exchange. The KDH-enhanced variety uses existing CipherSuite, and KDH-only defines new CipherSuites. Both KDH-enhanced and KDH-only message flows are referred to as TLS- KDH.
Earlier work on TLS-KDH was funded with a joint subsidy from NLnet and the programme '[veilig] door innovatie' from the Netherlands government.
For a complete overview of other projects within ARPA2 visit the ARPA2 website: http://arpa2.org
Run by ARPA2
This project was funded through the Internet Hardening Fund, a fund established by NLnet with financial support from the Netherlands Ministry of Economic Affairs and Climate Policy.
