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

[Marco Tiloca <[e-mail]>]

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>

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

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

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

>

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