Hi,
Here is a review of ace-key-groupcomm-13.
General
===
This draft provides a link between the ACE-OAuth authorization framework
(including its transport profiles) and specifications of communication security
in groups of constrained devices, e.g. the coap-groupcomm work currently
developed in CORE. The document is intended to support different group
communication schemes, but the details of those are defined in separate
“application profiles” such as draft-ietf-ace-key-groupcomm-oscore (for Group
OSCORE) and draft-ietf-ace-pubsub-profile (for pub/sub). This draft instead
defines a common interface to a KDC acting as RS in the ACE-OAuth architecture,
how to use this interface to perform various key management operations, and
requirements for such application profiles.
As such, this draft is thus an “intermediary” specification, and its usefulness
will be determined by the application profiles which I've glanced at but are
not part of this review.
While this approach seems reasonable from a structure point of view, I have a
question about abstracting the underlying communication in comment 1 below.
The content of the draft is quite elaborate and with detailed examples which is
good but also leads to my comment number 2.
Now for the main comments:
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.
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.
Two sub-questions:
a. Is it possible to extend the interface to make use of the underlying group
communication?
b. Is it possible to apply this interface with a key hierarchy scheme?
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.
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.
(This comment actually applies also to the transport profiles, which this draft
does not need to take responsibility for.)
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.
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).
"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?
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.
Nits
===
3.1
s/Toid/“Toid”
s/Tperm/“Tperm”
3.2
If this parameter is not present, the granted scope is equal to the one
requested in Section 3.1}.
- remove the “}”
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”
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.
3.3.1
"This format is consistent with every signature algorithm currently
considered in [I-D.ietf-cose-rfc8152bis-algs], "
s/considered/defined
3.3.2
"(see the 'client_cred_verify' parameter in
Section 4)"
Refer instead to 4.1.2.1
4.1.3.1
“in case both the 'role_filter' array and the 'id_filter'
array are not empty”
s/not empty/non-empty
4.1.3.1
"Finally, as mentioned in Section 4.1.2.1, both arrays 'role_filter'
and 'id_filter' MUST NOT be both empty."
replace with
"Finally, as mentioned in Section 4.1.2.1, the arrays 'role_filter'
and 'id_filter' MUST NOT both be empty."
4.4
A missing comma at the end of the following line:
"get_pub_keys": [true, ["sender"], []], "client_cred": PUB_KEY
Göran
On 2021-07-12, 18:16, "Ace on behalf of internet-dra...@ietf.org"
<ace-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Authentication and Authorization for
Constrained Environments WG of the IETF.
Title : Key Provisioning for Group Communication using ACE
Authors : Francesca Palombini
Marco Tiloca
Filename : draft-ietf-ace-key-groupcomm-13.txt
Pages : 78
Date : 2021-07-12
Abstract:
This document defines message formats and procedures for requesting
and distributing group keying material using the ACE framework, to
protect communications between group members.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://protect2.fireeye.com/v1/url?k=08daa3fb-57419b19-08dae360-86073b36ea28-572fafc3ef6c5ed5&q=1&e=fd87b927-3fdc-4d5a-ab71-6248ac68bf5d&u=https%3A%2F%2Fgithub.com%2Face-wg%2Face-key-groupcomm.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-13
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-13
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
