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

[Francesca Palombini <[e-mail]>]

Hi Jim,
Thanks again for your in depth review. We have identified 7 clear APs from some of your review comments, and we hope that we answer the other (inline). Please let us know if that is ok, and we will update the document as soon as possible.

Thanks,
Francesca and Marco

I was wandering through the document with a view to implementing and have
the following questions:

1.  Abstract: From the first paragraph I am not sure if the group
communications or the communications to the KDC are secured with OSCORE.

[*] Ok, we propose to change “where communications are based” to “where the group communication is based”. The communication to the KDC is up to the profile of ACE used between the joining node and the KDC. (AP1)

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.

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.

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.

5. Section 4.1 - I can understand things relative to the key_info blob that
is being returned.  I am not sure that I think that this is being defined
correctly however.  It makes more sense to me to have the following:
key_info = [ sign_alg: COSE_Algorithm, ?sign_parameters : map,
?key_parameters: map ] where the two maps are filled in from the required
fixed parameters from the two COSE registries.  This would end up with
something like the following as a potential value   [ sign_alg: ECDSA,
key_parameters: {'kty':'EC2', 'crv': 'P256'}]

[*] Ok, we can implement that. To make sure we understand your proposal, ‘key_parameters’ are taken from COSE Key Common Parameters and COSE Key Type Parameters registries?
What about ‘sign_parameters’? Can we be sure that those two field would cover all parameters of existing and future algorithms? If a new algorithm defines its own registry, we would need to add that, and say values from that registry can also be used in this map. (AP2)

6. Section 4.1.1 - why is the key info parameter format application
specific?  I would have assumed that it was the same as in the previous
section.

[*] Right, proposal to change “Its format” to “Its exact content”. (AP3)

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).

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.

9.  Section 6 - I don't know that the third bullet is in the list of cases
where the client_cred parameter is not required.

[*] Well spotted, and it needs to be clarified. Actually, the third bullet should say that if the PoP key in the access token has the format expected in the group and the client is aware of that, then the client can skip providing its own public key later on in ‘client_cred’. (AP4)

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)

11. Section 6 - What happens if any of first three bullets is true, but the
cached key does not match the required key parameters for the signing
algorithm.  In some of these cases there is no check that any signature
algorithm parameters that might exist are going to be checked and enforced.

[*] The first bullet point is actually about not providing a key, so no check needs to be done.
The second bullet point is about a previously provided key, so the check would be done as described.
Third bullet: yes we need to clarify. (AP6)

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)

Jim