> -----Original Message-----
> From: Ludwig Seitz <[email protected]>
> Sent: Wednesday, October 24, 2018 2:02 AM
> To: Jim Schaad <[email protected]>; draft-ietf-ace-oauth-
> [email protected]
> Cc: [email protected]
> Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
>
> On 23/10/2018 20:44, Jim Schaad wrote:
> >
>
> >
> >
> >>> * Section 6 - I am not sure that I agree with the SHOULD NOT in the
> >>> last paragraph. Think multicast.
> >> Any suggestions on how to mitigate the issue then? If I issue a token
> >> bound to a symmetric key for audience {R1, R2, R3}, as soon as R1 got
> >> this token it can impersonate the client and gain access to R2 and
> >> R3.
> >
> > I am not sure that I think this is an issue that needs to be
> > mitigated. It needs to be acknowledged, but the assumption would be
> > that if you have three resource servers that are hosting the same
> > audience they are going to be run by the same RO and already be
> > coupled. After all it should not matter which of them you do a GET
> > from, you should get the same answer. Similarly a PUT to one should
> > propagate to the others so that it is available to all clients.
> >
>
>
> Say the client is a cleaning service and the audience is the locks of the
> different apartments it is allowed to open.
>
> If the token uses symmetric keys, as soon as the cleaning service sends the
> token to one apartment, this apartment can open the other apartments. This
> is the situation I want to avoid.
I would not expect that the locks would all be a single audience. You might
have all of the locks in a single apartment be one audience but you would want
to separate the apartments into different security groups. The cleaning
service should be required to obtain a token specific to an apartment and not
generally for all apartments.
If you have a situation where a single audience encompasses multiple security
objects that are to be controlled differently then you run across the problem
that Stefanie was raising where you cannot know which RS to make the token for
because you are now needing to map audience, scope and actions all to a
different RS which seems to be defeating the purpose of having an audience.
Jim
>
> /Ludwig
>
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
