Re: [Ace] draft-ietf-ace-key-groupcomm-oscore

[Francesca Palombini <[e-mail]>]

Hi Jim,
We have now added your review comments to the github issues, and we’ll get to it. Below, the couple of comments that needed additional clarification (and consequent APs).
Thank you again for the thorough review!
Francesca and Marco
2.  Section 3.1 - "requester" seems to be an odd name for "sender" or
"publisher"
[*] This particular document does not consider the concept of publisher. Requester was chosen to identify a client in a group communication setting, i.e. stressing that it sends (group) requests and receives (unicast) responses. Sender would not be correct, as both clients and servers are senders at some point during the message exchange.
[JLS] I will probably complain again at a later date.  My problem is that requester is not the opposite of listener.  A different set might be “requester”, “responder”, “monitor”
[FP] Ok, thanks for the proposal. We will switch to these terms. (AP8)

3. Section 3.1 - I am trying to figure out why a Gid would be a reasonable
value for the scope.  This means that the AS is going to be the one to
assign the Gid value in many cases as it needs to check the scope value
there.  Is that going to be a common case?  I.e. Are Gids going to be
assigned by administrators?
[*] The Gid of the Authorization Request would be a reasonable scope because the join resource is associated to it (at the GM). The GM receiving a Join Request must be able to retrieve the correct Gid following the access to the join resource. No, the AS does not assign the Gid value (if that is used as scope in the Authorization Request). The AS only needs to check that the client is authorized to get an access token for that scope, regardless that it is a join resource. The Gid is assigned by the resource owner of the join resource at the GM, that is an administrator.
[JLS] Ok – so the answer to my question is yes.  I wanted to be sure it was not a registration process on the KDC (I think).
[FP] Right, it is not a registration process.

4. Section 3.1 - Is the form in Appendix C of the Gid in some respect
mandatory?  If it is not, then how does a receiver of a message distinguish
between two different groups that are using the same multicast address?  Is
that going to be a non-supported case?  The most common case of this would
be having two different groups on the default CoAP multicast address talking
to RDs with different permissions at the RD to see things.
[*] As of now, that is just an example, we might reconsider and make this at least mandatory to implement, so it would be good with more feedback on this. The requirements anyway are that in a GM all the Gids are unique, and that a Gid is changed after a group rekeying. The format in appendix C guarantees both. If your second question refers to one node in 2 groups (managed by 2 different GMs), where these 2 Gids collide, then that is up to the application to decide how to deal with it (discard, try both contexts…). We briefly discuss sec cons about it in section 8.5 of core-oscore-groupcomm. However, that is independent from the format of the Gid, as long as the requirements are met.
[JLS] My question dealt with having two different KDCs each of which has a Gid and that Gid collides for some reason.  The groups of the two KDCs are distinct and the resources accessible by those different KDCs are distinct and are quite possibly two different applications.
[FP] Ok, that’s what we thought. So we will add sec cons that this is up to the application to decide (AP9)



7.  Section 4.2 - for 'client_cred', I am unsure what the client is supposed
to do if the joining node does not know the countersignature algorithm.  Can
the include public key not be in a consistent format?  What does consistent
format even mean?
[*] Consistent format refers to the key type based on the countersignature algorithm used. If the joining node does not know the countersignature algorithm, it might just omit this parameter, or send a public key as a guess. If the guess is incorrect, the GM will reply as specified in 4.3 (see point 8).
[JLS] I don’t know what point 8 is – There are 6 points for the outer list and the inner point 8 defines a field and does not define a response.
[FP] I meant point 8. of your review comments: the one just below this one.

8. Section 4.3 - I don't understand why the GM is accepting the join request
if the client_cred passed in was not in the correct format.  Is this a typo?
[*] The reason for responding with a non-error response code is to be able to use the payload to provide the key info in a CBOR map. With a 4.XX response, that would not be possible since the payload is supposed to be a diagnostic human readable text string. We are willing to change that if the WG/CoAP experts can confirm that would be ok.
[JLS] So I return a 2.01 in both cases, and based on the content the client needs to determine what is happening?   We are breaking the 4.xx response already in the OAuth framework by returning an error response.  I would think that it would make more sense to continue that trend.
[FP] Ok, we will change this to error code. We will bring this up in CoRE as well. (AP10)

10.  Section 6 - What is the POP method for the fourth bullet method?
[*] We address this as well in point 9 of your review comments, to which we say: “Until now, we kept that out of the scope of this and dependent documents (see section 8 of ace-key-groupcomm-oscore), but we are looking to include it.
One possibility we are considering is to sign the key distribution request together with a nonce that was sent from the KDC (for the sake of freshness),  using the private key paired to the public key sent in ‘client_cred’.“
You seemed ok with this, so we will implement it here. (AP5)
[JLS] This is a problem that is going to need to be solved at some point for the OAuth framework as well at some point in the future.  But may be more of a problem here.  You might want to talk to Ludwig about the solution space.
[FP] We will do that.

12.  Section 7 - This text implies to me that all users of a group key need
to be able to act as servers and have a fixed port number which was supplied
some how to the GM so that it can be notified.   This could be done by
keeping up the DTLS session, but that is still a little bit tricky and would
not work for OSCORE based messages.  This text might want to point to the
section in the ietf-ace-key-groupcomm that deals with this and require that
the query or subscribe methods be supported.  Although both of those suffer
from the lack of hard break on the part of publishers.
[*] Yes, that is correct, group members would need to act as servers. The port number could be either default or part of the Join Request (in a new field “rekeying uri”?), with the group member assuming that the rekeying is done with this (unicast) default algorithm. The GM could then either confirm, or communicate to the joining node a different group rekeying scheme (in “group_policies”) and port and resource (in the new field “rekeying uri”) in the Join Response. However, that is quite heavy on the group member, which is a reason to use RD instead to discover in advance the rekeying scheme and rekeying uri as linked target attributes of the join resource. Would that work? Also why do you say that it would not work for OSCORE based messages? We could easily specify that when using the OSCORE profile between group member and GM, the nodes need to have both roles, so configure their keying material accordingly (for example: the group member’s recipient context need to contain a replay window). (AP7)
[JLS] I think that this may need to have a design session to figure out all of the ramifications and problems.
[FP] Ok, we will start drafting this on a separate branch to have a starting point. We could have this design session in Montreal or during an interim.
Jim