hi John, if you remember I even proposed something along those lines in Darmstadt and it was deemed (with reason) as not enough good protection since the attacker can use a proxy….
regards antonio On Jan 27, 2016, at 2:30 PM, John Bradley <ve7...@ve7jtb.com> 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
