How to authenticate a remote party in the InternetWide Identiy Framework?

The InternetWide Architecture works towards an infrastructure with a Bring Your Own IDentity concept to give end users optimal control over their online presence and privacy.

As with any identity framework, the two concepts at play are authentication, described below, and authorisation. These are mutually enforcing, but different concepts.

There are various mechanisms over which clients can authenticate.

X.509

The classical authentication mechanism for the Internet is PKIX, also known as X.509 Certificates. Indeed, it is possible to install certificates in most mailers and web browsers.

Certificates are based on public-key cryptography, where access to a private key is required to construct proof of being a certificate owner. Certificates bind identity to a public key. These key/identity bindings are generally signed by some "higher authority".

Although this mechanism is certainly available for many uses, it is barely used for client authentication due to its inherent complexity; X.509 certificates are only successful in practice for server authentication. So, when clients need to authenticate using X.509 then we surely need to improve on the complexity of rolling out these certificates.

In our IdentityHub phase, we will store certificates in an LDAP respository under each domain name, which can then be queried by any relying party. This is only secure when the path to that LDAP repository can be secured, but DNSSEC and DANE can make that possible. The use of such LDAP repositories under domain names is generally referred to as the Global Directory infrastructure.

OpenPGP

The alternative public-key system in today's World is OpenPGP. This system does not have the strict hierarchy that approves identity/key bindings that we have with X.509; instead, anyone can create a new key and anyone can make claims that the created key/id bindings are valid.

The simplicity of this mechanism makes it more light-weight to setup than X.509, and this may be part of the reason why this mechanism is actually being used by end users. It is most popular for signing and encryption of email, but extensions have been defined for its incorporation into general TLS connections, including HTTPS.

As with X.509, it is quite possible to define OpenPGP keys in an LDAP respository that can be securely loaded from LDAP. Indeed, the most-used implementation of today, which is GnuPG, implements facilities to lookup keys in such domain-bound LDAP key stores and, by doing so, supports fully distributed use of OpenPGP keys.

Kerberos

In parallel with these public-key mechanisms, there is one other sytem that has been there all along, and that is heavily used inside any company beyond a certain size, and that is Kerberos.

Kerberos is a single sign-on system, meaning that normally you login once a day and then carry credentials around for a full day, without any further need to login. The protocol interactions required for Kerberos tend to be blazingly fast, because it relies on symmetric cryptography, which is a class of algorithms that is thousands of times faster than the public-key crypto of X.509 and OpenPGP. In terms of end-user experience, Kerberos is king.

The InternetWide Identity Framework invests heavily in Kerberos; we are doing work to make it usable across realms, with improved privacy and possibly dissemenated authorisation. In addition, we have worked out a TLS mode for Kerberos to radically improve upon the security of its use in any TLS connection, most importantly HTTPS.

TLS Pool does it all!

All the aforementioned usage patterns are intentionally part of the TLS Pool project. So, when a plaintext connection comes in and it is time to upgrade it to TLS, simply hand over its networking socket to the TLS Pool and after it has gone through a handshare, harvest a new networking socket whose traffic is protected by TLS.

When the new socket is handed back from the TLS Pool, the remote identity is also provided, in the form of a DoNAI. This identity is authenticated, but it is not necessary to know how that has been done. For X.509, the usual fields will have been probed from a validated certificate; for OpenPGP, the user name field will be extracted from a validated OpenPGP key; for Kerberos, the principal name will be used with a realm-to-domain mapping to obtain the DoNAI form.

As an application, you couldn't care less about all these security mechanism variations -- your basic concern is to establish an authenticated identity for a remote user in some standard form. The TLS Pool has deliberately been designed to split the security mind set from the application mind set. This also means that the application should not worry about certificates, validation settings and so on; all these concerns are considered part of the TLS Pool configuration.

It should be clear from this that most applications could benefit from adopting the TLS Pool as their implementation for authentication. Read on for our advise on authorisation as well!