Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Hans Zandbelt]

+1, I've found the very same in OAuth deployments that I was involved 
in; the hard part is to give names and descriptions to these concepts so 
that they cover all use cases and can be applied unambiguously


Hans.

On 3/14/16 10:44 PM, Justin Richer wrote:

I agree that this is valuable, and not just for PoP. In all honesty,
it’s not even really required for PoP to function in many cases — it’s
just an optimization for one particular kind of key distribution
mechanism in that case.

In the years of deployment experience with OAuth 2, I think we’ve really
got three different kinds of things that currently get folded into
“scope” that we might want to try separating out better:


  - What things do I want to access? (photos, profile)
  - What actions do I want to take on these things? (read, write, delete)
  - How long do I want these tokens to work?
(offline_access/refresh_token, one time use, next hour, etc)


I think the first one is close to the audience/resource parameters that
have been bandied about a few times, including in the current token
exchange document. We should be consistent across drafts in that regard.
The second is more traditional scope-ish. The third has been patched in
with things like “offline_access” in certain APIs.

Just another vector to think about if we’re going to be adding things
like “audience” or “resource” or both to the token requests.

  — Justin



On Mar 14, 2016, at 6:26 PM, John Bradley mailto:ve7...@ve7jtb.com>> wrote:

Yes I will work on another proposal for allowing clients to specify
what resource they want a token for and providing the meta-data to the
client about the resources that a token is valid for.

We have part of it in the POP key distribution spec and talked about
separating it, as it is used more places than just for assigning keys.
I know some AS use different token formats for different RS so are
all-ready needing to pass the resource in the request to avoid making
a mess of scopes.

John B.






On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) mailto:phil.h...@oracle.com>> wrote:

Inline

Phil

On Mar 14, 2016, at 14:13, John Bradley mailto:ve7...@ve7jtb.com>> wrote:


We had two mandates.  One was to provide a spec for AS metadata.
The other was to mitigate the client mixup attack.  The request was
to do the latter without requiring the former for clients that don’t
otherwise need discovery.

There is no mandate for any of this. See
http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt


Returning the issuer and client_id from the authorization endpoint
and the client checking them can be done by the client without
discovery.


How does this address the issue of whether the client is talking to
the wrong endpoint?


Any client that has the resource and issuer hard coded probably
doesn’t need discovery.

We agree



One of the things that a client will need discovery for is to find
the RS, so requiring the client to know the RS URI before getting
the AS config seems backwards to me.

How can you make an assumption on order? You seem to be conflating
authentication with authorization by assuming the identity drives
what the resource is.

There are lots of applications that require user rights but are not
identify centric. For example a document service.


Unless the client tells the AS where it intends to use the token we
will be leaving a security hole because the bearer tokens will have
too loose an audience if they have one at all.

This is the biggest risk we have IMHO.


True you are telling the AS (Webfinger service) what the RS is but
that is not at a place that is useful in the token production process.


This has nothing to do with token production.

What we want to ensure is whether an honest client is correctly
configured and has not been mislead - eg by a phishing page.


I also think there are use cases where the AS doesn’t know all the
possible RS.   That is not something that a out of band check can
address.


May be. Lets identify them.


There are also cases where a token might be good at multiple RS
endpoints intentionally.



 In your solution the client would need to make a discovery request
for each endpoint.

Sure. Otherwise how would it know if there is one AS or a pool of AS
servers assigned to each instance?

Those requests lack the context of who the client and resource owner
are.  I think that will be a problem in some use cases.


Not sure I agree. This is about discovering a valid set of endpoints.
For mitm, we mainly want to check the hostname is correct. If a
client chooses evil.com  the cert can be valid and
TLS will pass. How does it otherwise know it is supposed to talk to
res.example.com ?


If this is added to the token endpoint it would be checked when code
or refresh are exchanged, not every time the token is used.

Your proposal requires rhe client to check. I am not clear how the AS
can know the exact uri. It is far easier to validate than to lookup

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[John Bradley]

Yes Brian and I discussed the reasons for separating 
audience/resource/destination from scope yesterday, and how that might impact 
token exchange and the need to align.

I think this is a core problem that needs to be addressed.   

The mixup at the resource is posable because scope is too overloaded.  Unless 
scopes were structured the client can’t tell what resource servers apply to a 
given scope.
The AS winds up applying the wrong audience to the AT, and the client has no 
way to tell.

There is no problem with giving a AT to a bad  or unknown RS.  That needs to be 
made safe by putting the correct audience in the AT.  
To do that the AS needs to know where the client is going to use the token so 
it can produce the correct token type and include the correct audience.

I agree that we also see a lot of hacks around using scopes and other 
mechanisms to indicate requested token validity time.

Scope is too overloaded, and we don’t return sufficient token meta-data with 
the opaque tokens.   
We need to address the core problem and not patch a symptom by adding external 
discovery.

John B.



