Subject: [OAUTH-WG] Use cases for Audience Restricted tokens + AS and RS "discovery"

From: George Fletcher <[email-masked]>
Date: Thu, 17 Mar 2016 13:37:24 -0400

Goals:

1. Help the client not send a token to the "wrong" endpoint
    a. wrong AS /token endpoint
    b. evil RS endpoint(s)
2. Allow good RS to determine if the token being validated was intended 
for that RS

Other high-level goals?

Use cases:

1. RS that supports multiple AS (we've had this in production since 2011)
2. RS rejects token not issued for use at the RS
3. Client that dynamically supports new RS (say any client that supports 
the jabber API)
4. Client that dynamically supports new AS

Feel free to add to the list :)

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 18 Mar 2016 07:09:38 +0000

Note that goal #2 is already taken care of by introspection (endpoint
varying response depending on authenticated client/RS), so maybe should be
refined here.

Le jeu. 17 mars 2016 18:44, George Fletcher <[email-masked]> a écrit :

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

---

From: George Fletcher <[email-masked]>
Date: Fri, 18 Mar 2016 08:50:48 -0400

I was thinking of goal #2 as addressing the issue of audience in the 
token. If the RS "authenticates" itself when calling introspection, then 
the AS could apply the audience restriction for the RS. Is that what you 
were thinking?

On 3/18/16 3:09 AM, Thomas Broyer wrote:
> varying response depending on authenticated client/RS), so maybe 
> should be refined here.
>
>
> Le jeu. 17 mars 2016 18:44, George Fletcher <[email-masked] 
> <mailto:[email-masked]>> a écrit :
>
>     Goals:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Fri, 18 Mar 2016 09:00:04 -0400

I'm with George. You can do introspection with no audience restriction. 
We implemented introspection with only scope restriction from the RS.

  -- Justin

On 3/18/2016 8:50 AM, George Fletcher wrote:
> token. If the RS "authenticates" itself when calling introspection, 
> then the AS could apply the audience restriction for the RS. Is that 
> what you were thinking?
>

---

From: Thomas Broyer <[email-masked]>
Date: Fri, 18 Mar 2016 13:59:12 +0000

> the AS could apply the audience restriction for the RS. Is that what you

Yes (or I think so).
Scopes are declared in relation to "applications" (which can be either
clients or RS), and our introspection endpoint returns {"active":false} if
there's no matching scopes between what the "application" has declared and
those of the token.
We actually do "scope restriction" (only returning the scopes related to
the requesting application), with the added rule that if there's no scope
left we return {"active":false} rather than an empty list of scopes.

---

From: George Fletcher <[email-masked]>
Date: Fri, 18 Mar 2016 10:14:34 -0400

This is pretty much what we do today as well.  The additional goal is to 
specifically bind tokes to a particular resource outside the context of 
the scope value. Just like in SAML, the RS would not process any token 
which was not specifically created for use with that RS. So it's an 
additional layer of protection beyond scopes.

Thanks,
George

On 3/18/16 9:59 AM, Thomas Broyer wrote:
>
>
> On Fri, Mar 18, 2016 at 1:50 PM George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I was thinking of goal #2 as addressing the issue of audience in
>     the token. If the RS "authenticates" itself when calling
>     introspection, then the AS could apply the audience restriction
>     for the RS. Is that what you were thinking?
>
>
> Yes (or I think so).
> clients or RS), and our introspection endpoint returns 
> {"active":false} if there's no matching scopes between what the 
> "application" has declared and those of the token.
> We actually do "scope restriction" (only returning the scopes related 
> to the requesting application), with the added rule that if there's no 
> scope left we return {"active":false} rather than an empty list of scopes.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 18 Mar 2016 16:04:36 -0600

The "a. wrong AS /token endpoint" is the mix-up issue, which can be
mitigated by returning an identifier for the AS in the authorization
response. It is something that needs to be addressed but "discovery" or
metadata aren't needed and audience restricted access tokens tokens don't
help.

Maybe that's obvious but there seems to be a lot of confusion on all this
so I wanted to reiterate it.

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Fri, 18 Mar 2016 15:27:51 -0700

There are two variations. 

Mitm the token endpoint is different then working one legit token endpoint against another thru redirect and state misdirection. 

In the mitm version you don't need multiple AS's.

Phil

> On Mar 18, 2016, at 15:04, Brian Campbell <[email-masked]> wrote:
> 
> The "a. wrong AS /token endpoint" is the mix-up issue, which can be mitigated by returning an identifier for the AS in the authorization response. It is something that needs to be addressed but "discovery" or metadata aren't needed and audience restricted access tokens tokens don't help.
> 
> Maybe that's obvious but there seems to be a lot of confusion on all this so I wanted to reiterate it.
> 
>> 2. Allow good RS to determine if the token being validated was intended for that RS
>> 
>> Other high-level goals?
>> 
>> Use cases:
>> 
>> 3. Client that dynamically supports new RS (say any client that supports the jabber API)

---

From: Brian Campbell <[email-masked]>
Date: Fri, 18 Mar 2016 16:38:57 -0600

How does one Mitm the token endpoint?

On Fri, Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

> Mitm the token endpoint is different then working one legit token endpoint
> against another thru redirect and state misdirection.
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 18 Mar 2016 15:52:41 -0700

By convincing the client to use a bad URL.  That’s kinda why we’re worried about bad discovery no?

