Re: [Ace] remarks on draft-tiloca-ace-oscore-gm-admin-00

[Marco Tiloca <[e-mail]>]

Hi Jim,

Thanks a lot for this review!

We have taken it into account in the latest submitted -01, together with
the followup discussion on the same thread on the list.

https://tools.ietf.org/html/draft-tiloca-ace-oscore-gm-admin-01

Please, see some replies inline.

Best,
/Marco

On 2019-11-20 00:13, Jim Schaad wrote:
> This is just going to be a high level review on how things are done rather
> than a detailed review on each line of text.
>
> 1. - Go and read that CoRE Pub-Sub update document - you know the one that
> Klaus and friends have not managed to get written since the model proposal
> was done way back when.

==>MT
The latest version considers an akin interface, along the lines of the
now published draft at
https://datatracker.ietf.org/doc/draft-hartke-t2trg-coral-pubsub/
<==

>
> 2.  Re-write this to use CoRAL - Yes I know that this makes another
> dependency on getting it published from the CoRE group, but I don't want to
> do things multiple times.

==>MT
We have now also added examples in CoRAL, for all the interactions
between Administrator and Group Manager, now also extended with FETCH
for filtered retrieval.
<==

>
> 3.  I think that this document really needs to be able to be used with
> HTTP/JSON as well as CoAP.   If you can get the JSON version of CoRAL from
> Klaus then this falls out without any work.

==>MT
We are now saying that the CoRAL examples are provided in text format,
but they are in CBOR or JSON on the wire.
<==

>
> 4.  Are you making it a requirement that the group name be the same as the
> group identifier assigned by the "group_name" parameter?  If so then having
> some type of title and description would seem to be almost mandatory.

==>MT
We have added a new group configuration parameter 'group_title', as a
CBOR text string. This specifies a human-readable descriptive name of
the group, suggesting what it is about.
<==

>
> 5.  There needs to be some parameters around pointing to the correct AS and
> so forth.  The management API may reject because it does not trust the AS.
> Don't assume that this is a single value for the AS either.

==>MT
Now the POST request to /manage specifies also an optional 'as_uri'
parameter, with the link to a suggested AS. The GM may accept the
suggestion or not.

At the moment, only the link is specified. As already mentioned, we can
think more of related sub-items about it to add.
<==

>
> 6.  You are missing a lot of management detail on the POST to the group
> node.  Some of the things that are missing would be:
> a)  Is the group active or inactive

==>MT
We have added one more status parameter 'active'.

Based on earlier discussions, an inactive group would mean that: i) no
new members are admitted, thus no new keys to new members are provided;
ii) stop issuing of new keys for current members; iii) current members
are expected to stop communicating (which should rely on informing them)
but are not removed. So the group is temporarily inactive but still exists.
<==

> b) How does the server react if you change a the content encryption
> algorithm, is this a simple re-key operation or is it more complicated
> c) How does the server react if you change the signature algorithm?  This
> would seem to be a much harder thing to do if the group is not empty or not
> active as everybody is going to need to re-join.
> d) Other parameter that are changed may be just as bad as changing the
> signature algorithm - how the re-key is done jumps immediately to mind.

==>MT
These cases are now discussed in Section 2.5.5.2.
<==

>
> 7.  Is there currently any way for a KDC to signal to all of the members
> that have joined that the key group no longer exists?  A DELETE would seem
> to indicate the need to be able to do this.

==>MT
This is now discussed in Section 2.5.6.1.
<==

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