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

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 19 Feb 2016 20:42:35 +0100

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.

---

From: Mike Jones <[email-masked]>
Date: Fri, 19 Feb 2016 20:18:55 +0000

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:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, February 19, 2016 11:43 AM
To: [email-masked]
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 to the list that tries to summarize the discussion status and asked a few questions:

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:

Link:

-- Option B: 'OAuth Response Metadata' by Nat Sakimura, Nov Matake and Sascha Preibisch

Link:

Ciao

Hannes & Derek

PS: (*) Regardless of the selected solution we will provide proper acknowledgement for those who contributed to the work.

---

From: Hans Zandbelt <[email-masked]>
Date: Fri, 19 Feb 2016 21:39:46 +0100

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
> .
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Hans Zandbelt              | Sr. Technical Architect
[email-masked] | Ping Identity

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Fri, 19 Feb 2016 22:12:19 -0700

Option A

Phil

> On Feb 19, 2016, at 13:39, Hans Zandbelt <[email-masked]> 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.
>

---

From: William Denniss <[email-masked]>
Date: Sat, 20 Feb 2016 00:49:08 -0800

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) <[email-masked]>
wrote:

> mod_auth_openidc [1] and lua-resty-openidc [2] clients for Apache and NGINX
> respectively.
> >
> > Hans.
> >

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 20 Feb 2016 10:46:52 +0100

Just a quick reply to two of your remarks:

On 02/20/2016 09:49 AM, William Denniss wrote:
> The security researcher documents are only informative references

I think they should be informative references since the motivate the
reason for doing the work but there is nothing in these publications
that raises interoperability concerns.

I believe the solution documents need to be descriptive enough that they
explain the threats so that a reader who does not read through the
informative reference section still understands what's going on.

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

This is something I criticized in my review as well. IMHO the documents
could do a better job in describing the threats and particularly the
assumptions that need to hold in order for the attacks to work. Without
those it will be difficult to inform readers when this is a concern and
what level of risk this represents.

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Sat, 20 Feb 2016 09:52:43 +0000

We can and will bring more of the threat descriptions into the full document.  For what it's worth, in the initial versions we referenced the German researcher's threat descriptions but intentionally didn't try to repeat them in detail in the spec, so that people would read their research publications if they wanted to know more.  The researchers did the hard work to discover the problems and deserved credit for them.

Have you read both of their publications?  If not, do yourself a favor and do.  They're actually both very readable and quite informative.

				Cheers,
				-- Mike

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Saturday, February 20, 2016 1:47 AM
To: William Denniss <[email-masked]>; Phil Hunt (IDM) <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

> The security researcher documents are only informative references

I think they should be informative references since the motivate the reason for doing the work but there is nothing in these publications that raises interoperability concerns.

I believe the solution documents need to be descriptive enough that they explain the threats so that a reader who does not read through the informative reference section still understands what's going on.

> 1 AS is at risk today. What are some risky situations that exist which 
> are mitigated by this draft?

This is something I criticized in my review as well. IMHO the documents could do a better job in describing the threats and particularly the assumptions that need to hold in order for the attacks to work. Without those it will be difficult to inform readers when this is a concern and what level of risk this represents.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 20 Feb 2016 11:24:42 +0100

Hi Mike,

On 02/20/2016 10:52 AM, Mike Jones wrote:
> Have you read both of their publications?  If not, do yourself a
> favor and do.  They're actually both very readable and quite
> informative.

I have read both documents. In context of this discussion the question
is whether we

(a) require them to be read (in which case they should be a normative
reference), or
(b) suggest them to be read (since they provide additional background
information). In this case they are an informative reference.

I believe believe we want (b) for the OAuth WG document. While I
encourage everyone to read the publications I also believe that there is
lots of material in there that goes beyond the information our audience
typically reads (such as the text about the formal analysis).

There is probably also a middle-ground where we either copy relevant
text from the papers into the draft or reference specific sections that
are "must-read".

One other issue: I actually thought that the threat that is outlined in
the research paper is sufficiently well described but the second threat,
which is called 'cut-and-paste attack', requires more work.
I noted this in my summary mail to the list, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html

Ciao
Hannes

---

From: Mike Jones <[email-masked]>
Date: Sat, 20 Feb 2016 10:41:05 +0000

Suggesting that they be read is of course, the right long-term approach.  But as someone who spent 20+ years as a researcher before switching to digital identity, I was sensitive to not wanting to upstage their work by copying too much of their material into our draft before their publications were widely known.  I'll of course commit to working the researchers and the working group to create a self-contained concise description of the threats and mitigations in the working group document.

				Cheers,
				-- Mike

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Saturday, February 20, 2016 2:25 AM
To: Mike Jones <[email-masked]>; William Denniss <[email-masked]>; Phil Hunt (IDM) <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Hi Mike,

On 02/20/2016 10:52 AM, Mike Jones wrote:
> Have you read both of their publications?  If not, do yourself a favor 
> and do.  They're actually both very readable and quite informative.

I have read both documents. In context of this discussion the question is whether we

(a) require them to be read (in which case they should be a normative reference), or
(b) suggest them to be read (since they provide additional background information). In this case they are an informative reference.

I believe believe we want (b) for the OAuth WG document. While I encourage everyone to read the publications I also believe that there is lots of material in there that goes beyond the information our audience typically reads (such as the text about the formal analysis).

There is probably also a middle-ground where we either copy relevant text from the papers into the draft or reference specific sections that are "must-read".

One other issue: I actually thought that the threat that is outlined in the research paper is sufficiently well described but the second threat, which is called 'cut-and-paste attack', requires more work.
I noted this in my summary mail to the list, see http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html

Ciao
Hannes

---

From: John Bradley <[email-masked]>
Date: Sat, 20 Feb 2016 13:16:12 +0100

