[OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP implementations)

Sun Jan 4 20:36:05 UTC 2009

Ok!

Let me assume we now BELIEVE we actually COULD leverage the (highly least-privilege-centric) .NET platform (operating in a constrained IIS7 data center hosted environment) to build our "custom" cert trust models, suiting openid discovery (operating in an UCI threat environment). That is: we have at least removed  the status quo barrier.

We can now get back to design issues. What _should_ the custom chain validation logic be, and how should it cooperate with cert-based namespace controls invoked by the vanity https URLs used during discovery and any redirects to https. (And, for folks in .Net land, how can one also leverage .NET namespace controls for URL bindings, when further leveraging the .NET security model to provide assurance?)

*         How do we know public keys are valid and authorized today? We verify they are signed by a trusted authority, and the authority roots back to a trusted store. The trusted stored  in (1) enterprise PKI and (2) H323 call agent signaling between distributed call clusters ...is usually the ldap directory (probably with its own  cross-forest trust on the cross-references between the ldap private directory management domains). There, group policy registers the root certs "authorized" by the organization, per OU.  The big point is not to talk about ldap resolvers (which competes with xri resolvers) but to  focus on the fact CA management is ..."not a browser list", updated by WindowsUpdate.

*         Now, the suspected compromise of the VeriSign Trust Network (or one of its sub brands, rather) has just this week  taught lots of folks about PKI features not that well known previously - how to manually configure the URL of the validation service  (OCSP responder), so one can FOR ONESELF run an OCSP server which overrides the status service of the trust network. Running that server _locally_ is Microsoft's own recommendation just this to its customer - to provide for full "compromise recovery". So, we are on good solid ground, when we take some trust away from (a) the CAs, and (b) the root distribution authorities.

*         But, ignoring OCSP ( now we understand the idea of taking "final decision/enforcement" power _away_ from the CA) Windows also allows you to specify for a stored root a "cross-cert" URL, even in those cert stores that are based on host registry (vs a DoD smartcard, or DISA ldap directory). Its this area where OpenID discovery can copy well established theory from the PKI world. Without describing all that cross-certs do  (but imagine cross-forest trust models from ldap applying to CAs) "One authority domain can bootstrap another."

*         So the idea is, rather than useX.509 cross-certification (where on CA root signs another CAs root), view the private association the RP has with the OP as the means by which a USER "cross-certifies" the certificate/CA being delivered  to the RP in a positive assertion. This is obviously a user<->SP trust model (since that's what openid assertions are!). The OP is not involved in that trust model formulation - except as a means of setting up the authenticated delivery of the user's AX values via the assertion.

*         Lets now use the OP as the BEARER doing the "forward" cross-certification of user<<CA>> - in a user-RP "trust setup" handshake. That is, once the OP releases a user's choices of cross-certified CA certs to the RP (under the control of the user's choice of release-profile, of course, per the normal (UCI) consent model of openid auth which happens in any case during identity verification), the RP SHOULD consider that the user has just cross-certified that CA cert.

*         Now, if we want to go a bit further, it's obviously trivial in several instances of an AX attribute to even be  communicating each of the user's vanity URLs, to be bound to https endpoints using those certs that the RP has now registered, per openid.

*         If we let the attribute value type of an AX attribute instance be a multi-valued ordered set, we can go even further:  the set can be the very sequence of https redirects that the user has authorized a discovery client to follow, when aiming for the openid and its XRDS.

*         The above obviously recourses, if the XRDS/HTML has delegation settings.

Ok I'm getting a bit fanciful with the later points, but I'm sure in a WG, folks can be simplifying  it all  down, focus on the holes etc.

As to acts of poisoning by third parties, the user is doing above nothing more that wifi https users do today on setting up the routers https admin port - using ALL the main browsers. As the new https CA is encountered, what does the user do? The user sets an override to "register" the new CA in the user's personal root trust list  (on that host, only). With the above procedures , that same set of overrides (and the cert itself) is recorded at the OP in AX attributes, and  is simply communicated  to the SPs of the users choice using openid assertions extended with AX. OpenID's release semantics  act as the "authority" (cross-certification act). Being UCI, the final trust authority is the user.

From: Andrew Arnott [mailto:andrewarnott at gmail.com]
Sent: Sunday, January 04, 2009 8:05 AM
To: Peter Williams
Cc: general at openid.net
Subject: Re: [OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP implementations)

Peter,

These are great resources.  Can you help me understand one issue that I think I see with your initial discovery phase that you explained?

It seems to me that if during discovery the RP is required to (temporarily) accept SSL certs that are not signed by a known good CA, and at the end of discovery or authentication the public keys for these certs are sent from OP to RP so the RP can match each cert it encountered with the known good list from the OP or identifier, (Am I understanding this correctly??) it seems to me a wide open door for someone to DNS poison the RP, redirecting traffic to his own server with his own certs, and his own OP which will send approval messages for those certs.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire

