I agree that in many cases the RS and AS are in different domains and I
think that OAuth2 explicitly was designed to support that.
I don't see how "sending a token to a bad RS" is a variant of the mix-up
attack.
To me, it's the clients responsibility to send the token to an
appropriate endpoint. In most cases, the RS endpoints are well known and
not discovered (unless we are talking about endpoints like the userinfo
endpoint).
While it's possible to use webfinger to do dynamic RS endpoint
discovery, I haven't seen any real use of that mechanism. What are the
use cases where the client will be confused to send the token to the
wrong RS apart from endpoints obtained via discovery? Also, the client
can always use the refresh_token mechanism to downscope tokens to a
single scope such that exposure is limited (which is the intent of
authorization protection in OAuth2).
If we are trying to solve a use case where tokens are bound to the RS
they are sent to, then we need something other than standard OAuth2. I
don't think we should be trying to solve that problem with these
security mitigations.
Thanks,
George
On 1/27/16 8:30 AM, John Bradley wrote:
It think requiring a common authority segment for the authorization endpoint
and the token endpoint might work in common cases, but there are legitimate
cases where the URI of the Authorization endpoint might be a alias in the case
of multi tenants, all using a common token endpoint.
The larger problem would be the RS, it is not uncommon to have the AS and RS in
different domains, so with bearer tokens unless you make the same authority
restriction for RS then you are not really stoping the attacker. They can get
the AT by impersonating the RS.
I think trying to enforce a common origin policy over OAuth would be a bad
direction to go.
I understand that it seems like a easy fix on the surface, and it works for
most of the things people are using OAuth for today, but would be quite
limiting over the long term.
John B.
On Jan 27, 2016, at 7:31 AM, sakim...@gmail.com wrote:
Hi Hans,
Sorry, I mixed up the IdP mix-up attack and the code phishing attack.
Mandating the Authorization and Token Endpoint being in the same
authority would solve the later without changing the wire protocol.
For AS mix-up attack, mandating the client to change the redirection endpoint
per AS would solve the problem without change the wire protocol.
If these are not possible, then we would have to look at changing the
wire protocol. The solution that solves the both cases must
provide the token endpoint URI authoritatively, which means
you have to mandate some variation of discovery mandatory.
Nat
At 2016-01-27 17:01 Hans Zandbelt wrote:
I don't see how that can deal with the specific form of the attack
where the Client would have sent the authorization request to the
legitimate authorization endpoint of a compromised AS and believes it
gets the response from that, where in fact it was redirected away to
the good AS.
IOW, I don't think this is so much about mixing up endpoints where to
send stuff to, but mixing up the entity/endpoint from which the Client
believes the response was received. That may just be terminology
though.
Bottom line as far as I see is that a wire protocol element in the
response is needed to tell the Client who issued it, regardless of how
the Client deals with configuration of the AS information.
Hans.
On 1/27/16 1:31 AM, Nat Sakimura wrote:
So, is there a lot of cases that the authority section of the Good AS's
Authorization Endpoint and the Token Endpoints are different?
If not, then requiring that they are the same seems to virtually remove
the attack surface for the mix-up related attacks. It does not introduce
new parameter nor discovery. If it can be done, it probably is not worth
adding a new wire protocol element to mitigate the mix-up variants.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Chief Architect
Identity Services Engineering Work: george.fletc...@teamaol.com
AOL Inc. AIM: gffletch
Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544 Photos: http://georgefletcher.photography
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
