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