Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

["Phil Hunt (IDM)" <[e-mail]>]

John

In many case all the AS has to check is the domain name component to check for mitm. 

POP and the other solns are dramatically more complex than a simple check. 

I see it as part of the discovery(bad name aside) problem because we discussed that if a client finds app.example.com how do we ensure it gets a complete set of oauth endpoints as a valid set of endpoints--that a hacker has not inserted one of their own endpoints. The most important endpoint to get right is ensuring the resource server (and optionally the path) is the correct one. We can't really define resource discovery but we can validate it to some degree. 

I am not stuck on webfinger or well-known. Because this is config maybe it should be an oauth endpoint. 

Phil

> On Mar 11, 2016, at 06:51, John Bradley <[e-mail]> wrote:
> 
> I think Phil is proposing something different.   Should the client send a token from this AS to that RS.  
> 
> His goal is to prevent man in the middle attacks where a bad RS gets a AT that is audianced to/accepted by another RS.
> 
> That is separate from the question of if a RS accepts tokens from a good AS.   A bad AS would always say yes.
> 
> We need to be careful of what if anything the RS provides to the client as meta-data without validation.
> 
> Currently the client can provide a list of scopes required to get access.   I personally feel it would be useful to also include in the unauthenticated error response an indication of what API the resource supports.  Say “scim2” as an example.   I don’t think adding that is however a high priority as most if all clients know what API they expect.   It might be useful if at some point in the future if a client were to be given a RS URI it could check to see if it is a protocol that it supports before bothering with OAuth.    I expect that a lot of people will want that left to the API definition.   I think we can talk about it but rate this low priority.
> 
> I agree that the RS giving out a list of AS that it trusts is a generally bad idea.  I hope that is not on the table.
> 
> I don’t think that preventing a client from sending a token to the wrong RS is part of a AS meta-data discovery problem.
> 
> I do however think that it is important.
> 
> We have been discussing this as a separate problem to AS meta-data discovery where the endpoints of the AS and it’s configuration are discovery.   Sorry for perhaps stating the obvious, but the RS is explicitly not part of the AS in OAuth 2.   Starting in WAP that was a core principal.
> 
> So we have a number of options to address the RS token leakage via MiTM attacks.
> 
> 1) PoP bound tokens.  If they are bound to the TLS channel by mutual TLS or Token binding they cannot be replayed.  Signed messages where the signing covers the RS Host and path components,  also would work.
> 
> 2) Have the AS audience restrict the resources the AT is good at. (AT should be doing that now) 
> In the token response include the list of audience/s the token is presentable at.  The client would throw an error if the RS it intends to send the token to is not on the list.   The RS the token is good at might change based on scopes, client_id and resource owner.   This is the place where all of that comes together.   In some cases the RS and AS might not have a pre-established relationship.   The client should send the RS base URI to the AS as part of the request.  The AS can use that to audience restrict the AT and issue the AT or refuse to issue the AT based on policy.
> It can also use the audience in the request to down audience the AT if the default is to have multiple audiences.    We may want to use a term other than audience for this like resource or destination.  It is a audience but that term might confuse people with AT.
> 
> We did talk about breaking audience out of POP key distribution, and Brian Campbell did a draft https://tools.ietf.org/html/draft-campbell-oauth-dst4jwt.   
> 
> To do this we could take dst4jwt and add another spec that adds a new dst parameter to the token and authorization endpoints requests That would be a space separated list of dst values.  and in the response from the token endpoint would be a JSON array of dst values.
> 
> 3) Have the AS always return all the list of all RS the token can be used at (basically Nat's link relationship proposal).  It needs a way to handle 
> down destinationing of AT and to allow for un-configured RS that it might issue a token for.  So could be combined with dst from 2.  Basically returning the acceptable destinations as link headers vs JS in the response is mostly a style issue that other people can bike shed.
> 
> 
> 4) Trying to add all the RS to the AS discovery document.  This seems impractical as there would be multiple protocols and doesn’t address un-configured RS.
> 
> 5) Some new AS endpoint that the client could introspect the RS URI and get back metadata about if the client should send tokens there.
>     A couple of problems with this.  The first is that it would not support un-configured RS unless you add dst to the token and authorization endpoints.   The other is that the introspection endpoint doesn’t have the context of the RO and client_id unless you also pass the code/RT and client_id, and probably client credentials.    Basically this is trying to introspect the AT to determine the audiance/dst.   By the time you build a new introspection endpoint securely it is going to look like the token endpoint with a bit more meta data about the token beyond expiry and scopes.
> 
> 
> I think we should go a head with the renamed "OAuth 2.0 Authorization Server Discovery Metadata” 
> I am also fine with making the default document 'openid-configuration’  as long as we allow for protocol specific variation so that SCIM2 could define a file name.    If people want we could do a API  to file name registry so that protocol specific ones can be defined.
> 
> We are all-ready working on option 1 to secure AT, we need a spec like I propose in 2 for bearer tokens.  We can add one request parameter and a bit more token meta-data to the token response and that takes care of the problem.   Honestly we probably should have separated scope and destination in the first place and returned both dst and scope in the response all along, so this is update that is consistent with the eisting architecture of OAuth 2.
> 
> Lets keep the two issues separate.
> 
> John B.
>  
> 
> 
> 
>> On Mar 11, 2016, at 12:07 AM, Anthony Nadalin <[e-mail]> wrote:
>> 
>> The relationship between AS and RS need to be scoped to “does this RS accept tokens from this AS” as a list is too much information that could be used in the wrong way
>>  
>> From: OAuth [mailto:[e-mail]] On Behalf Of Nat Sakimura
>> Sent: Thursday, March 10, 2016 6:25 PM
>> To: Phil Hunt (IDM) <[e-mail]>
>> Cc: oauth <[e-mail]>
>> Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>>  
>> Phil, 
>>  
>> Right. So what my conditional approvals (11 conditions in total) said was to drop the word "discovery" from everywhere. This is not a discovery spec. This is a configuration lookup spec as you correctly points out. So, I am with you here. 
>>  
>> Also, my 2nd conditiion is essentially saying to drop section 3. 
>>  
>> One thing that I overlooked and am with you is that we need to be able to express the AS-RS relationships. I have been preaching this in the other thread for so many times as you know so I thought I pointed it out, but missed apparently in my previous comment. So, I would add my 12th condition: 
>>  
>> 12. A way to express a list of valid RSs for this AS needs to be added to section 2. 
>>  
>> Best, 
>>  
>> Nat
>>  
>> 2016-03-11 2:09 GMT+09:00 Phil Hunt (IDM) <[e-mail]>:
>> I strongly oppose. 2 major issues. 
>>  
>> This is not service discovery this is configuration lookup. The client must have already discovered the oauth issuer uri and the resource uri. 
>>  
>> The objective was to provide a method to ensure the client has a valid set of endpoints to prevent mitm of endpoints like the token endpoint to the resource server. 
>>  
>> The draft does not address the issue of a client being given a bad endpoint for an rs. What we end up with is a promiscuous authz service giving out tokens to an unwitting client. 
>> 
>> Phil
>> 
>> On Mar 10, 2016, at 08:06, Vladimir Dzhuvinov <[e-mail]> wrote:
>> 
>> +1 to move forward with these
>> 
>> On 10/03/16 17:35, Brian Campbell wrote:
>> +1
>>  
>> On Thu, Mar 10, 2016 at 6:04 AM, Roland Hedberg <[e-mail]>
>> wrote:
>>  
>> I support this document being moved forward with these two changes:
>>  
>> - change name to “OAuth 2.0 Authorization Server Discovery Metadata” as
>> proposed by Brian and
>> - use the URI path suffix ’oauth-authorization-server’ instead of
>> ’openid-configuration’ as proposed by Justin.
>>  
>> 18 feb 2016 kl. 14:40 skrev Hannes Tschofenig <[e-mail]
>> :
>>  
>> Hi all,
>>  
>> This is a Last Call for comments on the  OAuth 2.0 Discovery
>> specification:
>> https://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>>  
>> Since this document was only adopted recently we are running this last
>> call for **3 weeks**.
>>  
>> Please have your comments in no later than March 10th.
>>  
>> Ciao
>> Hannes & Derek
>>  
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>> — Roland
>>  
>> ”Everybody should be quiet near a little stream and listen."
>> >From ’Open House for Butterflies’ by Ruth Krauss
>>  
>>  
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>  
>>  
>>  
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> 
>>  
>> -- 
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>