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

[Jim Schaad <[e-mail]>]

 

 

From: Francesca Palombini <[e-mail]> 
Sent: Tuesday, May 28, 2019 2:29 AM
To: Jim Schaad <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: draft-ietf-ace-key-groupcomm-oscore 

 

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)

[JLS] Should be ok.

 

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”

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

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.

 

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)

[JLS] Sounds good.

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)

[JLS] Sounds good

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.

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.

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)

[JLS] Will need to read after update.

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.

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)  

[JLS] Sounds good.

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.

Jim