Lessons from LDAP

One of the problems that any key management solution needs to solve is how to manage a distributed, hierarchical database of keys. LDAP, the Internet protocol used to communicate between directory servers and clients, is an example of another protocol for the management of distributed, hierarchical databases. The state of key management market today is very similar to the state of the LDAP market roughly 10 years ago, and looking at the capabilities of LDAP products may give some insights into how future key management systems may work.

Suppose that an LDAP client needs information that is stored in an LDAP server. To get this information, the client passes some sort of unique identifier to the server and requests the information associated with that unique identifier. It might pass a user's name, for example, and ask for their e-mail address. If the client is authorized access to this information, then the server returns it to the client.

If the server doesn't have the information that the client needs, it can redirect the client to a place where this information can be found. A metadirectory can even be used to integrate different directories so that several different directories can be easily managed by a single administrator. The dozens of application-specific directories that a typical enterprise needs to manage made metadirectories attractive.

Unfortunately, existing products don't support this ideal model very well. Many LDAP clients can't handle redirections at all. Metadirectories never became very successful due to the problems with integrating different sources of data. If the name "John Smith" is associated with the e-mail address "jsmith@example.com" in the directory used by an e-mail system and with the social security number "812-34-5678" in the directory used by the finance system, it may not always be the case the two John Smiths are the same. This made life very difficult for metadirectory vendors, and the technology never really became very successful. Some industry observers have even declared that metadirectory technology is now dead.

Just like the proliferation of application-specific directories around the time of the dot-com boom led to the introduction of metadirectories, the proliferation of application-specific key management systems has led to the development of standards for key management that should let key management servers from different vendors work together. With any luck, the evolving key management standards will eventually define a technology that ends up being as useful as LDAP and also avoids the problems that LDAP implementations still face today.

Suppose that a key management client requests a key from a key management server. This key needs to be uniquely identified in some way, and the client needs to pass some sort of unique identifier to the key server when it make a key request. It will probably also have to authenticate to the key server before it gives the client the key that it asked for. If the key server that the client requests a key from doesn't have that particular key, the server can redirect the client to the key server that does. And if you have a standards-based approach to key management, it's even possible for different applications to get keys from a single key server and for several different key servers to be managed by a single administrator.

The IEEE P1619.3 Standard for Key Management Infrastructure for Cryptographic Protection of Stored Data should be able to provide all of these features. Any compliant client will definitely be able to request a key from any compliant server. More advanced capabilities, like the ability to redirect clients to another key server and the ability may have to wait for future revision of the standard, but they're certainly on the standard's roadmap. So with any luck, P1619.3 can avoid the problems that LDAP experienced and become a useful standard for interoperable key management products.