Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

[William Denniss <[e-mail]>]

Maybe it's because I wasn't at the Darmstadt meeting so I don't have the
full context, but I don't find draft A
<https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01> to be
all that clear. Here's my review feedback:

Regarding the text "a client may be confused simply because it is receiving
authorization responses from more than one authorization server at the same
redirection endpoint". Even if the client re-uses the same redirection
endpoint, shouldn't state solve this? All incoming responses should have an
outgoing request with a matching state that would identify the
authorization request and therefore authorization server.


For the issue of dynamic discovery and the potential to insert a malicious
discovery document: can the recommendation be to use the hybrid flow of
Connect if you do discovery (and validate the issuer before exchanging the
code)?  Do we need to invent something new for this use-case?

Regarding sections 5 & 6 ("Mitigation Data Sent to the Token Endpoint"),
this describes something that seems similar to what is achieved by PKCE
(RFC7636). Binding information to the authorization code that must be
presented to redeem the code is precisely what PKCE does, and PKCE has
additional security properties. With the PKCE S256 challenge method, the
authorization request and response can leak in their entirety, and yet
still the attacker couldn't exchange the authorization code. Let's just
recommend RFC7636 for this mitigation.

The security researcher documents are only informative references, and yet
the spec seems to rely on them normatively. E.g.:
*  "Mitigating the attacks also relies on the client sending additional
data about the interaction to the token endpoint" (how does this mitigate
the attacks? and what attack exactly?).
*  "a client may be confused simply because it is receiving authorization
responses from more than one authorization server"  (why is the client
confused?)
I would like to see the attacks normatively described in the spec.

For my own knowledge: what are some of the use-cases that are subject to
these attacks? I'm not convinced every RP that talks to more than 1 AS is
at risk today. What are some risky situations that exist which are
mitigated by this draft?



On Fri, Feb 19, 2016 at 9:12 PM, Phil Hunt (IDM) <[e-mail]>
wrote:

> Option A
>
> Phil
>
> > On Feb 19, 2016, at 13:39, Hans Zandbelt <[e-mail]>
> wrote:
> >
> > Option A: I agree with Mike that the complexity and implementation cost
> of Option B will make adoption harder, which was also a concern with the
> first iteration of Option A.
> >
> > To be honest, I'm not sure most people would even understand why the
> complexity would be required and just forget about it. At least with the
> simplicity of the most recent option A they don't have to care, just add
> some simple parameters/checks.
> >
> > And for the record: I've also implemented option A in the
> mod_auth_openidc [1] and lua-resty-openidc [2] clients for Apache and NGINX
> respectively.
> >
> > Hans.
> >
> > [1] https://github.com/pingidentity/mod_auth_openidc
> > [2] https://github.com/pingidentity/lua-resty-openidc
> >
> >> On 2/19/16 9:18 PM, Mike Jones wrote:
> >> Option A.  I have higher confidence that this specification solves the
> >> problems because it was designed during a 4-day security meeting
> >> dedicated to this task by a group of over 20 OAuth security experts,
> >> *including both sets of researchers in Germany who originally identified
> >> the problem*.  This solution has also been implemented and interop
> >> tested by Roland Hedberg, Brian Campbell, and I believe others.  Note
> >> that the reason I am advocating this specification is **not** because
> >> I'm an editor of it; my role was to record in spec language what the
> >> OAuth security experts designed together over the 4-day period in
> Darmstadt.
> >>
> >> I’ll also note that even if Option B also solves the problem, it comes
> >> at significant adoption costs and complexity not found in A.  In
> >> particular, it requires that developers understand support a new “Link
> >> Relation” syntax not used elsewhere in OAuth.  As Nat writes about his
> >> own draft in
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html -
> there
> >> is not a standard JSON syntax for link relations.  He writes “we could
> >> easily create a parallel to it”.  I’d rather we solve the problem using
> >> standard mechanisms already employed in OAuth, rather than risk
> >> bifurcating OAuth in the developer community by unnecessarily
> >> inventing/creating new syntax that is unfamiliar to developers and that
> >> many of them may reject using.
> >>
> >>                                                           -- Mike
> >>
> >> P.S.  Information about the OAuth security meeting can be found at
> >>
> https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit
> >> and
> >>
> https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/edit
> >> .
> >>
> >> -----Original Message-----
> >> From: OAuth [mailto:[e-mail]] On Behalf Of Hannes
> Tschofenig
> >> Sent: Friday, February 19, 2016 11:43 AM
> >> To: [e-mail]
> >> Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for
> >> Adoption
> >>
> >> Early February I posted a mail to the list to make progress on the
> >> solution to the OAuth Authorization Server Mix-Up problem discovered
> >> late last year.
> >>
> >> Here is my mail about the Authorization Server Mix-Up:
> >>
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html
> >>
> >> Here is my mail to the list that tries to summarize the discussion
> >> status and asked a few questions:
> >>
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html
> >>
> >> Unfortunately, my mail didn't lead to the intended success. While there
> >> was some feedback I wasn't getting the desired response.
> >>
> >> In order to move forward I believe we need a working group document that
> >> serves as a starting point for further work in the group*. We have two
> >> documents that provide similar functionality in an attempt to solve the
> >> Authorization Server Mix-Up problem.
> >>
> >> So, here is the question for the group. Which document do you want as a
> >> starting point for work on this topic:
> >>
> >> -- Option A: 'OAuth 2.0 Mix-Up Mitigation' by Mike Jones and John
> Bradley
> >>
> >> Link:
> >>
> >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01
> >>
> >> -- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and
> >> Sascha Preibisch
> >>
> >> Link:
> >>
> >> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07
> >>
> >> Deadline for feedback is March, 4th.
> >>
> >> Ciao
> >>
> >> Hannes & Derek
> >>
> >> PS: (*) Regardless of the selected solution we will provide proper
> >> acknowledgement for those who contributed to the work.
> >>
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > --
> > Hans Zandbelt              | Sr. Technical Architect
> > [e-mail] | Ping Identity
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>