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

[Brian Campbell <[e-mail]>]

That *is* the scope of the current document, which a majority of folks have
agreed with. I was reiterating that the name of the document should reflect
its content, something else that has been widely agreed with.

On Fri, Mar 11, 2016 at 4:24 PM, Anthony Nadalin <[e-mail]>
wrote:

> Disagree, what purpose is this activity solving then, it was being pushed
> as what was need to solve the Mix-up, but that is not true. So now you are
> suggesting a change in scope and not dealing with discovery.
>
>
>
> *From:* OAuth [mailto:[e-mail]] *On Behalf Of *Brian
> Campbell
> *Sent:* Friday, March 11, 2016 3:11 PM
> *To:* John Bradley <[e-mail]>
>
> *Cc:* oauth <[e-mail]>
> *Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
>
>
>
> I tend to agree with John that addressing the concerns Phil raises should
> be part of (extension to) the core protocol.  And that those kinds of
> concerns don't manifest in the way OAuth is typically deployed now.
>
> The hopefully soon to be named "OAuth 2.0 Authorization Server Metadata"
> should keep it's scope to the publishing of authorization server metadata.
> The act of doing discovery is beyond its scope and so is trying to prevent
> a client from presenting a token to someplace it shouldn't.
>
>
>
> On Fri, Mar 11, 2016 at 9:08 AM, John Bradley <[e-mail]> wrote:
>
> Inline
>
> On Mar 11, 2016, at 12:13 PM, Phil Hunt (IDM) <[e-mail]>
> wrote:
>
>
>
> 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 was proposing ding that check at the authorization endpoint or token
> endpoint as part of AT issuance.
>
>
>
> It is up to the AS how much of the path to validate and or put in the aud
> or dst.
>
>
>
>
>
>
>
> I see it as part of the discovery(bad name aside) problem because we
> discussed that if a client finds app.example.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com%2f&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fiS8f60ypiXhyM0qVTeql%2b%2bOzH2wbmECQE7J5TtGPQM%3d>
> 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 think it is part of core protocol security and should/must not require
> discovery.
>
>
>
> What is app.example.com
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fapp.example.com&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=jAsZQeChJ%2bR1lbyBoVKwheIYi3PiWLrq%2bxDLbqU6rxk%3d>
> ?
>
>
>
> If it is the resource then the client would be preconfigured for it’s AS
> out of band or optionally would do discovery on the issuer uri that you
> admit needs to be configured out of band some way (note discovery is
> optional)
>
>
>
> In the AS meta-data draft it would do a get on a well known file that
> would have configuration for the AS, but not the RS, though some API may
> optionally list a API endpoint like connect has.
>
>
>
> The client then makes a authorization request (after registering out of
> band or dynamically).
>
> As part of the authorization request for implicit it could provide the
> aud/dst that it wants the token for.
>
> If that is not sent then the aud/dst are implicit in the scopes.
>
>
>
> The client gets back a AT with a list of scopes granted, aud/dst allowed
> and time to live for the token (one extra thing returned)
>
>
>
> This doesn’t require any discovery (yes there is a optional AS meta-data
> discovery but not required)
>
>
>
> I prefer to fix the RS man in the middle issue as part of the protocol and
> not part of discovery that should remain optional.
>
>
>
> I honestly don’t quite know how the client learns about this bad RS and
> starts talking to it, so this may be a solution to a problem that doesn’t
> yet exist.   The one place this is posable is if the registration for the
> client is compromised.  However we are discussing other mitigations for
> that that also explicitly do not require discovery.
>
>
>
> John B.
>
>
>
>
>
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-campbell-oauth-dst4jwt&data=01%7c01%7ctonynad%40microsoft.com%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=STr%2b4krd1hy8h6eHOCLh1PzQaKMUhWlKV2i%2fCL0K1SQ%3d>.
>
>
>
>
> 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] <[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]> <[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 <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-ietf-oauth-discovery-01&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=w3%2biiaWon81LJCU%2b2mCPRmA%2brECBHgqyRr0OgqiWSHU%3d>
>
>
>
> 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 <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>
>
> — 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 <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>
>
>
>
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> [e-mail]
>
> 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%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> 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%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=tNCikmXDBF7ubk%2b%2bzJiXwPB0LIzQXA%2fk%2bqR9m5WgA2k%3d>
>
>
>
>
>
> --
>
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fnat.sakimura.org%2f&data=01%7c01%7ctonynad%40microsoft.com%7c116eae6bd1b2492d56a508d349545c72%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6FVmdN7ad0YzoYKSNF%2fDO%2ffG2EF1haj5aOHiMid6UMI%3d>
> @_nat_en
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> 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%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bKsEVBUXc528yaAMLmycXcL33%2bFJCQrnq9asxRo5He8%3d>
>
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> 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%7c4b9bae5dda7a45096b8408d34a031e57%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bKsEVBUXc528yaAMLmycXcL33%2bFJCQrnq9asxRo5He8%3d>
>
>
>