Inline
> On Feb 20, 2016, at 9:49 AM, William Denniss <[email-masked]> 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?)
> 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) <[email-masked] <mailto:[email-masked]>> wrote:
> Option A
> 
> Phil
> 
> > On Feb 19, 2016, at 13:39, Hans Zandbelt <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > [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>
> >
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html <http://www.ietf.org/mail-archive/web/oauth/current/msg15789.html> - there
> >> 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>
> >> .
> >>
> >> From: OAuth [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Hannes Tschofenig
> >> To: [email-masked] <mailto:[email-masked]>
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html <http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html>
> >>
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html <http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html>
> >>
> >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 <https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01>
> >>
> >> https://tools.ietf.org/html/draft-sakimura-oauth-meta-07 <https://tools.ietf.org/html/draft-sakimura-oauth-meta-07>
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >
> > --
> > [email-masked] <mailto:[email-masked]> | Ping Identity
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: "Nat Sakimura" <[email-masked]>
Date: Mon, 22 Feb 2016 17:22:10 +0900

[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:[email-masked]] On Behalf Of John Bradley
Sent: Saturday, February 20, 2016 9:16 PM
To: William Denniss
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Inline

On Feb 20, 2016, at 9:49 AM, William Denniss <[email-masked] <mailto:[email-masked]> > wrote:

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

 

 

John B.

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

Option A

Phil

>> From: OAuth [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Hannes Tschofenig

---

From: John Bradley <[email-masked]>
Date: Mon, 22 Feb 2016 13:08:35 +0100

Inline

> On Feb 22, 2016, at 9:22 AM, Nat Sakimura <[email-masked]> wrote:
> 
> [case1] Code phishing + cut-n-paste attack  <>

In this case with OAuth the information protected by the AT can still be stolen.  While the attacker doesn’t get the AT directly it gets control of a client that has the AT.   If I link my Flikr account to your private Flikr feed, you as the Resource owner is still compromised.   Arguing that OAuth didn’t leak the token is not a good argument.   OAuth needs to protect against this.

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

Client_id are not guaranteed to be unique.  They need to be name spaced by the AS.   In OAuth currently we have no name for the AS this makes that difficult, the client can use the authorization endpoint URI, but that logic may well break in multi tenant situations.   Having a clear issuer string makes it easier for the client.  
> 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…

Yes
> 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 wi…

Yes
> 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 authorizat…

The client developers I have talked to really hate per AS redirect URI as being too awkward for deployments.  

The client would not need to re register to add a issuer URI to its client_id record.   That is one of the ways to do it.
> Also note that this is not a general framework for finding out tainted communication, so it may have other holes. 

Without sending the resource in the request, the Authorization endpoint, and token endpoints are not necessarily going to be able to return the correct next hop.

My biggest concern is that this potentially moves some of the client logic into the AS.   I don’t know that that is a bad thing but it feels to me like a real change to OAuth as it currently is.   I think we need to really think about this change, and how it will impact OAuth overall.  

I see this as potentially complimentary OAuth mix up returning a logical name for the AS.

> Per AS Redirect URI

This is probably the hardest for the client developer and for the deployer.  Yes it is simplest from a spec point of view. 
We need more developer feedback on this.

> (Extended) PKCE

In a step 0 the attacker has the good client create another request in the attackers user agent to get state-0 and code_challange-0

Step 2 is not required.
Step 3 Bad AS redirects to good AS with client_id_v + state-v + code_challenge-0
Step 4 GoodAS stores code_challenge-0
Step 5 GoodAS returns code-v + state-v to the clients redirect_uri
Step 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. 

Case C1 :  cut and paste
10.  The attacker launches cut-n-paste attack by inserting code-v into a response using state-0
11. The client sends code-v and based on state-0 it sends code_verifyer-0 to the good AS token endpoint.
12. The GoodAS verifies that code-verifyer-0 is correct for code_challange-0 that it bound to code in step 4
13. The GoodAS receives RT + AT.
14. The attacker has now used the client to bind the users resource to it’s account and is transferring money or looking at your data.

This could be 3rd party financial app like Mint as an example or photos or any other PII that could then be used to escalate identity theft.

This variation of the attack combining cut and paste with confused client was not mentioned in the research papers.

I found it looking to see if PKCE could be used to mitigate the confused client attack.

As I mentioned in a response to William, while the current PKCE Challenge methods only make the attack harder by forcing the attacker to get the client to make a step 0 request to get a code_challenge to use in the request,  we could define a new challenge method that would be effective.

That would remove the need to have a separate mechanism to prevent cut and paste.

The problem is that the PKCE challenge is independent of state so becomes vulnerable to the confused client.

What we would need to do is include state in the challenge so that if the AS receives mismatched state and code_challange in step 3 the verification of code verifier will fail. Effectively combining the cut and paste mitigation with PKCE.

I haven’t had time to write this up, but if the code_challenge == SHA256 (SHA256(state) || token_endpoint URI || Authorization_endpoint URI || client_id || code-veriyer) ,  then the attacker could not change state, client_id, or token_endpoint  independently of code_challenge.  (note I am using a hash of state to make storage size deterministic for the AS on the grounds that the client already needs to be able to do the hash) (Some attacks  change the client_id in the request so I am including it in the hash)

This is slightly more complicated than than S256, but not that much.  I wish I had thought of this when we were doing PKCE.   Hit me with the stupid stick, my fault.

I don’t know if it stops all the confused client attacks though.

If the client is confidential then it gives up it’s client secret assuming compromised registration, so we can’t really count on that for symmetric client authentication.

By including the token endpoint in the comparison if the client is sending the code to the attacker the client will use a different token endpoint_uri in to calculate the code_challenge than the GoodAS will use to verify it.    This would stop both cut and paste as well as stopping the attacker from using the code if they get it.   The attacker can’t get Secret for state-0, so it can’t create code_challenge that would be valid.

This stops the registration attack where the client gets a bad AS discovery endpoint that has all the Good AS info including dynamic registration endpoint but the bad AS token endpoint.   The bad AS would get the token, client_secret and code_verier, but will fail pkce verification because the token endpoint will be wrong.

The attack where the client registers with the good AS but with bad token endpoint and Authorization endpoint gives the attacker the ability to change the code_challenge that the Good AS is going to see.   It would need to make a new challenge using state and the GoodAS token endpoint and it’s client_id.   
To do that it needs the code_verifier to use to calculate the hash to use as the code_challenge value.  As long as the client is not tricked into accepting a replay of the authentication response we should be safe.  The client would need to do replay protection on the code_verifier values before it makes a request to the token endpoint.  

The BadAS could however make up a new code_challenge and code_verifier and use that in the request. For this one the AS would need to do pull discovery on the client to get a key, or the AS needs to return something in the response.  This attack can completely proxy all the endpoints as far as the client is concerned and is taking advantage of the AS saying you are granting permission to site X based on the redirect URI.  

I can’t see PKCE on it’s own being able to stop a client from being used as a redirector back to the attacker unless you also returned the code_challenge in the response from the authorization endpoint.

Hypothetically if we returned code_challenge in the response from the authorization endpoint and have a new PKCE challenge method we might find it covers all of the attacks.

We would need to put some serious analysis into this to see if it really covers all the attacks. 

It however doesn’t address the “token” response_type or steeling the access token by impersonating the RS. 

I think the correct way to stop the problem with access tokens is by audience restricting them.  
To do that the client needs to provide an audience in it’s request and the AS needs to include that in the AT.

I included the Authorization_endpoint URI in the hash to detect if the auth request may have been tampered with to change the audience for the AT.

For implicit we could have a version of PKCE where the AS returns a parameter with S256( client_id || authorization_endpoint URI || resource endpoint URI) to verify the request was not tampered with, and that would allow the AT to be properly audience restricted. 

This would be a completely new approach not involving discovery, logical names for AS, or link relations.

Effectively this code_challenge method becomes a signature over parts of the request and the implicit audience of the token_endpoint URI.  

People keep asking why PKCE doesn’t stop these attacks, and it won’t with the current PKCE methods,  however a new method along the lines I sketched out may let it work, or I could be completely wrong.

Too bad I don’t think I will make RSA to go over this in person.

John B.

>> 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 to be all that clear. Here's my review feedback:
>>  
>> On Fri, Feb 19, 2016 at 9:12 PM, Phil Hunt (IDM) <[email-masked]> wrote:
>>> Option A
>>> 
>>> Phil
>>>

---

From: William Denniss <[email-masked]>
Date: Mon, 22 Feb 2016 21:56:14 -0800

Thank you for the very detailed answers John. I like the idea of adding a
new challenge method to PKCE. This is the sort of thing PKCE was designed
for, so reusing that and adding a bit of logic to the code
generation/verification methods, as opposed to more extensions to the OAuth
protocol seems wise. Pity we didn't think of it at the time, and yes I wish
I could have attended the Darmstadt meeting. IETF95 should be a good chance
to hash out some of these things though (no pun intended)!

I agree with the assumption that from a client ease of implementation
perspective, they may wish to re-use the redirection endpoint. It's not the
best approach, but I fear it may be hard forcing people to change.

Regarding "Without sending the resource in the request, the Authorization
endpoint, and token endpoints are not necessarily going to be able to
return the correct next hop."  I'm inclined to agree, but I'll note that
the metadata spec can be used without the resource server bits: I do think
that the AS should know the token endpoint and be able to return that (it's
equiv to issuer -> discovery anyway), and I've always felt that this was a
pretty elegant idea (mix up mitigation or not).  I also think that perhaps
the two drafts can remain separate as they are not directly trying to solve
the same problem.

I strongly believe that the mix-up spec needs to normatively state the
attacks that are being mitigated. I've read the research papers (which I
agree should remain "informative"), yet this spec doesn't mitigate all the
issues (or does it?). It's really hard as a reviewer to verify that the
"Mix Up Mitigation" draft actually mitigates what it claims to, when it
doesn't clearly state what the issue is in normative terms.

I also wonder if the spec could be re-titled and focus on use-case that it
solves (supporting multiple ASes without using Connect), rather than the
attack it mitigates. I like that the metadata draft is targeted to solve a
particular use-case, while mitigating some attacks the process.

On Mon, Feb 22, 2016 at 4:08 AM, John Bradley <[email-masked]> wrote:

> 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.
> 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.
>
>
> In this case with OAuth the information protected by the AT can still be
> stolen.  While the attacker doesn’t get the AT directly it gets control of
> a client that has the AT.   If I link my Flikr account to your private
> Flikr feed, you as the Resource owner is still compromised.   Arguing that
> OAuth didn’t leak the token is not a good argument.   OAuth needs to
> protect against this.
>
>
> 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.
>
>
> Client_id are not guaranteed to be unique.  They need to be name spaced by
> the AS.   In OAuth currently we have no name for the AS this makes that
> difficult, the client can use the authorization endpoint URI, but that
> logic may well break in multi tenant situations.   Having a clear issuer
> string makes it easier for the client.
>
>
> 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.
>
>
> Yes
>
>
> 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.
>
>
> Yes
>
>
> 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.
>
>
> The client would not need to re register to add a issuer URI to its
> client_id record.   That is one of the ways to do it.
>
>
> 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.
>
>
> Without sending the resource in the request, the Authorization endpoint,
> and token endpoints are not necessarily going to be able to return the
> correct next hop.
>
> My biggest concern is that this potentially moves some of the client logic
> into the AS.   I don’t know that that is a bad thing but it feels to me
> like a real change to OAuth as it currently is.   I think we need to really
> think about this change, and how it will impact OAuth overall.
>
> 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.
>
>
> This is probably the hardest for the client developer and for the
> deployer.  Yes it is simplest from a spec point of view.
> 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.
> 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.
>
> 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:
> 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
> In a step 0 the attacker has the good client create another request in the
> attackers user agent to get state-0 and code_challange-0
>
> Step 2 is not required.
> Step 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.
>
> Case C1 :  cut and paste
> 12. The GoodAS verifies that code-verifyer-0 is correct for
> code_challange-0 that it bound to code in step 4
> 14. The attacker has now used the client to bind the users resource to
> it’s account and is transferring money or looking at your data.
>
> This could be 3rd party financial app like Mint as an example or photos or
> any other PII that could then be used to escalate identity theft.
>
> This variation of the attack combining cut and paste with confused client
> was not mentioned in the research papers.
>
> As I mentioned in a response to William, while the current PKCE Challenge
> methods only make the attack harder by forcing the attacker to get
> the client to make a step 0 request to get a code_challenge to use in the
> request,  we could define a new challenge method that would be effective.
>
> What we would need to do is include state in the challenge so that if the
> AS receives mismatched state and code_challange in step 3 the verification
> of code verifier will fail. Effectively combining the cut and paste
> mitigation with PKCE.
>
> I haven’t had time to write this up, but if the code_challenge == SHA256
> (SHA256(state) || token_endpoint URI || Authorization_endpoint URI ||
> client_id || code-veriyer) ,  then the attacker could not change state,
> client_id, or token_endpoint  independently of code_challenge.  (note I am
> using a hash of state to make storage size deterministic for the AS on the
> grounds that the client already needs to be able to do the hash) (Some
> attacks  change the client_id in the request so I am including it in the
> hash)
>
> This is slightly more complicated than than S256, but not that much.  I
> wish I had thought of this when we were doing PKCE.   Hit me with
> the stupid stick, my fault.
>
> If the client is confidential then it gives up it’s client secret assuming
> compromised registration, so we can’t really count on that for symmetric
> client authentication.
>
> By including the token endpoint in the comparison if the client is sending
> the code to the attacker the client will use a different token endpoint_uri
> in to calculate the code_challenge than the GoodAS will use to verify it.
>  This would stop both cut and paste as well as stopping the attacker from
> using the code if they get it.   The attacker can’t get Secret for state-0,
> so it can’t create code_challenge that would be valid.
>
> This stops the registration attack where the client gets a bad AS
> discovery endpoint that has all the Good AS info including dynamic
> registration endpoint but the bad AS token endpoint.   The bad AS would get
> the token, client_secret and code_verier, but will fail pkce verification
> because the token endpoint will be wrong.
>
> The attack where the client registers with the good AS but with bad token
> endpoint and Authorization endpoint gives the attacker the ability
> to change the code_challenge that the Good AS is going to see.   It would
> need to make a new challenge using state and the GoodAS token endpoint and
> it’s client_id.
> To do that it needs the code_verifier to use to calculate the hash to use
> as the code_challenge value.  As long as the client is not tricked into
> accepting a replay of the authentication response we should be safe.  The
> client would need to do replay protection on the code_verifier values
> before it makes a request to the token endpoint.
>
> The BadAS could however make up a new code_challenge and code_verifier
> and use that in the request. For this one the AS would need to do pull
> discovery on the client to get a key, or the AS needs to return something
> in the response.  This attack can completely proxy all the endpoints as far
> as the client is concerned and is taking advantage of the AS saying you are
> granting permission to site X based on the redirect URI.
>
> I can’t see PKCE on it’s own being able to stop a client from being used
> as a redirector back to the attacker unless you also returned the
> code_challenge in the response from the authorization endpoint.
>
> Hypothetically if we returned code_challenge in the response from the
> authorization endpoint and have a new PKCE challenge method we might find
> it covers all of the attacks.
>
> I included the Authorization_endpoint URI in the hash to detect if the
> auth request may have been tampered with to change the audience for the AT.
>
> For implicit we could have a version of PKCE where the AS returns a
> parameter with S256( client_id || authorization_endpoint URI || resource
> endpoint URI) to verify the request was not tampered with, and that would
> allow the AT to be properly audience restricted.
>
>
> Effectively this code_challenge method becomes a signature over parts of
> the request and the implicit audience of the token_endpoint URI.
>
> People keep asking why PKCE doesn’t stop these attacks, and it won’t with
> the current PKCE methods,  however a new method along the lines I sketched
> out may let it work, or I could be completely wrong.
>
> From: OAuth [mailto:[email-masked] <[email-masked]>] On
> Behalf Of John Bradley
> full context, but I don't find draft A 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.
>
> 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.
>
> 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.
>
>
>
>
> 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.
>
>
>
> additional security properties. With the PKCE S256 challenge method,
> the authorization request and response can leak in their entirety, and yet
> Unfortunately PKCE makes the assumption that attacker cannot modify the
> request.  In this case the attacker can modify 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.
>
> 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) )
> 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.
> 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.
>
> >> From: OAuth [mailto:[email-masked] <[email-masked]>]
> On Behalf Of Hannes Tschofenig

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 23 Feb 2016 08:05:50 +0000

