Hi Marco,
Please find responses inline.
On 2021-08-31, 18:10, "Marco Tiloca" <marco.tiloca=40ri...@dmarc.ietf.org>
wrote:
On 2021-08-24 18:52, Göran Selander wrote:
> Hi,
>
> Here is a review of ace-key-groupcomm-13.
>
>
> General
> ===
> 1. How does this scale to large groups?
>
> Depending on application it may not be necessary to update keys during
join of new members, and depending on the dynamics of the members rekeying may
not be a major issue. But if it is a large group and all group members need to
be updated at joining or leaving then this may require a lot of communication
for which the underlying group communication may be helpful.
>
> For example, in case of a new member joining then a new group key or the
new node's public key may be distributed using broadcast/multicast and
protected with some existing group key.
==>MT
Definitely the new group key material to use before completing the
joining of the new member.
As to the public key of the new group member (if there is one at all,
depending on the member's roles), it's actually good to admit its
provisioning _together_ with the group key material. It would spare
other group members to perform dedicated retrieval traffic with the KDC
just for that later on. This can be added to the last paragraph of
Section 4.3.
[GS: OK.]
As to using "some existing group key", yes, this requires a separate set
of administrative key material, possibly organized into a hierarchy
whose root is the administrative group key (see also later comments).
That's the key material used to protect rekeying messages at the
application layer, and in principle unrelated to the secure
communication protocol used in the group.
[GS: Sure, I could have been more accurate and written "a key derived from some
existing shared key". This can be done in different ways but since this draft
is about rekeying for group communication in resource constrained settings,
shouldn't the use of the existing secure group communication be defined here or
in an application profile?]
>
> In case of rekeying a group key after a node has been evicted, a similar
method could be used if it was possible to apply some key hierarchy scheme like
e.g. LKH, i.e. distributing new keys corresponding to a path from the evicted
node to the root in a key hierarchy.
==>MT
Yes. This is explicitly mentioned in Section 4.4, in the second bullet
point after Figure 15.
As above, this requires a separate set of administrative key material,
possibly organized into a hierarchy whose root is the administrative
group key (see also later comments). Also as above, that's the key
material used to protect rekeying messages at the application layer, and
in principle unrelated to the secure communication protocol used in the
group.
<==
[GS: Thanks, I missed that. It seems inevitable for good scalability that at
least the application profiles define this. More below.]
>
> Two sub-questions:
>
> a. Is it possible to extend the interface to make use of the underlying
group communication?
==>MT
It should already be able to accommodate it. In particular:
* In Section 4.4, the second bullet point after Figure 15 already
mentions this possibility. An application profile or a separate
specification that builds on and extends it would have to define the
exact rekeying scheme to use and its message formats.
* At the end of Section 4.1.2.1, it is defined that the Joining Response
can include an optional parameter 'mgt_key_material'. In case of
rekeying schemes more advanced than a basic point-to-point approach
using pairwise security associations, this parameter provides a group
member with the administrative key material _it_ needs to have to
participate in a group rekeying.
For example, if a hierarchy-based scheme is used, the parameter
specifies the administrative keys in the key tree from the leaf node
associated to the group member all the way up along the path from that
leaf node to the root (which is the administrative group key shared by
all the group members).
* In Section 4.4, the third bullet point after Figure 15 refers to a
local "control" resource at a group member, where the KDC can send
requests such as rekeying messages. The group member can provide the KDC
with the URI of such a local resource when joining the group, in the
'control_uri' parameter of the Joining Request.
This is more generally intended as a resource where the KDC can
reach the group member with a request, and is potentially usable for
several administrative operations, including a group rekeying. In the
previous, second bullet point, it can be explicitly mentioned that this
resource can also be the target of a group rekeying request sent over
multicast.
Note that 'control_uri' may indicate an administrative "root path",
that the group member determines as relevant for that security group. I
would imagine requests for different administrative tasks to target
different sub-resources identified by well-known path segments under
that path.
[GS: Right, so there are components defined which can be used for this purpose.]
There are still two missing things, though.
* A group member would need to know the multicast address where the KDC
sends group rekeying messages. This might also be provided as an
additional parameter in the Joining Response.
Several versions ago, we proposed to include this in draft, but the
idea was dismissed to keep things simple. Should we revisit this and add
an optional parameter of this kind in the Joining Response?
[GS: If needed for simple configuration, then I'd say "yes", see below.]
Note that this goes hand-in-hand with _requiring_ a joining node to
provide also the URI of a local control resource, in the 'control_uri'
parameter of the Joining Request. Hence, it becomes (even more)
important for the joining node to know as much as possible about how the
group works (e.g. by means of early discovery), before attempting to
join it by sending the Joining Request.
* When joining the group, a node also needs to know the exactly used
group rekeying scheme. The easiest way I see to signal it is defining
one more integer-valued ACE Groupcomm Policy (see Figure 9 in Section
4.1.2.1) to be specified in the optional 'group_policies' parameter of
the Joining Response.
Its value would indicate the exact rekeying scheme (and we would
need a new IANA registry). If the KDC does not say anything about that,
the joining node assumes that a group rekeying is performed
point-to-point, thus relying on the pairwise communication channel it
has with the KDC.
<==
[GS: Thanks for elaborate response. Maybe what I'm missing is a simple example
of how to apply the different components of this draft for using a key
hierarchy scheme (again, could go into a profile). On the latter topic of what
information needs to be provided before joining, some configuration data can be
assumed to be pre-configured. To re-iterate: I'm not looking for a "complete"
scheme which takes into account all information flows in all possible key
distribution schemes, but making sure that there is a simple deployment which
scales to very large groups.]
>
> b. Is it possible to apply this interface with a key hierarchy scheme?
==>MT
Yes, it is totally up to the application profile and what it defines.
The answer above should already give more practical details on what we
have and what seems to be still missing.
<==
>
> These features are not necessarily in scope of this draft, but it would
be good to understand if a specification of these features would be able to use
the interface defined here, or if some generalization is required in which case
that change may be considered already now.
==>MT
Agree. The draft key-groupcomm-oscore is defining in detail a simple,
point-to-point approach. Based on a comment above, it can be extended so
that, in case of rekeying upon joining of a new member, the rekeying
messages include also the public key and Sender ID of the new node (if
this is not a Monitor).
More generally, a multicast-based approach (e.g. relying on key
hierarchy) should be totally possible to separately define and use, once
some general aspects mentioned in the comments above are finalized here
in key-groupcomm to be inheritable in an application profile.
<==
[GS: OK! Any thoughts on where to put such an example?]
>
>
> 2. How would a "minimal" profile look like?
>
> The target setting for ACE in general and this draft in particular is
constrained devices and networks. Some parts of the draft give example of
thinking about lightweight aspects, but other parts are not at all minimalistic
and includes a large number of features, however in many cases optional.
>
> It would be interesting to have a “minimal” example, where care has been
taken in trying to define a group setting such that the resulting messages are
as few and as small as possible (for a certain security level). The same
comment applies to code size and state machine: There are a number of options
and “nice to have” features, which if all implemented could have a measurable
impact on the footprint.
>
> The use of the word "minimal" is not intended in an absolute sense but to
target as little as possible and still provide authorized group key
functionality. Perhaps such an exercise makes more sense in an application
profile, such as draft-ace-key-groupcomm-oscore. But this draft may be provide
a partial answer by indicating what handlers to include (sec. 4), what
groupcomm parameters (sec. 7), what error ids (sec 8), etc.
==>MT
I try to reply separately on each of the affected aspects mentioned above.
* The handlers as such (Section 4) run at the KDC, which is not intended
to be constrained. So, we defined the KDC as expected to offer the full
interface specified in Section 4.1. I can imagine an application profile
that really does not need a particular subset of handlers to declare
them as not to be implemented, possibly under certain conditions.
Thinking of a group member, I can imagine as important to have minimally
implemented the logic for:
FETCH on ace-group/
- To retrieve the group name and joining URI from the specified group
identifier.
POST/GET on ace-group/GROUPNAME/
- To join the group (POST) and retrieve the current group key material
as group member (GET).
GET/FETCH on ace-group/GROUPNAME/pub-key
- To retrieve the public keys of all the other group members (GET) or
only of some by filtering (FETCH). Admittedly, the latter might be
sacrificed, but it allows to reduce the number of transferred public
keys a lot.
GET on ace-group/GROUPNAME/num
- To retrieve only the current version of the group key material.
DELETE on ace-group/GROUPNAME/nodes/NODENAME
- To leave the group.
Instead, the following logic might be omitted in the implementation of a
minimal group member:
GET on ace-group/GROUPNAME/active
- To check the status of the group
GET on ace-group/GROUPNAME/policies
- To retrieve the group policies. Thus, they would be obtainable only
when joining the group with a POST on ace-group/GROUPNAME/ (see above).
GET/PUT on ace-group/GROUPNAME/nodes/NODENAME
- GET is for obtaining the current group key material plus the
"individual node key material" (e.g., the Sender ID in the Group OSCORE
case). The former can be obtained with a GET on ace-group/GROUPNAME/
(see above). The latter would not be possible to re-obtain as group
member, thus expecting the group member to just remember that
information, whose possible change happens in a synchronized way with
the KDC anyway (see right below).
- PUT is requesting new "individual node key material" (which can result
in the KDC providing new one, or rekeying the group, or both things
together). This can also be sacrificed, so that a group member needing a
new individual node key material would re-join the group with a POST on
ace-group/GROUPNAME/ (see above).
POST on ace-group/GROUPNAME/nodes/NODENAME/pub-key
- To upload a new public key of its own. This can be sacrificed,
assuming that a group member does not change its public key during its
membership.
[GS: This type of discussion makes sense to me and I think it should be
somewhere in the draft. The specification of exactly what of these to support
is not part of this draft, but could go into an application profile, or some
"compliance" document used for a particular deployment.]
* About the Error IDs (Section 8), error responses will be sent anyway
in case of errors at the KDC.
The group members can of course not understand those error IDs.
Also, based on the third from last paragraph in Section 4.0, the
accompanying textual 'error_description' is already optional.
Maybe it can help to:
- Remove the parameter 'error_description' altogether; or, even more
aggressively,
- Make it just optional for the KDC to use these extended error
responses with content format application/ace-groupcomm+cbor and payload
the CBOR map with 'error' and 'error_description'.
Thoughts?
[GS: I think the focus should be on what actions follow from the error message,
either autonomous or by humans. Detailed error codes can make sense for these
settings when there are different autonomous actions that can follow from the
errors. In case the errors anyway needs to be resolved by a human, a human
readable diagnostic message could be an alternative. Having said this, it is
not clear to me what can be predicted about deployment of a particular profile
of this draft. One question to ask is if the error semantics should be left
more to the profiles or does the current error codes have value for intended
profiles?]
* About the ACE Groupcomm Parameters summarized in Section 7), most of
them are required or practically required. Some of them can be
conditionally not supported, e.g. by particular group members. Trying to
have a first classification below:
Must be supported:
- 'scope', 'gkty', 'key', 'num' and 'exp', as related to the group in
question and the retrieval of its key material.
- 'gid', 'gname' and 'guri', as required for FETCH to /ace-group .
- 'pub_keys' and 'peer_identifiers', since public keys are sooner or
later going to be retrieved, accompanied by the node identifiers of the
corresponding nodes.
Practically must be supported:
- 'get_pub'keys' is practically necessary, except for the inconvenient
and undesirable behavior where: i) a group member does not ask for the
other group members' public keys upon joining; and ii) later on, the
group member only retrieves the public keys of all group members with a
GET to ace-group/GROUPNAME/pub-key (i.e., never by using FETCH).
Conditionally not supported
- 'client_cred', 'cnonce' and 'client_cred_verify' are not needed to be
supported by a node if this does not have a public key of its own that
it uses in the group.
- 'kdcchallenge' is not needed to be supported by a node if this does
not have a public key of its own that it uses in the group, or if it
does not post the Token to /authz-info at the KDC. The PoP input share
N_S of the KDC has thus to be determined differently and it's up to the
profiles to define how (see REQ21).
- 'pub_keys_repos' is not needed to be supported by a node if this does
not have a public key of its own that it uses in the group, or if it
does not store the public key in a repo to point to with this parameter.
- 'group_policies' might be sent by the KDC anyway. It may not be
supported by a node if it is already aware of all group policies. These
may include a particular group rekeying scheme (see comment above). In
other words, it may not be supported by a node that never joins a group
without knowing its group policies in advance.
- 'peer_roles' goes hand-in-hand with 'pub_keys' and 'peer_identifiers'.
Generally, it should be fine that it is not needed to be supported by a
node if this does not have to care of the exact role of the node
associated to a retrieved public key.
- 'control_uri', is already optional to include in the Joining Request.
However, its support is preferable to enable even point-to-point group
rekeying initiated by the KDC. On the other other hand, it would rather
become necessary to support, if the group uses an advanced key
management scheme. In such a case, a node willing to join such a group
has to support this parameter, in order to indicate the URI of a local
resource to the KDC.
- 'mgt_key_material' would be sent by the KDC anyway, if the group uses
an advanced key management schemes. In such a case, a node willing to
join such a group has to support this parameter. In other words, it may
not be supported by a node that never joins a group which uses an
advanced group key management scheme.
May generally be not supported:
- 'error' and 'error_description', see comment above.
- 'ace_groupcomm_profile', as already defined optional in Section 4.1.2.1.
Would this kind of reasoned classification help?
[GS: Yes, I think some reasoning or classification would be instructive.]
<==
>
> (This comment actually applies also to the transport profiles, which this
draft does not need to take responsibility for.)
==>MT
Right, to be kept in mind for the profiles too, considering the
additional profile-specific parameter that they can add.
<==
>
>
>
> More detailed comments
> ===
>
>
> I found the terminology “POST /token” vs. “Token Post”/“token POST”/“POST
Token” for the different message exchanges, respectively, quite confusing. For
a long time I thought the latter referred to the former. It is true that the
access token is carried with the method POST in the second exchange, but I
think that is irrelevant and would suggest to instead use some other consistent
terminology. For example, use “POST /token” and “POST /authz-info” to refer to
the exchanges, respectively. Alternatively, call the latter “Token
provisioning” or something similar without reference to the actual method by
which the token is provisioned.
>
> This applies in particular to:
>
> Figure 2
> “Token Post”
>
> Figure 3
> “POST Token”
>
> “3.3. Token Post”
>
> 3.3.1.
> “an OPTIONAL parameter of the Token Post
> response message “
>
> 3.3.2
> “Token Post response”
>
> etc.
==>MT
Right, I can replace this occurrences of "Token Post" with "Token
Uploading".
[GS: Good. (Perhaps consider also other synonyms to "uploading" ...)]
The use of "POST /token" and "POST /authz-info" is limited to Figures 2
and 3, where it should be appropriate.
<==
>
>
> 4.1
>
> Section 4.1 specifies the handlers, 20 pages. This is followed by how the
handlers are used 4.2 - 4.10, roughly one page per subsection. When reading I
ended up having two copies of the draft side by side looking at the handler and
its corresponding use. I'm not sure this is a problem, but reading the handlers
is more motivating after having read about how they are used. There is a
summary in the bullet list in 4.0 but this is merely a forward reference and
didn't make me do the mapping from handler to action in my head. Maybe just
move content such that 4.2-4.10 comes before 4.1 (and then you can remove the
bullet list in 4.0).
==>MT
The issue is that each example in Sections 4.2-4.10 also refers to the
corresponding handler description, which defines also the payload format
for that operation. In particular, all the ACE Groupcomm parameters are
introduced in Section 4.1. An example shown before that risks to not say
that much.
I think that a middle ground can be the following, and it should also be
aligned with and address similar comments that Cigdem gave in her review
[1].
1) Merging the points from the bullet list of Section 4.0 into the
corresponding resource description of Section 4.1, while still
preserving the forward pointers. This can make it easier to map between
actions from a client point of view with resources at the KDC, even
though no details have been introduced yet.
2) Separately moving each current Section 4.2-4.10 right after the
corresponding handler section, now numbered 4.1.x.y. After that, a
better structuring can also be achieved, so that:
- Section 4.1 is renamed "Overview of the Interface at the KDC".
- The following sections lose one numbering level, e.g. current 4.1.1
"ace-group" becomes 4.2 "ace-group".
- Each Section 4.x can be about a KDC resource. This in turn includes
4.x.y with a handler description for resource x, followed by 4.x.y.z
with the example for handler y or resource x (taken from current
Sections 4.2-4.10).
That is:
4. Keying Material Provisioning and Group Membership Management
4.1 Overview of the Interface at the KDC
4.2 ace-group
4.2.1 FETCH handler
4.2.1.1 Example <Content from current Section 4.2>
4.3 ace-group/GROUPNAME
4.3.1 POST handler
4.3.1.1 Example <Content from current Section 4.3>
4.3.2 GET handler
4.3.1.1 Example <currently missing>
...
How does it sound?
[1] https://mailarchive.ietf.org/arch/msg/ace/gv_uRo2Y45jqOLJghVSbAARWky0/
<==
[GS: Sounds good!]
>
>
> "It is REQUIRED of the application profiles of this specification to
> define what operations (e.g., CoAP methods) are allowed on each
> resource"
>
> It speaks of operations on each resource, but it does not say which
resources are mandatory to implement. Where is that written?
==>MT
Building on a comment above, the KDC is supposed to implement all these
resources (and possibly add more if needed and defined by a specific
application profile).
As discussed above, a minimal group member may however not need to
implement the logic to use some of those resources.
This requirement was more intended to require application profiles to
produce something like Figure 2 of ace-key-groupcomm-oscore , see its
Section 5.5 "Admitted Methods".
<==
[GS: OK]
>
>
>
> 9.
>
> The security consideration speaks about different key update strategies.
I was looking for considerations when to not rekey in case of new member
joining a group. I would imagine in e.g. a building automation setting where a
new actuator device is added into a group it may not always be necessary to
renew the group key of existing actuators. This is in particular assuming by
the nature of security for actuations there are already means in place to
determine freshness etc. preventing misuse of an old group key.
==>MT
We can add something along these lines, especially on when it might be
acceptable to not ensure backward security (or anyway not rigorously
upon every single new joining). Ultimately, it is up to the specific
application to decide and define policies for the KDC to enforce.
Besides the freshness aspects you mention, this is more about accepting
that the newly joined node would have access to communications in the
group prior its joining, if it has recorded such exchanged messages.
<==
[GS: OK]
>
>
>
> 3.3. Token Post
>
> - - -
>
> “The CBOR map MAY additionally include the following
> parameter, which, if included, MUST have the corresponding values:
>
> * 'sign_info' defined in Section 3.3.1, encoding the CBOR simple
> value Null to require information about the signature algorithm,
> signature algorithm parameters, signature key parameters and on
> the exact encoding of public keys used in the group.”
>
>
> This seems to unnecessary duplicate information coming just after:
>
>
> “3.3.1. 'sign_info' Parameter
>
> The 'sign_info' parameter is an OPTIONAL parameter of the Token Post
> response message defined in Section 5.10.1. of
> [I-D.ietf-ace-oauth-authz]. This parameter contains information and
> parameters about the signature algorithm and the public keys to be
> used between the Client and the RS. Its exact content is application
> specific.
>
> - - -
>
> When used in the request, the 'sign_info' encodes the CBOR simple
> value Null, to require information and parameters on the signature
> algorithm and on the public keys used.
>
> The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as
> in the request is given below.
>
> sign_info_req = nil”
==>MT
Ok, we can remove the redundancy and also be more explicit, pointing to
the exact format 'sign_info_req' or 'sign_info_resp' used in the message
in question.
<==
>
>
> 3.3.1
>
> I got the impression from the text above that ‘sign_info’ is the name of
the parameter, but it turns out that the actual parameter is either called
“sign_info_req” or “sign_info_res”. So, when it is stated that ‘sign_info’
encoding the CBOR simple value Null, which seems like a straightforward
assignment, there is actually no ‘sign_info’ parameter. This is a minor, still
slightly confusing.
==>MT
Yes, there is only one actual parameter, 'sign_info', and we want a
single CBOR abbreviation registered for it to use in the payload map.
Using the different _req and _resp versions in Section 3.3.1 is just a
way to make a hard distinction between the request and response case. It
might help to improve the CDDL definition, i.e.:
sign_info = sign_info_req / sign_info_resp
sign_info_req = nil ; used in a request
sign_info_resp = [ + sign_info_entry ] ; used in a response
...
[GS: Yes, that reads better to me]
Göran
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
