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

["Nat Sakimura" <[e-mail]>]

[case1] Code phishing + cut-n-paste attack 

  [case1a] through BadAS to GoodAS redirect

  [case1b] through tampering the unprotected client access response

  [case1c] through the server log

[case2] Token phishing (in case of implicit flow). 

[case3] Code and Client credential phishing

 

All of these seem to involve the tampering of the unprotected communication. 

If we can secure all the communication, the problem would be solved for all the variants and for those that we still do not know. One way of doing it is to use OAuth JAR and authorization response that includes ID Token, but that’s not possible in many cases as I understand. 

We have to accommodate a measure that is proportionate to the risks. 

 

The risk impact of [case1] is that the code is stolen, and it is used against the client to “login” to the client. The attacker will not have an access to the access token. Is that right? If that is the case, is this a case that we are really concerned of? Is it not out of scope for OAuth? If so, we can punt this case to something like a login protocol such as OpenID Connect. It also has the notion of “issuer” baked in, so there will be less conflict to use the mix-up draft. 

 

The risk impact of [case2] is more OAuth specific. The token is stolen as the token is going to be sent to a rogue resource, and the resource can use that to obtain the resource that was supposed to be only available to the proper client. 

 

The risk impact of [case3] is the most grave among these three. Now the attacker can create his own client that impersonates the compromised client. 

 

OAuth-mix-up

---------------------------

OAuth-mix-up draft gives one way of addressing [case2] by introducing a new concept of “issuer” and “discovery” to RFC6749. It also returns client_id and verifies it in 4.2, but if the BadAS has assigned a same client_id to the client, it does not help. 

 

By comparing the issuer stored in the session (the draft should be explicit about it) with the issuer in the response, the client can find out that the party he is getting the response from is not the one he sent a request to, that communication was compromised/tampered with, provided that the response is not tampered by the attacker in-browser. 

 

Note that the response may still be tampered (e.g., by MITB) so that the issuer can be re-written, in which case the mitigation does not work, but IMHO, we do not have to worry about it here, as with MITB, you can do worse things easier. 

 

One of the issue with this approach is that the central notion of “issuer” is new to the existing servers and clients. The verification rule in 4.1 states “Compare the issuer URL for the authorization server that the client received when it registered at the authorization server”, but in most existing pure OAuth cases, there is no such thing, so you cannot compare. This means that you would have to re-register, and if you are doing that, the per-AS redirect_uri seems to be a much simpler solution. 

 

Also note that this is not a general framework for finding out tainted communication, so it may have other holes. 

 

OAuth-meta

-------------------

OAuth-meta is not designed as a specific fix to the problem. Rather, it was designed as a general framework of providing the meta-data to the responses by leveraging RFC5988 registry. It just happens to mitigate this particular case. 

 

Again, it is not a general framework for finding out tainted communication, so it may have other holes. 

 

Per AS Redirect URI

--------------------------------

This does not involve wire protocol changes. It just adds requirements on the redirect uri. This by far is the simplest solution for [case2] (and [case1]), IMHO. 

 

Again, it is not a general framework for finding out tainted communication, so it may have other holes.

 

(Extended) PKCE

---------------------------------

To begin with, it works only with code flow. There has to be something else to deal with implicit flow. 

 

PKCE binds the authorization request/response to the token request. 

If used with a confidential client, it seems to mitigate the vulnerability. 

John points out that it is not the case. I must be missing something here… but my logic goes like: 

 

 

1.     The good client creates code_challenge-v and code_verifier-v=S256(code_challenge-v) and sends the client_id-v + code_challenge-v + state to the BadAS Authz EP. 

2.     BadAS as a client prepares a code_verifier-b and code_challenge-b=S256(code_verifer-b). 

3.     BadAS redirects to GoodAS with the client_id-v + code_challenge-b + state-v.  

4.     GoodAS stores the code_challenge-b. 

5.     GoodAS returns code-v + state-v to the client’s redirect uri. 

6.     The client finds the AS from the state and sends code-v + code_verifier-v + secret-b to the BadAS token endpoint. Now, code-v and code_verifer-v is phished. 

 

Now the attacker tries to use the code-v and code_verifier-v. 

 

### Case A: 

7.     The BadAS as a client sends client_id-v + … but he does not have client secret for the good client, so it fails. 

 

### Case B: 

8.     The BadAS as a client sends client_id-b + code-v + code_verifier-b + secret-b etc. to GoodAS. 

9.     GoodAS verifies the code_verifier-b is associated with code-v, but that code-v is not associated with client_id-b, so the token request fails. 

 

### Case C: cut-n-paste

10.  The attacker launches cut-n-paste attack by replacing the code-b with code-v. 

11.  The verifiers does not match, so fails. 

 

Please let me know what I am missing. 

 

Nat

 

 

 

 

 

 

--

PLEASE READ :This e-mail is confidential and intended for the

named recipient only. If you are not an intended recipient,

please notify the sender  and delete this e-mail.

 

From: OAuth [mailto:[e-mail]] On Behalf Of John Bradley
Sent: Saturday, February 20, 2016 9:16 PM
To: William Denniss
Cc: [e-mail]
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

 

Inline

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

_______________________________________________
OAuth mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/oauth

 

_______________________________________________
OAuth mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/oauth