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

[Marco Tiloca <[e-mail]>]

Hi Jim,

On 2020-01-31 16:46, Jim Schaad wrote:
>
> -----Original Message-----
> From: Marco Tiloca <[e-mail]> 
> Sent: Friday, January 31, 2020 3:24 AM
> To: Jim Schaad <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: Re: draft-ietf-ace-key-groupcomm-oscore
>
> Hi Jim,
>
> Thanks for these comments!
>
> Please, find some replies below.
>
> Best,
> /Marco
>
> On 2020-01-31 00:16, Jim Schaad wrote:
>> This is not a finished review - but I wanted to get it out.
>>
>> Jim
>>
>>
>> General - Should the concept of a legal requester be part of the 
>> information that is transported with the public key?  I don't believe 
>> that this is currently done, but would additionally allow for a server 
>> to ignore comments from individuals who are not authorized for that role.
> <MT>
> This can be indicated in the public key, and then the Group Manager indicates this "role" to other group members, when providing them with the public key of the legal requester.
>
> However, how can the Group Manager verify that a legal requester is indeed one, as its public key claims? If we stick to raw public keys, this seems not possible as the only thing that the Group Manager really does is verifying possession of the corresponding private key upon joining.
>
> This would probably require certificates rather than public keys, as provided in the 'client_cred' parameter upon joining, which is something that ace-key-groupcomm is anyway admitting, while we are just not doing it here. Then, it becomes about trusting the certificate issuer on legitimately claiming that the certificate owner is indeed a legal requester.
> </MT>
> [JLS] I was assuming that the GM could pull this information from the 'scope' field of the token.

<MT>
Ok, so it should be just about adding one more role to the current valid
ones for 'scope', and updating the list of possible role combinations.

Then it's up to the policy evaluation at the AS to confirm that a client
is indeed a legal requester, and that that ends up in the token.
</MT>

>
>> Section 2.2 - must new security parameters be regenerated on each 
>> membership change?
> <MT>
> If the application really requires forward and backward security, yes.
> This is further discussed in the first security consideration of Section 14.
>
> Related, more general aspects about this are discussed in the security considerations of ace-key-groupcomm. In particular, the Group Manager may want to enforce a more relaxed policy than "on each membership change", though making some compromise on the continuity of backward and forward security.
> </MT>
> [JLS] My problem is that I consider the secret key different from the parameters - might be a semantic issue

<MT>
Other than that, the ID Context (Group ID) is also renewed; the Master
Salt may be renewed; the used Sender IDs have to remain the same.

Maybe we can have here some of the text on this from the first paragraph
of
https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-06#section-2.1
</MT>

>
>> Section 2.2. - Does completion of a group rekeying include confirmed 
>> redistribution before the version number is incremented?
> <MT>
> I would say no, but regardless it's something to clarify, possibly already in ace-key-groupcomm .
>
> Having the Group Manager generated and sent out the new keying material is sufficient to also increment the version number.
>
> It is good that the Group Manager can also get confirmation of distribution, mostly for possible individual re-provisioning, possibly up to a maximum number of retries.
>
> Worst case, some group members remain behind, will not be able to retrieve a context or decrypt correctly, and will eventually go to the Group Manager to understand the current status, including the latest version number, and get the latest group key material.
> </MT>
> [JLS] This is how I read the text - please do some clarification

<MT>
Yes, will do.
</MT>

>
>> Section 4.2.1 - I think that we are going to need a discussion on a 
>> couple of issues related to the OSCORE half of how these values are 
>> going to be created.  Pieces of the discussion are: 1. What is the POP 
>> her going to try and prove.  Specifically is timeliness part of the 
>> discussion.  2. What do we do about  token which grants access to 
>> multiple topics.  Is joining the second group considered to be a 
>> re-join rather than an original join for the purposes of this 
>> discussion?  3.  What are the interactions about cached public keys, 
>> when are these ok and how is this communicated to the client as a failure?
> <MT>
> Sure. Some comments on your points for the discussion:
>
> 1. Ultimately the POP is about the owned private key used to sign by the joining node. Building this part of the challenge this way ties the challenge itself with the OSCORE context the two peers have. This is the same construction we have in [1] for building a signature challenge, so probably both documents would likely be affected.
>
> 2. Tokens covering multiple groups/topics are a next thing to define in ace-key-groupcomm. Adapting this challenge-based POP will follow. As a general case, the client wants to use different public keys in different groups, which would mean providing one POP signature for each key. Then, the N_S challenge can be as follows:
>
> --- If the Access Token is posted to /authz-info , the RS returns an array of N_S, i.e. as many as the number X of groups/topics in the 'scope' of the token. Since the client may then upload Y < X public keys (some of which for more than one group), the client should include in the joining request Y signatures, together with the respective used Y N_C nonces and Y N_S nonces of the X provided by the Group Manager.
>
> --- If a TLS exporter is used, 'context_value' has to be non empty, e.g.
> it can include the public key or a hash of it. For simplicity, we may want to have 'context_value' always non empty, i.e. also when only one public key is involved and even in the simple case of one group/topic only.
>
> --- In the OSCORE case, HMAC-Hash may take as 'salt' one more concatenated element, e.g. the public key or a hash of it. For simplicity, we may want to have 'salt' always including this additional element, i.e. also when only one public key is involved and even in the simple case of one group/topic only.
>
> 3. Cached public keys and how to handle them are discussed later in Section 5. If something goes wrong, the joining process fails and the Group Manager sends error responses as described in Section 4.3.
>
>
> [1]
> https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-01#section-3.1
>
> </MT>
>
>> Section 4.3 - Does it make sense to return a new rsnoce as part of 
>> these errors?
>>
> <MT>
> That's certainly possible, though I am not sure of the advantage, compared to sticking to the first one returned in the response to the Token POST.
> </MT>
> [JLS] depends on the "nonce" quality - that is one time only use.

<MT>
We can make it optional for the server to return a new nonce in the
error response.

If received, the client has to use that latest nonce when building the
challenge to sign for the new joining request.
</MT>

Best,
/Marco

> Jim
>
>
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>
> RISE Research Institutes of Sweden
> Division ICT
> Isafjordsgatan 22 / Kistagången 16
> SE-164 40 Kista (Sweden)
>
> Phone: [phone]
> https://www.ri.se
>
>
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se