<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Ah, my typo.</div><div class="">It’s “authorization endpoint”, not “token endpoint”.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">As Sascha suggested, sending some value to the token endpoint would be the solution.</div></div></blockquote><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 2, 2015, at 10:59, nov matake <<a href="mailto:nov@matake.jp" class="">nov@matake.jp</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi all,</div><div class=""><br class=""></div><div class="">I also think this issue doesn’t relate to the implicit flow.</div><div class="">If the attacker can get implicit access_tokens, it’s probably because client redirect_uri is invalid.</div><div class="">In the attack we are discussing here, all information displayed on the consent screen would be valid for the end-user, so that there are no chance for the user to detect the attack.</div><div class=""><br class=""></div><div class="">As Sascha suggested, sending some value to the token endpoint would be the solution.</div><div class="">However, I don’t think sending a secret which is issued in the first discovery response won’t fix the issue.</div><div class="">In that case, the attacker will simply get the secret from the server and bypass it to the original client.</div><div class=""><div class=""><div class=""><div class=""><br class=""></div><div class="">Sending a value which is “static" for the IdP seems solve the issue.</div><div class="">(eg. issuer, token endpoint etc.)</div></div><div class=""><br class=""></div><div class="">Regards,</div><div class="">nov</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 31, 2015, at 13:54, Preibisch, Sascha H <<a href="mailto:Sascha.Preibisch@ca.com" class="">Sascha.Preibisch@ca.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class="">
<div class="">Yes Mike,</div>
<div class=""><br class="">
</div>
<div class="">For the implicit flow there would be no /token endpoint. But if I am not mistaken the discussion was all about the code flow.</div>
<div class=""><br class="">
</div>
<div class="">I think the main goal should be a solution that stops the flow when a client requests an authorization code and not when exchanging it for the access_token. And a solution should also not depend on a client doing various validations.</div>
<div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class="">Sascha</div>
<div class=""><br class="">
</div>
<span id="OLK_SRC_BODY_SECTION" class="">
<div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);" class="">
<span style="font-weight:bold" class="">From: </span>Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net" class="">torsten@lodderstedt.net</a>><br class="">
<span style="font-weight:bold" class="">Date: </span>Friday, October 30, 2015 at 2:36 PM<br class="">
<span style="font-weight:bold" class="">To: </span>Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" class="">Michael.Jones@microsoft.com</a>><br class="">
<span style="font-weight:bold" class="">Cc: </span>Sascha Preibisch <<a href="mailto:sascha.preibisch@ca.com" class="">sascha.preibisch@ca.com</a>>, "<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>" <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>><br class="">
<span style="font-weight:bold" class="">Subject: </span>Re: [Openid-specs-ab] Securing token requests when discovery service is used<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div dir="auto" class="">
<div class=""></div>
<div class="">Hi Mike,</div>
<div class=""><br class="">
</div>
<div class="">is the attack applicable for the implicit grant? I think it would require the attacker to proxy the legitimate OP's authz endpoint, which results in a different URL being displayed in the user agent.</div>
<div class=""><br class="">
</div>
<div class="">kind regards,</div>
<div class="">Torsten.</div>
<div class=""><br class="">
Am 30.10.2015 um 21:14 schrieb Mike Jones <<a href="mailto:Michael.Jones@microsoft.com" class="">Michael.Jones@microsoft.com</a>>:<br class="">
<br class="">
</div>
<blockquote type="cite" class="">
<div class="">
<meta content="text/html; charset=us-ascii" class="">
<div class="">
<div style="font-family:Calibri,sans-serif; font-size:11pt" class="">The other thing that can't be faked by an attacker is the OP's keys. If the ID token isn't signed by the right keys, then the RP knows that there's a problem. This points to a possible solution involving
authenticating the jwks_uri value.<br class="">
<br class="">
Remember also that the Implicit flows don't use a token endpoint. So solutions that involve authenticating the token endpoint won't work for deployments using only Implicit flows.<br class="">
<br class="">
John, Justin, and Nov, when you send in your IIW session notes, can you also please send them here?<br class="">
<br class="">
Thanks,<br class="">
-- Mike</div>
</div>
<div dir="ltr" class="">
<hr class="">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; font-weight: bold;" class="">From:
</span><span style="font-family: Calibri, sans-serif; font-size: 11pt;" class=""><a href="mailto:Sascha.Preibisch@ca.com" class="">Preibisch, Sascha H</a></span><br class="">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; font-weight: bold;" class="">Sent:
</span><span style="font-family: Calibri, sans-serif; font-size: 11pt;" class="">?10/?30/?2015 1:00 PM</span><br class="">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; font-weight: bold;" class="">To:
</span><span style="font-family: Calibri, sans-serif; font-size: 11pt;" class=""><a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a></span><br class="">
<span style="font-family: Calibri, sans-serif; font-size: 11pt; font-weight: bold;" class="">Subject:
</span><span style="font-family: Calibri, sans-serif; font-size: 11pt;" class="">[Openid-specs-ab] Securing token requests when discovery service is used</span><br class="">
<br class="">
</div>
<div class="">
<div class="">
<div style="font-family:Consolas,monospace; font-size:12px" class="">Hi!</div>
<div style="font-family:Consolas,monospace; font-size:12px" class=""><br class="">
</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">Now that IIW is over I would like to bring up my thoughts regarding the</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">session we had with John regarding the discovery service issue.</div>
<div style="font-family:Consolas,monospace; font-size:12px" class=""><br class="">
</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">If I am the 'bad' discovery service provider I can fake all values within</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">the discovery response. Except for the /token endpoint. That has to point</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">to my system in order for me to receive the authorization_code and client</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">credentials.</div>
<div style="font-family:Consolas,monospace; font-size:12px" class=""><br class="">
</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">Therefore I believe there are two solutions:</div>
<div style="font-family:Consolas,monospace; font-size:12px" class=""><br class="">
</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">* the discovery response to the client has to include a secret which has to be included</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">in the initial /authorize request. The authorization server validates the</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">value and fails the request if it is invalid. This of course has the</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">drawback that the authorization server has to keep state. As a server guy</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">I would not like to support this flow</div>
<div style="font-family:Consolas,monospace; font-size:12px" class=""><br class="">
</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">* The better solution I see, and as I mentioned during the discussion, is</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">that the client should include the target /token endpoint as an additional</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">request parameter for the initial /authorize request. The authorization</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">server does a simple string comparison and fails if the /token endpoint is</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">not the one as expected</div>
<div style="font-family:Consolas,monospace; font-size:12px" class=""><br class="">
</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">Regards,</div>
<div style="font-family:Consolas,monospace; font-size:12px" class="">Sascha</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class=""><span class="">_______________________________________________</span><br class="">
<span class="">Openid-specs-ab mailing list</span><br class="">
<span class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a></span><br class="">
<span class=""><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=CwMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=HAtajlQ9KYailZ0S6-Ak9c7gPXdfkuQbjSnW7ZR1PjY&s=_d-STpg0ypM8VMn9WwuHM1zuRMkv-Pk-6wyXP8ax34s&e=" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br class="">
</div>
</blockquote>
</div>
</div>
</span>
</div>
_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class=""><a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></body></html>