[OAUTH-WG] Resource Service metadata

So, in thinking about all this AS restricting tokens to RS and "discovery" of RS endpoints, etc. I wondered why we don't just leverage RS metadata like we have AS metadata. For an AS we require an 'iss' claim to use as an identifier of the AS. We could do the same with RS metadata retrieving t

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

Right, if the client asks for a token to use at https://evil.rs then the AS can audience restrict the token to https://evil.rs so that it wouldn't be usable at https://good.rs. On Wed, Mar 16, 2016 at 8:46 AM, John Bradley wrote: > If the client sends the uri of the resource it intends to send

Re: [OAUTH-WG] Resource Service metadata

George, Thanks. It would be good to get a draft that sketches out the overall picture of this for BA — even if in very rough form given the deadline is monday. Or, maybe just a PPT walkthru. Interested to see what comes out. Phil @independentid www.independentid.com

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

IMHO, list of URIs that represent the partial paths under the same authority would not be too onerous. e.g., if you have https://example.com/apis/v1/userinfo https://example.com/apis/v2/userinfo

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

+1 for Nat's last few emails (avoiding generating too much traffic :-). Re: below, this is where I was thinking of masking/filter in bound config. The main thing that needs to be checked at configuration time is whether the client has a valid set of server host names to prevent a malicious pro

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

It is not just redirects that are a threat. Any user hosted content could potentially extract an access token from a query parameter. John B. > On Mar 17, 2016, at 1:34 PM, Phil Hunt wrote: > > +1 for Nat's last few emails (avoiding generating too much traffic :-). > > Re: below, this is wher

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

Nothing here has anything to do with mix-up. Thats another problem. Phil > On Mar 16, 2016, at 16:50, John Bradley wrote: > > If you recall in Darmstadt, the group decided that the mix up attack needed > to be addressed without requiring discovery. > > That is why I keep saying the are separ

Re: [OAUTH-WG] Resource Service metadata

a good AS (at first) may become compromised and attack another AS; whilst I agree it is less likely and less easy in static configs (hence my point about the dynamic scenario) the root cause is not related to configuration: it is a runtime attack (well at least one of the permutations is) on pe

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

The problem is similar to the one with redirect_uri, if you allow user hosted content on the domain they will be able to get the token if it is sent as a query parameter, and might be able to if it is sent as a header. Unfortunately many OAuth clients are badly behaved and make use of the que

Re: [OAUTH-WG] Resource Service metadata

Static deployments are a problem for mix-up. Agreed. I’m objecting to the notion that we don’t have to worry about discovery threats and that we need to do mix-up first. Rushing ahead with partial discovery so we can address mix-up seems like a *huge* mistake. Mix-up depends on a bad insider t

Re: [OAUTH-WG] Resource Service metadata

George, For the attacks we looked at in Darmstadt, we discussed that in order for the attack to succeed (at least as envisioned), the attacker needs to have the client invoke the real authorize endpoint in order for the user to be successful in issuing the grant. Assuming that it is the case,

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

I agree, but getting that horse back in the barn is not going to be an overnight project. We have multiple issues with bearrer tokens. At the moment we punt the issue to the client and count on it being configured properly to not leak the AT. Better tokens will never be as secure as PoP tokens

Re: [OAUTH-WG] Resource Service metadata

The aud of the access token is completely opaque to the client in all cases, with the possible exception of someone who is using scopes to represent resources and the client has some mapping of scopes granted to RS endpoints. I am just trying to find a less confusing way to do that without the

Re: [OAUTH-WG] Resource Service metadata

Isn't the solution to that attack defined? I was not including that attack in the thinking around audience restricted tokens and AS / RS endpoint "discovery". I think that regardless of this current discussion the requirement for the AS to return issuer and client_id needs to stay as does the b

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

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 der

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

If the client sends the uri of the resource it intends to send the token to in the token request the bad guy would get only a token audianced to itself and not to good RS. You can't solve the problem of bearer tokens with multiple audiences leaking. That is a risk inherent in using that sort of

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

Agreed... so I started a new thread on use cases:) Here is one example. Assume there is a client that speaks a known OAuth2 protected protocol (e.g. PortableContacts, or something like Jabber). A user of the client can enter the endpoint of their RS that speaks the protocol and the client "dis

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

Indeed, that’s what I suggested to Phil offline that we should draft a use case based requirement document. It looks to me that we are talking past each other with slightly different use-cases in mind. As far as I can tell, we do not have an agreement on the Requirements for discovery. We s

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

From my perspective we are not trying to solve a mix-up case or any other attack. We are trying to solve for audience restricted tokens in OAuth2 without PoP. In working to solve that case, we also want to close any possible attacks but that is not the primary goal. I, personally, don't want a

