Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Impressions

I support keeping those two in a single document. They actually belong to a same class of problem: the problem of accepting an input from an untrusted / un-protected source, i.e., the authorization response. When this vulnerability is applied to the 'state', it opens up the chance of authorization

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Impressions

I think Toresen states it well. The reason we looked at 2 again is that #1 in some of the attacks was being used to leak the code. In some of those cases the attacker had the client credentials and could use the directly to get access tokens. In other cases the attacker doesn’t have the clien

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Impressions

Hi Hannes, #2 is not directly described in the paper but was used to replay the code/token the attacker obtained via #1. In my observation, the discussion in Darmstadt has shown that OAuth (and its built-in mitigations) so far focused on preventing code/token leakage but we lake mitigation fo

[OAUTH-WG] OAuth 2.0 Mix-Up Mitigation: My Impressions

Hi all, when I posted the call for adoption of the 'OAuth 2.0 Mix-Up Mitigation' solution I wasn't expecting such a heavy debate on the list. While the call for adoption is still ongoing I would like to share my view as someone who has to judge consensus in a few days together with Derek. Regard

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

; To: Mike Jones <mailto:michael.jo...@microsoft.com>> > Cc: Hans Zandbelt <mailto:hzandb...@pingidentity.com>>; George Fletcher <mailto:gffle...@aol.com>>; oauth@ietf.org <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation >

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

gffle...@aol.com] *Sent:* Monday, January 11, 2016 10:21 AM *To:* Mike Jones ; oauth@ietf.org *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation Thanks Mike. One question after reading about the different attack vectors and this spec... How are the 'iss' and 'aud' values ret

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation Hi Mike, Isn’t Nat’s "OAuth Response Metadata” spec enough to solve those issues? https://tools.ietf.org/id/draft-sakimura-oauth-meta-05.txt On Jan 12, 2016, at 05:40, Mike Jones mailto:michael.jo...@microsoft.com>> wrote: The specificatio

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

[mailto:gffle...@aol.com] *Sent:* Monday, January 11, 2016 12:13 PM *To:* Mike Jones ; oauth@ietf.org *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation So just to make sure I understand... This specification requires the response from the Authorization Server to an successful /authorize call to

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

gt; From: Hans Zandbelt [mailto:hzandb...@pingidentity.com > <mailto:hzandb...@pingidentity.com>] > Sent: Monday, January 11, 2016 12:34 PM > To: Mike Jones <mailto:michael.jo...@microsoft.com>>; George Fletcher <mailto:gffle...@aol.com>>; oauth@ietf.org <ma

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

: Hans Zandbelt [mailto:hzandb...@pingidentity.com] Sent: Monday, January 11, 2016 12:34 PM To: Mike Jones ; George Fletcher ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation I disagree that validating endpoints "at this step" (which refers to right before making

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

y 11, 2016 12:13 PM *To:* Mike Jones ; oauth@ietf.org *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation So just to make sure I understand... This specification requires the response from the Authorization Server to an successful /authorize call to pass back code=, state= and jwt= (?) or indivi

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Correct From: George Fletcher [mailto:gffle...@aol.com] Sent: Monday, January 11, 2016 12:13 PM To: Mike Jones ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation So just to make sure I understand... This specification requires the response from the Authorization Server to an

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Thanks a bunch, -- Mike *From:*George Fletcher [mailto:gffle...@aol.com] *Sent:* Monday, January 11, 2016 10:21 AM *To:* Mike Jones ; oauth@ietf.org *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation Thanks Mike. One question after reading about the different attack vectors and this spec...

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

d against substitution but "iss" and "client_id" are not. And yes, I absolutely agree that good examples are essential. That's high on my list for the -01 version. Thanks a bunch,

Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Thanks Mike. One question after reading about the different attack vectors and this spec... How are the 'iss' and 'aud' values returned with the 'code' and 'state' parameters. It seems the client needs to verify the endpoints before making the request to exchange the code for a token. If the c

[OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authorization Server Mix-Up. This note announces the publication of the strawman OAuth 2.0 Mix-Up Mitigation draft he mentioned that mitigates the attack