Maybe this has been covered elsewhere, but one can see the case where "iss" in
an example is set to "my_auth_server" and that cut/paste gets re-used. That's
also possible even in the OpenID Discovery mechanism, it requires the
implementer to actually pick a unique value. It would be better if this were
not dependent on by-hand configuration.
-bill
On Tuesday, January 12, 2016 8:03 PM, Justin Richer <[email protected]> wrote:
+1 to Brian’s point, and points to Mike for promising to address this. I
wasn’t able to attend the meeting in Darmstadt, but I’ve been following the
discussion and original papers. Let’s take this one piece at a time and not
overreach with a solution.
In particular, the whole “late binding discovery” bit would cause huge problems
on its own. There’s good reason that OpenID Connect mandates that the “iss”
value returned from the discovery endpoint MUST be the same as the “iss” value
coming back from the ID Token, so let’s not ignore that.
— Justin
On Jan 12, 2016, at 5:53 PM, Mike Jones <[email protected]> wrote:
John Bradley and I went over this today and I'm already planning on simplifying
the draft along the lines described. I would have written this earlier but I've
been busy at a NIST meeting today.
John has also stated writing a note about how cut-and-paste does and doesn't
apply here but hasn't finished it yet because he's been similarly occupied.
He's also started writing up the state_hash token request parameter, as he
agreed to do.
Watch this space for the new draft...
Best wishes,
-- MikeFrom:Brian Campbell
Sent:1/12/2016 5:24 PM
To:oauth
Subject:[OAUTH-WG] Mix-Up About The Mix-Up Mitigation
The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations on
them) take advantage of the fact that there's nothing in the OAuth
authorization response to the client's redirect_uri that identifies the
authorization server. As a result, a variety of techniques can be used to trick
the client into sending the code (or token in some cases) to the wrong endpoint.
To the best of my recollection the general consensus coming out of the meetings
in Darmstadt (which Hannes mentioned inOAuth Security Advisory: Authorization
Server Mix-Up) was to put forth an I-D as a simple extension to OAuth, which
described how to return an issuer identifier for the authorization server and
client identifier as authorization response parameters from the authorization
endpoint. Doing so enables the client to know which AS the response came from
and thus avoid sending the code to a different AS. Also, it doesn't introduce
application/message level cryptography requirements on client implementations.
The mitigation draft that was posted yesterday diverges considerably from that
with a significantly expanded scope that introduces OpenID Connect ID Tokens
(sort of anyway) to regular OAuth and the retrieval of a metadata/discovery
document in-between the authorization request and the access token request.
It is possible that my recollection from Darmstadt is wrong. But I expect
others who were there could corroborate my account of what transpired. Of
course, the agreements out of the Darmstadt meeting were never intended to be
the final word - the whole WG would have the opportunity to weigh, as is now
the case. However, a goal of meeting face-to-face was to come away with a good
consensus towards a proposed solution that could (hopefully) be implementable
in the very near term and move thought the IETF process in an expedited manner.
I believe we'd reached consensus but the content of -00 draft does not reflect
it.
I've made the plea off-list several times to simplify the draft to reflect the
simple solution and now I'm doing the same on-list. Simplify the response
validation to just say not to send the code/token back to an AS entity other
that the one identified by the 'iss' in the response. And remove the id_token
and JWT parts that .
If this WG and/or the larger community believes that OAuth needs signed
responses, let's develop a proper singed response mechanism. I don't know if
it's needed or not but I do know that it's a decent chunk of work that should
be conscientiously undertaken independent of what can and should be a simple to
understand and implement fix for the idp mix-up problem.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