Re: [OAUTH-WG] Resource Service metadata

George Very good question... I considered that the RS metadata discovery could be fake. So the final step in configuration validation is to bind the relationship between as and rs discovery together to confirm the relationship is valid. We are of course assuming that a hacker needs to use th

Re: [OAUTH-WG] Resource Service metadata

I keep saying that the mixup mitigation draft doesn't require discovery. The AS meta-data draft started before the mixup mitigation work and is not related, other than that they both use the concept of issuer, as do you. The mixup doesn’t require discovery but it arguably makes it easier. Jo

Re: [OAUTH-WG] Resource Service metadata

I'm sorry to keep pushing on this but the attack is not opened up by discovery, having two fixed ASes is already a threat: multiple ASes in general leaves the client exposed. Discovery just increases the attack surface. Hans. On 3/17/16 4:16 PM, Phil Hunt wrote: George, For the attacks we l

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

+1 for a list of use cases :) On 3/17/16 2:30 AM, Nat Sakimura wrote: A disadvantage of this method is that it cannot be used in the case where concrete resource uri is unknown to the client until the user gives permission. Right, this is a different use case. That’s why we need a use-case

Re: [OAUTH-WG] Resource Service metadata

Phil @independentid www.independentid.com phil.h...@oracle.com > On Mar 16, 2016, at 10:59 AM, George Fletcher wrote: > > > > On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote: >> George >> >> Very good question... >> >> I consider

Re: [OAUTH-WG] Resource Service metadata

Inline... On 3/16/16 2:16 PM, Phil Hunt wrote: Phil @independentid www.independentid.com phil.h...@oracle.com On Mar 16, 2016, at 10:59 AM, George Fletcher > wrote: On 3/16/16 12:20 PM, Phil Hunt (ID

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

For me the difference between the /token endpoint and an RS endpoint is semantic. The /token endpoint is part of the AS and a critical part of the authorization flow. RS endpoints are under the control of the RS. Thanks, George On 3/16/16 11:30 AM, Phil Hunt (IDM) wrote: John, Mis configure

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

If this assumption is true, then there is really no point to try and come up with a middle ground. If the client MUST present the full endpoint URL to protect against possible open-redirect flaws then we have the following case. Client implements an instant messaging app. For the client to wor

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

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: I was thinking of goal #2 as addressing the issue of audience in the token. If the RS "authentic

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

A disadvantage of this method is that it cannot be used in the case where concrete resource uri is unknown to the client until the user gives permission. Right, this is a different use case. That’s why we need a use-case driven Requirement document to start with. Nat From: OAuth [ma

Re: [OAUTH-WG] Resource Service metadata

But it’s less likely (or less easy?) to have a malicious combination of endpoints in a static configuration. What this all boils down to is managing a set of endpoints as a “thing” that represents an AS (and some would argue associated RS). You can create that set manually or dynamically and fal

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

On Fri, Mar 18, 2016 at 1:50 PM George Fletcher 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? > Y

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

If one of the APIs has an open-redirect problem, won't that cause the token to leak to the attacker? That's why we went to exact match in OpenID Connect. Does it not apply in this case? Thanks, George On 3/17/16 2:42 AM, Nat Sakimura wrote: IMHO, list of URIs that represent the partial paths

Re: [OAUTH-WG] Resource Service metadata

I agree with Phil that the client can’t trust any abstract identifier that it might get from a bad RS unless it is were a URI that the client or AS could deference to get a list of the concrete URI for the RS. That seems like a lot of work that clients are unlikely to do. A AS might do it if it

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

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: Note that goal #2 is

Re: [OAUTH-WG] Resource Service metadata

agreed, I'm not suggesting that the client-to-evil-RS problem is addressed, I was objecting to the statement that Phil made about static configurations not being a problem; I don't think agreement was reached on a client-to-evil-AS solution either Hans. On 3/17/16 5:31 PM, George Fletcher wro

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

We are talking about resource accesses here, right? There's no query parameter from the point of view of OAuth: the access token is sent as Authorize header over TLS, so I am a bit puzzled by your comment... Nat 2016年3月18日(金) 2:49 John Bradley : > It is not just redirects that are a threat. Any

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

Yes without pop the mappings become a challenge quickly. We don’t have any sort of API management in OAuth, and that makes trying to secure bearer tokens a real challenge if you want a single token with multiple audiences. To have multiple audiences you need to have hight trust in all of the

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

I think in the mis-configuration case, it is different form the redirect issues. What we are concerned about is an attackers ability to convince the client to set up a connection via an attackers proxy which can even have a valid TLS enabled. The client won’t know it has done something wrong.