OpenID 2.0 security considerations

Dick Hardt dick at
Wed Aug 23 15:03:13 UTC 2006

Hi Hans

Good points. Do you have a suggestion on the security profiles? Do  
the following make sense?

HTTP - HTTP is used in one of more requests
HTTPS - HTTPS is used in all requests
PKI - public key is used for ??? (not used for anything now except  

In your comments below you appear concerned about clear-text  
association and stateless mode. Assuming the rest of the protocol is  
using HTTPS, what are the issues with clear-text association or  
stateless mode when used with HTTPS?

-- Dick

On 23-Aug-06, at 6:04 AM, Granqvist, Hans wrote:

> 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...

More information about the yadis mailing list