Part 8 of Global Directory

Previous parts of this series have used the Global Directory for storing public authentication information in the form of public key material. These mechanisms are much better than the common poor man's choice of using passwords. Unfortunately however, we are all poor men (and women) in some parts of our daily lives; we all use protocols and tools that are not capable of those advanced cryptographic exchanges. And a plethora of scripted web-tools is not improving that! So the ideal would be to publish a password verification method in the Global Directory as well. The SRP mechanism makes this possible.

This article is part of a series of articles about the global directory.

Distributing Passwords

Since the Global Directory is implemented with LDAP, and LDAP is used for internal central administration, there are bound to be methods for password sharing accross a local network. And indeed, there are; for instance, the userPassword attribute can attach a password in an object. This may either be in the plain, securely hashed, or salted and then securely hashed. In other words, it is possible to mention information that can be used to verify a password.

This is usually applied internally, on a network that is more or less reliable because it falls under local control. This is important for passwords, since they may be prone to attempts to dig up the password, even from the securely hashed forms. The most notable attack is a dictionary attack, which uses the fact that people often use simple words as their passwords. There are even attacks that harvest information published on social media to determine the words to try. This alone means that a password file should not normally made public. The aforementioned userPassword attribute would become a challenge by attackers when published.

The problem of dictionary attacks may be overcome by picking a random password, and salting it heavily. Both strings have the same entropy ("number of surprising bits") as the secure hash outcome -- more bits would not increase security and less bits would weaken the security without much benefit. This can either be accomplished by very well-trained users, or by using a machine-provided password. In fact, the password should not be supplied, but it should be made accessible for challenge/response type interactions, so that the password cannot be extracted; an interface like PKCS #11 would be suitable for that, as it can calculate secure hashes over pieces of data and intersect an internally kept secret while at it.

Interesting about a public store of password verification information is that it enables instant global password changes. This is a very practical measure that can lead to greatly increased security. Because it attacks the other factor available to attackers -- time. If a password remains unchanged for long periods of time, they become vulnerable. Cryptographers make it a hobby to estimate how long a cracking attempt on a password with a certain amount of entropy takes. Note that the publication of a password verifier in the Global Directory makes it possible to alter the password at a whim. This is also a great help in rolling to other secure hashes, in case the concrete hashing algorithm is cracked; although this usually is a slow and gradual process, nobody can claim with certainty that an algorithm is never cracked overnight. Again, the handling of passwords in a protective shell like PKCS #11 helps to make the password change unnoticable to its user.

So we come to a few principles for sharing passwords in the Global Directory:

Principle: Do not publish passwords that are selected by human users; generate them with a secure random generator to ensure a minimum level of entropy.

Principle: Rather than making the literal password available to the user, it is preferrable to make algorithms available that perform security calculations over the password.

Sharing Passwords

The idea of a centrally stored password verifier is that access to many locations can be accessed with the same password. When publishing it in the Global Directory, anything on the Internet could be accessed with the same password, meaning that no new credentials are needed on a per-site basis. This saves the end user from selecting a password that falls within the frivolous considerations that the local admin had in mind when he programmed the service.

A danger with this scheme however, is that multiple sites get to see the same password. As a result, one site could login to another. This could be resolved by not providing the password itself to the remote site, but unfortunately most cryptographic calculations require the password as input to determine a matching output between the directory-published information and the login attempt into the directory-bound account. Effectively, the password would be presented to all sites visited.

More clever cryptographic mechanisms can somewhat loosen this. For example DIGEST-MD5 uses an MD5 secure hash within another MD5 secure hash; the inner contains the password and a bit more information, and the outcome of that inner hash could be supplied to a remote site. However, since this part is designed to be static, this ends up behaving pretty much like a password replacement. It only helps in situations where the login attempt requires the actual password being presented, and this is the kind of situation that we would like to avoid. Clearly, a more clever calculation method is desirable.

We conclude by summing up yet another principle that would be required for publication of passwords in the Global Directory.

Principle: The password verification mechanism must not require re-usable credentials such as passwords to be sent to servers as part of the login process.

Enter SRP

The Secure Remote Password mechanism, abbreviated to SRP, can fulfil the aforementioned requirements. It is defined in RFC-2945 as SRP-3 and since updated to version SRP-6. SRP makes a calcalulation similar to Diffie-Hellman but it incorporates the password on the side trying to gain access, and a password verifier on the side trying to grant access. TODO:CHALLENGE:The password or other re-usable credentials cannot be derived by the latter, so we are not spreading access privileges through the login procedure.

The SRP mechanism can be implemented over a PKCS #11 interface, so it can co-operate with anything ranging from a software program, through cheap USB tokens, to high-end HSM devices. A PKCS #11 implementation is also suitable for generating password-like key files and the password verifier information. The result is that the password is generated on this device and never has to leave. Not bad at all for a poor man's credential!

SRP has bindings for LDAP, so publishing it in the Global Directory should not be an issue; you can follow the same procedure as for OpenPGP to import it into your OpenLDAP directory. The schema does not permit multiple versions of the SRP verifier information, so it is not possible to present alternatives in parallel. That is only a mild problem -- software generally implements sufficient varieties to accept different secure hashes (TODO:detectable?), and rollover of a published SRP credential would be instantaneous but that would at worst lead to a one-time login disruption. Those are probably acceptable situations.

SRP is implemented in SASL libraries, which means that it is available to a large number of password-reliant protocols. As long as they are flexible enough to notice the presence of SRP and provide it to protocol clients, this means that a lot of server software can actually use SRP. TODO: The trick that now remains is to train those SRP implementations to retrieve their credentials from the above LDAP scheme. It would need to derive a location from which to retrieve the SRP information in LDAP. This could well be done in the same way as used for the TLS pool, interpreting a domain name as a series of dc=,dc= patterns and interpreting user@domain as that same dc=,dc= pattern under which a (uid=) search must be made. On most SASL software this should be a straightforward extension that then applies to the entire range of applications that use this implementation.

Finally, SRP has been integrated into TLS, as specified in RFC 5054. The resulting protocol is called SRP-TLS and offers an alternative to the use of client-side certificates as a light-weight credential. It is not immediately clear if this enhances the potential of TLS, but it is supposed to be more efficient.

Further Reading