OpenID 2.0 security considerations
Dick Hardt
dick at sxip.com
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
HTTPS)
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...
URL: http://lists.danga.com/pipermail/yadis/attachments/20060823/dc0008f6/attachment.htm
More information about the yadis
mailing list