[OpenID] Thinking About OpenID.com

Sun Mar 23 04:00:25 UTC 2008

Thanks for correcting me, Nate; its surel the discussion that matters at this point of OpenID2's potential as a security infrastructure capable of scaling to the numbers of https/SSL endpoints based on medium assurance PKI management principles. I'm certain that I, Peter, will not be authoritatively stating, in terms any of the actual designers here would ever agree on, what the OpenID2 discovery model and protocol is. However, to this mere observer, the model clearly exists, its written up well in specification form for implementors, and it cleary has a rich and well thought through theoretical name server architecture - once one probes a little. How different it is to what has gone before is not as easy to discern, however.

The goal of my better-written missive was to use discussion to begin: to contrast the Shib1.3 and OpenID2 discovery communication patterns, to seek out the designers' intents for the (security) management models, to postulate equivalencies between the two discovery models, to note how HTTP Redirect messages and control signals are applied, and to enumerate the distinguishing requirements (if any). For example, the class of security requirements that apparently "intentionally-biased" OpenID protocols towards SymmetricKey (vs PublicKey) control principles are one set of issues of interest.

Peter.

Further discussion below, only for those interested in analytical research techniques.

----------------

You properly challenge my choice of verb:  to intecept. With the quoted term "intercepted", I attempted to interpret using one word an entire statement from the Shib1 wiki: "In Shibboleth version 1.3, the discovery service takes an AuthnRequest message as input and, as a result of interaction with the user, forwards this message on to the selected IdP." In short, we have a "forwarding" model, requiring user interaction. From your memo, Ive now believe that the forwarding must be occuring using either a browser-based auto-redirect or auto-post binding. For the user, this comes down to a first hand experience of: 1) choose an SP target, 2) select an IDP, 3) be "fowarded" towards the authentication service of that IDP. As a proprietary extension of SAML1.1 facilitatin the (non-standard) SP-initiated websso flow, it makes sense.

I want to now distinguish the act of "forwarding" in Shib1.3 discovery from that which happens during an OpenID2 OP's handling of "auth req/resp" messages -- where there is no apparent act of "forwarding" of a message to an IDP. Even though an OP does use a "fore-ground" process to signal the the RP process (what the webservices world would term a redirect "binding") the "restart discovery" signal from an OP to the RP is 1) not necessarily automatically processed, and 2) the end-user whose browser is currently aimed back at the target RP site is not necessarily the "controlling" party.

To help make the distinction clearer,  let me encourage us to adopt some terminology for what seems to be two, quite different, communication patterns: "chaining" vs "referals".  To be intellectually safe, I'm stealing these terms from the well worn LDAP/X.500 (distributed) directory service protocol -- standardized by the highly formal ISO/ITU-T process, as augmented by additional IETF and MACE profiling work. Because of Drummond's ultra clearly described model for abstract/concrete identifiers (persistent URNs, in webspeak) - where he implied that understanding these construct are essential to comprehension of the OpenID2 model --  I want to note in particular that the LDAP/X.500 directory model subsumes the (really old) X.650 Recommentation - whose  naming/addressing/registration model also concerns those names/identifiers/addresses which are specifically "persistent".

By contrasting Shib1.3 discovery and OpenID2 discovery in terms of this third, old but highly-formalized and abstract (X.500, X.650) model of chaining and referng name server activities regarding transient and persistent (possibly registered) identifiers, we could see if this common schema for abstract requirements analysis allows us to now transcend terminology, protocols, bindings, signals and even architectures for building secure name servers based in URIs. As the Layer7 naming server issue set is very clearly parochial and quasi-religious in nature (aka DNS, URIs,  IRIs, XRIs, DNs, OIDs, and now OpenIDs - from the DARPAspeak/Webspeak/OSIEspeak/identityspeak worlds) we will obviously only get so far, before the naming wars overtake attempts at a common conceptual analysis.

If I think more broadly, the other angle of usefuly security analysis of OpenID2 would be to contrast its discovery model with ENUM. We could contrast how the "OP referrals" that an RP agent in a particular "trust realm" may follow for an XRI/HXRI in the OpenID2 flow with the referals that an ENUM resolver follows for an URI (as an RFC 3761 DDDS participant automatically hops across the NAPTRs in the DNS, hopefully avoiding loops, in search of the illusive "single, unified identity" particle). Whats interesting there of course is that DDDS is (to Noah's more general point) tied to the formal semantics of HTTP and URIs - unlike OpenIDs which are "FORMALLY NOT URIs/URLs" -- but take URI/URL form, for the present.

There is alot to think about , before OpenID2 can be widely adopted as "public infrastructure".

From: Nate Klingenstein
Sent: Sat 3/22/2008 5:56 PM
To: Peter Williams
Cc: Johannes Ernst; openid-general List
Subject: Re: [OpenID] Thinking About OpenID.com

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080322/5c4e3c04/attachment-0002.htm>