Hi Peter,<br><br>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. <br>
<br>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?<br>
<br clear="all">--<br>Andrew Arnott<br>"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
<br><br><div class="gmail_quote">On Mon, Apr 27, 2009 at 4:57 AM, Peter Williams <span dir="ltr"><<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
________________________________<br>
From: Andrew Arnott [<a href="mailto:andrewarnott@gmail.com">andrewarnott@gmail.com</a>]<br>
Sent: Sunday, April 26, 2009 4:55 PM<br>
To: Peter Williams<br>
Cc: SitG Admin; <a href="mailto:general@openid.net">general@openid.net</a><br>
<div class="im">Subject: Re: [OpenID] Demo Travel/ retailshop<br>
<br>
</div><div class="im">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.<br>
<br>
--<br>
Andrew Arnott<br>
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - Voltaire<br>
<br>
<br>
</div><div class="im">On Sun, Apr 26, 2009 at 4:24 PM, Peter Williams <<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a><mailto:<a href="mailto:pwilliams@rapattoni.com">pwilliams@rapattoni.com</a>>> wrote:<br>
<br>
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.<br>
________________________________________<br>
</div>From: <a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a><mailto:<a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a>> [<a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a><mailto:<a href="mailto:general-bounces@openid.net">general-bounces@openid.net</a>>] On Behalf Of SitG Admin [<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a><mailto:<a href="mailto:sysadmin@shadowsinthegarden.com">sysadmin@shadowsinthegarden.com</a>>]<br>
<div class="im">Sent: Sunday, April 26, 2009 3:53 PM<br>
To: Andrew Arnott<br>
</div>Cc: <a href="mailto:general@openid.net">general@openid.net</a><mailto:<a href="mailto:general@openid.net">general@openid.net</a>><br>
<div class="im">Subject: Re: [OpenID] Demo Travel/ retailshop<br>
<br>
>Effectively, the RP would be asking an OP "I already know who this<br>
>user is, but I'd like to learn more about them."<br>
<br>
Could it be used for "I don't care who this user is, I just want to<br>
learn more about them."?<br>
<br>
-Shade<br>
_______________________________________________<br>
general mailing list<br>
</div><a href="mailto:general@openid.net">general@openid.net</a><mailto:<a href="mailto:general@openid.net">general@openid.net</a>><br>
<div class="im"><a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
_______________________________________________<br>
general mailing list<br>
</div><a href="mailto:general@openid.net">general@openid.net</a><mailto:<a href="mailto:general@openid.net">general@openid.net</a>><br>
<div><div></div><div class="h5"><a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
<br>
</div></div></blockquote></div><br>