Hi,
Please find some questions / comments regarding the
draft draft-ietf-ace-key-groupcomm-06. I suspect that most of the questions
are clarifications for me to better understand the context.
Yours,
Daniel
Key Provisioning for Group Communication using ACE
draft-ietf-ace-key-groupcomm-06
[...]
2. Overview
+------------+ +-----------+
| AS | | KDC |
| | .-------->| |
+------------+ / +-----------+
^ /
| /
v / +-----------+
+------------+ / +------------+ |+-----------+
| Client |<-' | Dispatcher | ||+-----------+
| |<-------->| (RS) |<------->|| Group |
+------------+ +------------+ +| members |
+-----------+
Figure 1: Key Distribution Participants
The following participants (see Figure 1) take part in the
authorization and key distribution.
* Client (C): node that wants to join the group communication. It
can request write and/or read rights.
* Authorization Server (AS): same as AS in the ACE Framework; it
enforces access policies, and knows if a node is allowed to join a
given group with write and/or read rights.
* Key Distribution Center (KDC): maintains the keying material to
protect group communications, and provides it to Clients
authorized to join a given group. During the first part of the
exchange (Section 3), it takes the role of the RS in the ACE
Framework. During the second part (Section 4), which is not based
on the ACE Framework, it distributes the keying material. In
Palombini & Tiloca Expires 12 November 2020 [Page 4]
Internet-Draft Key Provisioning for Group Communication May 2020
addition, it provides the latest keying material to group members
when requested or, if required by the application, when membership
changes.
<mglt>
The figure indicates the dispatcher as the RS. I
have the impression that in our case the KDC could
be seen as the RS that provides the necessary
material to access the dispatcher. From the text
it seems that no authorisation control is
performed at the dispatcher, access is granted by
the ownership of the (shared) keying material.
For that reason I am wondering why do we consider
the dispatcher as the RS instead of the KDC.
</mglt>
* Dispatcher: entity through which the Clients communicate with the
group and which distributes messages to the group members.
Examples of dispatchers are: the Broker node in a pub-sub setting;
a relayer node for group communication that delivers group
messages as multiple unicast messages to all group members; an
implicit entity as in a multicast communication setting, where
messages are transmitted to a multicast IP address and delivered
on the transport channel.
This document specifies a mechanism for:
* Authorizing a new node to join the group (Section 3), and
providing it with the group keying material to communicate with
the other group members (Section 4).
* A node to leave the group of for the KDC to remove a current
member of the group (Section 5).
* Retrieving keying material as a current group member (Section 4.3
and Section 4.4).
* Renewing and re-distributing the group keying material (rekeying)
upon a membership change in the group (Section 4.9 and Section 5).
Figure 2 provides a high level overview of the message flow for a
node joining a group communication setting, which can be expanded as
follows.
1. The joining node requests an Access Token from the AS, in order
to access a specific group-membership resource on the KDC and
hence join the associated group. The joining node will start or
continue using a secure communication association with the KDC,
according to the response from the AS.
<mglt>
"continue using a secure communication" is here I
think to indicate that establishment of a new
secure communication is not necessary. If that is
correct, we we could clarify that by adding the
communication to the AS is secured.
</mglt>
2. The joining node transfers authentication and authorization
information to the KDC, by posting the obtained Access Token to
the /authz-info endpoint at the KDC. After that, a joining node
MUST have a secure communication association established with the
KDC, before starting to join a group under that KDC. Possible
ways to provide a secure communication association are DTLS
[RFC6347] and OSCORE [RFC8613].
<mglt>
The relation between the KDC (application) and the
secure transport or communication is not entiorely
clear to me. A secure communication includes
authentication of the peers and encryption of the
traffic. I suppose that encryption is performed
by DTLS or OSCORE, but I am wondering if
authentication and authorization are performed by
the DTLS layer or by the KDC application. I have
the impression that KDC is entirely relying on
DTLS/OSCORE for encryption and
authentication/authorisation because the text
seems to assume that authz-info may be not
protected. I thus assume authorization is
characterized by the ability to set a DTLS/OSCORE
session. Of course other information will be
needed by the KDC (scope for exampel). If this
use case makes sense, it might be good to clarify
the interactions between dtls-authorized works, in
particular how these access tokens ( the merged
access token) are/is used. The other alternative
could be to set an unauthenticated DTLS/OSCORE and
then proceed to the communication of the access
token.
</mglt>
[ ...]
3. Authorization to Join a Group
This section describes in detail the format of messages exchanged by
the participants when a node requests access to a group. This
exchange is based on ACE [I-D.ietf-ace-oauth-authz].
As defined in [I-D.ietf-ace-oauth-authz], the Client requests from
the AS an authorization to join the group through the KDC (see
Section 3.1). If the request is approved and authorization is
granted, the AS provides the Client with a proof-of-possession access
token and parameters to securely communicate with the KDC (see
Section 3.2).
Communications between the Client and the AS MUST be secured, as
defined by the transport profile of ACE used. The Content-Format
used in the messages is the one specified by the used transport
profile of ACE (e.g. application/ace+cbor for the first two messages
and application/cwt for the third message, depending on the format of
the access token).
<mglt>
At that point, I assume that Client to AS
communication is secured via a standard DTLS
session. I am wondering if the POST can be
unsecured or is send over a secure channel.
</mglt>
The transport profile of ACE also defines a
number of details such as the communication and security protocols
used with the KDC (see Appendix C of [I-D.ietf-ace-oauth-authz]).
Figure 3 gives an overview of the exchange described above.
Client AS KDC
| | |
|---- Authorization Request: POST /token ------>| |
| | |
|<--- Authorization Response: 2.01 (Created) ---| |
| | |
|----- POST Token: POST /authz-info --------------->|
| |
Figure 3: Message Flow of Join Authorization
3.1. Authorization Request
The Authorization Request sent from the Client to the AS is as
defined in Section 5.6.1 of [I-D.ietf-ace-oauth-authz] and MAY
contain the following parameters, which, if included, MUST have the
corresponding values:
<mglt>
I believe that some parameters are mandatory. If
that is the case, it would be good to explain
which parameters are optional or mandatory.
</mglt>
* 'scope', containing the identifier of the specific group(s), or
topic(s) in the case of pub-sub, that the Client wishes to access,
and optionally the role(s) that the Client wishes to take.
Palombini & Tiloca Expires 12 November 2020 [Page 7]
Internet-Draft Key Provisioning for Group Communication May 2020
This value is a CBOR byte string, encoding a CBOR array of one or
more entries.
<mglt>
from the text above I understand that the value is
the output of a CBOR object, which somehow
requires the CBOR compression to be run twice. I
might be missing something, but it seems unclear
to me why this should be different from: This
value is an array of one or more entries.
This is my understanding from the text:
scope = [ entry, entry ]
entry = [group_id, ([ role, role, ] )]
</mglt>
An entry has as value a CBOR array, which contains:
- As first element, the identifier of the specific group or
topic.
- Optionally, as second element, the role (or CBOR array of
roles) that the Client wishes to take in the group. This
element is optional since roles may have been pre-assigned to
the Client, as associated to its verifiable identity
credentials. Alternatively, the application may have defined a
single, well-known role for the target resource(s) and
audience(s).
In each entry, the encoding of the group or topic identifier
(REQ1) and of the role identifiers (REQ2) is application specific,
and part of the requirements for the application profile.
<mglt>
Maybe it would worth specifying the reference the
REQ refer to.
</mglt>
[...]
3.2. Authorization Response
The Authorization Response sent from the AS to the Client is as
defined in Section 5.6.2 of [I-D.ietf-ace-oauth-authz] and MUST
contain the following parameters:
* 'access_token', containing the proof-of-possession access token.
* 'cnf' if symmetric keys are used, not present if asymmetric keys
are used. This parameter is defined in Section 3.2 of
[I-D.ietf-ace-oauth-params] and contains the symmetric proof-of-
possession key that the Client is supposed to use with the KDC.
* 'rs_cnf' if asymmetric keys are used, not present if symmetric
keys are used. This parameter is as defined in Section 3.2 of
[I-D.ietf-ace-oauth-params] and contains information about the
public key of the KDC.
* 'expires_in', contains the lifetime in seconds of the access
token. This parameter MAY be omitted if the application defines
how the expiration time is communicated to the Client via other
means, or if it establishes a default value.
Additionally, the Authorization Response MAY contain the following
parameters, which, if included, MUST have the corresponding values:
* 'scope' containing the granted scope, if different from the scope
requested by the client. This parameter has the same format and
encoding of 'scope' in the Authorization Request, defined in
Section 3.1.
* Other additional parameters as defined in
[I-D.ietf-ace-oauth-authz], if necessary.
The proof-of-possession access token (in 'access_token' above) MUST
contain the following parameters:
Palombini & Tiloca Expires 12 November 2020 [Page 9]
Internet-Draft Key Provisioning for Group Communication May 2020
* a confirmation claim (see for example 'cnf' defined in Section 3.1
of [RFC8747] for CWT);
* an expiration time claim (see for example 'exp' defined in
Section 3.1.4 of [RFC8392] for CWT);
* a scope claim (see for example 'scope' registered in Section 8.13
of [I-D.ietf-ace-oauth-authz] for CWT). This claim has the same
encoding as 'scope' parameter above. Additionally, this claim has
the same value of the 'scope' parameter if the parameter is
present in the message, or it takes the value of 'scope' in the
Authorization Request otherwise.
The access token MAY additionally contain other claims that the
transport profile of ACE requires, or other optional parameters.
As in [I-D.ietf-ace-oauth-authz], these parameters are included in
the payload, which is formatted as a CBOR map. The Content-Format
"application/ace+cbor" is used.
When receiving an Authorization Request from a Client that was
previously authorized, and for which the AS still owns a valid non
expired access token, the AS MAY reply with that token. Note that it
is up to application profiles of ACE to make sure that re-posting the
same token does not cause re-use of keying material between nodes
(for example, that is done with the use of random nonces in
[I-D.ietf-ace-oscore-profile]).
<mglt>
I am wondering if it is expected the client reads
the values contained in the access_token. I
suppose not, and even when the acces_token is not
encrypted the client is supposed to pass the
access token as opaque data to the KDC. Is that
correct ?
I am also wondering how the AS could inform which
transport are available to the KDC.
What is a little bit unclear to me is when the
access token is combined with another access token
from the transport layer. I suppose that the two
tokens are "merged" in some ways and I am
wondering if the transport access token is
expected to include those of the upper layers in
our case the KDC.
</mglt>
3.3. Token Post
The Client sends a CoAP POST request including the access token to
the KDC, as specified in Section 5.8.1 of [I-D.ietf-ace-oauth-authz].
If the specific transport profile of ACE defines it, the Client MAY
use a different endpoint than /authz-info at the KDC to post the
access token to.
<mglt>
I think the overview section mentions
application/cwt is used for that exchange. I
think it might be helpful to specify that post
uses application/cwt since later we indicate that
application/ace+cbor may carry another meaning.
It might worth updating this section as well.
I also have the impression that the response to
the post is called "AS Request Creation Hints".
If that is correct, the designation is misleading,
as hints are not targeting the AS in the case.
Maybe that would be good to indicate this is this
exchange that is being considered with a different
meaning as it has been defined in the framework.
If that is still correct, I am wondering how the
client can make a difference between the AS
Request Creation Hints as a Response that provides
additional information related to the group
communication. In particular I am wondering if
parameters are used to distinguish these two
responses.
</mglt>
Optionally, the Client might want to request necessary information
concerning the public keys in the group, as well as concerning the
algorithm and related parameters for computing signatures in the
group. In such a case, the joining node MAY ask for that information
to the KDC in this same request. To this end, it sends the CoAP POST
request to the /authz-info endpoint using the Content-Format
"application/ace+cbor". The payload of the message MUST be formatted
as a CBOR map, including the access token and the following
parameters:
* 'sign_info' defined in Section 3.3.1.
Palombini & Tiloca Expires 12 November 2020 [Page 10]
Internet-Draft Key Provisioning for Group Communication May 2020
* 'pub_key_enc' defined in Section 3.3.2, encoding the CBOR simple
value Null, to require information on the exact encoding of public
keys used in the group.
Alternatively, the joining node may retrieve this information by
other means.
After successful verification, the Client is authorized to receive
<mglt>
I am wondering if the verification goes beyond the
signature validation.
The remaining of the text seems also to assume
that ace+cbor is used. Is that correct ?
</mglt>
the group keying material from the KDC and join the group. In
particular, the KDC replies to the Client with a 2.01 (Created)
response, using Content-Format "application/ace+cbor" defined in
Section 8.14 of [I-D.ietf-ace-oauth-authz].
The payload of the 2.01 response is a CBOR map. If the access token
contains a role that requires the Client to send its own public key
to the KDC when joining the group, the CBOR map MUST include the
parameter 'kdcchallenge' defined in Section Section 3.3.3, specifying
a dedicated challenge N_S generated by the KDC.
<mglt>
I am wondering how the client provides the public
key, and I am wondering if the public key is not
provided through the access_token to the KDC. If
that would be correct, it seems then that the key
is provided by the AS or the access token instead
of the client. Maybe the public keys are those of
the members of the group.
</mglt>
The Client uses this
challenge to prove possession of its own private key (see the
'client_cred_verify' parameter in Section 4).
<mglt>
I have not yet read section 4, but it seems that
additional exchanges are performed that goes
beyond the Token post exchange. If my
understanding is correct, I am wondering if that
description fits the title of this section.
</mglt>
Note that the payload
format of the response deviates from the default as defined in the
ACE framework (see Section 5.8.1 of [I-D.ietf-ace-oauth-authz]).
The KDC MUST store the 'kdcchallenge' value associated to the Client
at least until it receives a join request from it (see Section 4.2),
to be able to verify the proof of possession. The same challenge MAY
be reused several times by the Client, to generate new proof of
possessions, e.g. in case of update of the public key, or to join a
different group with a different key, so it is RECOMMENDED that the
KDC keeps storing the 'kdcchallenge' after the first join is
processed as well. If the KDC has already discarded the
'kdcchallenge', that will trigger an error response with a newly
generated 'kdcchallenge' that the client can use to restart the join
process, as specified in Section 4.2.
If either of 'sign_info' or 'pub_key_enc' were included in the
request, the KDC MAY include the 'sign_info' parameter defined in
Section 3.3.1, optionally including the 'pub_key_enc' parameter
Section 3.3.2.
The 'sign_info' parameter MUST be present if the POST request
included the 'sign_info' parameter and/or the pub_key_enc with value
Null. The encoding of the 'sign_info' parameter in the response is
defined in Section 3.3.2. Note that the field 'id' takes the value
of the group identifier for which the 'sign_info' applies to, in this
specification.
Palombini & Tiloca Expires 12 November 2020 [Page 11]
Internet-Draft Key Provisioning for Group Communication May 2020
Note that the CBOR map specified as payload of the 2.01 (Created)
response may include further parameters, e.g. according to the
signalled transport profile of ACE.
Applications of this specification MAY define alternative specific
negotiations of parameter values for signature algorithm and
signature keys, if 'sign_info' and 'pub_key_enc' are not used (OPT2).
3.3.1. 'sign_info' Parameter
The 'sign_info' parameter is an OPTIONAL parameter of the AS Request
Creation Hints message defined in Section 5.1.2. of
[I-D.ietf-ace-oauth-authz].
<mglt>
The text can be read as 'sign_info' is defined in
Section 5.1.2. I believe that clarifying the
response is designated in the framework as AS
Request Creation Hints but has a different meaning
here may solve this issue.
</mglt>
[...]
3.3.2. 'pub_key_enc' Parameter
The 'pub_key_enc' parameter is an OPTIONAL parameter of the AS
Request Creation Hints message defined in Section 5.1.2. of
[I-D.ietf-ace-oauth-authz]. This parameter contains information
about the exact encoding of public keys to be used between the Client
and the RS. Its exact content is application specific.
In this specification and in application profiles building on it,
this parameter is used to ask the KDC information about the encoding
of public keys used in the group.
The CDDL notation of the 'pub_key_enc' parameter formatted as in the
request is given below.
pub_key_enc_req = nil
<mglt>
It is not entirely clear to me what pub_key_enc is
about. It is the format of the public key itself
or the encryption algorithm ?
Then it is unclear to me which public key is
referred to. "public keys used in the group" make
me think of a private/public key that is shared by
all members of the group. This public key is used
with the RS, that is the dispatcher, not to
authenticate the client. Am I correct ?
</mglt>
3.3.3. 'kdcchallenge' Parameter
The 'kdcchallenge' parameter is an OPTIONAL parameter of the AS
Request Creation Hints message defined in Section 5.1.2. of
[I-D.ietf-ace-oauth-authz]. This parameter contains a challenge
generated by the KDC and provided to the Client. The Client may use
this challenge to prove possession of its own private key in the
Joining Request ((see the 'client_cred_verify' parameter in
Section 4).
<mglt>
I suppose that will be clarified in section , but
of "its own private key" make me think that the
key in question is to authenticate the client,
instead of the key used for the group.
If that is correct, it is unclear to me why there
is a need to authenticate the client and why this
should not be performed instead by the AS. It
seems I am missing something here.
</mglt>
4. Keying Material Provisioning and Group Membership Management
[...]
Upon receiving a request from a Client, the KDC MUST check that it is
storing a valid access token from that Client for the group
identifier assiciated
<mglt>
associated
</mglt>
to the endpoint. If that is not the case, i.e.
the KDC does not store a valid access token or this is not valid for
that Client for the group identifier at hand, the KDC MUST respond to
the Client with a 4.01 (Unauthorized) error message.
4.1. Interface at the KDC
The KDC is configured with the following resources. Note that the
root url-path "ace-group" given here are default names:
implementations are not required to use these names, and can define
their own instead. The Interface Description (if=) Link Target
Attribute value ace-group is registered (Section 8.9) and can be used
to describe this inferface.
<mglt>
interface.
</mglt>
--
Daniel Migault
Ericsson
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
