OpenID 2.0 security considerations

Johannes Ernst at
Wed Aug 23 16:37:29 UTC 2006

This is very useful work. Would be interested in hear about all items  
you guys found in detail.

You probably realize that what you are proposing is a substantial  
expansion of the protocol and the complexity of implementations. If,  
from a security perspective, it must be, then it must be, but we  
should be aware of that.

I'd strongly argue that the protocol should never "die" unless  
absolutely necessary, but instead gracefully degrade. For example, a  
bank may want to require that IdPs whose assertions it accepts use  
HTTPS. However, I much rather have the protocol succeed and the RP  
decide that the assertion it got wasn't maximum-strength, and show  
restricted functionality after authentication, than simply say  
"sorry, won't do that". There are surprisingly many cases where this  
behavior makes a lot of sense.

On Aug 23, 2006, at 6:04, 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

Johannes Ernst
NetMesh Inc.

-------------- next part --------------
Skipped content of type multipart/related

More information about the yadis mailing list