On Tue, May 05, 2015 at 01:56:13PM +0100, Matt Caswell wrote: > Due to the infrequency with which it is being used in practice this > means that the code is not being kept up to date. There are some > technical issues (including its use of single DES) which mean the > existing solution is not fit-for-purpose. Viktor is probably better > placed to elaborate on those.
A better way to combine TLS with Kerberos, albeit with extra round-trips for initial session establishment, is to use anon-DH (ADH or AECDH) to establish a TLS session, and GSSAPI with channel-binding for mutual authentication. If one then stores GSSAPI authentication results along with TLS session state, resumed connections suffer no extra latency. GSSAPI has a well-defined API, and does not require extra TLS ciphersuites, Direct use of Kerberos makes the TLS library depend on the choice of Kerberos run-time (MIT vs. Heimdal) complicating package management. Also TLS Kerberos ciphersuites are defined only for obsolete ciphers (DES, 3DES, RC4 and IDEA). I don't see any likelihood of more modern KRB5 ciphersuites being added in the future. There are also TLS API difficulties, because it is not easy to configure the server principal name, handle different Kerberos name types, obtain the client principal name on the server side, ... There is little point in any case in doing TLS with Kerberos, it is not widely supported, it makes more sense to use GSSAPI with wrap/unwrap, or Roland Dowdeswell's libknc, that presents a Kerberos authenticated stream abstraction much more cleanly than Kerberos inside TLS. https://github.com/elric1/knc -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev