Last year we announced an experiment at Sun: in order to gather
more information about the operational characteristics of
“user-centric” identity technologies, we decided to roll out an OpenID
provider for Sun employees. This OpenID provider was intended to be
used by Sun employees for personal usage at various OpenID sites that
have been popping up at some places.
This experiment involved various parts of the company, including
field people, products folks, the security team, and our Chief Privacy
Officer. We negotiated a number of requirements for our experiment:
employee privacy must be maintained at all times, the system must not
interfere with any other Sun authentication or business system, etc.
All this was quite achievable and we passed the–albeit lax, since it
was an experiment–security and privacy reviews, the focus of which was
the protection of Sun employees and property.
The weakness in Debian-generated certificates and the recent DNS
cache poisoning attack vector resulted in a triple whammy: weak
certificates, broken DNS, weak protocol. After Ben’s report last week,
we revisited the current design of the service and came up with a few
recommendations. Mark Wilcox notes that my list could be hard to follow, especially for non-technical users. To some extend[1] I do agree with him, so we decided to take additional steps on our end to improve security:
The very core of these changes lies in the idea that we are
introducing HTTPS based OpenIDs for our users. In OpenID 1 and 2, a RP
normalizes any identifier without scheme prefix into an unsecured HTTP
based identifier. Only a prefixing the OpenID identifier with the
https:// scheme will result in discovery over an TLS secured transport
channel. This looks a lot “geekier” than the somewhat more appealing
“naked” OpenID identifiers, but as a result of this change, the lookup
will now be handled completely over server-authenticated channels.
In order to make this approach useful, we would need the cooperation of OpenID RPs: in the current specs, http://openid.sun.com/user and https://openid.sun.com/user are two separate entities, which–in my opinion–makes no sense. If RPs would start recognizing these two identifiers as the same entity, it would help improve the security of the OpenID protocol in a quite significant way, since users could easily migrate from the broken insecure HTTP discovery protocol over to the somewhat more secure HTTPS transport.
Obviously, this cannot address the key-reandomness weakness, but
then … only time can. Meanwhile we have to rely on CRLs and OSCP
checking for certificate revocation.
UPDATE: The approach outlined above might be criticized for equating two URI that are not equivalent (https://… and http://…). I appreciate this from a principal point of view, but extreme time require extreme measures ;-).
A reasonable way to address the potential security implication for current https://.. identifiers would be for the RP to perform a one-time security upgrade: assuming that the RP recognizes a particular claimed_id e.g. http://openid.sun.com/user. Whenever there is a login with the same identifier over HTTPS (i.e. claimed_id is https://openid.sun.com/user in the example), the RP can ‘upgrade’ the account to an HTTPS-only account.
On the OP side, any account for https://x.y.z should trigger the complete block for any http://x.y.z ids.
Thanks to John Bradley for some stimulating discussions on these issues.
tags: OpenID security transport security
[1] Mark mentions OAAM’s strong authenication and risk based authentication technologies as potential solutions for OpenID’s weaknesses. Maybe it is because I am not familir with this product, but I cannot see how OAAM can help with the weaknesses that occur through using HTTP (as opposed to HTTPS) for discovery. Likewise, socially engineered attacked can be effective in circumventing stronger authentication mechanisms (such as pictures or virtual keyboards) for less technology-sophisticated users: instead of their image, the rogue OP displays an error message along the lines of “Sorry, your personal image is currently unavailable due to maintenance. Please use standard authentication in the meantime.” This might not work with all users, but I know enough folks who would login also with the “standard authentication” scheme.