[OpenID] Demo Travel/ retailshop

Andrew Arnott andrewarnott at gmail.com
Mon Apr 27 14:33:27 UTC 2009


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>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]
> Sent: Sunday, April 26, 2009 4:55 PM
> To: Peter Williams
> Cc: SitG Admin; 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>> 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> [
> 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>]
> Sent: Sunday, April 26, 2009 3:53 PM
> To: Andrew Arnott
> Cc: 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>
> http://openid.net/mailman/listinfo/general
> _______________________________________________
> general mailing list
> general at openid.net<mailto:general at openid.net>
> http://openid.net/mailman/listinfo/general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090427/1ab9394e/attachment.htm>


More information about the general mailing list