> On Mar 14, 2016, at 7:44 PM, Justin Richer  wrote:
> 
> I agree that this is valuable, and not just for PoP. In all honesty, it’s not 
> even really required for PoP to function in many cases — it’s just an 
> optimization for one particular kind of key distribution mechanism in that 
> case. 
> 
> In the years of deployment experience with OAuth 2, I think we’ve really got 
> three different kinds of things that currently get folded into “scope” that 
> we might want to try separating out better:
> 
> 
>  - What things do I want to access? (photos, profile)
>  - What actions do I want to take on these things? (read, write, delete)
>  - How long do I want these tokens to work? (offline_access/refresh_token, 
> one time use, next hour, etc)
> 
> 
> I think the first one is close to the audience/resource parameters that have 
> been bandied about a few times, including in the current token exchange 
> document. We should be consistent across drafts in that regard. The second is 
> more traditional scope-ish. The third has been patched in with things like 
> “offline_access” in certain APIs.
> 
> Just another vector to think about if we’re going to be adding things like 
> “audience” or “resource” or both to the token requests.
> 
>  — Justin
> 
> 
>> On Mar 14, 2016, at 6:26 PM, John Bradley > > wrote:
>> 
>> Yes I will work on another proposal for allowing clients to specify what 
>> resource they want a token for and providing the meta-data to the client 
>> about the resources that a token is valid for.
>> 
>> We have part of it in the POP key distribution spec and talked about 
>> separating it, as it is used more places than just for assigning keys.   
>> I know some AS use different token formats for different RS so are all-ready 
>> needing to pass the resource in the request to avoid making a mess of scopes.
>> 
>> John B.
>> 
>> 
>> 
>> 
>> 
>>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) >> > wrote:
>>> 
>>> Inline
>>> 
>>> Phil
>>> 
>>> On Mar 14, 2016, at 14:13, John Bradley >> > wrote:
>>> 
 We had two mandates.  One was to provide a spec for AS metadata.   The 
 other was to mitigate the client mixup attack.  The request was to do the 
 latter without requiring the former for clients that don’t otherwise need 
 discovery.
>>> There is no mandate for any of this. See 
>>> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt 
>>> 
 
 Returning the issuer and client_id from the authorization endpoint and the 
 client checking them can be done by the client without discovery. 
>>> 
>>> How does this address the issue of whether the client is talking to the 
>>> wrong endpoint?
 
 Any client that has the resource and issuer hard coded probably doesn’t 
 need discovery.  
>>> We agree
>>> 
>>> 
 One of the things that a client will need discovery for is to find the RS, 
 so requiring the client to know the RS URI before getting the AS config 
 seems backwards to me. 
>>> How can you make an assumption on order? You seem to be conflating 
>>> authentication with authorization by assuming the identity drives what the 
>>> resource is. 
>>> 
>>> There are lots of applications that require user rights but are not 
>>> identify centric. For example a document service. 
 
 Unless the client tells the AS where it intends to use the token we will 
 be leaving a security hole because the bearer tokens will have too loose 
 an audience if they have one at all.
>>> This is the biggest risk we have IMHO. 
 
 True you are telling the AS (Webfinger service) what the RS is but that is 
 not at a place that is useful in the token production process.
>>> 
>>> This has 

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Justin Richer]

I agree that this is valuable, and not just for PoP. In all honesty, it’s not 
even really required for PoP to function in many cases — it’s just an 
optimization for one particular kind of key distribution mechanism in that case.

In the years of deployment experience with OAuth 2, I think we’ve really got 
three different kinds of things that currently get folded into “scope” that we 
might want to try separating out better:


 - What things do I want to access? (photos, profile)
 - What actions do I want to take on these things? (read, write, delete)
 - How long do I want these tokens to work? (offline_access/refresh_token, one 
time use, next hour, etc)


I think the first one is close to the audience/resource parameters that have 
been bandied about a few times, including in the current token exchange 
document. We should be consistent across drafts in that regard. The second is 
more traditional scope-ish. The third has been patched in with things like 
“offline_access” in certain APIs.

Just another vector to think about if we’re going to be adding things like 
“audience” or “resource” or both to the token requests.

 — Justin


