<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Yes Mike,</div>
<div><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>Regards,</div>
<div>Sascha</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>><br>
<span style="font-weight:bold">Date: </span>Friday, October 30, 2015 at 2:36 PM<br>
<span style="font-weight:bold">To: </span>Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>><br>
<span style="font-weight:bold">Cc: </span>Sascha Preibisch <<a href="mailto:sascha.preibisch@ca.com">sascha.preibisch@ca.com</a>>, "<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>" <<a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [Openid-specs-ab] Securing token requests when discovery service is used<br>
</div>
<div><br>
</div>
<div>
<div dir="auto">
<div></div>
<div>Hi Mike,</div>
<div><br>
</div>
<div>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><br>
</div>
<div>kind regards,</div>
<div>Torsten.</div>
<div><br>
Am 30.10.2015 um 21:14 schrieb Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>>:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta content="text/html; charset=us-ascii">
<div>
<div style="font-family:Calibri,sans-serif; font-size:11pt">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>
<br>
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>
<br>
John, Justin, and Nov, when you send in your IIW session notes, can you also please send them here?<br>
<br>
Thanks,<br>
-- Mike</div>
</div>
<div dir="ltr">
<hr>
<span style="font-family: Calibri, sans-serif; font-size: 11pt; font-weight: bold;">From:
</span><span style="font-family: Calibri, sans-serif; font-size: 11pt;"><a href="mailto:Sascha.Preibisch@ca.com">Preibisch, Sascha H</a></span><br>
<span style="font-family: Calibri, sans-serif; font-size: 11pt; font-weight: bold;">Sent:
</span><span style="font-family: Calibri, sans-serif; font-size: 11pt;">?10/?30/?2015 1:00 PM</span><br>
<span style="font-family: Calibri, sans-serif; font-size: 11pt; font-weight: bold;">To:
</span><span style="font-family: Calibri, sans-serif; font-size: 11pt;"><a href="mailto:openid-specs-ab@lists.openid.net">openid-specs-ab@lists.openid.net</a></span><br>
<span style="font-family: Calibri, sans-serif; font-size: 11pt; font-weight: bold;">Subject:
</span><span style="font-family: Calibri, sans-serif; font-size: 11pt;">[Openid-specs-ab] Securing token requests when discovery service is used</span><br>
<br>
</div>
<div>
<div>
<div style="font-family:Consolas,monospace; font-size:12px">Hi!</div>
<div style="font-family:Consolas,monospace; font-size:12px"><br>
</div>
<div style="font-family:Consolas,monospace; font-size:12px">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">session we had with John regarding the discovery service issue.</div>
<div style="font-family:Consolas,monospace; font-size:12px"><br>
</div>
<div style="font-family:Consolas,monospace; font-size:12px">If I am the 'bad' discovery service provider I can fake all values within</div>
<div style="font-family:Consolas,monospace; font-size:12px">the discovery response. Except for the /token endpoint. That has to point</div>
<div style="font-family:Consolas,monospace; font-size:12px">to my system in order for me to receive the authorization_code and client</div>
<div style="font-family:Consolas,monospace; font-size:12px">credentials.</div>
<div style="font-family:Consolas,monospace; font-size:12px"><br>
</div>
<div style="font-family:Consolas,monospace; font-size:12px">Therefore I believe there are two solutions:</div>
<div style="font-family:Consolas,monospace; font-size:12px"><br>
</div>
<div style="font-family:Consolas,monospace; font-size:12px">* 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">in the initial /authorize request. The authorization server validates the</div>
<div style="font-family:Consolas,monospace; font-size:12px">value and fails the request if it is invalid. This of course has the</div>
<div style="font-family:Consolas,monospace; font-size:12px">drawback that the authorization server has to keep state. As a server guy</div>
<div style="font-family:Consolas,monospace; font-size:12px">I would not like to support this flow</div>
<div style="font-family:Consolas,monospace; font-size:12px"><br>
</div>
<div style="font-family:Consolas,monospace; font-size:12px">* The better solution I see, and as I mentioned during the discussion, is</div>
<div style="font-family:Consolas,monospace; font-size:12px">that the client should include the target /token endpoint as an additional</div>
<div style="font-family:Consolas,monospace; font-size:12px">request parameter for the initial /authorize request. The authorization</div>
<div style="font-family:Consolas,monospace; font-size:12px">server does a simple string comparison and fails if the /token endpoint is</div>
<div style="font-family:Consolas,monospace; font-size:12px">not the one as expected</div>
<div style="font-family:Consolas,monospace; font-size:12px"><br>
</div>
<div style="font-family:Consolas,monospace; font-size:12px">Regards,</div>
<div style="font-family:Consolas,monospace; font-size:12px">Sascha</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>Openid-specs-ab mailing list</span><br>
<span><a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a></span><br>
<span><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=">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a></span><br>
</div>
</blockquote>
</div>
</div>
</span>
</body>
</html>