Good to see you are following along with what's happened.
Post by Anthony NadalinSorry but not true, this started out as âdiscoveryâ and now itâs not
*Sent:* Friday, March 11, 2016 3:59 PM
*Subject:* Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery
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.
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.
Campbell
*Sent:* Friday, March 11, 2016 3:11 PM
*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.
Inline
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
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.
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
Behalf Of *Nat Sakimura
*Sent:* Thursday, March 10, 2016 6:25 PM
*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
12. A way to express a list of valid RSs for this AS needs to be added to section 2.
Best,
Nat
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
+1 to move forward with these
+1
- 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.
Hi all,
This is a Last Call for comments on the OAuth 2.0 Discovery
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
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."
Post by Roland HedbergFrom âOpen House for Butterfliesâ by Ruth Krauss
_______________________________________________
OAuth mailing list
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
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
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
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
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>