On Sun, Jan 4, 2009 at 1:06 AM, Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>> wrote:

CTLs are not the whole story, but are a good place to start to see where the security constraints in the hosted  environment are imposed by the hoster's core setup. It's also interesting to glimpse from the following how .NET has evolved the trust management framework since the IIS4 days I once knew well, and see how the modern ACS is going further (rant on. in ways that are no longer being enforced solely within the crypto boundary, relying more on trusted systems theory like AuthMan RBAC. rant off).

I'm starting to envy Dick. This modern trust stuff looks like so much fun! Microsoft core platform engineering on crypto has always been classy, though can tend to become somewhat obscure and overly-professionalized - particularly as native code is mapped into the VM, as we see in the first resource:-

http://blogs.msdn.com/gproano/archive/2005/03/22/400645.aspx (fiddling with CTLs programmatically in early .NET)

If GoDaddy has console access, http://www.leastprivilege.com/CertificateBasedAuthenticationAndWCFTransportSecurity.aspx. gives you a start on the core CTL ideas in an IIS context, but is obviously not dynamic.

http://www.leastprivilege.com/SslStreamSample.aspx (lowlevel access to the SSL client library, presumably applying http.sys, with validation callback interface)

WCF model on app-based certificate trust constructs http://www.leastprivilege.com/CertificateBasedAuthenticationAndWCF.aspx

custom validation http://www.leastprivilege.com/CertificateBasedAuthenticationAndWCFMessageSecurity.aspx.

Looks like the peer trust model may be good for an openid ID RP doing what I suggested (to enhance https openid discovery . It can then collect all the asserted certificates from an OP, and then custom validation logic binds a particular cert to the inbound openid, for use next time with a vanity https URL that ultimately resolves during discovery to that OP-provisioned openid (via redirect, via delegation, or whatever)

http://www.leastprivilege.com/FederatingWithLiveIDUsingTheAccessControlService.aspx (modern clue on how folks MAY? address the issue of trust in a .NET host (of which IIS7 is only one option, recall). See notion of ACS. Only relevant to the distant future tho. Will probably be highly relevant to OP/RP white-listing too, tho.

From: general-bounces at openid.net<mailto:general-bounces at openid.net> [mailto:general-bounces at openid.net<mailto:general-bounces at openid.net>] On Behalf Of Andrew Arnott
Sent: Saturday, January 03, 2009 7:06 PM
To: Peter Watkins
Cc: general at openid.net<mailto:general at openid.net>

Subject: Re: [OpenID] The HTTPS in the OpenID (Re: Bug in OpenID RP implementations)

On Sat, Jan 3, 2009 at 4:34 PM, Peter Watkins <peterw at tux.org<mailto:peterw at tux.org>> wrote:

Can't you "just" add the CAs to trusted roots for the Windows account
that the asp.net<http://asp.net> app runs as?

Not while that ASP.NET<http://ASP.NET> app is running with medium trust.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire

On Sat, Jan 3, 2009 at 4:34 PM, Peter Watkins <peterw at tux.org<mailto:peterw at tux.org>> wrote:

Can't you "just" add the CAs to trusted roots for the Windows account
that the asp.net<http://asp.net> app runs as? I supposed it'd be tougher for folks
using integrated auth & impersonation, but I also expect most asp.net<http://asp.net>
webapps doing OpenID auth aren't using impersonation. Similarly, I'd
expect to be able to remove CA certs from the asp.net<http://asp.net> webapp user's
profile in order to shorten the CA whitelist.

I don't know how tough it is to edit the root certs for the profiles of
app pool-type accounts, and hope you'll forgive my not firing up
Studio on a Saturday night to see if there's an obvious API. :-)

On *nix it's usually pretty straightforward -- find the keystore
holding root certs and manipulate it via OpenSSL, Java keytool,
or whatever app is appropriate for the environment. Is it not the
same in Windows?

-Peter

On Sat, Jan 03, 2009 at 03:24:37PM -0800, Andrew Arnott wrote:
> Definitely some interesting thoughts in there.
> I'll add one more: while it makes a sensible default for Microsoft to cause
> .NET connections to HTTPS servers without a signed cert by a known good CA
> to fail, it doesn't seem like it should require the whole machine to trust
> the individual web site if that web site wishes to go ahead and make a
> connection.  Crying out loud: if a partial trust web site can initiate an
> HTTP connection to a random server (which it can, with GoDaddy's small
> deviation to Medium Trust), why couldn't it also open an HTTPS connection in
> order to encrypt the traffic, and decide to be its own judge on the validity
> of that certificate?
>
> I'm going to poke around Microsoft and see if I can't get this policy
> changed so that .NET clients can approve of these certs signed by
> lesser-known CAs.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090104/2826911d/attachment-0002.htm>