From: Francesca Palombini <francesca.palomb...@ericsson.com>
Sent: Tuesday, May 28, 2019 2:29 AM
To: Jim Schaad <i...@augustcellars.com>; ace@ietf.org
Cc: draft-ietf-ace-key-groupcomm-osc...@ietf.org
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
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
