Subject: Re: [core] Comments on draft-tiloca-core-oscore-discovery

From: Marco Tiloca <[email-masked]>
Date: Wed, 20 Feb 2019 23:01:11 +0100

(updated the subject)

Hello Jim,

Thanks a lot for your comments and sorry for the late reply.

Please, find our answers inline below.

We have been updating our draft based on your input.

Best,
/Marco

On 1/24/19 1:57 AM, Jim Schaad wrote:
> I am having a huge problem understanding this document because I am
> completely confused by the model that is being propagated here.  
>
> This document has a model that every group is going to be on a different
> resource.  It is not clear that this is the same model as is being used in
> the ACE group communication document.   Probably one of these two documents
> should provide a more explicit module of how things work if this is what is
> going to be desired.  I was under the impression that a single join point
> would be used for multiple groups at the same time.  This may be acceptable
> with this document but if so then it is really not clear.

<MT>

Sorry for the confusion. This document and the ACE document [1] are
aligned and in fact follow the same model. We can especially clarify
that this document uses two types of groups, namely "application group"
and "security group".

The concept of "application group" is already defined and used in the
Resource Directory draft, and we recall it in Section 1.1 of this document.

Then, we can also explicitly include the definition of "security group",
as a set of CoAP endpoints sharing common keying material for securing
communications in a group setting. With particular reference to Group
OSCORE, "security groups" are used in the same way both in the ACE
document [1] as well as in this document.

That said, the same and common model is such that:

- Each "application group" uses only one OSCORE group as "security group".
- A single join resource, i.e. join point, is associated to one
"security group".
- A "security group" and its join resource can be used by multiple
"application groups".

Also, to avoid further confusion, we have thought it's better to rename
the parameter "oscore-gp" as "app-gp". This is in fact used as name of
the "application group", and thus it is not strictly related to Group
OSCORE.

[1] https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore

</MT>

> This document appears to be pointed at dealing with multicast groups, but
> there does not seem to be any tie between multicast resources and join
> request points.  The document should also deal with the same issue for
> pub-sub servers as that is of interest as well.

<MT>

The multicast resources are shared by all the members of a same
"application group", registered in the RD and with its own IP multicast
address. Instead, a join resource (i.e. join request point) is related
to an OSCORE group used as "security group" by the "application group".

The link between the two is the attribute currently named "oscore-gp",
that can be used as search criterion. As mentioned above, we plan to
rename it as "app-gp", to align it with its intended meaning defined in
Section 5, i.e. name of an "application group".

We didn't think of pub-sub servers, since Group OSCORE does not cover
that communication model. However, we believe it may possible to
generalize this document to cover also a pub-sub setting, building on
[2]. At the same time, it is probably better to first see how security
activities related to pub-sub develop.

[2] https://tools.ietf.org/html/draft-ietf-core-coap-pubsub-06#section-5

</MT>

> This document appears to be missing the registration of the oscore-gp and
> oscore-gid attributes.  I don't know but assume that there is (or should be)
> a registry for these types of things.  Specifically do these items allow for
> multiple values or are they single valued?  (I will assume that if they are
> multiple valued they should appear as multiple items just to make life
> easier.)

<MT>

We are also considering where to possibly register those attributes, and
there seems to be no easy answer.

Since there is no registry for link target attributes, we thought of the
"RD Parameter" registry [3], but it's probably not the best thing to do.

In fact, other applications may still use those parameters in link
registrations, that could tell RDs to act differently on them in some
places [4]. However, that won't keep others from using those parameters
for their purposes in general to-be-registered link-format data.

More specifically on their values:

- "oscore-gid" does not allow for multiple values, since an OSCORE Group
has a single Group ID.

- "oscore-gp" (to be renamed as "app-gp") allows for multiple values.
When this happens, it in fact appears as multiple items, as we show in
the example at the end of Section 5.2.

We can make these points explicit in Section 5, in the bullet points
about these parameters.

[3]
https://tools.ietf.org/html/draft-ietf-core-resource-directory-19#section-9.3

[4] For instance, not accept them as endpoint attributes, or treat them
differently on lookup. All considering that, users must be prepared for
RDs not implementing the special behavior.

</MT>

> Jim

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