[OpenID] Demo Travel/ retailshop

Peter Williams pwilliams at rapattoni.com
Mon Apr 27 16:40:20 UTC 2009


I am NOT encoding the cert chain [assurance] signals into the value of the handle. Handles are just opaque handles (though I've been tempted to break that rule more than once).

In the RP's handle store, I simply store associated "attributes" with the handle - which include the cert chain [hashes] from the https+discovery security context over which the handle was first learned.

The point about the chained hashes is only my paranoia and experimentation. I could and probably should be storing the cert chain, or the EE cert only ; allowing dynamic chain discovery at the time handle is recovered from the store (and thus mesh better with traditional PKI theory, where intermediate certs should be able to rollover or link up to different trust point ...as the RP trust policy evolves). However, being paranoid, the specific chain provided during learning, and whose extension for AIA/CRLDPs I actually followed during learning, is what I bind as attributes to the handle. An entity providing the same cert chain but with a different intermediate CA cert would, for example, count as a different endpoint in this rather paranoid model. If the OCSP responder I used during initial learning is not available when the handle is cited later, I do NOT fallback to CRLs.... the endpoint is considered different to the original endpoint, and the handle cannot be cited (i.e. assertion cannot be relied upon).

Im just being paranoid, and this is done only for experimentation purposes ONLY. I ask myself: in the entirely free form world of UCI trust models,  how one now _superimpose_ more regular assurance constructs as an RP? How can the rigorous security world  enforced by RPs or discovery point complement a mostly unstructured world of millions of UCI OPs, so we get to enjoy new topology and management models in the identity space - and break free of of hub/spoke, NTLM federated trusts, hierarchical PKI, transitive kerberos handoffs....

I'm interested in the openid movement BECAUSE it sets out to be different in the management plane - not because its just another protocol and bit format implementing the same old upper layer security services stuff.



________________________________
From: Andrew Arnott [andrewarnott at gmail.com]
Sent: Monday, April 27, 2009 7:33 AM
To: Peter Williams
Cc: SitG Admin; general at openid.net
Subject: Re: [OpenID] Demo Travel/ retailshop

Hi Peter,

When storing and looking up association secrets, the OP endpoint URI and the association handle together make up the store/lookup mechanism.  I don't do anything with the cert chain's hash sequence. It's an interesting idea.

I'm a bit confused at what you describe you do though.  What HTTPS endpoint's chain hash sequence do you encode into the association handle?  If it's the OP endpoint's, then how can you verify that that same endpoint sent you the assertion when the assertion comes not from the endpoint but from the user agent (via redirect)?  All you have in that case is the OP endpoint URI and assoc_handle.  No connection with the OP that made the assertion from which to get the certificate.  Can you help me understand what I'm missing here?

--
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 Mon, Apr 27, 2009 at 4:57 AM, Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>> wrote:
so out of interest, when designing/building your RP library for .NET, how did you plan for the compromise of the "spoofing secret(s)" from the implementation's key/handle store? Do you leverage other .NET mechanisms for storing secrets?

For the native openid handshake, I decided a long time ago to persist association secrets with a binding to an https endpoint (aka a valid cert chain's hash sequence in the RP's security MIB + HTTPS url path). When handling an assertion, I considered it appropriate to check that the originator's transport endpoint is consistent with the endpoint data persisted with the handle. That is: its not enough for the assertion maker (normally an OP) to merely show knowledge of the secret. I imposed this "SSL handshake assurance" rule to address the nature of openid's native data origin authentication mechanism choice - a specifically duplex, symmetric secret. I essentially reimposed the [missing] properties of cert-based asymmetric key distribution and key derivation by read/write channel by imposing that handling rule.

If we move openid into the PCI audit space, which typically includes a measure of analysis of the strength of and assurance of the security protocols actually in use in the application context, we have to be concerned with the compromise handling properties of the protocol (implementation). Traditionally, a lot of the design of typical upper layer security services is concerned with preparations for the recovery phase of security incidents - not only normal phase handling procedures. If we are really allowed to use _external_ association procedures to support openid assertion authentication -- in lieu of the native procedures -- then each will have particular properties concerning the lifecycle and distribution of (derived) authentication secrets.

________________________________
From: Andrew Arnott [andrewarnott at gmail.com<mailto:andrewarnott at gmail.com>]
Sent: Sunday, April 26, 2009 4:55 PM
To: Peter Williams
Cc: SitG Admin; general at openid.net<mailto:general at openid.net>
Subject: Re: [OpenID] Demo Travel/ retailshop

Sharing your association secret from one RP to another site does not bestow any right other than "now able to forge identity assertions on behalf of the OP and fool the RP".  It makes no difference to the OP what assoc_handle an RP uses as far as determining privileges to access certain attributes.

--
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, Apr 26, 2009 at 4:24 PM, Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com><mailto:pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>>> wrote:

or. im an rp and I give the association secret to my delegated rp-partner, who is now authorizd to ask for non-identity claims (given the restrictions in his RP XRDS and the nature of the association id). Lets recall, from plaxo, external association managers are now legitimate. no reason why one cannot consider oauth to be an "extenrnal" association manager, or a "complementary" association manager between RPs to faciliate rights delegation for non-identity requests/assertions.
________________________________________
From: general-bounces at openid.net<mailto:general-bounces at openid.net><mailto:general-bounces at openid.net<mailto:general-bounces at openid.net>> [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 SitG Admin [sysadmin at shadowsinthegarden.com<mailto:sysadmin at shadowsinthegarden.com><mailto:sysadmin at shadowsinthegarden.com<mailto:sysadmin at shadowsinthegarden.com>>]
Sent: Sunday, April 26, 2009 3:53 PM
To: Andrew Arnott
Cc: general at openid.net<mailto:general at openid.net><mailto:general at openid.net<mailto:general at openid.net>>
Subject: Re: [OpenID] Demo Travel/ retailshop

>Effectively, the RP would be asking an OP "I already know who this
>user is, but I'd like to learn more about them."

Could it be used for "I don't care who this user is, I just want to
learn more about them."?

-Shade
_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net><mailto:general at openid.net<mailto:general at openid.net>>
http://openid.net/mailman/listinfo/general
_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net><mailto:general at openid.net<mailto:general at openid.net>>
http://openid.net/mailman/listinfo/general





More information about the general mailing list