Subject: [Ace] Jim's Proposal on legal requestor

From: Jim Schaad <[email-masked]>
Date: Tue, 25 Feb 2020 20:38:22 -0800

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.

*  I get an access token from an AS with a scope of  [
"coap://multicast-01", ["responder"]]
*  I join the group associated with that address
*  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

* The server TimeX receives the above message.  It starts to process the
message by checking the signature - that passes.  It then decrypts the
message and that succeeds.  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.

This will not happen for the MQTT profile as long as the AS (singular or
plural) are setup correctly as the MQTT broker would not allow the publish
operation to occur as it also has the set of operation permissions to
enforce.

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

Jim

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Feb 2020 08:17:04 -0500

clarifying question.

Jim Schaad <[email-masked]> 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 [
    > (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.

!

    > 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-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Marco Tiloca <[email-masked]>
Date: Wed, 26 Feb 2020 14:07:58 +0000

Hi!

Jim, I think now I understand your idea and it makes sense to me.

Some comments in line below.

Best,
/Marco

On 2020-02-26 14:17, Michael Richardson wrote:
> .... (I numbered the steps)

==>MT
Step (1) is intended to allow access to the group-membership resource at
the Group Manager (GM), to get the keying material for communicating in
the group.

Practically, the roles are currently used only at the GM to determine
which public keys is relevant to return to a node upon its joining.
<==

>     > because it does not know that this is a violation of the scope assigned

==>MT
As above, the original idea for that scope was to have it applied to the
group joining itself and the resource at the GM to access for joining.

But I agree that we should inform the other group members of that role,
i.e. "allowed to send requests" and/or "allowed to send responses".
<==

>     > signature public key from the KDC to the server.  

==>MT
This can be one more parameter in the Joining Response or in the Public
Key Response, when request public keys of group members are included.

Together with the array of public keys, we can have a same-ordered array
of roles echoing the roles from the scope of the Access Token above.
Each element of the array can possibly be an array of roles.

How does it sound?
<==

> One can create a

==>MT
Right, if it's "requester"-only.
<==

> Or, we need LAKE to turn the group key into 1:1.

==>MT
What I understand from Jim's proposal is essentially enabling at each
group member a list of valid request signers and valid response signers.
<==

==>MT
Just to complement, this is all fine for this level of "filtering", i.e.
"this group member can send requests/responses or not".

We have a separate draft at [1], defining a new Group OSCORE profile of
ACE, to enforce access control within the group, i.e. to access group
members' resources after having joined, i.e. as a group member towards
another group member.

That is, that profile considers a granularity of exact REST methods and
resources, i.e. as fine-grained as ACE can be. Also, it enables having
together ACE-based access control and Group OSCORE, which is so far not
possible with other profiles.

The current version -01 in the datatracker defines a "full mode" where
both OSCORE and Group OSCORE are considered as security protocols
between Client and RS. We plan to submit soon an updated version,
focusing more on a lighter, intended-to-be main mode, that focuses on
using only Group OSCORE as security protocol between Client and RS.

[1] https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01
<==

Best,
/Marco

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se

---

From: Jim Schaad <[email-masked]>
Date: Wed, 26 Feb 2020 07:44:05 -0800

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, February 26, 2020 5:17 AM
To: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [Ace] Jim's Proposal on legal requestor

clarifying question.

.... (I numbered the steps)
I believe that (1) was intended to allow you to become a responder for this
resource.

[JLS] Yes

!

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 <[email-masked]>, Sandelman Software Works  -=
IPv6 IoT consulting =-

---

From: Jim Schaad <[email-masked]>
Date: Wed, 26 Feb 2020 09:59:21 -0800

From: Ace <[email-masked]> On Behalf Of Marco Tiloca
Sent: Wednesday, February 26, 2020 6:08 AM
To: Michael Richardson <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [Ace] Jim's Proposal on legal requestor

Hi!

Best,
/Marco

clarifying question.

 

==>MT
Step (1) is intended to allow access to the group-membership resource at the Group Manager (GM), to get the keying material for communicating in the group.

Practically, the roles are currently used only at the GM to determine which public keys is relevant to return to a node upon its joining.
<==

[JLS] When implies that the only roles of interest are “monitor” vs not “monitor”.

 
 
!

==>MT
As above, the original idea for that scope was to have it applied to the group joining itself and the resource at the GM to access for joining.

But I agree that we should inform the other group members of that role, i.e. "allowed to send requests" and/or "allowed to send responses".
<==

 
    > signature public key from the KDC to the server.  

==>MT
This can be one more parameter in the Joining Response or in the Public Key Response, when request public keys of group members are included.

Together with the array of public keys, we can have a same-ordered array of roles echoing the roles from the scope of the Access Token above. Each element of the array can possibly be an array of roles.

How does it sound?
<==
[JLS] Yes this makes sense.  The only potential issue is what happens if the set of roles becomes in some sense unbounded for an application.  However, in that case I would expect that the list of roles would be known to the joining clients.  The one thing that comes up here is should there be a compression of these values since we are sending them to a larger group of people.

One can create a

==>MT

==>MT
What I understand from Jim's proposal is essentially enabling at each group member a list of valid request signers and valid response signers.
<==

==>MT
Just to complement, this is all fine for this level of "filtering", i.e. "this group member can send requests/responses or not".

We have a separate draft at [1], defining a new Group OSCORE profile of ACE, to enforce access control within the group, i.e. to access group members' resources after having joined, i.e. as a group member towards another group member.

That is, that profile considers a granularity of exact REST methods and resources, i.e. as fine-grained as ACE can be. Also, it enables having together ACE-based access control and Group OSCORE, which is so far not possible with other profiles.

The current version -01 in the datatracker defines a "full mode" where both OSCORE and Group OSCORE are considered as security protocols between Client and RS. We plan to submit soon an updated version, focusing more on a lighter, intended-to-be main mode, that focuses on using only Group OSCORE as security protocol between Client and RS.

Best,
/Marco

 
--
Michael Richardson  <mailto:[email-masked]> <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

_______________________________________________
Ace mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/ace

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: Marco Tiloca <[email-masked]>
Date: Thu, 27 Feb 2020 12:51:25 +0000

Hi Jim,

On 2020-02-26 18:59, Jim Schaad wrote:
>
>  
>
>  
>
> *From:* Ace <[email-masked]> *On Behalf Of *Marco Tiloca
> *Sent:* Wednesday, February 26, 2020 6:08 AM
> *To:* Michael Richardson <[email-masked]>; Jim Schaad
> <[email-masked]>; [email-masked]
> *Subject:* Re: [Ace] Jim's Proposal on legal requestor
>
>  
>
> Hi!
>
>     Jim Schaad <[email-masked]> <mailto:[email-masked]> 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
>
>      
>
> Step (1) is intended to allow access to the group-membership resource
> at the Group Manager (GM), to get the keying material for
> communicating in the group.
>
>         > 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.
>
>      
>
>     !
>
>
> ==>MT
> As above, the original idea for that scope was to have it applied to
> the group joining itself and the resource at the GM to access for joining.
>
> But I agree that we should inform the other group members of that
> role, i.e. "allowed to send requests" and/or "allowed to send responses".
> <==
>
>
>      
>
>      
>
>         > 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.  
>
>
> ==>MT
> This can be one more parameter in the Joining Response or in the
> Public Key Response, when request public keys of group members are
> included.
>
> Together with the array of public keys, we can have a same-ordered
> array of roles echoing the roles from the scope of the Access Token
> above. Each element of the array can possibly be an array of roles.
>
> How does it sound?
> <==
> [JLS] Yes this makes sense.  The only potential issue is what happens
> if the set of roles becomes in some sense unbounded for an
> application.  However, in that case I would expect that the list of
> roles would be known to the joining clients.  The one thing that comes
> up here is should there be a compression of these values since we are
> sending them to a larger group of people.
>

==>MT
Yes, I think so. One integer per role should work, registered by the
profile or application defining that role.

Other that the wider distribution you mention above, compression is good
anyway considering the recently discussion on 'scope' covering multiple
groups, each with its role(s) indicated.
<==

Best,
/Marco

>
>     One can create a
>
>         > similar scenario on the other side where a client sends a response when
>
>         > it is only authorized as a "requester".
>
>
> ==>MT
> Just to complement, this is all fine for this level of "filtering",
> i.e. "this group member can send requests/responses or not".
>
> We have a separate draft at [1], defining a new Group OSCORE profile
> of ACE, to enforce access control within the group, i.e. to access
> group members' resources after having joined, i.e. as a group member
> towards another group member.
>
> That is, that profile considers a granularity of exact REST methods
> and resources, i.e. as fine-grained as ACE can be. Also, it enables
> having together ACE-based access control and Group OSCORE, which is so
> far not possible with other profiles.
>
>     Michael Richardson <[email-masked]> <mailto:[email-masked]>, Sandelman Software Works
>

-- 
Marco Tiloca
Ph.D., Senior Researcher