> On Mar 14, 2016, at 6:26 PM, John Bradley  wrote:
> 
> Yes I will work on another proposal for allowing clients to specify what 
> resource they want a token for and providing the meta-data to the client 
> about the resources that a token is valid for.
> 
> We have part of it in the POP key distribution spec and talked about 
> separating it, as it is used more places than just for assigning keys.
> I know some AS use different token formats for different RS so are all-ready 
> needing to pass the resource in the request to avoid making a mess of scopes.
> 
> John B.
> 
> 
> 
> 
> 
>> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM) > > wrote:
>> 
>> Inline
>> 
>> Phil
>> 
>> On Mar 14, 2016, at 14:13, John Bradley > > wrote:
>> 
>>> We had two mandates.  One was to provide a spec for AS metadata.   The 
>>> other was to mitigate the client mixup attack.  The request was to do the 
>>> latter without requiring the former for clients that don’t otherwise need 
>>> discovery.
>> There is no mandate for any of this. See 
>> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt 
>> 
>>> 
>>> Returning the issuer and client_id from the authorization endpoint and the 
>>> client checking them can be done by the client without discovery.
>> 
>> How does this address the issue of whether the client is talking to the 
>> wrong endpoint?
>>> 
>>> Any client that has the resource and issuer hard coded probably doesn’t 
>>> need discovery.
>> We agree
>> 
>> 
>>> One of the things that a client will need discovery for is to find the RS, 
>>> so requiring the client to know the RS URI before getting the AS config 
>>> seems backwards to me.
>> How can you make an assumption on order? You seem to be conflating 
>> authentication with authorization by assuming the identity drives what the 
>> resource is.
>> 
>> There are lots of applications that require user rights but are not identify 
>> centric. For example a document service.
>>> 
>>> Unless the client tells the AS where it intends to use the token we will be 
>>> leaving a security hole because the bearer tokens will have too loose an 
>>> audience if they have one at all.
>> This is the biggest risk we have IMHO.
>>> 
>>> True you are telling the AS (Webfinger service) what the RS is but that is 
>>> not at a place that is useful in the token production process.
>> 
>> This has nothing to do with token production.
>> 
>> What we want to ensure is whether an honest client is correctly configured 
>> and has not been mislead - eg by a phishing page.
>>> 
>>> I also think there are use cases where the AS doesn’t know all the possible 
>>> RS.   That is not something that a out of band check can address.
>> 
>> May be. Lets identify them.
>> 
>>> There are also cases where a token might be good at multiple RS endpoints 
>>> intentionally.
>> 
>>>  In your solution the client would need to make a discovery request for 
>>> each endpoint.
>> Sure. Otherwise how would it know if there is one AS or a pool of AS servers 
>> assigned to each instance?
>>> Those requests lack the context of who the client and resource owner are.  
>>> I think that will be a problem in some use cases.
>> 
>> Not sure I agree. This is about discovering a valid set of endpoints. For 
>> mitm, we mainly want to check the hostname is correct. If a client chooses 
>> evil.com  the cert can be valid and TLS will pass. How 
>> does it otherwise know it is supposed to talk to res.example.com 
>> ?
>>> 
>>> If this is added to the token endpoint it would be checked when code or 
>>> refresh are exchanged, not every time the token is used.
>> Your proposal requires rhe client to ch

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Anthony Nadalin]

I would really like to see a comprehensive solution not this piece work, so we 
know what we are solving and what we are not.

-Original Message-
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hans Zandbelt
Sent: Monday, March 14, 2016 3:26 PM
To: Phil Hunt (IDM) ; John Bradley 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-bound-config-00.txt

On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:

> On Mar 14, 2016, at 14:13, John Bradley  > wrote:
>> Any client that has the resource and issuer hard coded probably 
>> doesn't need discovery.
> We agree

Yet any client that has hard coded a resource and 2 issuers doesn't need 
discovery either but is vulnerable to the IDP mixup attack.

I'd really like to see the two being addressed independently of each other, 
regardless of the fact that a Discovery solution *could* solve the IDP mixup 
attack as well.

Hans.

-- 
Hans Zandbelt  | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity

___
OAuth mailing list
OAuth@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c8cd9a8b2e020444382a708d34c57a6b4%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=1dsstJfhduQ3mZERUx6%2fO3OE241RK7ataalg6RY6JmA%3d

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[John Bradley]

Yes I will work on another proposal for allowing clients to specify what 
resource they want a token for and providing the meta-data to the client about 
the resources that a token is valid for.

We have part of it in the POP key distribution spec and talked about separating 
it, as it is used more places than just for assigning keys.   
I know some AS use different token formats for different RS so are all-ready 
needing to pass the resource in the request to avoid making a mess of scopes.

John B.