hi,

FWIW I also find Option A easier to understand/implement.

regards

antonio

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 23 Feb 2016 11:09:31 +0200

Hi Mike,

You mention that you spent considerable time in research. I wonder if
there is existing theory, in communications or information theory, that
can be used to formally establish and prove (or disprove) the security
of the proposed OAuth measures? Perhaps some work that is totally
unrelated to identity and the web protocols, but could well apply here?

My reasoning is that we have a closed system that is fairly simple, so
formal analysis must be entirely possible.

1. We have 5 parties (client, AS, RS, user, user agent).

2. The OAuth protocol follows a simple and well-defined pattern of
messages between the parties.

3. The points and the number of ways by which an adversary may break
into OAuth must therefore be finite.

4. The security requirement is essentially to guarantee the precedence
and authenticity of the messages from discovery endpoint to RS, and the
preferred way to do that is by establishing a binding between the
messages, which can be forward or backward binding.

Right now the WG concern is whether all possible attacks have been
recognised, and then taken care of. If we can have a formal model that
can reliably reveal and prove that, this will be a huge breakthrough.

Cheers,

Vladimir

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: Daniel Fett <[email-masked]>
Date: Tue, 23 Feb 2016 11:28:07 +0100

Hi Valdimir,

this is exactly what we did in our research paper. We also analyzed and
established a proof of security for one of the proposed mitigations.

