[OpenID] Supporting OpenID

Sun Apr 13 17:56:50 UTC 2008

I think its germane to address the apparently sensitive issue at the heart of the thread: gatewaying, particularly in this highly doctrinal UCI forum. UCI does, after all, attempt to distinguish itself by advancing personal privacy practices via "protocol design". How successfully it does that is up for debate. Without trusted endpoints enforcing a centralized network policy (in the sense of NCSC Red Book part II), how can any messaging protocol bearing signals prevent gatewaying from compromising its upstream privacy controls?

One can argue that the openid protocol engines fronting the Yahoo or Google or ASP.NET membership webservices are not classified properly as "gateways". They are each, in a contrasting classification, a single protocol implementation (leveraging libraries). However, those libraries and their APIs are protocols, often of the remoting variant and often with specific security state management conventions. Perhaps the most famous API is GSSAPI, which is in practice simply a programming-gateway to a particular Nortel/DEC token-passing protocol. If we address one more example, perhaps more pertinent, the JanRain .NET OP I played with a while back simply leveraged a Microsoft ASP.NET library to cast OpenID signals into ASP.NET Auth/AuthZ cookies. Surely in this case, as such cookies actually flowed across the wire, we have protocol to protocol gatewaying (via APIs)?

We can also do useful analysis by analogy. In the early 2000s, I spent endless hours petitioning for the standardization of OCSP - a relying party protocol that allows a certificate user to ping a repository of "status" information about X.509 certificate-encoded assertions. We achieved the goal, in IETF, ceding a couple of interesting and germane points though. First, we conceded that a CA could control an OCSP status server, with a  formal delegation model (using some bit signals expressing in, guess where!, signed delegation/subordination certificates). But the standard also concedes that said bit-level control requirements may be absent when a CA does not use technical delegation controls to work with OCSP Responders.. The contrast in these delegation control practice regimes embodies an architectural pattern that is similar to gatewaying in the UCI sphere, I venture , where one OP proxies up to another OP (or an OP proxies up to an IDP, which proxies to an STS, which...).

In the OCSP vs CA pattern, we wanted a (service-oriented) world to exist in which third-party validation authorities (read "RP-STS", these days) would aggregate third-party endorsement information along with first-party CA-delivered certificate status (delivered from the "official" Euro-style certificate "repository" of "subscriber" "records"). So called Enhanced Validation would deliver to you the relying party a "managed reliance signal", whose derivation was a realtime composition of (a) the status of the cert in a CA's public CRL, and (b) the named entity's credit score, as published by D&B, Equifax, etc. I hope that the parallels between CA/OCSP and OP/OP proxying (or OP/reputation-service integration) are obvious. Clearly, on the issue of assertions by one party and re-assertions made by another, we have been here, before - long before UCI became a moniker.

What is interesting is to note what pressures were applied in formulating a standard that could normalize the very notion that the entity that makes the assertion might not be the authoritative entity that establishes the assertion's credibility. DoD folks (being indoctrined in the NCSC Red Book) were aghast that a CA might not be the definitive authority. But, they were placated by the standard's formal delegation model controlling those pesky OCSP responders. Commercial CAs were mostly aghast, as it appeared that the economic value point justifying $400 for a cert was moving downstream closer to the decision maker.. inducing a transfer of economic value from the certificate server to the reliance server. They placated themselves by sending in the lawyers to threaten copyright infringement - and otherwise remove rights from their own relying parties to even engage in such "dubious practices". Names became copyrighted, as did CRLs. (You can guess which commercial CA engaged in this.) And then, along comes UCI (with URL names, bearing copyright-able/trademark-able domain-names) and an evangelist's regime that once again distinguishes between assertion making, and re-assertion making. 

If I stand back, the only thing that has changed (and this MAY represent the critical point of inflection) is that we now have sp-initiated flows, placing far more power in the hands of the RP. The worm has perhaps turned a full half circle. Its now easy to have several CAs/IDPs/OPs on the hook for assertion making , and quickly discard the one's that gets all uppity and imposed policy obligations on RP. With a tiny bit of operational planning, dumping an uppity OP has little or no operational consequence. I think this SP-centric federation model is what in the SAML world folks call "SP Affiliations".

_________________________
Peter Williams
Chief Information Security Officer
Mobile (805) 416-6305

From: Nate Klingenstein
Sent: Sat 4/12/2008 10:43 PM
To: Peter Williams
Cc: Will Merydith; Paul Madsen; general at openid.net
Subject: Re: [OpenID] Supporting OpenID

Peter,

I'm not sure how it's germane to this discussion, but there are at least two distinct issues with proxies and gateways.  These issues are particular to spoofing and reassertion, which are the easiest ways to implement a gateway, and consequently the ways that are really widespread.

The impact on the privacy of the end user you describe is one concern.  They consume and parse user information before passing it along.

However, security is also impacted: without the elaborate proxying and delegation design you note, they eliminate the end-to-end trust between providers and often incidentally destroy information.  We prefer to make our authorization decisions by attribute, and the issuer/authority for those attributes can be important for their interpretation.  This information is usually lost in proxying models, and is actually remarkably difficult to preserve.

Large content providers are facing this problem now as the pool of deployers grows.  Multiple organizations that have no resources to run their own IdP are banding together to form single IdP's.  This gateway makes differentiation of users for resource allocation and contractual fulfillment challenging, while access control rules must be more complicated.  I'd like to see such single IdP's in the future at least provide attributes to allow for differentiation, and would like to see IdP outsourcing services arise for organizations that would prefer to use them.

That all said, there are often situations where these perceived shortcomings of proxying are actually desirable.  A set of applications may wish to appear to many IdP's as a single application for simplicity, or backend applications may not want to understand federated identity.  A gateway is perfect for these use cases.

Just another tool in the identity kit,
Nate.

If I generalize the topic now, I did note in browsing some Shibboleth design session notes on an Internet2 wiki that Scott Cantor has previously expressed reservations on gatewaying - on the grounds (and here I interpret a little) that they interfere with privacy features. The point being, I think, that the very notion of gatewaying sp-initiated flows back to back (and yet further back-to-back WITHOUT formalized proxy control signaling) interferes with the writer-to-reader (end-to-end) assumptions that the security services built into the websso protocols usually make, in their privacy-enhanced signaling. While cardspace clearly has the capability to enforce writer-to-reader (relying on TPM to TPM and crypto control system to enforce an ORCON policy), its making broad assumptions about trust hardware and trust OS deployment that is of course not "yet viable," in today's web.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080413/e17c9b63/attachment-0002.htm>