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 wanted to look up the identifier for a given resource. Something like do get on resource get back Abstract identifier (probably well known location, as recently pointed out in another thread you can’t allow it to point to user content.) The AS gets the file and maps the uri to a abstract identifier for audience. I guess that would be one way that you could map AS URI to a abstract identifier, but I wouldn’t want to count on clients doing it. John B. > On Mar 16, 2016, at 3:46 PM, Phil Hunt <phil.h...@oracle.com> wrote: > > 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 <http://www.independentid.com/>phil.h...@oracle.com > <mailto:phil.h...@oracle.com> > > > > > >> On Mar 16, 2016, at 11:29 AM, George Fletcher <gffle...@aol.com >> <mailto:gffle...@aol.com>> wrote: >> >> Inline... >> >> On 3/16/16 2:16 PM, Phil Hunt wrote: >>> >>> Phil >>> >>> @independentid >>> www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com >>> <mailto:phil.h...@oracle.com> >>> >>> >>> >>> >>> >>>> On Mar 16, 2016, at 10:59 AM, George Fletcher <gffle...@aol.com >>>> <mailto:gffle...@aol.com>> wrote: >>>> >>>> >>>> >>>> On 3/16/16 12:20 PM, Phil Hunt (IDM) wrote: >>>>> George >>>>> >>>>> Very good question... >>>>> >>>>> I considered that the RS metadata discovery could be fake. >>>> Same way that the 'iss' claim must "match" the url used to retrieve the >>>> metadata would apply to the 'rsid' claim >>>> -- I think that should suffice to ensuring the 'rsid' identifier can't be >>>> spoofed by another site >>> >>> So the attacker makes iss and url match for the resource discovery. Yet the >>> AS service provider doesn’t know where the client is using the tokens. How >>> would the client or the AS detect that the wrong iss was given? >> Because if the attacker makes the rsid and the url match, then the client >> will submit an rsid that isn't "registered" with the AS and the AS won't >> issue the token. This assumes the client is not talking to an evil AS (as >> there are other mitigations for that case). >>> >>>>> >>>>> So the final step in configuration validation is to bind the relationship >>>>> between as and rs discovery together to confirm the relationship is >>>>> valid. >>>> And what I'd like to see is the 'rsid' value used to represent the RS >>>> rather than some unique endpoint (even if wildcards are allowed) >>> >>> Long term, I think this would be better. Do we have a way to issue RSID >>> values in the works? >> No, but that is what this email thread is contemplating:) Just as the AS iss >> value is selfdefined by the AS, the rsid should be selfdefined by the RS. >> Requiring a 'rsid' claim in the RS metadata is a mirror of how the AS 'iss' >> claim is defined for the AS in it's metadata. >>> >>> That said, I would have thought this is more ownerous than checking >>> *.example.com <http://example.com/> matches the given URL by the client. >> My problem with the URL level checking is that a RS may legitimately have >> endpoints on multiple domains. An RS may move endpoints from one domain to >> another (say when moving from version 1 to version 2 of an API). Using the >> rsid for audience restriction and as an indirect mechanism for specifying >> actual endpoints, the RS has a much looser coupling with the AS. >> >> AS we move into "federated authorization" meaning that an RS outsources it's >> API authorization to one or more AS's, this will become more important. >>>> >>>> Another step that may be required is for the RS to return it's 'rsid' in >>>> the realm field of the WWW-Authenticate response header. This allows a >>>> client to discover metadata about the RS and it's endpoints. It also >>>> allows the client to determine if the 'rsid' returned by the RS matches >>>> the 'rsid' it is expecting. >>> >>> Agreed. This might work. But should the check be when the client asks for >>> the configuration metadata or when the client asks for tokens? I think it >>> only needs to happen at config time. >> What I see here is that the desire is to audience protect tokens. To do >> that, the audience need to be specified everytime a token is requested. I >> really don't the AS to have to manage the complex state of which audiences >> have previously been issued to refresh_tokens and then reconstruct the >> correct audience for a requested downscoped access_token. It's much simpler, >> since the client knows which RS it's going to send the token to, to provide >> that when requesting tokens. >> >> The complication comes when exchanging the code for the tokens, it needs to >> specify all possible audiences (rsid's) it might send the token to based on >> the requested scopes. There will be a fair amount of complex logic at the AS >> to ensure the correct behavior. I do worry about this complexity. >>>>> >>>>> We are of course assuming that a hacker needs to use the real AS >>>>> authorize endpoint to succeed in obtaining an access token(it can't be >>>>> mitm'd). Once the grant is obtained by the client, the threat comes when >>>>> the client uses the grant at a mitm'd token endpoint OR an access token >>>>> at a mitm'd resource endpoint. >>>>> >>>>> So the AS and its config set becomes the trust anchor. Binding allows us >>>>> to extend trust to the RS discovery giving some assurance that a client >>>>> has a correct set of endpoints including resource. >>>> Are you recommending that the AS metadata provide a list of the 'rsid' >>>> supported by the AS? >>> No. I think that is a bad idea. Better to use an identity oracle function >>> and say, give me the config for rsid=xyz >> Good :) >>> >>> That also allows a common AS discovery endpoint to actually do discovery >>> for multiple AS systems. E.g. to configure a client to a specific AS >>> service designated by the customer paying for the resource service. >>> >>> IOW. by providing a resource query, the meta-data config discovery actually >>> looks more like discovery. :-) >>>>> >>>>> John's solution requires translating aud to res url and changes to core >>>>> oauth. He seems to imply there is a need for ongoing validation of >>>>> resource. I'm not yet convinced that is really needed. Maybe it is >>>>> needed because the client could be convinced to follow a link embedded in >>>>> a resource that is somehow not part of the defined audience? >>>>> >>>>> Thanks >>>>> >>>>> Phil >>>>> >>>>> On Mar 16, 2016, at 08:57, George Fletcher < >>>>> <mailto:gffle...@aol.com>gffle...@aol.com <mailto:gffle...@aol.com>> >>>>> wrote: >>>>> >>>>>> 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 the metadata from a >>>>>> .well-known location and including a claim of 'rsid' to use as an >>>>>> identifier of the Resource Server. >>>>>> >>>>>> This 'rsid' identifier could then be used for registration with the AS >>>>>> and presentation by the client when requesting tokens. >>>>>> >>>>>> This provides a separation between an identifier for a resource and the >>>>>> specific endpoints the token will be sent to. A client could "discover" >>>>>> the necessary endpoint on a periodic basis and use a single identifier >>>>>> with the AS for any of the endpoints or scopes supported by the RS. If >>>>>> desired the RS could expose the supported scopes in the RS metadata file. >>>>>> >>>>>> Thoughts? >>>>>> >>>>>> Thanks, >>>>>> George >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >> > > _______________________________________________ > 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