Of course, any proof always depends on some assumptions (e.g., no
untrusted third-party code on RP's web site) and aims at specific
security properties.

As you can see from the paper, due to the web itself being complex, the
analysis is also rather lengthy.

In the related work section we also refer to other approaches of
formally analyzing web protocols. We do not think that approaches
"unrelated to web protocols" can produce useful results, because the web
brings many very specific features and constraints.

Cheers,
Daniel

-- 
Informationssicherheit und Kryptografie
Universität Trier - Tel. 0651 201 2847 - H436

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 23 Feb 2016 14:35:04 +0200

This sounds fantastic, Daniel. I was only aware of the work by the
researchers from RUB.de about the CSRF attack on OIDC discovery. I'm
reading the paper right now and want to take some time off to study it
in more detail.

Congratulations for doing this,

Vladimir

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 23 Feb 2016 17:00:16 +0200

> particular use-case, while mitigating some attacks the process.
I find this reframing an excellent idea. Today I shared the draft with a
few client devs I know. Starting from the use case makes it easier to
decide when you need to act (as opposed to figuring out what the attack
is and then why you need to act).

Does your client need to support more than one AS? Ok, then do this ...
because -> see security considerations.

Vladimir

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 23 Feb 2016 17:29:33 +0200

Comment starts at line 173 :)

> Too bad I don’t think I will make RSA to go over this in person.

If PKCE with a new mode manages to fix everything, that would be great!

I'm just reframing the essence of the proposed solution, as I roughly
understood it:

1. The mix-up attack causes the client to be set up with compromised
endpoints. There are 3 ways to prevent that:

a) by letting the client submit a signature of the setup endpoints to
the AS, via new PKCE mode, or version of PKCE for implicit.
b) by letting each AS response hint the URL for the next hop
c) by a combination of a & b

=> a) is best because it's just one extra param, the hash is of fixed
size and relatively short

2. The confusion attack is made possible when using more than one AS.
There are 3 ways to prevent that:

a) by requiring separate redirect_uri for each AS
b) by returning the client_id in the AS response

b) is best because it can be combined with the mix-up attack prevention
via new PKCE mode.

If multiple resource URIs are to be included in the hash, how do we make
the order predictable?

Vladimir

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 23 Feb 2016 17:15:27 +0000

Hi

Some OAuth2 providers may return self-contained access tokens which are 
JWS Compact-encoded.
I wonder is it really a good idea and would it not be better to only 
JWE-encrypt the tokens. I'm not sure JWS signing the claims is 
necessarily faster then only encrypting the claims, assuming the 
symmetric algorithms are used in both cases.

For example, my colleague and myself, while dealing with the issue 
related to parsing an access token response from a 3rd party provider 
were able to easily check the content of the JWS-signed access_token by 
simply submitting an easily recognized JWS Compact-formatted value (3 
dots) into our JWS reader - we did not have to worry about decrypting it 
neither the fact we did not validate the signature mattered.

But access tokens are opaque values as far as the clients are concerned 
and if the introspection is needed then the introspection endpoint does 
exist for that purpose...

Thanks, Sergey

---

From: Antonio Sanso <[email-masked]>
Date: Tue, 23 Feb 2016 19:31:41 +0000

hi Sergey,
just my 2 cents
let’s start from a simple fact that encryption is not authentication. :)

Now, if the claim sets of a JWS contains only not confidential information JWS is enough.

See also inline

On Feb 23, 2016, at 6:15 PM, Sergey Beryozkin <[email-masked]> wrote:

> Hi
> 
> Some OAuth2 providers may return self-contained access tokens which are JWS Compact-encoded.
> I wonder is it really a good idea and would it not be better to only JWE-encrypt the tokens. I'm not sure JWS signing the claims is necessarily faster then only encrypting the claims, assuming the symmetric algorithms are used in both cases.

