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> 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
