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

From: Jim Schaad <[email-masked]>
Date: Thu, 30 Jan 2020 15:16:17 -0800

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.

Section 2.2 - must new security parameters be regenerated on each membership
change?

Section 2.2. - Does completion of a group rekeying include confirmed
redistribution before the version number is incremented?

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?

Section 4.3 - Does it make sense to return a new rsnoce as part of these
errors?

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 31 Jan 2020 11:23:49 +0000

Hi Jim,

Thanks for these comments!

Please, find some replies below.

Best,
/Marco

> 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

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

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

> public keys, when are these ok and how is this communicated to the client as

<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

<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: +46 (0)70 60 46 501
https://www.ri.se

---

From: Jim Schaad <[email-masked]>
Date: Fri, 31 Jan 2020 07:46:03 -0800

-----Original Message-----
From: Marco Tiloca <[email-masked]> 
Sent: Friday, January 31, 2020 3:24 AM
To: Jim Schaad <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: draft-ietf-ace-key-groupcomm-oscore

Hi Jim,

Best,
/Marco

On 2020-01-31 00:16, Jim Schaad wrote:
> 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.

>
> Section 2.2 - must new security parameters be regenerated on each 
> membership change?

<MT>

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

> 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

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

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]

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

Jim

--
Marco Tiloca
Ph.D., Senior Researcher

---

From: Marco Tiloca <[email-masked]>
Date: Fri, 31 Jan 2020 18:32:00 +0000

Hi Jim,

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

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

> [JLS] This is how I read the text - please do some clarification

<MT>
Yes, will do.
</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

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: Jim Schaad <[email-masked]>
Date: Fri, 31 Jan 2020 11:06:44 -0800

-----Original Message-----
From: Marco Tiloca <[email-masked]> 
Sent: Friday, January 31, 2020 10:32 AM
To: Jim Schaad <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: draft-ietf-ace-key-groupcomm-oscore

Hi Jim,

On 2020-01-31 16:46, Jim Schaad wrote:
> To: Jim Schaad <[email-masked]>; 
> [email-masked]
> Cc: [email-masked]
>> 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>

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

[JLS]  I just realized we are not talking about the same problem.  I was thinking about propagating the difference between a publisher (client) and a responder (server) from the key server to the users of the keys.  This would mean that a server would be able to say - but this message is not authorized to ask me a question, so don't reply (or fail).

> 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>
[JLS] Perhaps we need to have some type of term for the difference between those items which are "static" over time and those items which are "dynamic" over time.  This might also be a difference in what is returned on the issue you raised today in the virtual.

Jim

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

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

<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

--
Marco Tiloca
Ph.D., Senior Researcher