JWE algorithms are all AEAD AFAIK so is not only symmetric encryption plus there is the content key  "wrap algorithm”.

regards

antonio

> 
> For example, my colleague and myself, while dealing with the issue related to parsing an access token response from a 3rd party provider were able to easily check the content of the JWS-signed access_token by simply submitting an easily recognized JWS Compact-formatted value (3 dots) into our JWS reader - we did not have to worry about decrypting it neither the fact we did not validate the signature mattered.
> 
> But access tokens are opaque values as far as the clients are concerned and if the introspection is needed then the introspection endpoint does exist for that purpose...
> 
> Thanks, Sergey
> 
> 
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 23 Feb 2016 21:41:40 +0200

Hi Sergey,

JWE will indeed make the token content confidential to clients. However,
without a proper signature (RSA or EC, HMAC in JWS doesn't qualify), the
RS cannot establish the origin of the token. With symmetric crypto (e.g.
JWE alg=dir) anyone who has the shared key will be able to create a
token (e.g. other RS in the domain that rely on the AS). With asymmetric
crypto, anyone with access to the public key of the RS will be able to
encrypt for the recipient.

Hope this helps,

On 23/02/16 19:15, Sergey Beryozkin wrote:
> were able to easily check the content of the JWS-signed access_token
> by simply submitting an easily recognized JWS Compact-formatted value
> (3 dots) into our JWS reader - we did not have to worry about
> decrypting it neither the fact we did not validate the signature
> mattered.
>
> But access tokens are opaque values as far as the clients are
> concerned and if the introspection is needed then the introspection
> endpoint does exist for that purpose...
>
> Thanks, Sergey
>
>
>

---

From: Roland Hedberg <[email-masked]>
Date: Tue, 23 Feb 2016 20:59:19 +0000

In line !

> 22 feb 2016 kl. 05:08 skrev John Bradley <[email-masked]>:
> 

I stumbled over exactly this point when I made my implementation follow the Mix-Up draft.
If not discovery is involved I think an AS has to have a name which is different from the endpoint URIs.

> The client developers I have talked to really hate per AS redirect URI as being too awkward for deployments.

I on the other hand found it quite easy to do per AS redirect URIs, so it might well be implementation
dependent rather then contextual.

> We need more developer feedback on this.

As I said above I found this quite simple to implement.

> People keep asking why PKCE doesn’t stop these attacks, and it won’t with the current PKCE methods,  however a new method along the lines I sketched out may let it work, or I could be completely wr…

Once you have written down something more definite I promise to implement it promptly such that we can do interop
testing early in the process.

Before John brought up this new PKCE mode I was on the Option A side of the fence now I’d like to see more
of this PKCE idea before committing to one or the other.

— Roland

”Everybody should be quiet near a little stream and listen."
From ’Open House for Butterflies’ by Ruth Krauss

---

From: Sergey Beryozkin <[email-masked]>
Date: Tue, 23 Feb 2016 21:54:20 +0000

Hi
> let’s start from a simple fact that encryption is not authentication. :)
And since then the access tokens are supposed to provide the source 
guarantee to the client ? Can you point to any text somewhere suggesting 
the clients must expect the access tokens be a set of JWT JWS signed 
claims ? (lets put the whole PoP aside for now...)

> Now, if the claim sets of a JWS contains only not confidential information JWS is enough.
You are right - this is close to what I was asking about. My point is 
that given that a JWS-signed JWT content can be processed as easily as 
Base64 encoded data, the problems will start happening if a given OAuth2 
server inadvertently puts more into this JWT container than it should...

Thanks Sergey

-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 23 Feb 2016 23:08:47 +0000

I would go with option A, option B introduces concepts/syntax that complicates the current Oauth model

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Friday, February 19, 2016 11:43 AM
To: [email-masked]
Subject: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

Here is my mail about the Authorization Server Mix-Up:
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg15336.html&data=01%7c01%7ctonynad%40microsoft.com%7c9a5edea9bc704239059508d33964d07c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=DgIHvagw6YjaIFDFlxp4%2bhgQ7ivmV%2f2FuuuiDwVQRv8%3d

Here is my mail to the list that tries to summarize the discussion status and asked a few questions:
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg15697.html&data=01%7c01%7ctonynad%40microsoft.com%7c9a5edea9bc704239059508d33964d07c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1EvoWm%2b7K2BSdvTGCDxmzBkmeSo3Wm1GWamgtG6fcNk%3d

Link:
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-jones-oauth-mix-up-mitigation-01&data=01%7c01%7ctonynad%40microsoft.com%7c9a5edea9bc704239059508d33964d07c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=l27GZP9%2bS5BgvlXxSsgJ2cZv66mFbRpdkREO5L%2bcjsQ%3d

Link:
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-sakimura-oauth-meta-07&data=01%7c01%7ctonynad%40microsoft.com%7c9a5edea9bc704239059508d33964d07c%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Bo6qJ%2b7JcAqfRCzAfD4D4oDCOF%2be29RFRLeyWtJP9lg%3d

Ciao
Hannes & Derek

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Feb 2016 00:17:12 +0100

The idea of including the state in the PKCE calculation was one I think Hans brought up at the meeting in Darmstadt.

I think we discounted it as not solving the problem because the attacker could manipulate the code_challenge.

As and example the attacker receives the request and changes the code_challenge to one it makes up based on the state from a second request made to the client in it’s browser. 

The attacker can replay the token to the client with the state that will validate the code_callenge or use the token directly at the token endpoint to get a access token as it would know both the client secret and code verifier.

We moved on to look at another way to validate state by passing it to the token endpoint for validation to stop the cut and paste attack.

In thinking again about William and Nat’s question about why not PKCE, I looked at the idea of using PKCE again.

The problem with using PKCE as it is now is that we made the assumption that the attacker could not modify the request.

That got me trying to think of a way to:
 a) stop the attacker from modifying the request (signed request, probably too complicated to be generally deployed)
 b) allow the client to detect if code_challenge has been modified and abort of the request was compromise.

I realized that you could simply echo back the code_challenge from the authorization endpoint and that would allow the client to know if code_challenge had been altered in the request, assuming the attacker can’t modify the response from the legitimate AS.

So if we add that step we now have a client where code_challenge can’t be altered.  

That in it selfs stops the cut and pate attack.  It however still allows an attacker to use the code it receives along with the the code_verifier and client secret to get a AT and RT from the legitimate token endpoint.

So that is not enough Including state in the hash calculation helps against the cut and paste attack but we fixed that by returning code_challenge.

That leaves the other things we were talking about returning from the authorization endpoint.

If we include token_endpoint URI in the hash then any token the client requests thinking it is for the attackers token endpoint won’t generate the same code_challenge as the AS would based on it’s token endpoint.   The attacker would know the code_challenge and the real token endpoint URI but would have to generate a collision in the lifetime of code to use the code.   This would not be possible based on the PKCE analysis.