> On Mar 14, 2016, at 7:17 PM, Phil Hunt (IDM)  wrote:
> 
> Inline
> 
> Phil
> 
> On Mar 14, 2016, at 14:13, John Bradley  > wrote:
> 
>> We had two mandates.  One was to provide a spec for AS metadata.   The other 
>> was to mitigate the client mixup attack.  The request was to do the latter 
>> without requiring the former for clients that don’t otherwise need discovery.
> There is no mandate for any of this. See 
> http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt 
> 
>> 
>> Returning the issuer and client_id from the authorization endpoint and the 
>> client checking them can be done by the client without discovery. 
> 
> How does this address the issue of whether the client is talking to the wrong 
> endpoint?
>> 
>> Any client that has the resource and issuer hard coded probably doesn’t need 
>> discovery.  
> We agree
> 
> 
>> One of the things that a client will need discovery for is to find the RS, 
>> so requiring the client to know the RS URI before getting the AS config 
>> seems backwards to me. 
> How can you make an assumption on order? You seem to be conflating 
> authentication with authorization by assuming the identity drives what the 
> resource is. 
> 
> There are lots of applications that require user rights but are not identify 
> centric. For example a document service. 
>> 
>> Unless the client tells the AS where it intends to use the token we will be 
>> leaving a security hole because the bearer tokens will have too loose an 
>> audience if they have one at all.
> This is the biggest risk we have IMHO. 
>> 
>> True you are telling the AS (Webfinger service) what the RS is but that is 
>> not at a place that is useful in the token production process.
> 
> This has nothing to do with token production. 
> 
> What we want to ensure is whether an honest client is correctly configured 
> and has not been mislead - eg by a phishing page. 
>> 
>> I also think there are use cases where the AS doesn’t know all the possible 
>> RS.   That is not something that a out of band check can address.
> 
> May be. Lets identify them. 
> 
>> There are also cases where a token might be good at multiple RS endpoints 
>> intentionally.
> 
>>  In your solution the client would need to make a discovery request for each 
>> endpoint.
> Sure. Otherwise how would it know if there is one AS or a pool of AS servers 
> assigned to each instance?
>> Those requests lack the context of who the client and resource owner are.  I 
>> think that will be a problem in some use cases. 
> 
> Not sure I agree. This is about discovering a valid set of endpoints. For 
> mitm, we mainly want to check the hostname is correct. If a client chooses 
> evil.com  the cert can be valid and TLS will pass. How does 
> it otherwise know it is supposed to talk to res.example.com 
> ?
>> 
>> If this is added to the token endpoint it would be checked when code or 
>> refresh are exchanged, not every time the token is used.   
> Your proposal requires rhe client to check. I am not clear how the AS can 
> know the exact uri. It is far easier to validate than to lookup since as you 
> say the client may be authorized to use multiple ASs. 
>> With a out of band check the client would never know if a RS was 
>> removed/revoked.  
> 
> Not sure that is in scope. 
> 
> None of the current proposals address this issue. 
>>  
>> 
>> I don’t see checking when refreshing a token as something that is a huge 
>> burden.
> 
> Still its a lot more than once. 
> 
> Why don't you draft another alternative?
>> 
>> If the server wants to do the check on it’s side then we could require the 
>> client to send the RS URI in the token request. that way you really know the 
>> client is not going to get a token for the wrong RS endpoint.
>> If you check out of band in discovery you really have no idea if the client 
>> is checking.
> 
> In the new webfinger draft, the client isn't checking. The service provider 
> simply does not disclose oauth information to misconfigured clients. 
>> 
>> John B.
>>  
>> 
>> 
>>> On Mar 14, 2016, at 3:56 PM, Phil Hunt >> > wrote:
>>> 
>>> Thanks to Mike and John for their feedback.  I’ll take each in turn:
>>> 
>>> Mike,
>>> 
>>> Regarding your suggested amendments
>>> 
>>> Item 1: Returning the config URL would create two problems. O

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Hans Zandbelt]

On 3/14/16 10:17 PM, Phil Hunt (IDM) wrote:


On Mar 14, 2016, at 14:13, John Bradley mailto:ve7...@ve7jtb.com>> wrote:

Any client that has the resource and issuer hard coded probably
doesn’t need discovery.

We agree


Yet any client that has hard coded a resource and 2 issuers doesn't need 
discovery either but is vulnerable to the IDP mixup attack.


I'd really like to see the two being addressed independently of each 
other, regardless of the fact that a Discovery solution *could* solve 
the IDP mixup attack as well.


Hans.

--
Hans Zandbelt  | Sr. Technical Architect
hzandb...@pingidentity.com | Ping Identity

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Phil Hunt (IDM)]

Inline

Phil

> On Mar 14, 2016, at 14:13, John Bradley  wrote:
> 
> We had two mandates.  One was to provide a spec for AS metadata.   The other 
> was to mitigate the client mixup attack.  The request was to do the latter 
> without requiring the former for clients that don’t otherwise need discovery.
There is no mandate for any of this. See 
http://tools.ietf.org/wg/oauth/charters?item=charter-oauth-2016-01-22.txt
> 
> Returning the issuer and client_id from the authorization endpoint and the 
> client checking them can be done by the client without discovery. 

How does this address the issue of whether the client is talking to the wrong 
endpoint?
> 
> Any client that has the resource and issuer hard coded probably doesn’t need 
> discovery.  
We agree


> One of the things that a client will need discovery for is to find the RS, so 
> requiring the client to know the RS URI before getting the AS config seems 
> backwards to me. 
How can you make an assumption on order? You seem to be conflating 
authentication with authorization by assuming the identity drives what the 
resource is. 

There are lots of applications that require user rights but are not identify 
centric. For example a document service. 
> 
> Unless the client tells the AS where it intends to use the token we will be 
> leaving a security hole because the bearer tokens will have too loose an 
> audience if they have one at all.
This is the biggest risk we have IMHO. 
> 
> True you are telling the AS (Webfinger service) what the RS is but that is 
> not at a place that is useful in the token production process.

This has nothing to do with token production. 

What we want to ensure is whether an honest client is correctly configured and 
has not been mislead - eg by a phishing page. 
> 
> I also think there are use cases where the AS doesn’t know all the possible 
> RS.   That is not something that a out of band check can address.

May be. Lets identify them. 

> There are also cases where a token might be good at multiple RS endpoints 
> intentionally.

>  In your solution the client would need to make a discovery request for each 
> endpoint.
Sure. Otherwise how would it know if there is one AS or a pool of AS servers 
assigned to each instance?
> Those requests lack the context of who the client and resource owner are.  I 
> think that will be a problem in some use cases. 

