Re: [Ace] FW: Review of draft-ietf-ace-key-groupcomm-oscore-05

[Marco Tiloca <[e-mail]>]

Hello Jim,

The latest version -06 submitted today should have addressed all your
comments below.

https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-06

Please, see replies inline. Thanks a lot for this review!

Best,
/Marco

On 2020-03-15 22:43, Jim Schaad wrote:
> Forgot to cc the group
>
> -----Original Message-----
> From: Jim Schaad <[e-mail]> 
> Sent: Sunday, March 15, 2020 1:48 PM
> To: '[e-mail]'
> <[e-mail]>
> Subject: Review of draft-ietf-ace-key-groupcomm-oscore-05
>
> * Introduction:  In para 2, the second sentence needs to be re-written.  If
> you remove the subclause, then you get "This relies on a Group Manager where
> members exchange   CoAP messages secured with Group OSCORE." Which is wrong.

==>MT
We have rephrased the text as: “This relies on a Group Manager, which is
responsible for managing an OSCORE group, and enables the group members
to exchange CoAP messages secured with Group OSCORE.”
<==

>
> * Section 2 -  The following is a problematic statement " All communications
> between the involved entities rely on the CoAP protocol and MUST be
> secured."  For something like MQTT you want to be able to do it in JSON/HTTP

==>MT

Rephrased as: “All communications between the involved entities MUST be
secured.”

<==

>
> * Section 2.2 - I think it might be worthwhile in para 3 to give the reason
> for needing a new group identifier - This is because of the conflict in name
> between group identifier of OSCORE and group identifier of
> ace-key-groupcomm.  You have not yet stated that they are different things.

==>MT
Now the first bullet point on the Gid clarifies that it is
OSCORE-related information, and highlights the difference from the group
name in Section 1.1.
<==

>
> * Section 3.1 - I think I said this before but ["requester", "monitor"]
> seems to be a bit of an oxymoron.  Anybody who is either a requester or a
> responder can be a monitor without advertising the fact.

==>MT

We have removed this combination of roles.


It’s true that if the joining node is requester or requester+monitor ,
it has in either case to provide its own public key and may want to
retrieve the other members’. So there is no difference in terms of key
provisioning either.

<==

>
> * Section 3.1 -  The table in figure 1 is currently not usable due to the
> definition of scope in ace-key-groupcomm.

==>MT

This should now be fine, since Section 3.1 of ace-key-groupcomm is
admitting flexibility in the encoding of group name and roles, left to
the application profile as per REQ1 and REQ2.


In this document, REQ1 is defining group names to be encoded as CBOR
text strings, while REQ2 is defining roles to be encoded as abbreviating
CBOR integers.

<==

>
> * Section 3.1 - The framework allows for the scope and the audience to be
> implicit for an endpoint that is only doing one thing.  Are you sure you
> want to eliminate that option?

==>MT
Right. In the revised text, we don’t mention ‘audience’ anymore, while
we detail the content of ‘scope’ if present.
<==

>
> * Section  4 - I think you probably want to justify the reason for changing
> the base name of the resource.  Also the same comments that I made in
> ace-key-groupcomm about registering as a well-known are going to exist if
> you really want it to be fixed.

==>MT

That was an oversight. The segment group-manager/ was supposed to be
group-oscore/ , as in the operations described in the following sections.


On the second part of the comment, this resource just inherits the
Interface Description (if=) Link Target Attribute value “ace-group”
introduced in Section 4.1 of ace-key-groupcomm and registered in Section
8.9 of that same document.

<==

>
> * Section 5.2 - scope should not be a mandatory element in the request - it
> is implicit in the path name and the scope in the token.

==>MT
Ok, we have made scope optional in the joining request, by simply not
mentioning it anymore. Then the MAY contain from ace-key-groupcomm
applies here.
The last path segment is fine for the GM to understand the group at
hand, then the corresponding allowed roles are also retrievable from the
stored token claims. <==

>
> * Section 5.2.1 -  Is this a place where we need to look at replay?  I don't
> think so because of the cryptographic wrapper, but we need to have that
> discussion in the document.  Which indicates a pointer from this section to
> where that discussion is.

==>MT
At the end of the section, we have added a pointer to the new Section
17.3, whose content was already included as part of Section 17.2.
<==

>
> * Section 5.4 - cs_alg should refer to the IANA registries not the COSE
> document - what if there is a new signature algorithm, like say RSA.

==>MT
Done.
<==

>
> * Section 6 - is it an error for a monitor to provide a public key?  After
> all an invalid signature would not need to be checked.   To make life even
> more fun, does the rsnonce need to be provided on a token post?

==>MT

We have added text under the first bullet point, to explain that it is
not an error, and the Group Manager just silently ignores ‘cnonce’,
‘client_cred’ and ‘client_cred_verify’, in case the joining node has
“monitor” as single authorized role.


As to the second question, we have also added some text in Section 5.1.
That is, when responding to a Token POST, the Group Manager does not
need to return 'kdcchallenge' (was rsnonce) to the client, if ‘scope’ in
the posted Access Token indicates only the role “monitor” or only the
role “verifier”, for each of the specified groups. The final choice to
take advantage of this optimization is left to the implementor.

<==

>
> * Section 8 - For bullet 2.a - Is there a reason why this does not do the
> rekey and return the new key material rather than returning an error?

==>MT
Ok, we have rephrased the text as: “The Group Manager rekeys the OSCORE
group. That is, the Group Manager generates new group keying material
(see Section 16) and replies to the group member with the same group
rekeying message defined in Section 16, providing the new group keying
material. Then, the Group Manager rekeys the rest of the OSCORE group,
as discussed in Section 16.”
<==

>
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> 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: [phone]
https://www.ri.se