[Ace] questions on draft-ietf-ace-key-groupcomm-06

[Daniel Migault <[e-mail]>]

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