Not sure I agree. This is about discovering a valid set of endpoints. For mitm, 
we mainly want to check the hostname is correct. If a client chooses evil.com 
the cert can be valid and TLS will pass. How does it otherwise know it is 
supposed to talk to res.example.com?
> 
> If this is added to the token endpoint it would be checked when code or 
> refresh are exchanged, not every time the token is used.   
Your proposal requires rhe client to check. I am not clear how the AS can know 
the exact uri. It is far easier to validate than to lookup since as you say the 
client may be authorized to use multiple ASs. 
> With a out of band check the client would never know if a RS was 
> removed/revoked.  

Not sure that is in scope. 

None of the current proposals address this issue. 
>  
> 
> I don’t see checking when refreshing a token as something that is a huge 
> burden.

Still its a lot more than once. 

Why don't you draft another alternative?
> 
> If the server wants to do the check on it’s side then we could require the 
> client to send the RS URI in the token request. that way you really know the 
> client is not going to get a token for the wrong RS endpoint.
> If you check out of band in discovery you really have no idea if the client 
> is checking.

In the new webfinger draft, the client isn't checking. The service provider 
simply does not disclose oauth information to misconfigured clients. 
> 
> John B.
>  
> 
> 
>> On Mar 14, 2016, at 3:56 PM, Phil Hunt  wrote:
>> 
>> Thanks to Mike and John for their feedback.  I’ll take each in turn:
>> 
>> Mike,
>> 
>> Regarding your suggested amendments
>> 
>> Item 1: Returning the config URL would create two problems. One,it makes 
>> bound discovery a two-step process - that adds complexity.  It seems far 
>> simpler to mandate TLS (which I think it already does in the security 
>> considerations).  
>> 
>> The two-step process allows the current discovery process to continue. I 
>> disagree with this. This is why I put forward an “alternate" draft that is 
>> almost the same but simply adds the check before returning the configuration 
>> data.  I worry that  developers would have no incentive to do the two-step 
>> approach. They would just start at step 2 which in turn puts AS’s at risk of 
>> exposing tokens because it works. This makes OAuth promiscuous.
>> 
>> Regarding existing implementations. Most of those implementations are for 
>> OIDC.  I think it makes sense for OIDF to continue use of OIDC's discovery 
>> spec because the UserInfo endpoint is well defined and the likelihood of a 
>> client mis-inf

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[John Bradley]

We had two mandates.  One was to provide a spec for AS metadata.   The other 
was to mitigate the client mixup attack.  The request was to do the latter 
without requiring the former for clients that don’t otherwise need discovery.

Returning the issuer and client_id from the authorization endpoint and the 
client checking them can be done by the client without discovery. 

Any client that has the resource and issuer hard coded probably doesn’t need 
discovery.  
One of the things that a client will need discovery for is to find the RS, so 
requiring the client to know the RS URI before getting the AS config seems 
backwards to me. 

Unless the client tells the AS where it intends to use the token we will be 
leaving a security hole because the bearer tokens will have too loose an 
audience if they have one at all.

True you are telling the AS (Webfinger service) what the RS is but that is not 
at a place that is useful in the token production process.

I also think there are use cases where the AS doesn’t know all the possible RS. 
  That is not something that a out of band check can address.
There are also cases where a token might be good at multiple RS endpoints 
intentionally.  In your solution the client would need to make a discovery 
request for each endpoint.
Those requests lack the context of who the client and resource owner are.  I 
think that will be a problem in some use cases. 

If this is added to the token endpoint it would be checked when code or refresh 
are exchanged, not every time the token is used.   
With a out of band check the client would never know if a RS was 
removed/revoked.   

I don’t see checking when refreshing a token as something that is a huge burden.

If the server wants to do the check on it’s side then we could require the 
client to send the RS URI in the token request. that way you really know the 
client is not going to get a token for the wrong RS endpoint.
If you check out of band in discovery you really have no idea if the client is 
checking.

John B.
 


