clarifying question. Jim Schaad <[email protected]> wrote: > I do not seem to have been doing a good job of explaining the issue > that I am raising here, so I am going to go scenario based for a > description.
> (1) I get an access token from an AS with a scope of [
> "coap://multicast-01", ["responder"]]
> (2) I join the group associated
> with that address
> (3) I then decide to send the message below out
> encrypted with the group symmetric key and signed with the public key I
> registered during the join
> GET coap://multicast-01/resource1
.... (I numbered the steps)
I believe that (1) was intended to allow you to become a responder for this
resource.
> It then processes the get request
> because it does not know that this is a violation of the scope assigned
> to me by the AS.
!
> The only way that I know for the server TimeX to enforce the allowable
> operations is for that information to be propagated along with the
> signature public key from the KDC to the server. One can create a
> similar scenario on the other side where a client sends a response when
> it is only authorized as a "requester".
It seems to me that if the access control to the group is a group-shared
symmetric key + asymmetric signature, that each responder requires the list of
valid signers.
Or, we need LAKE to turn the group key into 1:1.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
