<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">I agree that the user needs to go back to the IdP. <div><br></div><div>I was saying the first step of getting the user to the RP can't be OAuth, because it doesn't have enough info.</div><div><br></div><div>I was thinking that the IdP would need to have the user full frame and present some sort of dialog before sending the request to the RP.</div><div>Otherwise the attacker XSRFs the IdP to get to the RP.</div><div><br></div><div>You seem to have another use case where the attacker is cooperating with a bad IdP to log the user into a RP as some 4th party that the attacker controls?</div><div><br></div><div>John<br><div><div>On 2011-10-31, at 9:22 PM, Allen Tom wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi John -<div><br></div><div>I think that there's still an XRSF vulnerability even if the the IdP shows a dialog before generating the assertion.</div><div><br></div><div>The attacker could login to the IdP with the attacker's own account, then go through the flow to see the dialog. The attacker could then click through the dialog and capture the assertion (possibly using a browser extension, or modified client) and then send the assertion to a victim (possibly via IM or email) to have the victim be signed into the RP using the attacker's account.</div>
<div><br></div><div>This is why the RP needs to bounce the browser back to the OP to have the OP verify that the assertion was issued to the same browser before sending the browser back to the RP.</div><div><br></div><div>
I used to think that Login XRSF was not a big deal (who cares if an attacker can get someone else to login as the attacker?) - however there are a few interesting scenarios where a victim could have their privacy compromised.</div>
<div><br></div><div>Allen</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Mon, Oct 31, 2011 at 5:10 PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word">If the IdP is not presenting a dialog then it leaves the user open to XSRF. <div><br>
</div><div>In a code flow you only get code and state from the IdP it is the RP's responsibility to figure out where it came from, so that wouldn't work.</div><div>If you used the Token flow the RP would need to look into the id_token to see where it came from. </div>
<div>That would be a problem for simple clients, because they need the introspection endpoint, and to get that they need to get the issuer from inside the token.</div><div><br></div><div>I think we need a separate API that takes as its parameters:</div>
<div> issuer</div><div> nonce</div><div> hmac of issuer & nonce with client secret.</div><div><br></div><div>That way the RP can tell that the IdP is sending the request and not a 3rd party.</div><div><br></div><div>The RP would do a normal authentication with prompt=none to the issuer.</div>
<div><br></div><div>There is a extra hop.</div><div><br></div><div>We need to identify & authenticate the issuer/IdP somehow in the first step.</div><div><br></div><div>John B.</div><div><div></div><div class="h5"><div>
<br></div><div><br></div><div><br></div><div><div><div>On 2011-10-31, at 5:42 PM, Allen Tom wrote:</div><br><blockquote type="cite">Hi John -<div><br></div><div>Is this the Unsolicited Assertion use case - where the user clicks on a sponsored link hosted on the IdP's site and gets authenticated on the RP's site?</div>
<div><br></div><div>I think we had discussed this at IIW a couple years ago, and the general consensus was that upon receiving an unsolicited positive assertion, the RP would need to redirect the user's browser back to the OP to have the OP re-generate the assertion and resend it back to the RP. </div>
<div><br></div><div>The downside is that the UX would suffer due to the extra round trip.</div><div><br></div><div>Allen</div><div><br></div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Mon, Oct 31, 2011 at 6:56 AM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just a note on a possible idea.<br>
<br>
The when the RP registers a client ID it sets unsolicited_login_url: to some return_url<br>
<br>
The IdP then sends the id_token with nonce set to a time stamp + entropy , and a claim of idp_initiated: true .<br>
<br>
We probably need to restrict this to the code flow.<br>
<br>
RP could then check that the id_token was not generated by XSRF and set it's cookies.<br>
<br>
I don't see a general way that a unmodified RP is going to be able to safely.<br>
<br>
This should probably be an extension.<br>
<br>
John B.<br>_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net" target="_blank">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br></div>
</blockquote></div><br></div></body></html>