[Ace] ace-key-groupcomm-03

[Peter van der Stok <[e-mail]>]

Hi authors, 

Many thanks for this document 

Below my review of the latest version of this document, based on my
implementation experience. 

General point: I find it difficult to understand which secure
communication channel is discussed at some points in the document. My
suggestion is to name the two secure channels in section 1.1. 

For example: 

Management channel: channel secured with OSCORE or DTLS between client
and KDC, according to specified transport profile. 

Group channel: channel secured with OSCORE between group members,
according to specified transport profile. 

Mode detailed text suggestions follow below: 

Page 3 par 2: s/is in Appendix/is shown in Appendix/ 

Figure 1: 

According to text both Dispatcher and KDC can be RS, but only Dispatcher
has (RS) added in the figure 1. 

Page 4, bullet 2: s/join the group/join a given group/ 

Page 4, bullet 3: s/join the group/join a given group/ 

Page 4, bullet 3: remove last phrase "If required…. Changes.". It does
not add anything, does it? 

Page 4, bullet 4: what is an "implicit entity"? The phrase provokes more
questions than it clarifies. 

Page 5, bullet 1: remove: "to communicate with group members" (section
4) is sufficient explanation.) 

Page 5, bullet 2: Shorten to: "Leaving of a node or removal of a node by
the KDC (section 5)" 

Page 5, bullet 3: Do you mean? " retrieval of keying material by a group
member" 

Page 5, line 4 from below: s/between client and KDC/between client and
AS/ 

Page 5, end: suggestion is 

s/The exchange  …and KDC/The joining Request and Joining Response and
all further messages between client and KDC are exchanged over the
Management channel/ 

page 6, top: Remove : "All further … exchange." 

Page 6: s/All communications  … section 4/The group members communicate
via the group channel using keying material of section 4/ 

Section 3, par 2, s/join the group through the KDC/join a given group/ 

Section 3, par 3; reduce to: 

The first two messages exchanged over the management channel use
content-format application/ace+cbor and the third message uses content
format application/cwt. 

Section 3.1, par1: /is as defined/is defined/ 

Section 3, page 7: The appearance of (REQx) is very surprising; Would be
good to announce the function of "(REQx)" at the start of section 3 or
end of section 2. 

Page 6, bullet 4: Not clear what you mean here. Are they optional,
superfluous, or a MUST? 

Section 3.2, par 1: s/is as defined/is defined/ 

Page 8 The phrase "The access token MUST…. ACE requires" is difficult to
parse. 

In my understanding, the request contains a scope parameter, the token
contains a scope parameter and the response contains a scope parameter. 
Which scope must be a subset of the other? That is not clear. And how
can they be a subset; we're talking array. 

Last par of section 3.2: I understand that the AS always replies with a
new access token. 

Section 3.3: May be it is good to write that the POST exchange is not
secured. 

Page 9: N_S is the value of the {"rsnonce" :value} pair? 

Page 10: The phrase: "It is required of the application profiles….". Is
not clear. Does it mean that all application profiles must be changed to
include this parameter? And what if this has not happened? 

Page 11, section 4: It is good to specify that all exchange between
joining node and KDC passes over the management channel. 

Page 12, line 2: Add:  securely communicate "over the group channel"….. 

Page 12: s/assiciated/associated/ 

Sec 4.1: please, make clear from the very start that the path names of
the resources are example names. 

Page 13, section 4.1.2.1: Scope does not specify the resource path, but
the value of gid 

Page 14: N_C is the value of the ("cnonce":value} pair? 

Page 14: I don't understand the paragraph: "The handler verifies … error
message." How can the gid be a subset of the "scope"? This occurs at
several other occasions in the text. 

Page 15: should num be monotonically increasing with each new version? 

Page 16, bullet 1: what are the member identifiers? 

Page 20, section 4.1.6: It is not clear to me how node is defined. 

Page 21, section 4.2: Instead of pairwise secure communication channel
use the term Management channel. 

Page 22, paragraph 3: group identifier cannot be equal to the value of
the scope; At most it can be equal to the first array element of the
scope value. 

Page 22, section 4.3, paragraph 2: "that the client was not able to
receive". The process in which clients receive new keying material
without asking for it is not clear to me. Suggest to remove the phrase. 

Page 23, Text after figure 7: 

The rekeying process is not clear to me. Is it possible to discuss at
least one approach, where the ContextId changes with the Master secret
and the salt, every time the group changes composition or the keying
material is refreshed. Receiving an unknown contextId means that
rekeying took place and new material needs to be fetched. However, is
there enough information to know which KDC handles the rekeyed group?
The ContextId is unknown, and the receiverId may refer to multiple
contexts, while it is not guaranteed that each group has its own
resource on the member platform. Greetings,

Peter 
-- 
Peter van der Stok
vanderstok consultancy
mailto: [e-mail], [e-mail]
www: www.vanderstok.org [1]
tel NL: [phone]     F: [phone] 

Links:
------
[1] http://www.vanderstok.org