> On Mar 14, 2016, at 3:56 PM, Phil Hunt  wrote:
> 
> Thanks to Mike and John for their feedback.  I’ll take each in turn:
> 
> Mike,
> 
> Regarding your suggested amendments
> 
> Item 1: Returning the config URL would create two problems. One,it makes 
> bound discovery a two-step process - that adds complexity.  It seems far 
> simpler to mandate TLS (which I think it already does in the security 
> considerations).  
> 
> The two-step process allows the current discovery process to continue. I 
> disagree with this. This is why I put forward an “alternate" draft that is 
> almost the same but simply adds the check before returning the configuration 
> data.  I worry that  developers would have no incentive to do the two-step 
> approach. They would just start at step 2 which in turn puts AS’s at risk of 
> exposing tokens because it works. This makes OAuth promiscuous.
> 
> Regarding existing implementations. Most of those implementations are for 
> OIDC.  I think it makes sense for OIDF to continue use of OIDC's discovery 
> spec because the UserInfo endpoint is well defined and the likelihood of a 
> client mis-informed about the resource endpoint is not there.  IMO This does 
> not apply to the broader OAuth community.
> 
> Item 2:  It may be appropriate to have a separate configuration registry 
> specification, but I think we should hold off until we have a complete 
> solution and then make the decision what drafts should exist and how many 
> pieces.  A big concern is the perceived complexity of multiple solutions and 
> multiple drafts.
> 
> As to John Bradley’s comments:
> 
> Re: Discovery is the wrong place to mitigate threats. 
> I’m confused by this.  Our mandate was to solve a security threat by having a 
> discovery specification to prevent clients being mis-lead about endpoints (of 
> which resource service is one) in an oauth protected exchange.  Maybe what 
> you mean is we should not use .well-known of any kind and we should just 
> create a “/Config” endpoint to OAuth?
> 
> Re: Your proposal for MITM mitigation
> You propose that instead the resource endpoint check should be in the oauth 
> protocol itself.  The difference is that validation is transferred back to 
> the client to get it right. As well, without the client informing the AS, I 
> can’t see a way for the AS to know what endpoint the client is using.  The 
> webfinger approach does this once and only requires that the host name be 
> checked in many cases.
> 
> As a principle, the members have discussed many times that the AS service 
> should do validation when possible — this was particularly true at the 
> Germany meeting when this came up. This is why I prefer the client tell the 
> service provider what it intends to do and the service provider can fail that 
> request immediately if necessary. We don’t have to depend on the developer 
> getting the spec correct to fail the correct way.
> 
> I worry that adding more pa

Re: [OAUTH-WG] Multiple authorization servers for one resource server

[Justin Richer]

We don’t include the scopes or identity information in the token itself, so as 
to prevent it from leaking to parties that shouldn’t need it. 

The main benefit of introspection is liveness, but it also lets you reference 
data tied to the token that you don’t want to ship in the token itself.

At the end of the day, it’s a trade off as to what you want to put into the 
token and what you want attached as a reference. Good news is that you can do 
both together and use the strengths of each.

 — Justin

> On Mar 13, 2016, at 10:36 PM, Andrea Ceccanti  
> wrote:
> 
> Hello,
> 
> interesting thread, thanks.
> 
> Assuming the scopes are included in the token, the main purpose of call to 
> the introspection endpoint is to ensure
> the token hasn't been revoked?
> 
> We are considering a deployment where a RS can trust multiple AS, and having 
> a JWT as access token, with
> issuer, scopes and basic identity information included seems to solve our 
> issues.
> 
> Thanks,
> Andrea
> 
> 
> 
> 
> 2016-03-13 9:03 GMT+08:00 Justin Richer  >:
> What we've done in deployments is to combine JWT and introspection. You have 
> all of your servers issue signed JWTs that include the "iss" (issuer) in the 
> body, signed with the key of the AS. The tokens also include a random "jti" 
> field. The RS submits the token to the introspection endpoint of the server 
> identified in "iss", but only after validating the signature and other basic 
> bits of information. If the introspection call comes back positive (and with 
> the right scope, client, and resource owner information), the resource is 
> served.
> 
>  -- Justin
> 
> 
> On 3/11/2016 10:02 PM, Takahiko Kawasaki wrote:
>> Hello,
>> 
>> I have a question.
>> 
>> If there exist multiple authorization servers that can issue access tokens 
>> for one resource server, when the resource server receives an access token 
>> from a client application, as the first step, the resource server has to 
>> determine which authorization server to use for access token introspection.
>> 
>> Is there any standard way to determine which authorization server to use?
>> 
>> There may be several ways, for example:
>> 
>> (1) Embed information about the access token issuer in the access token.
>> (2) Add a request parameter to identify the access token issuer.
>> (3) Separate protected resource endpoints for each authorization server.
>> 
>> If there is a standard way, I'd like to know it.
>> 
>> Best Regards,
>> Takahiko Kawasaki
>> 
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth 
>> 
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> 
> 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Multiple authorization servers for one resource server

[John Bradley]

Sorry your first email didn’t mention introspection.

I answered assuming a JWT.

A JWE can have the issuer in the envelope, so the recipient just needs to 
base64url decode the envelope to see who it issuer was and from that determine 
where to introspect it.

However if you are introspecting the token why bother making it a JWE, just 
send a regular JWS with a reference claim in the body that can be looked up by 
the AS during introspection.

If you are trying to do stateless introspection then just send a JWE access 
token containing the required claims and forget the introspection.

John B.

> On Mar 14, 2016, at 1:16 PM, Mike Schwartz  wrote:
> 
> This was the original requirement:
> 
> " multiple authorization servers that can issue access tokens for one 
> resource server, when the resource server receives an access token from a 
> client application, as the first step, the resource server has to determine 
> which authorization server to use for access token introspection."
> 
> Not sure we're all on the same page after numerous responses...
> 
> So the fact that the token is an encrypted JWT is great... the question is: 
> who issued it? That's why I was thinking of a url encoded JWT with the issuer 
> + the encrypted token, such as {"iss": "https://as.example.com";, "token": 
> "(encrypted JTW)"}
> 
> - Mike
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Phil Hunt]