Depending on the type of client authentication, the client will establish a valid connection to the hacker’s proxy which then replays the token request to the real endpoint.  The hacker now has the token.

Same thing for the resource endpoint - except worse. The hacker doesn’t need the token as they now see the payload.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Mar 18, 2016, at 3:38 PM, Brian Campbell <[email-masked]> wrote:
> 
> On Fri, Mar 18, 2016 at 4:27 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
> On Mar 18, 2016, at 15:04, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Thu, Mar 17, 2016 at 11:37 AM, George Fletcher <[email-masked] <mailto:[email-masked]>> wrote:
>> Goals:
>> 
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: John Bradley <[email-masked]>
Date: Fri, 18 Mar 2016 20:01:00 -0300

The Mitigation we agreed on for the bad token endpoint is returning the issuer and client_id form the authorization endpoint.

Phil are you saying that you no longer agree with that? 

The question that was unresolved was how the client would get a bad resource URI, and what the correct mitigation is if any.

John B.

> On Mar 18, 2016, at 7:52 PM, Phil Hunt <[email-masked]> wrote:
> 
>> On Mar 18, 2016, at 3:38 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: John Bradley <[email-masked]>
Date: Fri, 18 Mar 2016 20:16:59 -0300

You still have a good AS and a bad AS it is just that the bad AS is using the good AS’s authorization endpoint.

I guess it comes down to how you define what a AS is if it is malicious.

Remember all of the attacks postulated in the papers require a xsrf attack or man in the network to cause a client to start a authorization with the bad AS triggering bad discovery and registration.

If the bad AS is publishing a malicious RS and the “good” registration, authorization, and token endpoints.   It will have a different issuer from the 
good AS authorization endpoint.   When the client performs authorization thinking it is going to bad AS and gets back the issuer for good AS that will trigger an error in the client and it will never present the AT to the bad RS’s resource endpoint.

If the developer hard codes some bad RS endpoint in the client then, I admit returning the iss and client_id from the authorization endpoint won’t help.

John B.

> On Mar 18, 2016, at 7:27 PM, Phil Hunt (IDM) <[email-masked]> wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 18 Mar 2016 16:19:03 -0700

John,

I haven’t changed my mind. But I now think we’ve come away with a different understanding of the threats.

I recall that we agreed that “iss” and “client_id” are for mitigating mix-up, by allowing a client to figure out what token endpoint a grant is for.  There is nothing that helps a client to determine that the token endpoint it is about to use is valid.  IOW. The client could have the correct “iss” and “client_id” from the AS authorization endpoint, but it thinks it is supposed to pass the grant to token.evil.com instead of token.example.com to redeem it.

Phil

@independentid

> On Mar 18, 2016, at 4:01 PM, John Bradley <[email-masked]> wrote:
> 
>> On Mar 18, 2016, at 7:52 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 18 Mar 2016 16:28:23 -0700

John

You are trying to solve a completely different problem.

In the bad discovery scenario there is no good AS and bad AS.

1.  There is only one AS and one RS infrastrucutre

2.  The client is mis-configured because it has been given a bad endpoint for one of dyn-reg, token, or resource

The client has no way to know what constitutes a valid set of endpoints.

The AS is acting in good faith in all respects.  It become promiscuous because it is turning over grants and/or tokens over to clients that are sending them to a bad endpoint.

Phil

@independentid

> On Mar 18, 2016, at 4:16 PM, John Bradley <[email-masked]> wrote:
> 
>> On Mar 18, 2016, at 7:27 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: John Bradley <[email-masked]>
Date: Fri, 18 Mar 2016 20:29:27 -0300

The mitigation prevents the client from sending the code to a token endpoint that is not associated with the AS returning the code.

I think you need to describe a MiTM attack on the token endpoint that the proposed mitigation that was reviewed by the researchers doesn’t mitigate.

You seem to have defined some new attacks as not being the confused client attacks that you are trying to mitigate.

Perhaps not understanding the attack is causing some of us to not understand the value of the mitigation you propose.

John B.

> On Mar 18, 2016, at 8:19 PM, Phil Hunt <[email-masked]> wrote:
> 
> John,
> 
> I recall that we agreed that “iss” and “client_id” are for mitigating mix-up, by allowing a client to figure out what token endpoint a grant is for.  There is nothing that helps a client to determine that the token endpoint it is about to use is valid.  IOW. The client could have the correct “iss” and “client_id” from the AS authorization endpoint, but it thinks it is supposed to pass the grant to token.evil.com <http://token.evil.com/> instead of token.example.com <http://token.example.com/> to redeem it.
> 
> Phil
> 
> @independentid
>> On Mar 18, 2016, at 4:01 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: John Bradley <[email-masked]>
Date: Fri, 18 Mar 2016 20:43:44 -0300

Phil someone is giving the client the bad endpoints.  From the perspective of the client that is an AS.

I count that as two entities one good and one bad.

We agreed not to force clients to do discovery.  

How is the client being given this bad set of endpoints?

If it is being given them by dereferencing a issuer to get the .well-known then the mitigation will stop the attack because the two issuers can’t be the same unless the attacker has compromised the good AS’s .well-known, and that I would argue is a different problem.

John B.

> On Mar 18, 2016, at 8:28 PM, Phil Hunt <[email-masked]> wrote:
> 
> John
> 
>> On Mar 18, 2016, at 4:16 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>