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
