[OpenID] Thinking About OpenID.com

[Nate Klingenstein]

Peter,

> In the Shib1.3 world, apparently, the "AuthnRequest" message from an  
> SP to an IDP can be "intercepted" by a discovery server.

We called this service a "WAYF" -- where are you from -- initially,  
and we're trying to move along from that name because it sounds a bit  
silly and isn't very instructive.  It's not an interception, though.   
It's SP's responsibility to discover the right IdP, and it can do that  
a lot of ways.  It often chooses to do so with the help of a WAYF  
using an old proprietary protocol because SAML 1.1 had no AuthnRequest.

The 2.0 version is a DS, and it differs in that it sends the discovery  
results back to the SP to allow the SP to choose a protocol, profile,  
and optionally sign the request.

> The main functional plane difference between the Shib1.3 and the  
> OpenID2 notions of IDP/OP discovery seems to lie in the area of  
> using chaining (Shib1.3) vs. referrals/redirects (OpenID2). When  
> analysing the associated control plane, this difference affects the  
> security management properties -- invoking traditional debate over  
> the merits and de-merits of changing’s messaging-security model vs.  
> referral’s channel-security model, accompanied usually by discussion  
> of the pros and cons to each model of either publickey-based,  
> symmetrickey-based, or  hybrid crypto control principles.

I'm not sure I follow, so I hope my response is relevant.

The WAYF is a URL rewriting engine, essentially completely removed  
from the trust model.  It doesn't alter the semantics of the SAML 1.1  
request or the SAML 1.1 response in any form. The only thing it does  
is redirect the request, which is unauthenticated and contains three  
simple parameters, to the right IdP.  The only attack possible with  
the WAYF is to send the user to the wrong IdP, which could result in  
phishing or DoS, but it's a pretty lame attack made more so by the  
fact that the SP has to be implicit in it, since the SP chooses a WAYF  
directly.  It could just do its phishing at the outset.  (in 2.0, the  
DS could be used to phish for the user's home IdP, leading to one  
small additional check of the SP's metadata; see the SAML spec for more)

The parameters in the authentication request that the Shibboleth IdP  
receives are processed the same regardless of whether they went  
through a WAYF.  The location to be returned to is checked in metadata  
against the entity ID, both of which must be known in advance through  
an out-of-band relationship, such as a pairwise agreement or a  
federation.  Because of this check there is no risk of sending  
information about the user, attributes or successful authentication,  
to the wrong party.  The IdP could always be configured to be  
promiscuous, answering requests from anyone, but not many deployers do  
this.

If this doesn't get at the essence of what you were asking, could you  
please explain in gory detail how referrals are involved in the  
OpenID2 security model?

Take care,
Nate.