Returning the code_challenge and including the token_endpoint URI in the hash is the minimum needed for the code flow to stop both cut and paste as well  as protect the code from being used if stolen via a confused client attack.   It doesn’t stop the theft just the use of the token.  So it is mitigating the issue a different way from A and B that are trying to stop the attacker from getting the code.

Given the technique I realized it would be simple enough to also include some other paramaters in the hash
1) The authorization endpoint in the hash causing it not to validate if the client has been given a bad authorization endpoint so the client can modify the request.  
2) The client_id so that it cannot be tampered with in the request.
3) The state  This is tied to the browser instance for XSRF protection.  Including this means it cannot be changed and is another protection against cut and paste.

Including all 4 in the hash may be overkill as they overlap in protection.  I however think that not integrity protecting one of the values might bite us in the future.

We could go farther and include scopes or the whole request but that gets more complicated than it is worth.  We do have a option for request signing already.

So we almost had this at the Darmstadt meeting but it slipped away.

This is not stoping the attack it is protecting code.   

I should point out that some of the attacks like man in the middling registration can still compromise the client secret, making it possible for an attacker to impersonate a client.

Nat’s option B doesn’t have a solution to that ether as far as I can tell.

I think the only option for that is to have a logical identifier for the AS and some sort of discovery check at registration to be certain that you are using the correct registration location.

Option A plus discovery works for that and mitigates confused client but not cut and paste.

We still have a problem with AT leaking.   I think that needs to be dealt with separately. 
Access tokens should have a audience (by value or by introspection) the client needs to tell the AS what resource it want s to use the token at and have that included as the audience or the request rejected because it is an invalid audience.

That should happen at the token endpoint for code.
For implicit it would need to be at the authoriation endpoint and the audience would need to be echoed back to prevent tampering.

The AT can also be protected by POP so I think that code and AT should be kept separate issues.

John B.

> On Feb 23, 2016, at 9:59 PM, Roland Hedberg <[email-masked]> wrote:
> 
> In line !
>

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 23 Feb 2016 23:23:42 +0000

I hear that many folks don't want to add a mandatory crypto operation on the client side :-(

-----Original Message-----
From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Tuesday, February 23, 2016 3:17 PM
To: Roland Hedberg <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

John B.

> I on the other hand found it quite easy to do per AS redirect URIs, so 
> it might well be implementation dependent rather then contextual.
> 
>>> 
>>> Per AS Redirect URI
>> In a step 0 the attacker has the good client create another request 
>> in the attackers user agent to get state-0 and code_challange-0
>> 
>> Step 2 is not required.
>> Step 3 Bad AS redirects to good AS with client_id_v + state-v + 
>> code_challenge-0 Step 4 GoodAS stores code_challenge-0 Step 5 GoodAS 
>> returns code-v + state-v to the clients redirect_uri Step 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.
>> 
>> Case C1 :  cut and paste
>> 10.  The attacker launches cut-n-paste attack by inserting code-v 
>> into a response using state-0 11. The client sends code-v and based on state-0 it sends code_verifyer-0 to the good AS token endpoint.
>> code_challange-0 that it bound to code in step 4 13. The GoodAS receives RT + AT.
>> I haven’t had time to write this up, but if the code_challenge == 
>> SHA256 (SHA256(state) || token_endpoint URI || Authorization_endpoint 
>> URI || client_id || code-veriyer) ,  then the attacker could not 
>> change state, client_id, or token_endpoint  independently of 
>> code_challenge.  (note I am using a hash of state to make storage 
>> size deterministic for the AS on the grounds that the client already 
>> needs to be able to do the hash) (Some attacks  change the client_id 
>> in the request so I am including it in the hash)
>> 
> Once you have written down something more definite I promise to 
> implement it promptly such that we can do interop testing early in the process.
> 
> Before John brought up this new PKCE mode I was on the Option A side 
> of the fence now I’d like to see more of this PKCE idea before committing to one or the other.
> 
> — Roland
>

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 24 Feb 2016 10:27:34 +0000

2016年2月24日(水) 8:17 John Bradley <[email-masked]>:
[..snip..]

> This is not stoping the attack it is protecting code.

IMHO, this is the right approach. We should solve the problem
architecturally rather than bandaging the hols.

>
> I should point out that some of the attacks like man in the middling
> registration can still compromise the client secret, making it possible for
> an attacker to impersonate a client.

In case of the dyn-reg, the client really should make sure the identity of
the registration endpoint it is talking to through TLS certs checking. This
is the right way of addressing the man-in-the-middle in this case.
Manual case is hard to fix with a bearer client secret. We probably need to
do public key crypto. Instead of giving a bearer client secret, have the
client regiser the public key, just like we register ssh public key all the
time with github etc. It should not be too hard at all.

> I think the only option for that is to have a logical identifier for the
> AS and some sort of discovery check at registration to be certain that you
> are using the correct registration location.
>

How does it help with preventing the client credential theft through mitm
during the registration? Client secret is already gone by the time you do
the discovery.

> Access tokens should have a audience (by value or by introspection) the
> client needs to tell the AS what resource it want s to use the token at and
> have that included as the audience or the request rejected because it is an
> invalid audience.
>

Is not the scope the implicit combination of the resource, the endpoint
form which you can access the resource,  and operation?

> That should happen at the token endpoint for code.

And, that's why we can send scope there.
The response can also include scope, which is good but my problem here is
that scope value in the response would be a bit too vague. Either having
the uri from which the client can get the list of the resource endpoint, or
get them as RFC5988 header would be nicer.

> For implicit it would need to be at the authoriation endpoint and the
> audience would need to be echoed back to prevent tampering.
>

For a javascript client that is interacting with the authorization
endpoint, getting them in the response header would be great.
For a client that is getting the response through browser redirect, the
audience value needs to be protected by PKCE response or something.

