[Ace] Review of draft-ietf-ace-key-groupcomm-oscore

[Ludwig Seitz <[e-mail]>]

Hello Marco, Jiye, Francesca,

I have read draft-ietf-ace-key-groupcomm-02 and I have a few comments 
for you:

==
  1.1
"The URI of a join resource is fixed."

How can that be a requirement? The Group Manager might also be a mobile 
unit that changes address as it moves through different networks.
Perhaps rephrase to "The URI-Path of a join resource is fixed"?

==
1.1
"Monitor: ... This corresponds to the term "silent server" used in 
[I-D.ietf-core-oscore-groupcomm]."

Any special reason for defining an separate equivalent term? Otherwise 
this only makes the set of documents harder to read.

==
2.
"To this end, the AS must signal the specific transport profile to use, 
consistently with requirements and assumptions defined in the ACE 
framework [I-D.ietf-ace-oauth-authz]."

Note that in the ACE framework the AS does not have the obligation to 
signal the profile, since the assumed base-case is that the profiles are 
pre-configured and well-known in most constrained applications (this is 
an update from previous versions of the ACE framework).

==
All document: Update references to OSCORE to point to RFC 8613

==
2.
"2. The joining node transfers authentication and authorization 
information to the Group Manager by posting the obtained Access 
Token (see Section 4)."

Although it is explained in section 4 you might want to mention already 
here _where_ the information is POSTed (or replace "posting" with "sending")

==
2.
"5.  The joining node and the Group Manager maintain the secure 
channel, to support possible future communications."

Maintaining such a channel is costly in terms of memory, is that really 
a requirement?

Also in the case of object security, speaking of a 'channel' is misleading.

==
3.2
"Also, the 'profile' parameter ..."

See previous comment on profile being optional in the ACE framework

==

4.
"the Access Token post"

I don't think this term is well-understood in general. I'd suggest 
removing it with something less REST-centric for the uninitiated reader, 
like e.g. "the sending of the Access Token to ..."

==
4.1
" Note that the CBOR map specified as payload of the 2.01 (Created)
    response may include further parameters,"

Note that the ACE framework does not specify this response payload to be 
a CBOR map. Please explicitly state here that you are deviating from the 
default payload format in the ACE framework.

==
4.2
"In case the joining node knows the encoding of public keys in the 
OSCORE group, as well as the countersignature algorithm and possible 
associated parameters used in the OSCORE group, the included public key 
MUST be in a consistent format. "

What is a "consistent format"? Please rephrase to be more specific.
Or did you mean "compatible format"?

==
4.3
"That is, the public key has to be encoded as  expected in the OSCORE 
group, and has to be consistent with the counter signature algorithm and 
possible associated parameters used in the OSCORE group."

What is "consistent with the ... algorithms and ... parameters"?
Did you mean "compatible"?

==
4.3
"The 'profile' parameter MUST be present and has value 
coap_group_oscore_app (TBD), which is defined in Section 9.3 of this 
specification."

See comments on 'profile' before.

==
6.
"In this case, the joining node MAY not provide again its own public key 
to the Group Manager,"

This could be misunderstood to mean "MAY NOT ...", how about rephrasing 
this to: "MAY choose not to provide ..." ?

==
7.
"When doing so, the Group Manager MAY take a best effort to preserve the 
same unchanged Sender IDs for all group members"

This is incorrect use of requirements language. This 'MAY' can not be 
tested and the arguments for claiming conformance to this requirement 
would be quite diffuse. I suggest to require maintaining the Sender IDs. 
Why should the GM change them in the first place?


Regards,

Ludwig


-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone [phone]