Re: [core] Review of draft-tiloca-core-oscore-discovery-05

[Marco Tiloca <[e-mail]>]

Hi Jim,

Thanks for this review!

We have addressed most comments in the latest version -06.

Please, see our replies in line, with three points marked as "[OPEN]".

Best,
/Marco

On 2020-06-06 04:08, Jim Schaad wrote:
> *  Consistently through this document you refer to an OSCORE group, however
> the groupcom-bis document talks about a security group.  At some point these
> need to be related.  Should you just be talking about security groups?

==>MT
Now we refer to "security groups" throughout the text. The term is
introduced in the terminology of Section 1.1, where we say that we
especially consider OSCORE groups in this document.
<==

>
> * Why do you believe that the group manager is going to know what
> application groups are associated with any given OSCORE group.   I don't
> believe that this information is being specified anyplace as being provided
> to the GM.  Does it make sense to register the three different groups that
> are from the bis document and make things flow the way one would expect from
> a device point of view  Application Group => Security Group, Application
> Group=> CoAP Group.  I assume that both clients and servers are going to
> know they want to deal with a specific application and start from there.  I
> don't know what an application itself as a root node would look like in the
> RD.

==>MT
[OPEN]

Considering also the input to the discussion about CoRAL Forms [1] :

1) we can extend the ACE gm-admin document [2] so that, when
creating/updating an OSCORE group at the Group Manager, the
Administrator indicates also the associated application groups, as part
of the configuration to store.

2) Then, in this document we can assume that the Group Manager knows
also about the application groups, when registering its security groups
to the RD.

This would not change the interactions in this document, when it comes
to the registration and lookup of other types of groups in the RD.

Note that the main RD document already defines registration and lookup
of application and CoAP groups, on which we are just building with no
changes.


[1] https://mailarchive.ietf.org/arch/msg/core/BoYGYmEpJMUS8bk4PNHOEaFFcdU/
[2] https://tools.ietf.org/html/draft-tiloca-ace-oscore-gm-admin
<==

>
> * I do not understand "Values registered as a string that look like an
> integer are not supported".  I need an example for what you are talking
> about.  I would have expected that alg=-2 and alg="-2" would both be legal,
> but "-2" is a required to be supported since it is a text string per the
> definition above.

==>MT
With the parameter value "-2" we intend to indicate the integer -2.

Link-format does not distinguish between "-10" and -10, as it is weakly
typed (or rather not typed at all). But the IANA registry for COSE
parameters seems to be strongly typed. We trust the experts not to let
the 3-byte string value "-10" into the registry, but to allow having
both numeric and string values in the link attribute, we have to rule
that out formally.

The intention is to say that if "-10" were ever entered into the
registry, this protocol wouldn't allow using it. We have improved the
wording about this point in Section 2.1, trying to make it clearer.
<==

>
> * I need to get some help.  What is the difference, both theoretical and
> factual, between the if= and rt= links.  How much of this should be if= vs
> rt= because it is common amount all expected group managers as oppose to
> just the Ace group manager.

==>MT
[OPEN]

Based on [3], if= expresses that the resource "follows this pattern of
behavior", while rt= expresses that the resource "is a".

But all the interactions that we are specifying can be interchangably
phrased as "if it claims to be an X" or "if it follows the X interface".

So, on one hand, it probably does not matter too much, and we can just
keep 'rt' that we use now.

On the other hand we are specifying an 'if' value "ace.group" for the GM
interface described in the ACE documents, see [4]. Shouldn't we then
have 'if' also for the links we register in this document, since they
target the same type of GM?


[3] https://tools.ietf.org/html/rfc6690#section-3
[4] https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-08#section-4.1
<==

>
> * In the example in section 3.1 - I don't know that the GM should be the one
> registering the "rel" links here.  That should be up to the endpoint
> instead.  Perhaps break this up into a POST and a GET?

==>MT
[OPEN]

Who else can register the "rel" links? The Administrator that created
the security group at the GM?

Most important, why is the GM not appropriate for this registration?
It's about links to the AS for the sake of the group-membership
resources that the GM itself owns. Consistently, the GM is the entity
which is going to consume the issued Access Tokens.

Also, the comment says "the endpoint instead", but the endpoint in
Section 3.1 is exactly the GM.

In the suggested split, what is the GET supposed to cover and provide?
If the point of the GET is for the GM to retrieve the "rel" links
(registered by someone else), that feels strange, because the GM knows
about the AS already since the security group was created.
<==

>
> * In section 5, I believe that the registration of the endpoints is
> incorrect.  You are doing this in two steps, but the first registration is
> going to be replaced not augmented by the second registration.  You need to
> do a single registration here.

==>MT
Correct, we have fixed the double registration in -06.

After doing that, we have also removed altogether from the example the
registration of endpoints to an application group. In fact, this feature
is not natively supported by the RD and we would prefer to not introduce
it in this document.
<==

>
> * In section 5 - It seems relatively obvious how you deal with an OSCORE
> group having multiple applications, but I think you need to have some
> discussions on how you deal with an application which has multiple OSCORE
> groups in it.

==>MT
Right. For what concerns this document, we have made the following changes.

1) Since this is something more general than the example of this
section, we have added some text in Section 4 "Discovery of Security
Groups", see the three new paragraphs after the bullet list.

The second and third of those paragraphs are about multiple application
groups using a same security group. At the moment, this text generically
refers to application policies to decide about the exact application
group to consider.

We can refine the text in a next version, also based on the outcome of
the discussion started at [5]. In particular, we can give examples of
such situations, with a safe one currently being: different security
groups reflect different security algorithms/parameters to use; a CoAP
server in the application group joins all of those security group; a
CoAP client that wants to talk to the servers in that application group
joins any of those security groups it supports.

2) About the example itself in this section, we have now stressed that
it does not have any particular ambition to serve as recommendation or
as best practice to adopt. It simply shows a possible workflow involving
a Commissioning Tool used in a certain way, but this does not have to be
mistaken for how the workflow should necessarily be (see second and
third paragraph in Section 5).


[5] https://mailarchive.ietf.org/arch/msg/core/4JtUVaB-XG_g0i_8v8CEMGyNdO8/


Thanks a lot again!
<==

>
> 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: [phone]
https://www.ri.se