> >>> 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 are not guaranteed to be unique.  They need to be name spaced
> by the AS.   In OAuth currently we have no name for the AS this makes that
> >>> 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.
> >>
> >>> 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.
> >>>
> >>> 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
> >> In a step 0 the attacker has the good client create another request in
> the attackers user agent to get state-0 and code_challange-0
> >>
> >> Step 2 is not required.
> code_challenge-0
> >> 11. The client sends code-v and based on state-0 it sends
> code_verifyer-0 to the good AS token endpoint.
> >> This could be 3rd party financial app like Mint as an example or photos
> or any other PII that could then be used to escalate identity theft.
> >>
> >> This variation of the attack combining cut and paste with confused
> client was not mentioned in the research papers.
> >>
> >> As I mentioned in a response to William, while the current PKCE
> Challenge methods only make the attack harder by forcing the attacker to
> get the client to make a step 0 request to get a code_challenge to use in
> the request,  we could define a new challenge method that would be
> effective.
> >>
> >> The problem is that the PKCE challenge is independent of state so
> becomes vulnerable to the confused client.
> >>
> >> What we would need to do is include state in the challenge so that if
> the AS receives mismatched state and code_challange in step 3 the
> verification of code verifier will fail. Effectively combining the cut and
> paste mitigation with PKCE.
> >>
> SHA256 (SHA256(state) || token_endpoint URI || Authorization_endpoint URI
> || client_id || code-veriyer) ,  then the attacker could not change state,
> wish I had thought of this when we were doing PKCE.   Hit me with the
> stupid stick, my fault.
> >>
> >> If the client is confidential then it gives up it’s client secret
> assuming compromised registration, so we can’t really count on that for
> symmetric client authentication.
> >>
> >> By including the token endpoint in the comparison if the client is
> sending the code to the attacker the client will use a different token
> endpoint_uri in to calculate the code_challenge than the GoodAS will use to
> verify it.    This would stop both cut and paste as well as stopping the
> attacker from using the code if they get it.   The attacker can’t get
> Secret for state-0, so it can’t create code_challenge that would be valid.
> >>
> >> The attack where the client registers with the good AS but with bad
> token endpoint and Authorization endpoint gives the attacker the ability to
> change the code_challenge that the Good AS is going to see.   It would need
> to make a new challenge using state and the GoodAS token endpoint and it’s
> client_id.
> >> To do that it needs the code_verifier to use to calculate the hash to
> use as the code_challenge value.  As long as the client is not tricked into
> >> I can’t see PKCE on it’s own being able to stop a client from being
> used as a redirector back to the attacker unless you also returned the
> >> Effectively this code_challenge method becomes a signature over parts
> of the request and the implicit audience of the token_endpoint URI.
> >>
> >> People keep asking why PKCE doesn’t stop these attacks, and it won’t
> with the current PKCE methods,  however a new method along the lines I
> sketched out may let it work, or I could be completely wrong.
> >

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 24 Feb 2016 14:40:03 +0200

Comments inline.

On 24/02/16 12:27, Nat Sakimura wrote:
> the registration endpoint it is talking to through TLS certs checking. 

Looking at the unfolding situation, I also tend to agree with that.

Once initial AS / IdP discovery (and subsequent client reg) is
compromised, I don't see a way to reliably recover from that further
down the line:

* The bad AS/IdP can act as a reg proxy, and rewrite reg requests /
responses. Even if the client requests private_key_jwt auth, the
attacker can rewrite that to client_secret_basic. Unless private_key_jwt
is made mandatory for all dynamic regs :)

* The bad AS/IdP can also potentially proxy the redirect to / from the
honest authorisation endpoint. Augmented PKCE and returning select AS
parameters will not prevent the ultimate impersonation of the user in
that case.

* The token requests to the AS/IdP can be intercepted, as previously
discussed here and elsewhere.

> This

+1

I've got two questions:

1. Is it fundamentally possible to solve MitM attacks, without having
reliable client authentication in place?

2. Is it possible to have reliable client authentication without crypto?
(with client_secret_basic)

It appears to me that the answer to both questions is negative, and we
cannot really get around crypto and expect to solve these problems :)

The extended PKCE solution that John Bradley wrote about seems to admit
just that. We start hashing parameters, which is crypto already :)

I think the solution will crystallise once we clear these fundamental
questions. And if it turns out that there is no real way around crypto,
and that is proved, that message and the required changes would be
easier to communicate to the developers.

---

From: George Fletcher <[email-masked]>
Date: Wed, 24 Feb 2016 12:34:15 -0500

> Access tokens should have a audience (by value or by introspection) the client needs to tell the AS what resource it want s to use the token at and have that included as the audience or the request…
I have some concerns with requiring an audience for AT issuance. Today a 
client can get a token with scopes "instantMessaging readMail sendMail 
readContacts writeContacts" and then use that token against multiple 
endpoints (im.example.com mail.example.com contacts.example.com). This 
is a common usage of OAuth2.

Forcing the client to get a unique AT for each service it wants to talk 
to is a change from the model that is currently in place.

Thanks,
George

-- 
Chief Architect
Identity Services Engineering     Work: [email-masked]
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Feb 2016 21:08:44 +0100

I think that AT reuse by MITM attacks should be dealt with as a separate issue.

There are several possibilities. 
1) POP tokens (You will recall the Eran wanted them for this reason)
2) The AS telling the client where the token can be used and the client comparing the URI (may be multiple)
3) The client telling the AS where it intends to use the token (may be multiple)
4) some sort of discovery doc being static version of 2.

I would argue that 1 is the best option.  That supports your use case.   Yes it has downsides as far as complexity.

Based on some questions Justin asked me I am trying to work out a way to use token binding in a way that may be much simpler than what we currently are discussing. (still theoretical work) 

Having the RS point to the authorization endpoint is problematic without POP or full discovery.

Restricting the use of the access tokens has been something we have not made any real progress on to this point.

John B.

> On Feb 24, 2016, at 6:34 PM, George Fletcher <[email-masked]> wrote:
> 
> I have some concerns with requiring an audience for AT issuance. Today a client can get a token with scopes "instantMessaging readMail sendMail readContacts writeContacts" and then use that token against multiple endpoints (im.example.com mail.example.com contacts.example.com). This is a common usage of OAuth2. 
> 
> Forcing the client to get a unique AT for each service it wants to talk to is a change from the model that is currently in place.
> 
> Thanks,
> George
> 
>>> On Feb 23, 2016, at 9:59 PM, Roland Hedberg <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>> In line !
>>> 
>>>> 22 feb 2016 kl. 05:08 skrev John Bradley <[email-masked]> <mailto:[email-masked]>:
>>>> 
>>>>> On Feb 22, 2016, at 9:22 AM, Nat Sakimura <[email-masked]> <mailto:[email-masked]> wrote:
>>>>> 
> Identity Services Engineering     Work: [email-masked] <mailto:[email-masked]>
> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch <http://twitter.com/gffletch>
> Office: +1-703-265-2544           Photos: http://georgefletcher.photography <http://georgefletcher.photography/>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Feb 2016 08:43:34 +0100

Vladimir,

yes, we could do a formal analysis and it would be a very good idea.
It would even go faster if a few of us work together on it. Anyone
interested?

This would be a good contribution for the workshop in July, btw.

Ciao
Hannes

---

From: Brian Campbell <[email-masked]>
Date: Fri, 26 Feb 2016 15:27:54 -0700

My preference is for Option A.

The mix-up attack, in all it's variations, relies on there being no means
in OAuth for the AS to identify itself to the client when it returns the
user's browser to the client's redirect_uri. 'OAuth 2.0 Mix-Up Mitigation'
addresses that fundamental missing piece by including the 'iss'
authorization response parameter.

During the course of the discussions in Darmstadt Hans and I independently
implemented and successfully interop tested the 'iss' and 'client_id'
authorization response parameters, which is what was anticipated to be in
the mitigation draft. Doing so was very simple and straightforward. And it
addresses the vulnerability. We decided, unfortunately, to pull that
functionality out of a looming a product release due to the churn in this
WG and the perceived risk of changes in what would eventually become the
standard solution. Of course, that kind of risk is always present with
draft standards but it's been very frustrating in this case to have worked
towards a simple solution to a known problem only to have progress get hung
up in lack of agreement in this WG.

