Rick van Rein

Fri 05 September 2014


Delivery of KRB5-KDH and TLS-KDH protocol specs

Delivery report of the first instances of the KRB5-KDH and TLS-KDH specifications

InternetWide.org drives an ideology of a free and open, well-distributed Internet architecture. As part of our endeavour we engage in standardisation work in the Internet Engineering Task Force.

The intention of this work was to realise a combination of:

  • Mutual Authentication (client to server and server to client)
  • The extremely efficient Kerberos5 infrastructure components
  • Perfect Forward Secrecy through Diffie-Hellman

We have aimed to introduce these mechanisms through extensions of Kerberos5 and TLS. Today we released a first version of the two protocol modifications for public review. These are highly technical documents, intended as proposals to a community that is aware of the inner workings of Internet protocols and standardisation.

We have first investigated related work and then continued into the design of a conceptual protocol to describe our intentions. Doing this, we have been able to innovate in various places. Interestingly, the modifications made are small, and they are perfectly integrated with the existing protocol environments, so they can be put to use where available without hindrance to parties that do not support them. This is not special in itself -- it merely marks proper protocol design.

We then proceeded to make a minimal enhancement to Kerberos5, to enable it to cryptographically bind Diffie-Hellman key exchange (description, spec) into the application protocol. This is the protocol that is used between users and services; for instance, between your mail reader software and your IMAP mail server. What we added here is Perfect Forward Secrecy, a facility that makes it impossible for an attacker to grab your traffic off the wire and decode it on a future date when they guess the password that protects your access to Kerberos.

The second enhancement we made was to TLS, the basic security protocol for many Internet traffic -- you may know it from the "lock" in your browser. The common protocol is as complex as the certificates that it uses for server authentication. The approach that we introduced is based on the much simpler Kerberos5 protocol, which also is simpler to keep secure. We introduced a Kerberos5-protected Diffie-Hellman key exchange (description, spec) into TLS to establish a similar user experience as with Kerberos5, but this time using the Internet's favourite security protocol.

This is not the end of the line of research though; we may have created solutions that fit well with the desires of a closed infrastructure such as that of a corporation or a country's government, but crossover to other realms is ideally extended until it can cover the entire Internet. This is the work of a continued project on realm crossover that can build on the achievements of the prior two projects.

Specifications themselves also are not the end of the line. They may now be implemented, which may turn up new insights that will advance the proposals; also, peer review by Internet experts and security experts may reveal all sorts of technical improvements. After that, there remains the matter of achieving tool support. For our ARPA2 project, that is easy to do; we have an upcoming TLS Pool project that will encompass these ideas, or at least TLS-KDH.

Go Top