Hello Francesca, Marco,I have finally managed to read the whole of draft-ietf-ace-key-groupcomm and have a few comments for you:
Figure 2: I suggest you move the "Defined in ..." to the leftthey way it is now, it looks as if the Dispatcher was defined in the ACE framework.
== "3.1. MUST contain ... 'grant_type'"This is no longer true. Grant_type was made optional in one of the latest updates of the ACE framework. When it is absent, grant_type=client_credentials is assumed as default.
== 3.3 "... and includes the following parameters: "How is that supposed to work? The framework defines sending of the token to /authz-info as a CoAP POST, where the payload is the bytes of the token. In order to include additional parameters you would have to redefine this payload to be a CBOR map (as the OSCORE profile does).
==The whole section 3 talks about parameters send back and forth between the client and the KDC without defining how these are carried. It seems to be implied that there are CBOR maps in the payload, but that should be made explicit, especially where it differs from what the framework defines.
==3.1 the text about the parameters in the client's post to the /authz-info endpoint at the KDC talks about parameters "sign_info" and "pub_key_enc" and claims they are specified in 3.3.1 and 3.3.2, but these sections specify the parameters for the "AS request creation hints" messages and not in this context. At least some clarification should be added.
== Section 4 "If not previously established, the Client and the KDC MUST first establish a pairwise secure communication channel using ACE."This sentence is not strictly correct. Using what part of ACE? The ACE framework just says that you should establish a secure communication channel, it's the specific profiles that define how these channels are established. Please add some clarification.
=="The Client and the KDC MAY use that same secure channel to protect further pairwise communications, that MUST be secured."
This is very questionable use of requirements language. How do I claim or test conformance with the second MUST?
== Section 4: "The same set of message ..." should be "messages" == " Note that proof-of-possession to bind the access token to the Client is performed by using the proof-of-possession key bound to the access token for establishing secure communication between the Client and the KDC." This may or may not be true for a specific secure communication protocol(e.g. think of DTLS with X.509 certificates without client authentication). You need to require this from the underlying secure communication protocol.
==4.1 "The endpoint in the KDC is associated to the 'scope' value of the Authorization Request/Response."
Associated how? This is too unspecific to lead to interoperable implementations. I would like to see this association specified in detail.
==4.2 "as defined in the "ACE Groupcomm Key" registry, defined in Section 11.5."
If possible, rephrase this to avoid the double use of "defined". == 5.2"If the leaving node wants to be part of a group with fewer roles, it does not need to communicate that to the KDC, and can simply stop acting according to such roles."
There are legitimate cases where a node might want to explicitly deactivate roles it is currently using (principle of least priviledge) and not just stop using them.
== 6. "Then, if it wants to continue participating in the group communication, the node has to request new updated keying material to the KDC." should be "... keying material from the KDC." == Sections 8. and 9.Would be nice if there also were back-references to where those parameters are
defined in the draft. /Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
