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

[John Bradley <[e-mail]>]

Inline
> On Feb 20, 2016, at 9:49 AM, William Denniss <[e-mail]> wrote:
> 
> 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.

If only that were the case.   That is the nub of the problem people think state works to do that, but it enables the attack not stops it.

State contains where the client sends the request.   The client assumes any response following that is from the AS it sent the request to.  
Most of the attacks documented take advantage of this by misdirecting the request to a different AS than the one the client “thinks” it is making the request to.  

This is done in two ways. One is by pointing at another AS’s authorization endpoint as part of registration, and the other is by redirecting and rewriting the authorization request.

The client thinking it has a response from a AS based on state then uses the associated token and RS endpoints.   Those endpoints are wrong for the AS that really returned the response.   Thus the client becomes a proxy for relaying responses from the target AS.

Both mitigations attempt to mitigate this by having the AS return something that can be compared with state to determine if the request has been misdirected.

In one case we return a logical identifier (Name) for the AS that is compared to a name provided as part of client setup.  This name can optionally be used as the input to discovery to verify other meta-data about the AS.

In the second mitigation the URI of the token endpoint or resource server is returned.

They both provide a way for the client to determine if the stored state is invalid because the response is coming from a different place than the request went to.

It was noted by the researchers that the OIDC flow “code id_token” was not susceptible to this attack because the client validates the issuer of the id_token and the client_id that the AS thinks it is responding to (some of the attacks rewrite the client_id in the request).

For reference http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation <http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation> points 2 & 3 of the OIDC validation.

Knowing that works based on researcher feedback, the first option allows the two id_token claims to be returned from the Authorization endpoint without forcing OAuth clients to support signed JWT.   It also allows AS to provide a issuer URI but allows clients to compare the strings without forcing them to do discovery.   Clients that do discovery can use this value to bootstrap/validate that.   This takes advantage of validation that some clients already perform and applies it to the code response.

The second option from Nat allows the client to compare the token_endpoint URI from configuration to the one in the response.  A difference would indicate that the AS is different, in a similar way to the other option.  

The difference is that the second option doesn’t include the client_id and while I don’t have an attack against that off the top of my head, it was felt that it is a open attack surface and should be closed.  

The other difference is I think more subtle and changes OAuth in the second option (Nat probably argues that would be a good thing).
OAuth to this point assumes that the client is in charge, that the developer configures the endpoints etc via service documentation.
In the authorization request or the AT request the AS has no information about what RS is being used as part of the protocol.

The second option changes that by providing link relationships where each step provides meta data about where to use the result.
The Authorization endpoint points to the token endpoint, the token endpoint points to the resource server and the resource server points to the Authorization endpoint.   To get that to work for a number of uses cases you probably need to tell the authorization endpoint and possibly the token endpoint what resource or resources you want the scopes for.    A given AS might have more than one token endpoint (not common but not precluded,  but something that might happen in multi tenant or other special cases), and if it is using JWT access tokens it may not even know about the given RS.

So to be able to give the meta-data for the next hop the endpoint responding may need more information.

The two mitigations are not incompatible, we could do both.

I do however think that the second one may have architectural side effects that we need to more fully discuss.  
Adding link relation/follow your nose processing to OAuth may be a good thing, but may have impacts that we have not fully thought through yet.

> 
> 
> 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?

As above this would work , but we don;t want to force all OAuth clients to have to deal with JWT.   This would be a fix for Connect if we were only concerned about that.

> 
> 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.
> 
Unfortunately PKCE makes the assumption that attacker cannot modify the request.  In this case the attacker can modify the request. 

PKCE provides protection in cases where the attacker can’t modify the PKCE challenge in the request. 
If the attacker can modify the request then they make a new request in a second browser to get the PKCE challenge and replace the one in the request being modified by that one.

I need to think about it a bit more but there might be a way to do it by defining a new PKCE method. 

If the code_challenge  were a HASH of state || code_verifyer, that would do both.   

The server would need to store state and code_challange.  The client would just calculate the hash over both, but still send the same code_verifier.
( optimization would be for the code_challange == S256 (S256(state) || code_verifier)  that way the AS only needs to store the hash of state)

The attacker can’t change the state in the first request, or the client will reject the response, and because the code_verifyer will be different between the requests the AS would reject the second one because the code_challange will be wrong.

That is more complicated for the client, but would allow you to do it with PKCE with no more crypto than PKCE S256 (the MTI) already requires.

For Asymmetric PKCE the code_challange would be a JWK of the public key and the code_verifier would be a JWS (S256(state) )
(You might want to include code in the JWT but I need to think that through)

So yes unless someone finds a flaw in that logic we may be able to define some PKCE modes to mitigate against cut and paste.
I didn’t think of defining a new PKCE mode at the time.  You should have been at the meeting:)


> 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?

Any RP is at risk if one of the AS it talks to is compromised, it can compromise all of the AS that the client talks to.  That is just not a good design.

Hans did a proof of concept that only required access to the logs of one AS to compromise all AS.

John B.
> 
> 
> 
> On Fri, Feb 19, 2016 at 9:12 PM, Phil Hunt (IDM) <[e-mail] <mailto:[e-mail]>> wrote:
> Option A
> 
> Phil
> 
> > On Feb 19, 2016, at 13:39, Hans Zandbelt <[e-mail] <mailto:[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 <https://github.com/pingidentity/mod_auth_openidc>
> > [2] https://github.com/pingidentity/lua-resty-openidc <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 <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 <https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXzGptU4/edit>
> >> and
> >> https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/edit <https://docs.google.com/document/d/1cRa11EgimnTeJZR1-PUpNRpi_u_EoSpO5NtakVbA_sk/edit>
> >> .
> >>
> >> -----Original Message-----
> >> From: OAuth [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Hannes Tschofenig
> >> Sent: Friday, February 19, 2016 11:43 AM
> >> To: [e-mail] <mailto:[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 <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 <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 <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 <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] <mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >
> > --
> > Hans Zandbelt              | Sr. Technical Architect
> > [e-mail] <mailto:[e-mail]> | Ping Identity
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> _______________________________________________
> OAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth