Sorry I don’t recall agreeing that audience restricting the AT is not a remedy for an attacker getting the token to access a resource.
I don’t quite follow that. John B. > On Apr 12, 2016, at 12:00 PM, Phil Hunt (IDM) <phil.h...@oracle.com> wrote: > > > > Phil > >> On Apr 12, 2016, at 03:49, John Bradley <ve7...@ve7jtb.com> 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 <sberyoz...@gmail.com> 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 <bcampb...@pingidentity.com >>>> <mailto:bcampb...@pingidentity.com>> 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) >>>>> <phil.h...@oracle.com <mailto:phil.h...@oracle.com>> 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 >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> -- >>> Sergey Beryozkin >>> >>> Talend Community Coders >>> http://coders.talend.com/ >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
