OpenID 2.0 security considerations

[Granqvist, Hans]

We've been conducting an internal security review of the OpenID 2.0 authentication protocol here at VeriSign and I wanted to share some of the findings with you. 
 
Now, before I start, I understand there is a draft in progress that is due any day now and that this draft might mitigate some of the concerns, but I still want to bring these issues up, as I think some of them may warrant potential wire-format changes to the current specified protocol.
 
One main concern is the way the protocol mixes comparatively strong mechanisms such as Diffie-Hellman key generation and HMAC-based signed assertions with weaker options such as Clear-Test Association Sessions and Stateless Mode. 
 
This can be solved by specify Open ID 2.0 protocol "security profiles" and how to discover and negotiate these. The negotiation phase may change the wire-format, since the idp and rp would need to communicate reluctance, inabilities, and cryptographic errors when deciding specific security profiles. (This is a potential wire-format change.)
 
Such a security profile would specify whether discover elements have to be digitally signed, and if so in what way; whether TLS/SSL (or other secure channel) is needed for discovery transport. The profile should also handle the current problem with using ephemeral-ephemeral DH in the association exchange (specify how to replace with ephemeral-static with certified public key, or how to protect association establishment with TLS/SSL and X.509 cert checking.) Or perhaps there is another authenticated key exchange mechanism.

Some other considerations include 

*	how to deal with a malicious rp redirecting the User-Agent to a malicious idp for purposes of learning passwords, etc.
*	having the rp incorporate randomness into the MAC key
*	cryptographically link and sequence each authentication request-response pair with a MAC on the request, as a better replay protection mechanism
*	eliminating ability of an IdP to downgrade to a clear-text association session or to a stateless mode process.

There are a few more, but I just wanted to post this as an indication that there are some security issues within the protocol. We should address these sooner rather than later. The major change seems to be the establishment of security profiles, but the use of these might force wire-format changes. 
 
To think about: 

*	
	Are security profiles a usable concept? 
*	
	How important is the protocol's capability to self-handle such security profiles' negotiation (think TLS cipher suite negotiation)? 
*	
	Can the protocol "just die" if idp/rp have a profile mismatch? 
*	
	Once a profile is decided between user/rp/idp (implicit or explicit) how should the protocolt gracefully handle (intentional or not) missteps? 

Let's see if we can work through some of these concerns. Obviously, the less disruptive changes to existing code-bases the better!
 
Thanks,
Hans Granqvist
 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/yadis/attachments/20060823/9ab5bf65/attachment.html