Thanks to Mike and John for their feedback.  I’ll take each in turn:

Mike,

Regarding your suggested amendments

Item 1: Returning the config URL would create two problems. One,it makes bound 
discovery a two-step process - that adds complexity.  It seems far simpler to 
mandate TLS (which I think it already does in the security considerations).  

The two-step process allows the current discovery process to continue. I 
disagree with this. This is why I put forward an “alternate" draft that is 
almost the same but simply adds the check before returning the configuration 
data.  I worry that  developers would have no incentive to do the two-step 
approach. They would just start at step 2 which in turn puts AS’s at risk of 
exposing tokens because it works. This makes OAuth promiscuous.

Regarding existing implementations. Most of those implementations are for OIDC. 
 I think it makes sense for OIDF to continue use of OIDC's discovery spec 
because the UserInfo endpoint is well defined and the likelihood of a client 
mis-informed about the resource endpoint is not there.  IMO This does not apply 
to the broader OAuth community.

Item 2:  It may be appropriate to have a separate configuration registry 
specification, but I think we should hold off until we have a complete solution 
and then make the decision what drafts should exist and how many pieces.  A big 
concern is the perceived complexity of multiple solutions and multiple drafts.

As to John Bradley’s comments:

Re: Discovery is the wrong place to mitigate threats. 
I’m confused by this.  Our mandate was to solve a security threat by having a 
discovery specification to prevent clients being mis-lead about endpoints (of 
which resource service is one) in an oauth protected exchange.  Maybe what you 
mean is we should not use .well-known of any kind and we should just create a 
“/Config” endpoint to OAuth?

Re: Your proposal for MITM mitigation
You propose that instead the resource endpoint check should be in the oauth 
protocol itself.  The difference is that validation is transferred back to the 
client to get it right. As well, without the client informing the AS, I can’t 
see a way for the AS to know what endpoint the client is using.  The webfinger 
approach does this once and only requires that the host name be checked in many 
cases.

As a principle, the members have discussed many times that the AS service 
should do validation when possible — this was particularly true at the Germany 
meeting when this came up. This is why I prefer the client tell the service 
provider what it intends to do and the service provider can fail that request 
immediately if necessary. We don’t have to depend on the developer getting the 
spec correct to fail the correct way.

I worry that adding more parameters to the authz and token protocol flows 
increases complexity and attack surface. It also means per authorization 
validation has to take place vs. a one-time validation at config time.  Placing 
it in the configuration lookup phase (whether via web finger or just a special 
OAuth endpoint) seems more appropriate and far less complex - as the request 
itself is simple and has only one parameter. Here we are not considered about 
legitimacy of the client. we’re just concerned with the issue "has the client 
been correctly informed?”

That said, it may be that when we consider all the use cases, some combination 
of AS protocol and discovery may be both needed. I’m not ready to make 
conclusions about this.  The current oauth-discovery spec seems to put future 
generic clients at risk and that is my primary concern.

Best Regards,

Phil

@independentid
www.independentid.com phil.h...@oracle.com 






> On Mar 13, 2016, at 10:28 PM, Mike Jones  wrote:
> 
> Thanks for posting this, Phil.  It provides a concrete example of a way that 
> protected resource discovery could be added to authorization server metadata 
> discovery, and as such, should provide useful input for working group 
> discussions on this topic.  It’s always great when someone takes the time to 
> write an actual draft that can be examined and implemented, and I appreciate 
> you doing that.
>  
> The content of your draft points out that there appears to be complete 
> agreement on what the authorization server metadata format should be, which 
> is great!  I’ll note that Section 3 of draft-hunt-oauth-bound-config-00 
> titled “Authorization Server Metadata” is an exact copy of Section 2 of 
> draft-ietf-oauth-discovery-01 (with the same title), modulo applying a 
> correction suggested by the working group.  To me this suggests that the 
> authorization server metadata definitions in draft-ietf-oauth-discovery 
> (which is now the whole normative content of the draft) are clearly ready for 
> standardization, since even your alternative proposal includes them verbatim.
>  
> Reading your draft, the problem I have with it is that you

Re: [OAUTH-WG] Multiple authorization servers for one resource server

[Mike Schwartz]

This was the original requirement:

" multiple authorization servers that can issue access tokens for one 
resource server, when the resource server receives an access token from 
a client application, as the first step, the resource server has to 
determine which authorization server to use for access token 
introspection."


Not sure we're all on the same page after numerous responses...

So the fact that the token is an encrypted JWT is great... the question 
is: who issued it? That's why I was thinking of a url encoded JWT with 
the issuer + the encrypted token, such as {"iss": 
"https://as.example.com";, "token": "(encrypted JTW)"}


- Mike


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] oauth - Requested session has been scheduled for IETF 95

["IETF Secretariat"]

Dear Hannes Tschofenig,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

oauth Session 1 (2:00:00)
Wednesday, Morning Session I 1000-1230
Room Name: Buen Ayre B size: 125
-



Request Information:


-
Working Group Name: Web Authorization Protocol
Area Name: Security Area
Session Requester: Hannes Tschofenig

