OpenID 2.0 security considerations

[Martin Atkins]

Granqvist, Hans wrote:
 >
> 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.)
>  

I'm not convinced that this needs to be explicitly "negotiated". 
Ignoring HTTPS for a moment we have three scenarios:

1. Relying party is stateless. Provider supports stateless mode.
2. Relying party is stateless. Provider does not support stateless mode.
3. Relying party is capable of "smart mode".

I'm assuming here that all providers support "smart mode", since there 
is no good reason not to and it is required by the spec.

So, in each of these situations:

1. Relying party makes a stateless query. Provider answers. Relying 
party validates the supplied signature against the provider.

2. Relying party makes a stateless query. Provider breaks. (Ideally: 
provider returns an error to relying party.)

3. Relying party makes a "smart mode" query. All goes well.

So the only "negotiation" here is that an error is returned in case 2. 
Presumably at this point all the relying party can do is fail, because 
if it were capable of "smart mode" it would have used it in the first place.

A similar situation arises for use of SSL.

A relying party can:
* Allow both SSL and cleartext
* Allow cleartext only
* Allow SSL only

A provider can:
* Expose its identity server over HTTP
* Expose its identity server over HTTPS

In the case of a mis-match, all the relying party can do is fail. The 
only opportunity for "negotiation" I see here is to add another case to 
the second list:
* Expose two identity servers, one over HTTP and one over HTTPS.

We discussed when developing version 1 the possibility of declaring 
multiple identity servers and having the relying party choose its 
"favourite", but the conclusion was that it was too problematic since it 
creates lots of difficult cases. However, I guess the Yadis bindings for 
OpenID allow this even if core OpenID 1 doesn't.