Robin Wilton's esoterica

You may have seen the recent announcements about DNS cache poisoning, and the potential effect of this on all kinds of internet-based applications' security. One area in which it can have a particularly significant impact is OpenID... because OpenID (largely for reasons of simplicity and ease-of-setup, originally) was designed to avoid the need for any prior exchange of security information between Relying Parties (RPs) and OpenIdentity Providers (OPs). That kind of prior exchange was seen by some as one of the obstacles to the rapid adoption of alternative distributed authentication schemes, like Liberty's Identity Federation Framework (ID-FF), or the SAML protocols that is based on.

OpenID doesn't use such prior exchanges between OPs and RPs, but relies instead on the integrity of the underlying DNS system to ensure that the 'correct' OP is connected to the 'correct' RP. If the DNS infrastructure is compromised by something like a cache poisoning attack, it becomes impossible for OPs and RPs to tell 'real' communicating partners from bogus ones - and any resulting authentication is correspondingly undermined.

You may be wondering what this has to do with a strong Liberty proponent like Sun... (apart from the obvious "told you so" opportunity, which I am not going to stoop to...). Well, last year the CTO group I work in set up an experimental OP server so that we and our colleagues could try it out, and see how it fits into the broader identity eco-system technically, commercially and from a user perspective.

This DNS news, plus a couple of other factors which I'll come to later, was therefore of direct and immediate relevance to us.

Let me clarify at this point that the OP server was set up explicitly as an R&D 'play-pen': it is not connected to Sun's enterprise authentication systems, and it cannot be used to access any Sun applications, sites or resources. Sun employees' ability to authenticate securely to Sun systems is entirely unaffected by it. We also made it clear to anyone registering that this is for personal use only in accessing non-business-related third party sites. (We've added a few other points to that advice recently - more on that in due course).

Another factor, was that we got a polite heads-up from Ben Laurie of Google's Security Group, and Richard Clayton of the Computer Laboratory, Cambridge University. They had noticed that the certificate used by our OP originated in a flawed software crypto module in one of the systems we used during the development work for this project. To be fair to the developers of that module (it was part of a Debian/Ubuntu distribution), the bug in their key-generation routines had been spotted and a patch created in May this year. Unfortunately, by that time, we had already used it to generate what turned out to be a weak public key pair.

Ben and Richard have published a security advisory, which you can find here, succinctly setting out how the confluence of the DNS vulnerability and the certificate bug have a potentially devastating effect on OpenID's security model.

In R&D terms, the whole exercise has been very interesting (even before these recent excitements...). For instance, at the outset, we were able to use the project as a vehicle for a number of other actions:

- We worked with an external OpenSSO committer on an open-source OpenID extension for OpenSSO, which we thought might come in handy for others to experiment with.

- We became the first company to offer a non-assertion covenant on the OpenID spec, and we think that turned out to be influential.

- We raised the question about whether offering "implicit" attributes (like "This OpenID holder is a Sun employee") might be of value or use.

- We performed a formal security review which we feel usefully supplemented the many OpenID security critiques out there even at that stage last year.

So, what are we going to do now, in the light of developments like the 'DNS cache poisoning'  and 'weak key pair' vulnerabilities?

Well, I suppose the first thing to note is - in response to Ben and Richard's alert, we took our OP offline, revoked the weak certificate and generated a strong replacement. However, as Ben pointed out, that doesn't fix things... As long as someone else is in a position to route users to bogus OPs, where they might be fooled by the revoked, weak certificate, the problem persists.  A better solution to that part of the problem might centre around the more effective use of existing security mechanisms - such as Certificate Revocation Lists (CRLs) - by both clients and RPs. I suspect Ben will be writing about those aspects in more depth soon, so keep an eye on his blog, here.

The next point is that taking our own OP off the network doesn't really fix anything, either. So we're going to leave our OP where it is, and Sun employees will continue to be able to register and use it. We are going to increase the guidance we give those employees, about steps they can take to minimise the risk of phishing. Again, that will be a valuable R&D exercise in seeing whether a relatively tech-savvy user community can be educated to change its browsing habits for the better - not a bad pay-off if it works.

We're also thinking about some constructive proposals about ways to improve the security infrastructure in general; after all, masquerade attacks are nothing new, particularly in the world of public key cryptography, and there are several mechanisms already out there which could be brought into play.

So our approach will be to address those parts of the problem we can fix (or at least mitigate) one our own, and where that isn't possible, continue contributing to the identity community based on what we learn.

Thanks, again, to Ben and Richard for handling the "advisory" process in such a co-operative and professional way.