Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 19 Jan 2016 12:49:53 +0100

Hi all,

this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00

Please let us know by Feb 9th whether you accept / object to the
adoption of this document as a starting point for work in the OAuth
working group.

Note: This call is related to the announcement made on the list earlier
this month, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
time for analysis is provided due to the complexity of the topic.

Ciao
Hannes & Derek

---

From: Brian Campbell <[email-masked]>
Date: Wed, 20 Jan 2016 15:42:30 -0700

I conditionally accept this document as a starting point for work in the
OAuth working group on the assumption that the considerable simplifications
discussed and accepted at
http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html will be
incorporated.

This document is (should be) intended to provide a mitigation to a security
problem. As such, it would be nice to see it progress a little faster than
the typical WG document. The more quickly the document can progress and/or
be perceived as stable, the better.

On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig <
[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 20 Jan 2016 17:26:00 -0800

+1 for adoption

+1 for Brian's comments

Phil

> On Jan 20, 2016, at 14:42, Brian Campbell <[email-masked]> wrote:
> 
> I conditionally accept this document as a starting point for work in the OAuth working group on the assumption that the considerable simplifications discussed and accepted at http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html will be incorporated.
> 
> This document is (should be) intended to provide a mitigation to a security problem. As such, it would be nice to see it progress a little faster than the typical WG document. The more quickly the document can progress and/or be perceived as stable, the better.
> 
>> On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig <[email-masked]> wrote:
>> Hi all,
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 20 Jan 2016 22:48:10 -0300

+1 for adoption

Mike and I are working on addressing the comments in a new draft for your reading pleasure shortly.

John B.

> On Jan 20, 2016, at 10:26 PM, Phil Hunt (IDM) <[email-masked]> wrote:
> 
> +1 for adoption
> 
> +1 for Brian's comments
> 
> Phil
> 
> On Jan 20, 2016, at 14:42, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> I conditionally accept this document as a starting point for work in the OAuth working group on the assumption that the considerable simplifications discussed and accepted at http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html <http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html> will be incorporated.
>> 
>> On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi all,
>> 
>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 <https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00>
>> 
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html <http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html>. More
>> [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: William Denniss <[email-masked]>
Date: Thu, 21 Jan 2016 02:29:51 +0000

+1 for adoption, this is important work.

On Thu, Jan 21, 2016, 9:48 AM John Bradley <[email-masked]> wrote:

> This document is (should be) intended to provide a mitigation to a
> security problem. As such, it would be nice to see it progress a little
> faster than the typical WG document. The more quickly the document can
> progress and/or be perceived as stable, the better.
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 21 Jan 2016 03:43:19 +0000

+1

From: OAuth [mailto:[email-masked]] On Behalf Of William Denniss
Sent: Wednesday, January 20, 2016 6:30 PM
To: John Bradley <[email-masked]>; Phil Hunt (IDM) <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

On Thu, Jan 21, 2016, 9:48 AM John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
+1 for adoption

John B.

On Jan 20, 2016, at 10:26 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:

+1 for adoption

+1 for Brian's comments

Phil

On Jan 20, 2016, at 14:42, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
I conditionally accept this document as a starting point for work in the OAuth working group on the assumption that the considerable simplifications discussed and accepted at http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg15351.html&data=01%7c01%7ctonynad%40microsoft.com%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sX563oe%2bghIV9OA6eZR2cYUMkZYzCI3asjExkNX6Xp0%3d> will be incorporated.
This document is (should be) intended to provide a mitigation to a security problem. As such, it would be nice to see it progress a little faster than the typical WG document. The more quickly the document can progress and/or be perceived as stable, the better.

On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-jones-oauth-mix-up-mitigation-00&data=01%7c01%7ctonynad%40microsoft.com%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9Xrf3wL%2f7UfJ%2fdpWRT%2fCWSasgKTRcqsrSSMKLGwUtJ0%3d>

Note: This call is related to the announcement made on the list earlier
this month, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html<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%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=WPQQcD9G823Ab4osrjKwfqFlu5WxZGWzFvjQc3e4sF8%3d>. More
time for analysis is provided due to the complexity of the topic.

Ciao
Hannes & Derek

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=00hoXh2DlO9QyJrXMdarxQNiuSQIKaeL490qBrxCYFc%3d>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=00hoXh2DlO9QyJrXMdarxQNiuSQIKaeL490qBrxCYFc%3d>
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=00hoXh2DlO9QyJrXMdarxQNiuSQIKaeL490qBrxCYFc%3d>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=00hoXh2DlO9QyJrXMdarxQNiuSQIKaeL490qBrxCYFc%3d>

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 21 Jan 2016 04:12:37 +0000

Thought I did, but apparently not. A belated +1.

2016年1月21日(木) 12:43 Anthony Nadalin <[email-masked]>:

> +1
>
>
>
> *From:* OAuth [mailto:[email-masked]] *On Behalf Of *William
> Denniss
> *Sent:* Wednesday, January 20, 2016 6:30 PM
> *To:* John Bradley <[email-masked]>; Phil Hunt (IDM) <
> [email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
>
>
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2foauth%2fcurrent%2fmsg15351.html&data=01%7c01%7ctonynad%40microsoft.com%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sX563oe%2bghIV9OA6eZR2cYUMkZYzCI3asjExkNX6Xp0%3d>
> will be incorporated.
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-jones-oauth-mix-up-mitigation-00&data=01%7c01%7ctonynad%40microsoft.com%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=9Xrf3wL%2f7UfJ%2fdpWRT%2fCWSasgKTRcqsrSSMKLGwUtJ0%3d>
>
> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html
> <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%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=WPQQcD9G823Ab4osrjKwfqFlu5WxZGWzFvjQc3e4sF8%3d>.
> More
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=00hoXh2DlO9QyJrXMdarxQNiuSQIKaeL490qBrxCYFc%3d>
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=00hoXh2DlO9QyJrXMdarxQNiuSQIKaeL490qBrxCYFc%3d>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=00hoXh2DlO9QyJrXMdarxQNiuSQIKaeL490qBrxCYFc%3d>
>
>
>
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c57b5111a35fc43e3276208d3220ac8b6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=00hoXh2DlO9QyJrXMdarxQNiuSQIKaeL490qBrxCYFc%3d>
>

---

From: Antonio Sanso <[email-masked]>
Date: Thu, 21 Jan 2016 06:14:05 +0000

+1 for adoption

---

From: Roland Hedberg <[email-masked]>
Date: Thu, 21 Jan 2016 07:53:14 +0000

+1 for adoption

> 21 jan 2016 kl. 07:14 skrev Antonio Sanso <[email-masked]>:
> 
> +1 for adoption

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 21 Jan 2016 08:38:41 +0000

Well, re-reading, I have a bit of problem with the draft.

It is defining a new concept 'issuer', which is not found in RFC6749, as
the authorization server's configuration information location. It is
returned in 'iss' authorization response parameter. On the other hand,
there is an existing concept of 'issuer' for identifying the authorization
server in OpenID Connect. e.g., Google's discovery document's URI is
https://accounts.google.com/.well-known/openid-configuration and issuer in
it is https://accounts.google.com . This value MUST exactly match the "iss"
in ID Token.
Unfortunately, this does not match the value of OAuth issuer defined in
Section 2 of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned
as specified in 3.1. As such, validation as specified in bullet 1 of
Section 4 fails in Google's case -- OR it means that the document is
internally inconsistent.

Also, I do not understand the value of OAuth issuer when there is no
configuration file but everything is determined in the developer
documentation. This is one of the assumption of RFC6749 and many OAuth
servers are operated like that. Technically, since the discovery document
does not exist, it is an empty string, which fails the validation rule set
here.

As to section 5 is concerned, I could not read out what threat it is trying
to mitigate. Is it trying to address the case that the client is not doing
a proper state check? From section 6, it seems it is trying to do the
binding between the authorization request and the token request, but if
that is the case, is it not better to just use PKCE than introducing
something new?

The draft-sakimura-oauth-meta-05 approach is similar, but it avoids these
confusions.
Instead of relying on 'issuer' concept, it uses token endpoint URI. Per
discussion in Yokohama, the identifier that distinguishes the authorization
server is the URI of the authorization endpoint uri. This is the trust
anchor of the entire flow, and it exists even if the client is not using
discovery of any kind. If you cannot trust this endpoint, everything
breaks. Oauth-meta chains the trust through metadata step by step.

In case of 'code' flow, the next step on the server side is the token
endpoint uri. This is returned in a parameter called 'turi', a shorthand
for token endpoint uri. The validation rule is that the client MUST check
that turi and the token endpoint uri that is previously known to the client
exactly matches. (Actually, a simpler way is just use the value returned in
turi.)

Then, the client sends the token request to turi. If additional security
through authorization and token request binding, or making sure that the
client instance is really the intended audience, then use PKCE [RFC7636].
The client_id parameter in draft-jones-oauth-mix-up-mitigation-01 does not
help in the case of public client, but PKCE works.

In addition, draft-sakimura-oauth-meta-05
<https://tools.ietf.org/html/draft-sakimura-oauth-meta-05> [1] provides
other goodies as well, such as HATEOAS. It achieves all these by the full
use of RFC5988 and introducing very little new things. It is only one page!

So, IMHO, the combination of draft-sakimura-oauth-meta-05 and RFC7636 seems
to be a better solution.

   - It does not break the existing implementations;
   - It does not confuse the reader by defining two concepts of issuer
   depending on the context;
   - It works in the case that the configuration is done through the
   developer documentation. i.e., it does not require yet to be defined
   discovery spec.
   - It works for public client as well;
   - It enables HATEOAS - Yes. It makes OAuth finally RESTful!;

There is one discussion point that I want to raise for oauth-meta.
Currently, the authorization response metadata such as turi are returned as
query parameters. This is to enable the dynamic reallocation of the
endpoints, and adhere to the HATEOS principle. If you do not need this
dynamism, then there is an alternative proposal that I have, that makes it
extremely simple to implement for the server. In this case, the client just
sends HEAD request to the authorization endpoint. Then the authorization
endpoint returns 200 OK with turi in the header. e.g.,

 HTTP/1.1 200 OK
   Link: <https://example.com/token>; rel="turi",
   Content-Type: application/JSON; charset=utf-8

This can be achieved without touching the authorization endpoint code, but
just by configuration. In case of apache, use 'header append' in the apache
configuration. If we take this course, then there is another advantage to
be added:

   - You do not need to change the server code.

Is it not attractive?

Cheers,

Nat Sakimura

[1] https://tools.ietf.org/html/draft-sakimura-oauth-meta-05

---

From: Josh Mandel <[email-masked]>
Date: Thu, 21 Jan 2016 09:04:10 -0500

Apologies if this is the wrong forum for my comment (and please direct me
to the appropriate place in that case), but I have two questions about the
propose mitigation (and the thinking behind it) that I think the write-up
could address:

1. Could the writeup clarify whether/how the primary "mixup" threat differs
from what RFC6819 identifies as in section 4.6.4?

2. Has the workgroup considered a mitigation that puts more responsibility
on the authorization server, and less on the client? For example, if would
be helpful for the writeup to clarify why having the client send an
"audience field" (in the terminology of RFC6819) to the authorization
endpoint would not mitigate the threat. (In that scenario, the
authorization server can recognize that the audience does not correspond to
a resource server it knows, rather than asking clients to make this check).
I assume this approach has been considered and rejected as an incomplete
mitigation, but I don't have visibility into where/how that discussion
went.

Thanks,

Josh
Hi all,

Ciao
Hannes & Derek

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 21 Jan 2016 14:39:57 +0000

Hi Josh,

It is similar but slightly different IMHO.

Section 4.6.4 of the RFC6819 is the access token phishing by a counterfeit
resource server.
The mix-up attack described here is the code phishing by a counterfeit
token endpoint.

In my view, both can be mitigated by the server returning the next step:
i.e., authorization endpoint returning the legitimate token endpoint uri,
and token endpoint returning legitimate resource endpoint uris. This
involves no discovery endpoint, which is good.

Your way also works. It is just the reverse of my proposal. The difference
being that my proposal does not need any coding on the server but just
configuration, and it can return more metadata if needed.

Cheers,

Nat

2016年1月21日(木) 23:04 Josh Mandel <[email-masked]>:

> 1. Could the writeup clarify whether/how the primary "mixup" threat
> differs from what RFC6819 identifies as in section 4.6.4?
>

---

From: Josh Mandel <[email-masked]>
Date: Thu, 21 Jan 2016 09:50:39 -0500

Thanks Nat - that's helpful. If both mitigations *can* work effectively,
then I would like to see this group consider the decision between them
carefully (if that hasn't happened yet). Again, don't hesitate to let me
know if this is the wrong place/time for such discussion.

At a high level, I would rather ask server developers to do some "coding",
for two reasons:

1. Most OAuth servers talk to many, many clients. So consolidating the
security critical work in one place (server) is a net savings of work
(rather than asking each client to implement these checks.

2. OAuth server developers are typically more sophisticated than client
developers, and therefore more likely to understand the implications and
more likely to get these critical details correct. Asking each client
developer to do something right is likely to result in heterogenius
implementation and persistent security holes. But if the server does the
heavy lifting, and clients just have to pass along an extra parameter, this
is more likely to see consistent implementation (for example, clients will
fail to work if misconfigured, which will prompt developers to fix them).
On Jan 21, 2016 09:40, "Nat Sakimura" <[email-masked]> wrote:

>> 2. Has the workgroup considered a mitigation that puts more
>> responsibility on the authorization server, and less on the client? For
>> example, if would be helpful for the writeup to clarify why having the
>> client send an "audience field" (in the terminology of RFC6819) to the
>> authorization endpoint would not mitigate the threat. (In that scenario,
>> the authorization server can recognize that the audience does not
>> correspond to a resource server it knows, rather than asking clients to
>> make this check). I assume this approach has been considered and rejected
>> as an incomplete mitigation, but I don't have visibility into where/how
>> that discussion went.
>>
>> Thanks,
>>
>> Josh
>> Hi all,
>>

---

From: George Fletcher <[email-masked]>
Date: Thu, 21 Jan 2016 13:30:11 -0500

+1 for adoption

-- 
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: Thu, 21 Jan 2016 19:59:42 -0300

There have been a lot of discussions. I think Hannes posted some minutes of the F2F meeting we had with the security researchers.

The problem can’t be mitigated without some action on the client side.  It boils down to the client making a request to AS1 (From it’s perspective) and getting back a response from AS 2 (that it thinks is AS1)

This can be done if AS1 is a good AS but has it’s logs compromised so that an attacker can read them. Hans Zandbelt built a proof of concept for the attack. 

In some cases the attacker gets the code and the credential to use it at the good AS token endpoint and in others it just gets the code and can replay that at the client to extract information from the API through the client by binding the api access to a new account.

PKCE unfortunately mitigates a different attack, where the client is impersonated and trys to replay a intercepted code.  It however assumes the token endpoint is good, and is no help in the case of a compromised token endpoint.

The client in these attacks is vulnerable because it relies on some local state, or the value of the state parameter to know who the response is coming from.  This allows a authorization request that is intercepted to be used to create a new request in that browser to a different AS, or trick the client into using a Authorization endpoint for a different authorization server.

One problem is that OAuth doesn’t really have a unified concept of what a AS is.  Traditionally it is a Authorization endpoint URI, token end point URI and resource server URI that some one gives the client in some documentation.   

As ling as a client only talks to one AS then there is no problem.   However once a client is configured to talk to more than one AS, we have problems if one of those AS lies about it’s endpoints, or is compromised and used to attack another AS.   As a design goal you don’t want the overall  security to be limited by the weakest system.

One approach as Nat promotes is to have the authorization endpoint return the next hop, token endpoint for code or RS URI for token. The token endpoint must also return the RS URI or the client must push the RS URI to the token endpoint or the attacker just replaces the RS URI in the config and captures the token that way. 

The other way is to provide a name for each AS as part of registration and the client not allow duplicate registrations with the same name.  When the response comes back the client checks the name against the one it made the request to.  If the name dereferences to a discovery document then the client can check that name at registration or runtime to validate the net hops.

I think the two approaches mitigate the attack in similar ways.  Nat’s is more REST friendly and returns the next hop as a parameter of header.  

The one Mike and I wrote up based on the meeting in Germany provides identifiers (iss and client_id) that can be checked for validity in the simple case and be dereferenced via .well-known to get the information Nat’s proposal is providing.

Perhaps the main difference is Nat is using the token endpoint as the identifier for the AS and Mike’s is using location for a discovery document as the identifier.

I don’t recall the reasons using the token endpoint as the identifier was rejected at the meeting.  Perhaps others can post the reasons.

We need to close on this quickly, otherwise if we are indecisive fixes will not go into products for another year or so until this is a RFC.

That is my main concern.

John B.

> On Jan 21, 2016, at 11:50 AM, Josh Mandel <[email-masked]> wrote:
> 
> Thanks Nat - that's helpful. If both mitigations *can* work effectively, then I would like to see this group consider the decision between them carefully (if that hasn't happened yet). Again, don't hesitate to let me know if this is the wrong place/time for such discussion.
> 
> At a high level, I would rather ask server developers to do some "coding", for two reasons:
> 
> 1. Most OAuth servers talk to many, many clients. So consolidating the security critical work in one place (server) is a net savings of work (rather than asking each client to implement these checks.
> 
> 2. OAuth server developers are typically more sophisticated than client developers, and therefore more likely to understand the implications and more likely to get these critical details correct. Asking each client developer to do something right is likely to result in heterogenius implementation and persistent security holes. But if the server does the heavy lifting, and clients just have to pass along an extra parameter, this is more likely to see consistent implementation (for example, clients will fail to work if misconfigured, which will prompt developers to fix them).
> 
> On Jan 21, 2016 09:40, "Nat Sakimura" <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Josh, 
> 
> Section 4.6.4 of the RFC6819 is the access token phishing by a counterfeit resource server. 
> The mix-up attack described here is the code phishing by a counterfeit token endpoint. 
> 
> In my view, both can be mitigated by the server returning the next step: i.e., authorization endpoint returning the legitimate token endpoint uri, and token endpoint returning legitimate resource endpoint uris. This involves no discovery endpoint, which is good. 
> 
> Your way also works. It is just the reverse of my proposal. The difference being that my proposal does not need any coding on the server but just configuration, and it can return more metadata if needed. 
> 
> Cheers, 
> 
> Nat
> 
> 2016年1月21日(木) 23:04 Josh Mandel <[email-masked] <mailto:[email-masked]>>:
> Apologies if this is the wrong forum for my comment (and please direct me to the appropriate place in that case), but I have two questions about the propose mitigation (and the thinking behind it) that I think the write-up could address:
> 
> 1. Could the writeup clarify whether/how the primary "mixup" threat differs from what RFC6819 identifies as in section 4.6.4?
> 
> 2. Has the workgroup considered a mitigation that puts more responsibility on the authorization server, and less on the client? For example, if would be helpful for the writeup to clarify why having the client send an "audience field" (in the terminology of RFC6819) to the authorization endpoint would not mitigate the threat. (In that scenario, the authorization server can recognize that the audience does not correspond to a resource server it knows, rather than asking clients to make this check). I assume this approach has been considered and rejected as an incomplete mitigation, but I don't have visibility into where/how that discussion went.
> 
> Thanks,
> 
> Josh 
> Hi all,
>

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 22 Jan 2016 00:38:10 +0000

Still doing the analysis. We spent 1.5 hours today with John, George, nov
and me on the OpenID Connect WG call on this issue. John explained the
mitigation, but none of us was convinced that it works.

Then, after the call, I and nov went on with various scenarios. The interim
conclusion is that:

   - client_id response parameter does not help. There are legitimate cases
   that client_id duplicates out there and we cannot ban that.
   - iss response parameter does not help unless the discovery is performed
   and the value of iss is checked against the value of OAuth issuer inside
   the document. (<- Discovery becomes mandatory. From our experience on RP
   discovery step in OpenID 2.0, chance of this being done properly seems to
   be rather slim.)
   - sending the state to the token endpoint helps in the case code was
   stollen, but code should not be stolen to start with.

Cheers,

Nat

2016年1月22日(金) 7:59 John Bradley <[email-masked]>:

> There have been a lot of discussions. I think Hannes posted some minutes
> of the F2F meeting we had with the security researchers.
>
> The problem can’t be mitigated without some action on the client side.  It
> boils down to the client making a request to AS1 (From it’s perspective)
> and getting back a response from AS 2 (that it thinks is AS1)
>
> This can be done if AS1 is a good AS but has it’s logs compromised so that
> an attacker can read them. Hans Zandbelt built a proof of concept for the
> attack.
>
> In some cases the attacker gets the code and the credential to use it at
> the good AS token endpoint and in others it just gets the code and can
> replay that at the client to extract information from the API through the
> client by binding the api access to a new account.
>
> PKCE unfortunately mitigates a different attack, where the client is
> impersonated and trys to replay a intercepted code.  It however assumes the
> token endpoint is good, and is no help in the case of a compromised token
> endpoint.
>
> The client in these attacks is vulnerable because it relies on some local
> state, or the value of the state parameter to know who the response is
> coming from.  This allows a authorization request that is intercepted to be
> used to create a new request in that browser to a different AS, or trick
> the client into using a Authorization endpoint for a different
> authorization server.
>
> One problem is that OAuth doesn’t really have a unified concept of what a
> AS is.  Traditionally it is a Authorization endpoint URI, token end point
> URI and resource server URI that some one gives the client in some
> documentation.
>
> As ling as a client only talks to one AS then there is no problem.
> However once a client is configured to talk to more than one AS, we have
> problems if one of those AS lies about it’s endpoints, or is compromised
> and used to attack another AS.   As a design goal you don’t want the
> overall  security to be limited by the weakest system.
>
> One approach as Nat promotes is to have the authorization endpoint return
> the next hop, token endpoint for code or RS URI for token. The token
> endpoint must also return the RS URI or the client must push the RS URI to
> the token endpoint or the attacker just replaces the RS URI in the config
> and captures the token that way.
>
> The other way is to provide a name for each AS as part of registration and
> the client not allow duplicate registrations with the same name.  When the
> response comes back the client checks the name against the one it made the
> request to.  If the name dereferences to a discovery document then the
> client can check that name at registration or runtime to validate the net
> hops.
>
> I think the two approaches mitigate the attack in similar ways.  Nat’s is
> more REST friendly and returns the next hop as a parameter of header.
>
> The one Mike and I wrote up based on the meeting in Germany provides
> identifiers (iss and client_id) that can be checked for validity in the
> simple case and be dereferenced via .well-known to get the information
> Nat’s proposal is providing.
>
> Perhaps the main difference is Nat is using the token endpoint as the
> identifier for the AS and Mike’s is using location for a discovery document
> as the identifier.
>
> I don’t recall the reasons using the token endpoint as the identifier was
> rejected at the meeting.  Perhaps others can post the reasons.
>
> We need to close on this quickly, otherwise if we are indecisive fixes
> will not go into products for another year or so until this is a RFC.
>
> That is my main concern.
>
> John B.
>
>
>
>
>
>> Your way also works. It is just the reverse of my proposal. The
>> difference being that my proposal does not need any coding on the server
>> but just configuration, and it can return more metadata if needed.
>>
>> Cheers,
>>
>> Nat
>>
>>> Apologies if this is the wrong forum for my comment (and please direct
>>> me to the appropriate place in that case), but I have two questions about
>>> the propose mitigation (and the thinking behind it) that I think the
>>> write-up could address:
>>>

---

From: William Denniss <[email-masked]>
Date: Fri, 22 Jan 2016 08:43:20 +0800

When I first heard Nat's proposal in Yokohama I thought it was pretty
elegant. And remember that it was first proposed to add more RESTful
behavior to OAuth and not just as a mix-up mitigation.

For the mix-up topic, I wonder if this comes down to: if you are already
doing OpenID Connect, the issuer/discovery path feels natural, as that's
what you're used to. But if you're pure OAuth, without those concepts then
Nat's solution is more natural?

I do recall some contention in Yokohama around returning the same info
twice (e.g. returning the token endpoint, and returning a discovery
document URL which could potential reference a different token endpoint).

There's something quite nice about the possibility for the AS returning
more detailed configuration like the relevant resource servers where the
token can be used – something that discovery can't do as it doesn't have
the context of the authorization grant.

---

From: John Bradley <[email-masked]>
Date: Thu, 21 Jan 2016 21:47:54 -0300

I will point out for clarification that this would be like IdP discovery in openID 2 that everyone did.  I think IdP not doing RP discovery in openID 2 is a weak argument.
There may be other evidence that RP will not do discovery, but if that is the case why are we doing a OAuth discovery spec?  
Many people see your spec as discovery as well just in a different way.

I think both ways can work, but doing both leaves too many options. 

John B.

> On Jan 21, 2016, at 9:38 PM, Nat Sakimura <[email-masked]> wrote:
> 
> Still doing the analysis. We spent 1.5 hours today with John, George, nov and me on the OpenID Connect WG call on this issue. John explained the mitigation, but none of us was convinced that it works. 
> 
> Then, after the call, I and nov went on with various scenarios. The interim conclusion is that: 
> client_id response parameter does not help. There are legitimate cases that client_id duplicates out there and we cannot ban that.  
> iss response parameter does not help unless the discovery is performed and the value of iss is checked against the value of OAuth issuer inside the document. (<- Discovery becomes mandatory. From our experience on RP discovery step in OpenID 2.0, chance of this being done properly seems to be rather slim.) 
> sending the state to the token endpoint helps in the case code was stollen, but code should not be stolen to start with. 
> Cheers, 
> 
> Nat
> 
> 
> 2016年1月22日(金) 7:59 John Bradley <[email-masked] <mailto:[email-masked]>>:
>> On Jan 21, 2016, at 11:50 AM, Josh Mandel <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 22 Jan 2016 00:58:27 +0000

The point is, the idea of making discovery mandatory even if the authz
server is currently not doing it but giving info through developer
documentation, does not sound likely to fly.

2016年1月22日(金) 9:47 John Bradley <[email-masked]>:

> I will point out for clarification that this would be like IdP discovery
> in openID 2 that everyone did.  I think IdP not doing RP discovery in
> openID 2 is a weak argument.
> There may be other evidence that RP will not do discovery, but if that is
> the case why are we doing a OAuth discovery spec?
>    - client_id response parameter does not help. There are legitimate
>    cases that client_id duplicates out there and we cannot ban that.
>    - iss response parameter does not help unless the discovery is
>    performed and the value of iss is checked against the value of OAuth issuer
>    inside the document. (<- Discovery becomes mandatory. From our experience
>    on RP discovery step in OpenID 2.0, chance of this being done properly
>    seems to be rather slim.)
>> The problem can’t be mitigated without some action on the client side.
>> It boils down to the client making a request to AS1 (From it’s perspective)
>> This can be done if AS1 is a good AS but has it’s logs compromised so
>> that an attacker can read them. Hans Zandbelt built a proof of concept for
>> the attack.
>>
>> The other way is to provide a name for each AS as part of registration
>> and the client not allow duplicate registrations with the same name.  When
>> the response comes back the client checks the name against the one it made
>> the request to.  If the name dereferences to a discovery document then the

---

From: John Bradley <[email-masked]>
Date: Thu, 21 Jan 2016 21:58:44 -0300

I will point out for the benefit of the people on the the list who were not at the F2F in Germany, that Mike and I were asked to write up the consensus of the group.

We have done that. 

The work group is free to adopt it or modify it.   

Brian and others raised issues about how accurately we reflected the consensus in the first draft.  I think that is mostly resolved.   We should continue refining that if needed.

Separately the work group needs to consider other proposals do come to a Work Group consensus rather than a meeting consensus.

My main concern is coming to that consensus quickly.    We do have people who have implemented the mitigations in the spec Mike and I did.

Perhaps we should also document Nat’s proposal so it can be tested as well.

John B.

> On Jan 21, 2016, at 9:43 PM, William Denniss <[email-masked]> wrote:
> 
> When I first heard Nat's proposal in Yokohama I thought it was pretty elegant. And remember that it was first proposed to add more RESTful behavior to OAuth and not just as a mix-up mitigation.
> 
> For the mix-up topic, I wonder if this comes down to: if you are already doing OpenID Connect, the issuer/discovery path feels natural, as that's what you're used to. But if you're pure OAuth, without those concepts then Nat's solution is more natural?
> 
> I do recall some contention in Yokohama around returning the same info twice (e.g. returning the token endpoint, and returning a discovery document URL which could potential reference a different token endpoint).
> 
> There's something quite nice about the possibility for the AS returning more detailed configuration like the relevant resource servers where the token can be used – something that discovery can't do as it doesn't have the context of the authorization grant.
> 
> On Fri, Jan 22, 2016 at 6:59 AM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Mike Jones <[email-masked]>
Date: Fri, 22 Jan 2016 01:04:25 +0000

I believe that it’s simpler and more elegant to return an issuer, from which the discovery metadata document can be retrieved, which contains *all* the configuration information about the authorization server, than to return some of the configuration parameters but not most of them (which is what the oauth-meta proposal does).  There’s lots more in a typical discovery document than just a few endpoint addresses.  For instance, there are statements about what response types are supported, other configuration choices, keys, etc.

I also think that returning the issuer is more future-proof than trying to decide now what all the configuration information is that might want to be verified by the client and hoping we get it right.  With the issuer, assuming that discovery is supported, it can retrieve and check all of it, should the client want/need to do so.  Even when discovery isn’t supported, the issuer still provides a concrete identifier for the authorization server that can be checked for equality.

We talked about the value of that approach in the side meetings in Yokohama and people were supportive then.

                                                                -- Mike

From: OAuth [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Thursday, January 21, 2016 4:48 PM
To: Nat Sakimura <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

John B.

On Jan 21, 2016, at 9:38 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:

  *   client_id response parameter does not help. There are legitimate cases that client_id duplicates out there and we cannot ban that.
  *   iss response parameter does not help unless the discovery is performed and the value of iss is checked against the value of OAuth issuer inside the document. (<- Discovery becomes mandatory. From our experience on RP discovery step in OpenID 2.0, chance of this being done properly seems to be rather slim.)
  *   sending the state to the token endpoint helps in the case code was stollen, but code should not be stolen to start with.
Cheers,

Nat

2016年1月22日(金) 7:59 John Bradley <[email-masked]<mailto:[email-masked]>>:
There have been a lot of discussions. I think Hannes posted some minutes of the F2F meeting we had with the security researchers.

That is my main concern.

John B.

On Jan 21, 2016, at 11:50 AM, Josh Mandel <[email-masked]<mailto:[email-masked]>> wrote:

On Jan 21, 2016 09:40, "Nat Sakimura" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Josh,

Cheers,

Nat

2016年1月21日(木) 23:04 Josh Mandel <[email-masked]<mailto:[email-masked]>>:
Apologies if this is the wrong forum for my comment (and please direct me to the appropriate place in that case), but I have two questions about the propose mitigation (and the thinking behind it) that I think the write-up could address:
1. Could the writeup clarify whether/how the primary "mixup" threat differs from what RFC6819 identifies as in section 4.6.4?
2. Has the workgroup considered a mitigation that puts more responsibility on the authorization server, and less on the client? For example, if would be helpful for the writeup to clarify why having the client send an "audience field" (in the terminology of RFC6819) to the authorization endpoint would not mitigate the threat. (In that scenario, the authorization server can recognize that the audience does not correspond to a resource server it knows, rather than asking clients to make this check). I assume this approach has been considered and rejected as an incomplete mitigation, but I don't have visibility into where/how that discussion went.
Thanks,
Josh
Hi all,

Ciao
Hannes & Derek

---

From: nov matake <[email-masked]>
Date: Fri, 22 Jan 2016 11:39:54 +0900

If the OAuth server supports discovery, “iss” can be used.
If not, attacker’s OAuth server can describe honest OAuth server’s “iss” in its developer document.

So returning “iss” would require discovery support NOW, not in the future.

> On Jan 22, 2016, at 10:04, Mike Jones <[email-masked]> wrote:
> 
> On Jan 21, 2016, at 9:38 PM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Hans Zandbelt <[email-masked]>
Date: Fri, 22 Jan 2016 10:11:37 +0100

+1 to everything Mike stated

Hans.

On 1/22/16 2:04 AM, Mike Jones wrote:
> I believe that it’s simpler and more elegant to return an issuer, from
> which the discovery metadata document can be retrieved, which contains
> **all** the configuration information about the authorization server,
> than to return some of the configuration parameters but not most of them
> (which is what the oauth-meta proposal does).  There’s lots more in a
> typical discovery document than just a few endpoint addresses. For
> instance, there are statements about what response types are supported,
> other configuration choices, keys, etc.
>
> I also think that returning the issuer is more future-proof than trying
> to decide now what all the configuration information is that might want
> to be verified by the client and hoping we get it right.  With the
> issuer, assuming that discovery is supported, it can retrieve and check
> all of it, should the client want/need to do so.  Even when discovery
> isn’t supported, the issuer still provides a concrete identifier for the
> authorization server that can be checked for equality.
>
> We talked about the value of that approach in the side meetings in
> Yokohama and people were supportive then.
>
>                                                                  -- Mike
>
> *From:*OAuth [mailto:[email-masked]] *On Behalf Of *John Bradley
> *Sent:* Thursday, January 21, 2016 4:48 PM
> *To:* Nat Sakimura <[email-masked]>
> *Cc:* [email-masked] WG <[email-masked]>
> There may be other evidence that RP will not do discovery, but if that
> is the case why are we doing a OAuth discovery spec?
>
>     Still doing the analysis. We spent 1.5 hours today with John,
>     George, nov and me on the OpenID Connect WG call on this issue. John
>     explained the mitigation, but none of us was convinced that it works.
>
>       * client_id response parameter does not help. There are legitimate
>       * iss response parameter does not help unless the discovery is
>         performed and the value of iss is checked against the value of
>         OAuth issuer inside the document. (<- Discovery becomes
>         mandatory. From our experience on RP discovery step in OpenID
>         2.0, chance of this being done properly seems to be rather slim.)
>       * sending the state to the token endpoint helps in the case code
>         was stollen, but code should not be stolen to start with.
>
>     Cheers,
>
>     Nat
>
>         There have been a lot of discussions. I think Hannes posted some
>         minutes of the F2F meeting we had with the security researchers.
>
>         The problem can’t be mitigated without some action on the client
>         side.  It boils down to the client making a request to AS1 (From
>         it’s perspective) and getting back a response from AS 2 (that it
>         thinks is AS1)
>
>         This can be done if AS1 is a good AS but has it’s logs
>         compromised so that an attacker can read them. Hans Zandbelt
>         built a proof of concept for the attack.
>
>         In some cases the attacker gets the code and the credential to
>         use it at the good AS token endpoint and in others it just gets
>         the code and can replay that at the client to extract
>         information from the API through the client by binding the api
>         access to a new account.
>
>         PKCE unfortunately mitigates a different attack, where the
>         client is impersonated and trys to replay a intercepted code.
>         It however assumes the token endpoint is good, and is no help in
>         the case of a compromised token endpoint.
>
>         The client in these attacks is vulnerable because it relies on
>         some local state, or the value of the state parameter to know
>         who the response is coming from.  This allows a authorization
>         request that is intercepted to be used to create a new request
>         in that browser to a different AS, or trick the client into
>         using a Authorization endpoint for a different authorization server.
>
>         One problem is that OAuth doesn’t really have a unified concept
>         of what a AS is.  Traditionally it is a Authorization endpoint
>         URI, token end point URI and resource server URI that some one
>         gives the client in some documentation.
>
>         As ling as a client only talks to one AS then there is no
>         problem.   However once a client is configured to talk to more
>         than one AS, we have problems if one of those AS lies about it’s
>         endpoints, or is compromised and used to attack another AS.   As
>         a design goal you don’t want the overall  security to be limited
>         by the weakest system.
>
>         One approach as Nat promotes is to have the authorization
>         endpoint return the next hop, token endpoint for code or RS URI
>         for token. The token endpoint must also return the RS URI or the
>         client must push the RS URI to the token endpoint or the
>         attacker just replaces the RS URI in the config and captures the
>         token that way.
>
>         The other way is to provide a name for each AS as part of
>         registration and the client not allow duplicate registrations
>         with the same name.  When the response comes back the client
>         checks the name against the one it made the request to. If the
>         name dereferences to a discovery document then the client can
>         check that name at registration or runtime to validate the net hops.
>
>         I think the two approaches mitigate the attack in similar ways.
>         Nat’s is more REST friendly and returns the next hop as a
>         parameter of header.
>
>         The one Mike and I wrote up based on the meeting in Germany
>         provides identifiers (iss and client_id) that can be checked for
>         validity in the simple case and be dereferenced via .well-known
>         to get the information Nat’s proposal is providing.
>
>         Perhaps the main difference is Nat is using the token endpoint
>         as the identifier for the AS and Mike’s is using location for a
>         discovery document as the identifier.
>
>         I don’t recall the reasons using the token endpoint as the
>         identifier was rejected at the meeting.  Perhaps others can post
>         the reasons.
>
>         We need to close on this quickly, otherwise if we are indecisive
>         fixes will not go into products for another year or so until
>         this is a RFC.
>
>         That is my main concern.
>
>         John B.
>
>             Thanks Nat - that's helpful. If both mitigations *can* work
>             effectively, then I would like to see this group consider
>             the decision between them carefully (if that hasn't happened
>             yet). Again, don't hesitate to let me know if this is the
>             wrong place/time for such discussion.
>
>             1. Most OAuth servers talk to many, many clients. So
>             consolidating the security critical work in one place
>             (server) is a net savings of work (rather than asking each
>             client to implement these checks.
>
>             2. OAuth server developers are typically more sophisticated
>             than client developers, and therefore more likely to
>             understand the implications and more likely to get these
>             critical details correct. Asking each client developer to do
>             something right is likely to result in heterogenius
>             implementation and persistent security holes. But if the
>             server does the heavy lifting, and clients just have to pass
>             along an extra parameter, this is more likely to see
>             consistent implementation (for example, clients will fail to
>             work if misconfigured, which will prompt developers to fix
>             them).
>
>                 Section 4.6.4 of the RFC6819 is the access token
>                 phishing by a counterfeit resource server.
>
>                 In my view, both can be mitigated by the server
>                 returning the next step: i.e., authorization endpoint
>                 returning the legitimate token endpoint uri, and token
>                 endpoint returning legitimate resource endpoint uris.
>                 This involves no discovery endpoint, which is good.
>
>                 Your way also works. It is just the reverse of my
>                 proposal. The difference being that my proposal does not
>                 need any coding on the server but just configuration,
>                 and it can return more metadata if needed.
>
>                 Cheers,
>
>                 Nat
>
>                     Apologies if this is the wrong forum for my comment
>                     (and please direct me to the appropriate place in
>                     that case), but I have two questions about the
>                     propose mitigation (and the thinking behind it) that
>                     I think the write-up could address:
>
>                     1. Could the writeup clarify whether/how the primary
>                     "mixup" threat differs from what RFC6819 identifies
>                     as in section 4.6.4?
>
>                     2. Has the workgroup considered a mitigation that
>                     puts more responsibility on the authorization
>                     server, and less on the client? For example, if
>                     would be helpful for the writeup to clarify why
>                     having the client send an "audience field" (in the
>                     terminology of RFC6819) to the authorization
>                     endpoint would not mitigate the threat. (In that
>                     scenario, the authorization server can recognize
>                     that the audience does not correspond to a resource
>                     server it knows, rather than asking clients to make
>                     this check). I assume this approach has been
>                     considered and rejected as an incomplete mitigation,
>                     but I don't have visibility into where/how that
>                     discussion went.
>
>                     Thanks,
>
>                     Josh
>
>                     Hi all,
>

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

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 23 Jan 2016 22:52:48 +0000

Since we have been discussing in another thread and you guys may be a aware
of it in this thread, here is one of the problem statement for the mix-up
draft explaining why it does not solve the problem as it is written now.

It can be fixed to solve the problem, but then the overhead size will be
much larger and involves an extra round trip compared to oauth-meta draft.

See
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
for the details.

Nat

---

From: William Denniss <[email-masked]>
Date: Sun, 24 Jan 2016 20:11:04 -0800

> an attacker can read them. Hans Zandbelt built a proof of concept for the

So for mix-up, we're only talking about a compromised logs attack and not a
completely compromised AS?

> and captures the token that way.

I believe the RS URI would not be needed to defeat the compromised logs
mix-up attack for the code flow. The client will send the client_id it got
when registering at AS1 to the token endpoint returned by AS2 (using Nat's
spec), which will then cause a failure due to client_id mis-match. So
simply returning the "token_endpoint" URI in the AS2 authorization response
would defeat the compromised-logs mix-up attack, would it not?

> rejected at the meeting.  Perhaps others can post the reasons.

Can you help clarify something that I've yet to discern from the minutes,
does OpenID Connect solve the mix-up attack by binding all the tokens
together and to the issuer via the ID Token?

We need to close on this quickly, otherwise if we are indecisive fixes will
> not go into products for another year or so until this is a RFC.
>
> That is my main concern.
>
> John B.
>
>
>
>
>

---

From: nov matake <[email-masked]>
Date: Mon, 25 Jan 2016 15:11:41 +0900

Hum, even if the client uses different redirect_uri per each IdP, code phishing attack succeeds in Nat’s sample attack scenario.
In such scenario, returning AuthZ endpoint URI as AuthZ response also won’t help.

So it seems returning “iss" (with discovery support) or oauth-meta is MUST for such case.

> On Jan 24, 2016, at 07:52, Nat Sakimura <[email-masked]> wrote:
> 
> Since we have been discussing in another thread and you guys may be a aware of it in this thread, here is one of the problem statement for the mix-up draft explaining why it does not solve the problem as it is written now. 
> 
> It can be fixed to solve the problem, but then the overhead size will be much larger and involves an extra round trip compared to oauth-meta draft. 
> 
> See http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/ <http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/> for the details. 
> 
> Nat
> 2016年1月22日(金) 18:11 Hans Zandbelt <[email-masked] <mailto:[email-masked]>>:
> > *From:*OAuth [mailto:[email-masked] <mailto:[email-masked]>] *On Behalf Of *John Bradley
> > *To:* Nat Sakimura <[email-masked] <mailto:[email-masked]>>
> > *Cc:* [email-masked] <mailto:[email-masked]> WG <[email-masked] <mailto:[email-masked]>>
> >     On Jan 21, 2016, at 9:38 PM, Nat Sakimura <[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >
> >     2016年1月22日(金) 7:59 John Bradley <[email-masked] <mailto:[email-masked]>
> >     <mailto:[email-masked] <mailto:[email-masked]>>>:
> >
> >             On Jan 21, 2016, at 11:50 AM, Josh Mandel <[email-masked] <mailto:[email-masked]>
> >             <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >
> >             On Jan 21, 2016 09:40, "Nat Sakimura" <[email-masked] <mailto:[email-masked]>
> >             <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> >
> >                 Hi Josh,
> >
> >                 2016年1月21日(木) 23:04 Josh Mandel <[email-masked] <mailto:[email-masked]>
> >                 <mailto:[email-masked] <mailto:[email-masked]>>>:
> >
> >                     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >                     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> >             [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]> | Ping Identity

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 25 Jan 2016 08:41:52 +0000

The token endpoint mix-up attack was originally discussed in the context
of OIDC, in August 2015. Back then John Bradley noted that by simply
replacing Basic client authentication with JWT (client_secret_jwt or
private_key_jwt) the attack is successfully prevented. Yes, the authz
code will be captured, but the bogus AS will not be able to replay it
with the legitimate AS because the JWT used for client authentication is
bound (via the "aud" claim) to the original token endpoint.

https://bitbucket.org/openid/connect/issues/979/discovery-security-considerations-csrf

http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication

Is this going to be added to the list of solutions? Its usefulness is
limited to confidential clients, but it's a good solution nevertheless.

JWT authentication helps in another case also - when the client by
mistake sends out the token request over plain HTTP.

Cheers,

Vladimir

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: "Nat Sakimura" <[email-masked]>
Date: Mon, 25 Jan 2016 18:52:21 +0900

Right, JWT client authentication prevents the “code phishing”. However, when you generalize it, it amounts to the phishing of any “bearer tokens”, including not only code+client_secret pair but also access token against resources. 

. 

So, the general solution would either be: 

1)     Let the client know which endpoint is the legitimate endpoint to receive the token authoritatively; OR

2)     Stop using bearer tokens and move to PoP tokens. 

So, I did not deal with the JWT client authentication option in my blog post. 

Cheers, 

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 Vladimir Dzhuvinov
Sent: Monday, January 25, 2016 5:42 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

The token endpoint mix-up attack was originally discussed in the context of OIDC, in August 2015. Back then John Bradley noted that by simply replacing Basic client authentication with JWT (client_secret_jwt or private_key_jwt) the attack is successfully prevented. Yes, the authz code will be captured, but the bogus AS will not be able to replay it with the legitimate AS because the JWT used for client authentication is bound (via the "aud" claim) to the original token endpoint.

Is this going to be added to the list of solutions? Its usefulness is limited to confidential clients, but it's a good solution nevertheless.

JWT authentication helps in another case also - when the client by mistake sends out the token request over plain HTTP.

Cheers,

Vladimir

 
 
See
 
Nat
2016年1月22日(金) 18:11 Hans Zandbelt  <mailto:[email-masked]> <[email-masked]>:

Hans.

 

                                                                 -- Mike
 
*From:*OAuth [mailto:[email-masked]] *On Behalf Of *John Bradley
*Sent:* Thursday, January 21, 2016 4:48 PM
*To:* Nat Sakimura  <mailto:[email-masked]> <[email-masked]>
*Cc:* [email-masked] <mailto:[email-masked]>  WG  <mailto:[email-masked]> <[email-masked]>
*Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

 

John B.
 
    On Jan 21, 2016, at 9:38 PM, Nat Sakimura <[email-masked] <mailto:[email-masked]> 
     <mailto:[email-masked]> <mailto:[email-masked]>> wrote:

    Then, after the call, I and nov went on with various scenarios. The
    interim conclusion is that:

    Cheers,
 
    Nat
 
    2016年1月22日(金) 7:59 John Bradley <[email-masked] <mailto:[email-masked]> 
     <mailto:[email-masked]> <mailto:[email-masked]>>:

 

 
        using a Authorization endpoint for a different authorization

server.

 
 
        check that name at registration or runtime to validate the net

hops.

 

 
        That is my main concern.
 
        John B.
 
            On Jan 21, 2016, at 11:50 AM, Josh Mandel <[email-masked] <mailto:[email-masked]> 
             <mailto:[email-masked]> <mailto:[email-masked]>> wrote:

            At a high level, I would rather ask server developers to do
            some "coding", for two reasons:

 
            On Jan 21, 2016 09:40, "Nat Sakimura" <[email-masked] <mailto:[email-masked]> 
             <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
 
                Hi Josh,

 
                The mix-up attack described here is the code phishing by
                a counterfeit token endpoint.

 
                Cheers,
 
                Nat
 
                2016年1月21日(木) 23:04 Josh Mandel <[email-masked] <mailto:[email-masked]> 
                 <mailto:[email-masked]> <mailto:[email-masked]>>:

 
 
                    Thanks,
 
                    Josh
 
                    Hi all,
 
                    this is the call for adoption of OAuth 2.0 Mix-Up
                    Mitigation, see

                    Please let us know by Feb 9th whether you accept /
                    object to the
                    adoption of this document as a starting point for
                    work in the OAuth
                    working group.
 
                    Note: This call is related to the announcement made
                    on the list earlier
                    this month, see

http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html.

                    More
                    time for analysis is provided due to the complexity
                    of the topic.
 
                    Ciao
                    Hannes & Derek

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

 

-- 
Vladimir Dzhuvinov :: [email-masked] <mailto:[email-masked]>

---

From: John Bradley <[email-masked]>
Date: Mon, 25 Jan 2016 11:11:24 -0300

The mixup attack where the client is confused about who the response is coming from is posable both by providing bad configuration information and by compromising a existing AS.

The point was that telling clients to only register with “good” AS or somehow validating the configuration information is not sufficient to stop the attack.

If a AS is completely compromised you would be able to do the same attack.   In principal the OAuth protocol should not intertwine the security of different AS so that if one is compromised it degrades the security of all the others.

You are correct that in the compromised log flow the RS would not be able to leak the token unless it is compromised as well or the introspection endpoint on the AS is. 

Given that the log attack is just one example we do also want to cover the ones where a client is given bad discovery information with a evil RS.   

This RS attack is not dissimilar to the attack that Eran was concerned about  where a client starts at the RS and gets a insufficient_scope error and then goes to it’s AS and requests a token with a new scope.
This would also be an example of client becoming confused about who it is dealing with.  I recall that bearer took the URI of the Authorization endpoint URI out of the error response to prevent that.
It is also not the current pattern to start with the resource except in UMA that might have an issue (it is probably mitigated some other way George can comment, he know the UMA spec)

The ways that I can think of to avoid the confused client RS attack are:
1. Proof of Possession tokens.  That was Eran’s solution, and there are other good reasons to do it and the work is already chartered, but perhaps overkill for many applications.

2. AS based Discovery where the RS are listed in the AS discovery document.  This is what Connect provides with the “userinfo_endpoint” claim in discovery.   This depends on having a logical identifier for the AS.

3. Providing the URI of the resource the token is being requested for in the token request.  This is what the “aud" parameter in POP key distribution is doing (that may wind up as a separate spec if adopted)

4. Providing the list of URI that the token can be used at in the response from the token endpoint.   This is basically Nat’s proposal.

Certainly some combination of them is also possible.

Connect provides mitigation for the mix up attack in some flows, specifically “code id_token” “token id_token” and “code token id_token”.

The mitigation doesn’t work for the code flow, because the client sends the code to the token endpoint before it can validate the id_token. 

Returning the iss and client_id from the authorization endpoint per Mike’s draft allows the client to reject the authorization response and not leak the code.

John B.

On Jan 25, 2016, at 1:11 AM, William Denniss <[email-masked]> wrote:
> 
> 
> On Thu, Jan 21, 2016 at 2:59 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> So for mix-up, we're only talking about a compromised logs attack and not a completely compromised AS?
>  
> I believe the RS URI would not be needed to defeat the compromised logs mix-up attack for the code flow. The client will send the client_id it got when registering at AS1 to the token endpoint returned by AS2 (using Nat's spec), which will then cause a failure due to client_id mis-match. So simply returning the "token_endpoint" URI in the AS2 authorization response would defeat the compromised-logs mix-up attack, would it not? 
>  
> Can you help clarify something that I've yet to discern from the minutes, does OpenID Connect solve the mix-up attack by binding all the tokens together and to the issuer via the ID Token?
> 
> 
[snip]  For readability of a long thread.

---

From: John Bradley <[email-masked]>
Date: Mon, 25 Jan 2016 11:35:20 -0300

Using client secret JWT works as long as long as the attacker doesn’t know the client secret of the client_id associated with the “good AS”.  
The reason is that the attacker cannot replay a signed assertion because it contains a audience and client_id that would not match.

In the case where the “bad AS” gets the client to register and can proxy that registration and create a new client_id at the “good AS” with the client’s redirect URI, than this mitigation would not work.
The bad AS would just use the client credential stolen in the proxy registration to create a new authentication to the token endpoint.

While as a general principal not giving the attacker your credential unencrypted on the wire is a very good thing, if the attacker man in the middles the registration then this won’t help.

We did discuss this in Germany.  It was also felt that forcing clients to do crypto was overkill. 

Standardizing doing client secret JWT authentication in OAuth would be a good thing, but should be separate.

Based on the assertions draft you only need to define how to use the keys and what the values for aud is in the non connect case (I suspect the token endpoint URI would be the obvious choice but someone needs to write it down to be interoperable). 

John B.

> On Jan 25, 2016, at 5:41 AM, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
> https://bitbucket.org/openid/connect/issues/979/discovery-security-considerations-csrf <https://bitbucket.org/openid/connect/issues/979/discovery-security-considerations-csrf>
> 
> http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication <http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication>
> 
> 
>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/ <http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/>
>> for the details.
>> 
>> Nat
>> 2016年1月22日(金) 18:11 Hans Zandbelt <[email-masked]> <mailto:[email-masked]>:
>> 
>>>> *To:* Nat Sakimura <[email-masked]> <mailto:[email-masked]>
>>>> *Cc:* [email-masked] <mailto:[email-masked]> WG <[email-masked]> <mailto:[email-masked]>
> Vladimir Dzhuvinov :: [email-masked] <mailto:[email-masked]>_______________________________________________
> OAuth mailing list
> [email-masked]

---

From: George Fletcher <[email-masked]>
Date: Mon, 25 Jan 2016 10:30:10 -0500

I'm still catching up... but to this point specifically...

Doesn't this require that the same client_id NOT be used simultaneously 
at two (or more) Authorization Servers? If so, I don't believe that is a 
viable option. It's a little late in the game to be putting requirements 
on the AS as to how it generates it's client_id.

Thanks,
George

On 1/25/16 9:11 AM, John Bradley wrote:
>
> Returning the iss and client_id from the authorization endpoint per 
> Mike’s draft allows the client to reject the authorization response 
> and not leak the code.

---

From: John Bradley <[email-masked]>
Date: Mon, 25 Jan 2016 14:32:01 -0300

No, client id_are scoped by issuer.  

There is no need for AS to make the client_id globally unique.

 The client needs to not allow two AS to provide it with the same issuer client_id pair.

That would probably be imposable for many clients anyway. 

For Connect clients typically manage configurations using issuer as the primary key.  I doubt may would support even two client_id from the same issuer.

For OAuth what clients do is slightly less clear.  In general they don’t have more than one AS per API do might try and organize things by RS or AS.

In principal a OAuth client might have two different AS each with a different client ID and that will be OK as long as the client_id in the request is the same as the one in the response.

So going to a new AS and getting back the same iss and client_id that you registered someplace else would be an error for the client.

I don’t think that is unreasonable.

John B.

> On Jan 25, 2016, at 12:30 PM, George Fletcher <[email-masked]> wrote:
> 
> Doesn't this require that the same client_id NOT be used simultaneously at two (or more) Authorization Servers? If so, I don't believe that is a viable option. It's a little late in the game to be putting requirements on the AS as to how it generates it's client_id.
> 
> Thanks,
> George
>

---

From: George Fletcher <[email-masked]>
Date: Mon, 25 Jan 2016 13:10:42 -0500

Comments inline

> No, client id_are scoped by issuer.
This makes sense, but I'm not sure it's a current assumption by OAuth2 
implementations :)
> That would probably be imposable for many clients anyway.
I would rather say that the results of two client_ids being the same 
from two different issuers is undefined.
>
> For Connect clients typically manage configurations using issuer as 
> the primary key.  I doubt may would support even two client_id from 
> the same issuer.
If scoped by issuer this makes sense, though the concept of "issuer" as 
a comparable entity wasn't really talked about with OAuth2.
>
> For OAuth what clients do is slightly less clear.  In general they 
> don’t have more than one AS per API do might try and organize things 
> by RS or AS.
I agree that not many clients support dynamic client registration. 
However, I would say there a number that support multiple AS that are 
"fixed" within the code (including fixed endpoint URIs). So I would say 
that the associations would be fixed in code. There wouldn't necessarily 
be an association outside of the code which maps button A to AS1 and 
button B to AS2.
>
> In principal a OAuth client might have two different AS each with a 
> different client ID and that will be OK as long as the client_id in 
> the request is the same as the one in the response.
>
> So going to a new AS and getting back the same iss and client_id that 
> you registered someplace else would be an error for the client.
>
I agree that this is reasonable with the assumption that client_id's are 
scoped by "issuer". It's just likely that most clients in the field do 
not have this sort of explicit association. The OAuth2 Dynamic Client 
Registration spec does not define an "issuer" in the response. For the 
OAuth2 use cases, what is the proposed "issuer" equivalent URI that is 
being used to scope the client_id?
>
> John B.
>
>
>> On Jan 25, 2016, at 12:30 PM, George Fletcher <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Doesn't this require that the same client_id NOT be used 
>> simultaneously at two (or more) Authorization Servers? If so, I don't 
>> believe that is a viable option. It's a little late in the game to be 
>> putting requirements on the AS as to how it generates it's client_id.
>>
>> Thanks,
>> George
>>

---

From: John Bradley <[email-masked]>
Date: Mon, 25 Jan 2016 15:22:21 -0300

The presumption is that registration would need to add a issuer, as an identifier of the AS, and that would be optionally be used in discovery.

OAuth as is supports the single AS model.

To support multiple AS for a single client something needs to change.    Adding issuer and client_id to the response with optional discovery was seen as the least disruptive at the Germany meeting.

 The other way to do it is to return discovery info from the the authorization and token endpoints, however the request probably also need to be modified so that the AS knows what the resource is, otherwise 
other things will break.    

It is possible now to have one authorization endpoint provide code for per Tennent token endpoints.(No I don’t know of any one doing it).

Anything we add to tighten up the trust model will have impacts on what can be done with OAuth.  

John B.
> On Jan 25, 2016, at 3:10 PM, George Fletcher <[email-masked]> wrote:
> 
> Comments inline
> 
> This makes sense, but I'm not sure it's a current assumption by OAuth2 implementations :)
>> 
> I would rather say that the results of two client_ids being the same from two different issuers is undefined.
>> 
> If scoped by issuer this makes sense, though the concept of "issuer" as a comparable entity wasn't really talked about with OAuth2.
>> 
> I agree that not many clients support dynamic client registration. However, I would say there a number that support multiple AS that are "fixed" within the code (including fixed endpoint URIs). So I would say that the associations would be fixed in code. There wouldn't necessarily be an association outside of the code which maps button A to AS1 and button B to AS2.
>> 
> I agree that this is reasonable with the assumption that client_id's are scoped by "issuer". It's just likely that most clients in the field do not have this sort of explicit association. The OAuth2 Dynamic Client Registration spec does not define an "issuer" in the response. For the OAuth2 use cases, what is the proposed "issuer" equivalent URI that is being used to scope the client_id? 
>> 
>> John B.
>> 
>> 
>>> On Jan 25, 2016, at 12:30 PM, George Fletcher <[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: George Fletcher <[email-masked]>
Date: Mon, 25 Jan 2016 13:39:41 -0500

So now, in addition to the dynamic client registration spec, the client 
would need to support OAuth2 Discovery.

I guess my concern is that it feels like we are adding a lot of little 
things to try and mitigate these attacks in OAuth2 and it's confusing 
when they are needed and when they aren't.

For me it would be simpler to say that OAuth2 with a single 
pre-configured AS is fine. If a client wants to support multiple 
Authorization Servers (a la dynamic client registration or some other 
method) then here are all the things that need to be done. Maybe this 
would be simpler as a profile of OAuth2 (in the vein of OpenID Connect) 
that adds the necessary requirements to mitigate these attacks.

This way an OAuth2 developer knows which spec to follow based on their 
requirements and all the necessary steps would be in "one" place.

Thanks,
George

On 1/25/16 1:22 PM, John Bradley wrote:
> The presumption is that registration would need to add a issuer, as an 
> identifier of the AS, and that would be optionally be used in discovery.
>
> To support multiple AS for a single client something needs to change. 
>    Adding issuer and client_id to the response with optional discovery 
> was seen as the least disruptive at the Germany meeting.
>
>  The other way to do it is to return discovery info from the the 
> authorization and token endpoints, however the request probably also 
> need to be modified so that the AS knows what the resource is, otherwise
> other things will break.
>
> It is possible now to have one authorization endpoint provide code for 
> per Tennent token endpoints.(No I don’t know of any one doing it).
>
>> On Jan 25, 2016, at 3:10 PM, George Fletcher <[email-masked] 
>> If scoped by issuer this makes sense, though the concept of "issuer" 
>> as a comparable entity wasn't really talked about with OAuth2.
>>>
>> "fixed" within the code (including fixed endpoint URIs). So I would 
>> say that the associations would be fixed in code. There wouldn't 
>> necessarily be an association outside of the code which maps button A 
>> to AS1 and button B to AS2.
>>>
>>> So going to a new AS and getting back the same iss and client_id 
>>> that you registered someplace else would be an error for the client.
>>>
>> I agree that this is reasonable with the assumption that client_id's 
>> are scoped by "issuer". It's just likely that most clients in the 
>> field do not have this sort of explicit association. The OAuth2 
>> Dynamic Client Registration spec does not define an "issuer" in the 
>> response. For the OAuth2 use cases, what is the proposed "issuer" 
>> equivalent URI that is being used to scope the client_id?
>>>
>>> John B.
>>>
>>>
>>>> simultaneously at two (or more) Authorization Servers? If so, I 
>>>> don't believe that is a viable option. It's a little late in the 
>>>> game to be putting requirements on the AS as to how it generates 
>>>> it's client_id.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>>> Returning the iss and client_id from the authorization endpoint 
>>>>> per Mike’s draft allows the client to reject the authorization 
>>>>> response and not leak the code.
>>>>
>>>
>>
>> -- 
>> 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: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 25 Jan 2016 10:58:21 -0800

I recall making this point in Germany. 99% of existing use is fine. OIDC is probably the largest community that *might* have an issue. 

I recall proposing a new security document that covers oauth security for dynamic scenarios. "Dynamic" being broadly defined to mean:
* clients who have configured at runtime or install time (including clients that do discovery)
* clients that communicate with more than one endpoint
* clients that are deployed in large volume and may update frequently (more discussion of "public" cases)
* clients that are script based (loaded into browser on the fly)
* others?

Phil

> On Jan 25, 2016, at 10:39, George Fletcher <[email-masked]> wrote:
> 
> would

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 25 Jan 2016 22:58:44 +0000

Hi Phil,

Since I was not in Darmstadt, I really do not know what was discussed
there, but with the compromised developer documentation described in
http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/, all
RFC6749 clients with a naive implementer will be affected. The client does
not need to be talking to multiple IdPs.

Nat

2016年1月26日(火) 3:58 Phil Hunt (IDM) <[email-masked]>:

> I recall making this point in Germany. 99% of existing use is fine. OIDC
> is probably the largest community that *might* have an issue.
>
> I recall proposing a new security document that covers oauth security for
> dynamic scenarios. "Dynamic" being broadly defined to mean:

---

From: Justin Richer <[email-masked]>
Date: Mon, 25 Jan 2016 18:53:33 -0500

+1

> On Jan 25, 2016, at 1:39 PM, George Fletcher <[email-masked]> wrote:
> 
> So now, in addition to the dynamic client registration spec, the client would need to support OAuth2 Discovery.
> 
> I guess my concern is that it feels like we are adding a lot of little things to try and mitigate these attacks in OAuth2 and it's confusing when they are needed and when they aren't.
> 
> For me it would be simpler to say that OAuth2 with a single pre-configured AS is fine. If a client wants to support multiple Authorization Servers (a la dynamic client registration or some other method) then here are all the things that need to be done. Maybe this would be simpler as a profile of OAuth2 (in the vein of OpenID Connect) that adds the necessary requirements to mitigate these attacks.
> 
> This way an OAuth2 developer knows which spec to follow based on their requirements and all the necessary steps would be in "one" place.
> 
> Thanks,
> George
> 
>>> On Jan 25, 2016, at 3:10 PM, George Fletcher <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Comments inline
>>>