Kerberos through TLS-KDH

The most exciting enhancement that is introduced through the TLS Pool is its support of Kerberos, which it always does in unison with Perfect Forward Secrecy. This modified TLS protocol is not only much more efficient than a classical X.509-based security model, it also resolves many issues that have historically grown around the X.509 system, leads to improved user experience and is more to the point about its security guarantees.

The normal flow of a full-blown TLS handshake, where both ends supply a Certificate, is as follows:

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                      Certificate
                                                ServerKeyExchange
                                               CertificateRequest
                                   <--------      ServerHelloDone
      Certificate
      ClientKeyExchange
      CertificateVerify
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

It is certainly not always the case that the client authenticates; most secure web servers will relay pages to anyone, and authenticate themselves to the client but not require to validate the client’s identity.

Still, there are situations where the client identity is of use — a personalised service, possibly with authorisations for certain functions based on a validated client identity.

In either case, the customary form for the Certificate messages is that of an X.509 Certificate. Alternatives are possible, notably OpenPGP Public Keys and even raw public keys.

For the InternetWide Architecture however, we have selected the Kerberos infrastructure as the principal cornerstone of identity. This is a very common choice made in many corporate infrastructures as well — except that then it is used internally. What we aim to do is connect realms all over the Internet, facilitate authorisation, allow people a bring-your-own-identity service level but with privacy protection through pseudonyms, aliases, roles and groups. yeah, that’s quite a bit, but we found the places to integrate this with Kerberos — it’s mostly a matter of making it happen.

Now let’s look at HTTPS security. Its current integration with Kerberos is disastrous, to say it politely. The best efforts in this direction are all known to be flawed and barely secure. The practices behind their deployment may be even worse. This is in sharp contrast with the usefulness of having a good HTTPS setup based on a company’s single-signon infrastructure. In fact, the poor systems of today are usually only tolerated because there is no alternative and people do like to have their single-signon enacted for the web.

In contrast with these current practices, what we do with TLS-KDH is to integrate Kerberos in a cryptographically solid manner with TLS. We use a Kerberos ticket as the client’s Certificate which, in line with the way Kerberos works, also authenticates the server without needing it to send one. The server may however still send a classical X.509 Certificate, which may prove useful if the client opts out of Kerberos (choosing to not be authenticated). The ServerKeyExchange and ClientKeyExchange are filled with the proper fillings to ensure Perfect Forward Secrecy, a property that avoids tapping even when keys are known — a great asset in general, and basically a must with Kerberos.

HTTPS can directly benefit from this, and may refer to the TLS layer to learn about client identities, if it cares. For mail and chat servers, and basically anything else, the same mechanism can be used (they might use SASL EXTERNAL to implement authorisation).

The mechanism described here is surprisingly more efficient than that of X.509 Certificate validation. TLS-KDH [research suggests 5000-fold improvements](javascript:alert(“tom thesis… link?”)) of the authentication effort! This can be quite helpful in light of the growing desire to “encrypt everything”. Much of the advantage lies in the use of symmetric crypto by Kerberos, but the infrastructure is also simpler: instead of long-lived X.509 Certificates that are founded on a feeble email check and which may have to be withdrawn later, a Kerberos ticket is so short-lived that it can be used without retraction infrastructure. The next day, a new ticket will be acquired and used because yesterday’s has stopped to be usable.

Combine the immense potential that the TLS-KDH mechanism offers with the idea that Kerberos can be taken out of companies to work on the Internet as a whole — with that, and the much faster response times compared to X.509, a highly pragmatic mechanism has been created for a future, secure Internet.

TLS-KDH should rank high for its innovative empowerment, but in the end it is just one of the options when using the TLS Pool — it is never enforced. It is helpful however, that the TLS Pool speaks with applications in terms of identities, not certificates. This means that the application does not need to be aware of the mechanism that brought it the authenticated identities that it can act on — the TLS Pool handles it all.

Given the high efficiency and relative simplicity of making a solid implementation of TLS-KDH, a special profile has been created that includes just TLS-KDH. This may be useful for constrained environments, such as embedded systems.