-----Original Message-----
From: Ace <ace-boun...@ietf.org> On Behalf Of Michael Richardson
Sent: Wednesday, February 26, 2020 5:17 AM
To: Jim Schaad <i...@augustcellars.com>; ace@ietf.org
Subject: Re: [Ace] Jim's Proposal on legal requestor


clarifying question.

Jim Schaad <i...@augustcellars.com> 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.


[JLS] Yes

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

[JLS] Having the list of valid signers in not in itself sufficient as both
requests and responses are going to be signed so you know who sent the
message and the fact that they are on the legal list.  Doing the turn the
group key into 1:1 doesn't work if you want to do a multicast request, as
that would end up being all unicast.

Jim


--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works  -=
IPv6 IoT consulting =-




_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Reply via email to