I am fine with keeping it separate, however proper audience restriction of bearer tokens or POP tokens are key mechanisms to protect AT from miss use from a number of attacks.
John B. > On Apr 12, 2016, at 12:06 PM, Phil Hunt (IDM) <[email protected]> wrote: > > To be clear what I am saying... RI should be considered on its own merits as > an optional protocol extension. > > I do not believe it has merit when linking it to client mis-configuration > detection. The issues should be kept separate. > > Phil > >> On Apr 12, 2016, at 09:00, Phil Hunt (IDM) <[email protected]> wrote: >> >> >> >> Phil >> >>> On Apr 12, 2016, at 03:49, John Bradley <[email protected]> wrote: >>> >>> We did agree in BA that if the client sends no resource the AS would >>> audience the AT per configured policy and reply to the client with >>> additional meta-data about what resources the AT can be used at. >> >> We also agreed that was not a remedy for an attack where an attacker simply >> wants the token to use at the correct site to gain access to the resource. >> >> RI is no remedy for misconfiguration esp if it should be optional for the >> client. >>> >>> It should be obvious that this is in no way a breaking change. >>> >>> The only clients that need to provide a resource are ones that are asking >>> for a token for a unknown resource, not something that is supported >>> securely currently or by Pil’s spec. Or when down scoping a RT with >>> multiple audiences so that the server can provide the correct token type/ >>> claims / encryption/ signing. Can we agree that with symmetrically signed >>> AT it is not a good thing to use the same key for all RS? >>> >>> At the moment this can sort of be done with scopes but the client needs >>> much more documentation about the scopes to understand the mapping between >>> resource and scope, or possibly discovery of meta-data about the resource, >>> something also not covered in Phil’s draft. >>> >>> We can update the draft as an ID. >>> >>> This is essentially the audience part of the POP key distribution with the >>> addition of Nat’s meta-data for the token endpoint (in the existing JSON >>> rather than a new header) >>> >>> We need to address this. Discovery in general and Phil’s draft >>> specifically are not a replacement, even if we were to adopt them. >>> >>> To Phil’s other question about token binding, no an attacker can’t usefully >>> MitM a token bound AT. >>> The private key is controlled by the client and never disclosed. You can >>> give the token to a MitM attacker but they cannot use it anyplace even with >>> themselves as they don’t have the private key. That is the security goal >>> of token binding. >>> >>> John B. >>> >>>> On Apr 12, 2016, at 4:30 AM, Sergey Beryozkin <[email protected]> wrote: >>>> >>>> Hi >>>>> On 11/04/16 23:19, Phil Hunt (IDM) wrote: >>>>> I am objecting to modifying the protocol in the default case as a >>>>> majority do not need RI in the case of fixed endpoints. >>>>> >>>>> Migration would be challenging because the change is breaking and >>>>> affects existing clients. >>>> How does it break the existing clients given this is an optional feature ? >>>> Can you please describe the situation where the existing clients get >>>> broken ? >>>> >>>> Brian, would it make sense to update the text to mention that the clients >>>> do not have to be directly configured and instead it can be set during the >>>> registration time, so that the property gets seamlessly linked to client >>>> access tokens, etc, without the client applications having to be set up >>>> with the resource indicators manually ? >>>> >>>> Thanks, Sergey >>>> >>>>> Dynamic discovery are up and coming cases and a relatively green field. >>>>> Dealing with it at configuration/discovery makes broader sense as it has >>>>> no impact on existing clients. >>>>> >>>>> Phil >>>>> >>>>> On Apr 11, 2016, at 12:18, Brian Campbell <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>>> I'm not sure where the idea that it's only applicable to special uses >>>>>> like collaboration services is coming from. The pattern described in >>>>>> the draft (using a different parameter name but otherwise the same) is >>>>>> deployed and in-use for normal OAuth cases including and especially >>>>>> the resource owner centric ones. >>>>>> >>>>>> >>>>>> On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM) >>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>> >>>>>> I am finding I am not happy with solving the bad resource endpoint >>>>>> config issue with resource indicator. At best I see this as a >>>>>> special use draft for things like collab services or things which >>>>>> aren't resource owner centric. >>>>>> >>>>>> Yet resource endpoint config is a concern for all clients that >>>>>> configure on the fly. Is it reasonable to make resource indicator >>>>>> mandatory for all clients? Probably not. >>>>>> >>>>>> As OAuth depends primarily on TLS, it feels wrong not to have a >>>>>> solution that confirms the server host names are correct either >>>>>> via config lookup or some other mechanism. >>>>>> >>>>>> Tokbind is also a solution but I suspect it may only appeal to >>>>>> large scale service providers and may be further off as we wait >>>>>> for load balancers to support tokbind. Also there are issues with >>>>>> tokbind on initial user binding where the mitm attack might itself >>>>>> establish its own token binding. I have to think this through some >>>>>> to confirm. But the issue of worry is what is happening on >>>>>> initialization and first use if the hacker has already interceded >>>>>> a mitm. That would make validation at config time still critical. >>>>>> >>>>>> Hopefully somebody can arrive at an alternative for broader oauth >>>>>> use cases. >>>>>> >>>>>> Phil >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> -- >>>> Sergey Beryozkin >>>> >>>> Talend Community Coders >>>> http://coders.talend.com/ >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