Number of Sessions: 1
Length of Session(s):  2 Hours
Number of Attendees: 50
Conflicts to Avoid: 
 First Priority: ace saag cfrg tls core lwig




Special Requests:
  Please avoid conflict with sec area BoFs.
-

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Multiple authorization servers for one resource server

[George Fletcher]

For what it's worth, we deployed such a system in 2011 using signed 
JWTs, symmetric keys and supporting key rotation via the kid JWT header 
field. The body of the JWT includes 'iss', 'exp', 'uid' (for the user), 
'access_token' (AS specific opaque blob), and 'validation_url' (where to 
validate the AS specific opaque blob).


The issuing AS would generate this JWT and sign it. The RS, then 
validates the signature. If necessary, the RS then also validates the 
opaque token with the issuing AS.


Of course, using encrypted JWTs may be a better solution these days:)

Thanks,
George

On 3/13/16 4:44 PM, Mike Schwartz wrote:
I like the idea of an encrypted JWT... I guess if there are multiple 
AS's, how would you know which key to use? Cycle through each key? Are 
you suggesting maybe use a non-encrypted JWT that contains an 
encrypted JWT as a value? Something like


{"iss": "https://example.com";,
 "token": "fjbfgy5Fdx8ybx0.."
}

Are there any OAuth2 profiles to standardize this approach?

- Mike


--

Michael Schwartz
Gluu
Founder / CEO
m...@gluu.org

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

[Anthony Nadalin]

Mike, there is no need to rush standardizing the metadata since there are still 
obvious issues with discovery or what one thinks discovery should be and should 
not be. This is also not the OpenID Foundation, this group should not be 
constrained by what OpenID has done but we should be informed. Some 
companies/individuals may have taken what was used by OpenID and used that as 
Oauth Discovery but once again we should not be restrained in what is 
technically the best choice because OpenID did it a certain way, it may be that 
OpenID did it the best way but lets not try to force the decision bases upon 
OpenID Certification.

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Sunday, March 13, 2016 10:29 PM
To: Phil Hunt 
Cc: oauth 
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-bound-config-00.txt

Thanks for posting this, Phil.  It provides a concrete example of a way that 
protected resource discovery could be added to authorization server metadata 
discovery, and as such, should provide useful input for working group 
discussions on this topic.  It’s always great when someone takes the time to 
write an actual draft that can be examined and implemented, and I appreciate 
you doing that.

The content of your draft points out that there appears to be complete 
agreement on what the authorization server metadata format should be, which is 
great!  I’ll note that Section 3 of draft-hunt-oauth-bound-config-00 titled 
“Authorization Server Metadata” is an exact copy of Section 2 of 
draft-ietf-oauth-discovery-01 (with the same title), modulo applying a 
correction suggested by the working group.  To me this suggests that the 
authorization server metadata definitions in draft-ietf-oauth-discovery (which 
is now the whole normative content of the draft) are clearly ready for 
standardization, since even your alternative proposal includes them verbatim.

Reading your draft, the problem I have with it is that you are returning the AS 
metadata only as a WebFinger response, rather than as an https-protected 
resource published by the authorization server.  The choice to only return this 
via WebFinger makes your draft incompatible with most deployed implementations 
of OAuth metadata, including the 22 implementations using it listed at 
http://openid.net/certification/
 (see the “OP Config” column in the table) and OAuth 2.0 libraries such as 
Microsoft’s “ADAL” library, which uses the metadata path for client 
configuration.  Without having ASs provide the metadata as an https-protected 
resource, implementations such as ADAL can’t use it for client configuration as 
the currently do.

Therefore, I would request that you make these minor revisions to your draft 
and republish, so as to provide a unified way forward that is compatible with 
all known existing OAuth Discovery deployments:

1.  Modify your section 2 “Authorization Server WebFinger Discovery” to 
have the WebFinger request return the issuer identifier for the AS as the 
“WebFinger “rel” value, rather than returning the metadata values by value as 
the “properties” value.

2.  Reference the metadata definitions from Section 2 of 
draft-ietf-oauth-discovery, rather than duplicating them in your Section 3.

That would have the advantage of paring your draft down to only the new things 
that it proposes, enabling them to be more clearly understood and evaluated on 
their own merits.  I look forward to the discussions of ways of performing 
additional kinds of OAuth discovery, and consider your draft a valuable input 
to those discussions.

  Best wishes,
  -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Sunday, March 13, 2016 6:45 PM
To: Phil Hunt mailto:phil.h...@oracle.com>>
Cc: oauth mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-bound-config-00.txt

As I have told Phil off list.

Discovery is the wrong place to try and provide security against man in the 
middle attacks on the RS.

This requires the client to know what the RS URI is before retrieving the 
information on the AS Configuration.

The proposal Mike and I have been working on requires the client to have a 
notion of what API it is looking for and retrieve the .well-known file for that 
API from the issuer.   That allows a protocol like Connect to register its own 
config file that can point to the RS.

If the API specific well known is not available the client can try the default 
oauth-server one.

That then allows us to deal with restricting where AT are presented as part of 
the