OpenID 2.0 security considerations

[Gabe Wachob]

Hans-

 

Let me chime in here too since I've been concerned about the lack of a
stated trust model from day one - I assumed that these issues would be
raised at some point - I'm glad you've raised them earlier rather than
later. 

 

I'd note that OpenID auth is *very* similar to 3-D Secure, the protocol
behind Verified by Visa and Mastercard's SecureCode. Unfortunately, the
specification is not published publicly without accepting a license so I
can't make references to it except from my relatively in-depth hands on
experience with it while I was at Visa - suffice it to say that many of the
same security issues that are dealt with in 3-D Secure appear here as well.
Some of my feedback is guided by that experience.

 

  _____  

 

This can be solved by specify Open ID 2.0 protocol "security profiles" and
how to discover and negotiate these. 

 

 

Yikes - the concept of profiles that get negotiated at runtime scares me. I
suppose we could just cast this in terms of multiple service types. 

 

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.

Is this something that OpenID the wire protocol has to deal with, or the
IdP? That is, isn't this just a form of phishing issue that IdP's have to
deal *in any case*? I'm not saying OpenID has to ignore the issue, but I do
wonder if OpenID can propose the solution. 

 

I honestly don't remember how (or if) 3-D Seure/VbV addressed this phishing
issue. Its basically the same phishing issue that occurs for home banking -
a site that looks like your bank asks you for some credentials and you use
your best judgement to determine whether handing over your credentials to
that site (an IdP) is a good idea. There are some methods on the server side
(and increasingly on the client side built into browsers) to mitigate these
phishing attacks these days. but the problem is obviously still unsolved. 

 

 

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

I must say that I agree with this. If don't think clear-text anything should
be "negotiatable" - I think it should be advertised explicitly as a separate
service endpoint with a separate service type. 

 

To think about: 

*	Are security profiles a usable concept? 

Personally, the farthest I'd like to see OpenID auth go in this direction is
the advertisement of different service types, e.g. "insecure" and "secure"
(or maybe 3 levels - but no more). 

*	How important is the protocol's capability to self-handle such
security profiles' negotiation (think TLS cipher suite negotiation)? 

TLS negotiation is great and we should rely on it as much as is possible -
but I would really like to avoid the complexity of that sort of negotiation
at the OpenID level - otherwise, we are getting away from one of the driving
architectural principles of OpenID - simplicity! I'd also note that by
saying "TLS" and not discussing anything about CA and PKI hierarchies, we
are relying on the default installed trusted CA roots out there - which some
users may or may not trust for certain purposes (again, Visa background
speaking here). 

 

*	Can the protocol "just die" if idp/rp have a profile mismatch? 

I'd rather it die than operate insecurely, unless the user, idp, and rp
*all* really want to act in an insecure manner. 

*	Once a profile is decided between user/rp/idp (implicit or explicit)
how should the protocolt gracefully handle (intentional or not) missteps? 

I think the only graceful failure should be to "fail up" to a stronger
security profile/service. I'd rather it fail all together if the security
intentions of the 3 parties aren't achievable. 

 

Let's see if we can work through some of these concerns. Obviously, the less
disruptive changes to existing code-bases the better!

 

Yes, though, OpenID 2.0 is going to imply quite a number of changes anyway.
The thing *I* would personally like to see unchanged (as much as possible)
is the message flow and the trust relationships between the parties (though
again I'm not sure I've seen that explicitly described anywhere and may in
fact be leading to some confusion on the part of newcomers). 

 

            -Gabe

 

 

Thanks,

Hans Granqvist

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/yadis/attachments/20060823/c04c3e6a/attachment.html