I'll also say that in many/most cases the AS doesn't explicitly know all of
the resources that tokens it issues can or will be used at (and there are
often more than one). So the ruri/Resource URI parameter isn't really a
workable option.

On Thu, Feb 25, 2016 at 12:43 AM, Hannes Tschofenig <
[email-masked]> wrote:

> >> Suggesting that they be read is of course, the right long-term
> approach.  But as someone who spent 20+ years as a researcher before
> switching to digital identity, I was sensitive to not wanting to upstage
> their work by copying too much of their material into our draft before
> their publications were widely known.  I'll of course commit to working the
> researchers and the working group to create a self-contained concise
> description of the threats and mitigations in the working group document.
> >>
> >>                              Cheers,
> >>                              -- Mike
> >>
> >> To: Mike Jones <[email-masked]>; William Denniss <
> [email-masked]>; Phil Hunt (IDM) <[email-masked]>
> >> Cc: [email-masked]
> text from the papers into the draft or reference specific sections that are
> "must-read".
> >>

---

From: "Donald F. Coffin" <[email-masked]>
Date: Sat, 27 Feb 2016 12:10:38 -0500

+1

Best regards,

Don

Donald F. Coffin

Founder/CTO

REMI Networks

2335 Dunwoody Xing #E

Dunwoody, GA 30338-8221

Phone:      (949) 636-8571

Email:        <mailto:[email-masked]> [email-masked]

From: Brian Campbell [mailto:[email-masked]] 
Sent: Friday, February 26, 2016 5:28 PM
To: Hannes Tschofenig <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call for Adoption

The mix-up attack, in all it's variations, relies on there being no means in OAuth for the AS to identify itself to the client when it returns the user's browser to the client's redirect_uri. 'OAuth 2.0 Mix-Up Mitigation' addresses that fundamental missing piece by including the 'iss' authorization response parameter. 

During the course of the discussions in Darmstadt Hans and I independently implemented and successfully interop tested the 'iss' and 'client_id' authorization response parameters, which is what was anticipated to be in the mitigation draft. Doing so was very simple and straightforward. And it addresses the vulnerability. We decided, unfortunately, to pull that functionality out of a looming a product release due to the churn in this WG and the perceived risk of changes in what would eventually become the standard solution. Of course, that kind of risk is always present with draft standards but it's been very frustrating in this case to have worked towards a simple solution to a known problem only to have progress get hung up in lack of agreement in this WG.     

I'll also say that in many/most cases the AS doesn't explicitly know all of the resources that tokens it issues can or will be used at (and there are often more than one). So the ruri/Resource URI parameter isn't really a workable option. 

On Thu, Feb 25, 2016 at 12:43 AM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]> > wrote:

Vladimir,

Ciao
Hannes

On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote:
>> From: Hannes Tschofenig [mailto:[email-masked] <mailto:[email-masked]> ]
>> To: Mike Jones <[email-masked] <mailto:[email-masked]> >; William Denniss <[email-masked] <mailto:[email-masked]> >; Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]> >
>> Cc: [email-masked] <mailto:[email-masked]>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 27 Feb 2016 20:16:07 +0200

Hi Brian,

> authorization response parameter.

This fundamental piece is indeed missing. I'm not sure measure "A" can
also cover dynamic discovery and registration though. The mixup attack
was originally described there, with OpenID Connect.

How about this variation:

Suppose the malicious IdP:

1. Registers the client under attack for
a) malicious authz endpoint
b) malicious token endpoint (optional)

... while also acting as proxy, where there are two variants:
a) repeats the client registration with the honest IdP to obtain
client_id + credentials that it keeps for itself; or
b) is already registered as a client with the honest IdP

Then:

1. When the authz request is made to the malicious authz endpoint, the
request is rewritten with the client_id and redirect_uri which the
malicious IdP has with the honest IdP. The state may or may not be replaced.

2. The browser is then given a second redirect with the rewritten
parameters to the authz endpoint of the honest IdP.

3. The user doesn't notice this double redirect, and logs in / gives
consent.

4. The honest IdP sends the browser back to the registered malicious
redirect_uri. The attacker receives the code or tokens (depending on the
response type)

5. A second redirect is made back to the redirect_uri of the client,
with rewritten state, iss, client_id

What is your take on this?

The ideal fix for me would be one that covers dynamic discovery and
registration as well. I'm not convinced option A does that.

Cheers,

Vladimir

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 27 Feb 2016 21:31:40 +0200

Hi Hannes,

I'm glad to hear that you're interest to work on this. The approach in
the Trier report was really enlightening to me. I'm still digesting it.

OAuth 2 was created with the promise to be developer friendly and
extensible, but compared with some other security protocols, doesn't
extend security guarantees to profiles / usages of it. Consider for
example TLS, which allows other protocols to ride on top of it, without
having to worry about breaking TLS security the way we now do now when
thinking of more dynamic use cases of OAuth :)

I wish we would come up with some simple recipe that will be easy to
explain to developers, and at the same time will guarantee the security
in all dynamic use cases. E.g. if you do dynamic discovery then make
sure A,B,C...

Cheers,
Vladimir

---

From: John Bradley <[email-masked]>
Date: Sat, 27 Feb 2016 18:15:41 -0500

If the malicious client is registering it’s own redirect URI then option A won’t help. 

On the other hand the Good AS should identify the malicious client to the user.

I think this is a separate problem of client impersonation being used for Phishing.

This is really a case of bad guy registers client and phishes the user to login pretending to be some other client.

That can all be done with the good client not being involved at all. 

John B.

> On Feb 27, 2016, at 1:16 PM, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
> Hi Brian,
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 28 Feb 2016 16:35:43 +0100

Hi all,

I prefer to use draft-jones-oauth-mix-up-mitigation-01 as starting point 
simply because it gives some description of the threats we need to cope 
with. This does not preclude to eventually use 
draft-sakimura-oauth-meta-07 as solution or any other suitable 
mechanisms we find consensus on.

In my opinion, both proposals (iss and meta data) are very similar on a 
conceptual level as they inform the client about the sender of the 
redirect. iss could nicely fit with the upcoming OAuth AS discovery, 
whereas meta is appealing if we want a mechanism, which always keeps the 
client informed where it is considered secure to obtain/use credentials 
(tokens, codes, ...).

Beside this, I would like to emphasize again that code injection/copy 
and paste is not related to idp mix up (even if we discussed both in the 
same workshop). Even traditional OAuth deployments (single AS) are 
potentially affected by the attack. I suggest to split the draft into 
separat documents per threat/mitigation and move forward mitigation 
against code injection as quickly as possible. The current proposal to 
tie the authz code to the client state seems a pretty simple and 
straightforward solution to me.

kind regards,
Torsten.