Re: [Ace] draft-ietf-ace-key-groupcomm-13

[Cigdem Sengul <[e-mail]>]

Thanks, Marco!
MT2 comments and revisions clarified things for me.
Best wishes,
--Cigdem

On Tue, Oct 12, 2021 at 9:07 AM Marco Tiloca <[e-mail]> wrote:

> Hi Cigdem,
>
> Thanks for the follow-up feedback! I believe your points are now all
> captured in the Editor's copy on Github.
>
> Please, find inline my replies to your four latest points, marked as "
> ==>MT2".
>
> Best,
> /Marco
>
> On 2021-10-11 17:36, Cigdem Sengul wrote:
>
> Hello Marco,
>
> Apologies for getting back to you late, I was/am snowed under at work.
> But I've also read through the previous interim discussion as well.
> In general, I think  everything is much clearer now.
> Some more comments inline, mostly OKing your suggestions (and removing
> some previous ones where we are in agreement, and there is no feedback
> sought).
> Kind regards,
> --Cigdem
>
>
> On Wed, Sep 1, 2021 at 9:27 PM Marco Tiloca <[e-mail]> wrote:
>
>> Hi Cigdem,
>>
>> Thank you very much for your review! Please, find my replies inline
>> marked as "==>MT".
>>
>> Best,
>> /Marco
>>
>> On 2021-08-25 23:52, Cigdem Sengul wrote:
>>
>>
>> Hello,
>> Here is also my review, as promised. I agree with Göran's comments and
>> tried not to repeat them (but I realise I have the same concern about the
>> presentation of Section 4 - more details below).
>> *General comments:*
>> The draft is quite thorough in providing details about how a node, as a
>> participant of group communication, can get authorisation, join/get
>> information about and leave the group, how a node can be removed, and how
>> the key information is provided to protect the group communication. In the
>> pub-sub draft, we take advantage of all these resources to secure pub-sub
>> communication.
>> In addition to some questions I have about resources (in my detailed
>> comments), most of my comments are focused on improving the readability of
>> the draft. As Göran also mentioned, after defining the available resources,
>> it would be good to explain the flows and then give details of endpoints
>> and examples. This way, it would be possible to understand first the
>> primitives available for securing group communication, then have more
>> detail important for the implementation.
>>
>>
>> ==>MT
>> I believe that the proposal to address this point in the review from
>> Göran [1][1reply] can help here too. I re-include it below for convenience.
>>
>> 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 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 look?
>>
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/ace/pr2gBhvqy9j8AfUdQVTZLwamXac/
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Face%2Fpr2gBhvqy9j8AfUdQVTZLwamXac%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524510355%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sY%2Fi1al%2FDXzqr7JFhSJBU1P6WMogxGdeAhT8KoxpIT8%3D&reserved=0>
>>
>> [1reply]
>> https://mailarchive.ietf.org/arch/msg/ace/dEU04pB3u-iYNBwSlfjJaqkEvgo/
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Face%2FdEU04pB3u-iYNBwSlfjJaqkEvgo%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524520321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fjWpy921q1BNpx5ZwLMoFfGCGosc8r2yWMaM9SWPpsY%3D&reserved=0>
>>
>> <==
>>
>
> [CS: I think this would make things a lot more clear, yes.]
>
>>
>> Also,  reading the draft, it was first not clear how the rekeying was
>> supported, whether it was a push/poll based solution, i.e., whether the KDC
>> pushes new keys or the group participants query for the new key
>> information.  Both options are supported, but it would be nice to have one
>> clear section on this with a recommendation (Sections 4.4 and 4.5 look like
>> the main sections for this, but there are several instances throughout the
>> text rekeying is mentioned.)
>>
>>
>> ==>MT
>> I think most of the useful content is in the bullet list in Section 4.4.
>> Instead, Section 4.5 is about renewing "individual keying material" (e.g.
>> an OSCORE Sender ID), and is not related to the group rekeying.
>>
>> Here's a possible way forward. We can introduce a new section specific on
>> group rekeying, with the alternatives from Section 4.4. Then, this section
>> can be pointed by (at least) Sections 4.5, 5 and 9.1.
>>
>> As to what can be recommended, I started to think of something like the
>> following:
>>
>> - The KDC should make /ace-group/GROUPNAME observable, hence supporting a
>> distribution approach based on notifications.
>>
>> - If the joining node does not plan to observe /ace-group/GROUPNAME , the
>> joining node MUST specify 'control_uri' in the joining request.
>>
>> - The KDC must support at least one push-based approach, minimally a
>> point-to-point one. More efficient alternatives, e.g. based on multicast,
>> remain possible.
>>
>> - If the Group Manager rekeys the group members point-to-point, the Group
>> Manager sends the rekeying message to a certain group member either as a
>> notification (if the group member is registered as an observer of
>> /ace-group/GROUPNAME) or as a request to the resource of the group member
>> at 'control_uri' (if the group member is not registered as an observer).
>>
>>    If neither of the two is possible (which means the group member is not
>> complying with the above), the group member would miss a rekeying. Later
>> on, after having failed to successfully exchange secure messages with other
>> peers in the group, the group member will have to align itself in a pull
>> fashion, by sending a GET request to ace-group/GROUPNAME or
>> ace-group/GROUPNAME/nodes/NODENAME.
>>
>>
>> What do you think?
>> <==
>>
> [CS: I think combined with what you shared after the previous interim
> meeting, it's getting a lot more clear how rekeying is supported, and
> signaled to the group participants.]
>
>>
>> Finally, I've read the draft linearly and revised my comments if
>> something I questioned was answered later; however, I've kept the comment
>> to show where someone can be puzzled, and a forward pointer to the correct
>> section may be appropriate. My comments are within [CS: ]. I hope you find
>> them useful.
>>
>>
>> ==>MT
>> Thanks! Please, see also my replies in line.
>> <==
>>
>>
>> *Detailed comments:*
>>
>>
>> ACE Working Group                                           F. Palombini
>> Internet-Draft                                               Ericsson AB
>> Intended status: Standards Track                               M. Tiloca
>> Expires: 13 January 2022                                         RISE AB
>>                                                             12 July 2021
>>
>>
>>            Key Provisioning for Group Communication using ACE
>>                     draft-ietf-ace-key-groupcomm-13
>>
>>
>> [SNIP]
>>
>>
>> 1.1.  Terminology
>>
>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>>    "OPTIONAL" in this document are to be interpreted as described in BCP
>>    14 [RFC2119] [RFC8174] when, and only when, they appear in all
>>    capitals, as shown here.
>>
>>    Readers are expected to be familiar with the terms and concepts
>>    described in [I-D.ietf-ace-oauth-authz][I-D.ietf-cose-rfc8152bis-stru
>>    ct][I-D.ietf-cose-rfc8152bis-algs], such as Authorization Server (AS)
>>    and Resource Server (RS).
>>
>>    This document uses names or identifiers for groups and nodes.  Their
>>    different meanings are summarized here:
>>
>>    *  "Group name" is the invariant once established identifier of the
>>       group.  It is used in the communication between AS, RS and Client
>>       to identify the group.
>>
>> [CS: This has confused me earlier with the distinction of security and
>> application
>> group not being clear at the time. Would it be possible to emphasise this
>> is a Security Group
>> Name?]
>>
>>
>> ==>MT
>> Even better, we can add an earlier definition of "Group", clarifying that
>> it is a security group. Something like:
>>
>> "Group: a set of nodes that share group keying material and security
>> parameters used to protect their communications. That is, the term refers
>> to a "security group". This is not to be confused with an "application
>> group", which has relevance at the application level and whose members
>> share a common pool of resources or content."
>>
>> It shouldn't be necessary to explicitly point to the definition of
>> "application group" and "security group" given in
>> draft-ietf-core-groupcomm-bis.
>> <==
>>
> [CS: Excellent]
>
>
>>
>> 2.  Overview
>>
>>    The full procedure can be separated in two phases: the first one
>>    follows the ACE framework, between Client, AS and KDC; the second one
>>    is the key distribution between Client and KDC.  After the two phases
>>    are completed, the Client is able to participate in the group
>>    communication, via a Dispatcher entity.
>>
>>
>>        +------------+                  +-----------+
>>        |     AS     |                  |    KDC    |
>>        |            |        .-------->|           |
>>        +------------+       /          +-----------+
>>              ^             /
>>              |            /
>>              v           /                           +-----------+
>>        +------------+   /      +------------+        |+-----------+
>>        |   Client   |<-'       | Dispatcher |        ||+-----------+
>>        |            |<-------->|            |<------->||   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
>>       addition, it provides the latest keying material to group members
>>       when requested or, if required by the application, when membership
>>       changes.
>>
>> [CS: It is not clear to me whether the KDC is programmed to rekey when
>> membership
>> changes or that needs to be invoked as a request from one of the group
>> communication
>> participants (which may have, say, a coordinator role). (Again, this is
>> clarified later,
>> but each time I saw it, it triggered the same question.)]
>>
>>
>> ==>MT
>> This will be clarified in a dedicated section about group rekeying (see
>> the comments at the beginning of this reply).
>>
>> In short, a rekeying is started only by the KDC, due to different
>> possible reasons, and can be done through different distribution
>> approaches. There is no such thing like a "request for rekeying the group".
>> <==
>>
> [CS: +1]
>
>>
>>
>>
>>
>> Palombini & Tiloca       Expires 13 January 2022                [Page 5]
>>
>> Internet-Draft  Key Provisioning for Group Communication       July 2021
>>
>>
>>    *  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.
>>
>> [CS:Is a Dispatcher always needed? Clients initiating unicast messages to
>> other
>> group members directly p2p?]
>>
>>
>> ==>MT
>> That's a good point. We can clarify that the Dispatcher enforces the
>> distribution of a message intended to multiple recipients. A
>> single-recipient message (even though intended to another member of the
>> security/application group) can be reached by alternative, more direct
>> means.
>> <==
>>
> [CS: +1]
>
>>
>>
>> 3.  Authorization to Join a Group
>>
>>   [SNIP]
>>
>> 3.1.  Authorization Request
>>
>>    The Authorization Request sent from the Client to the AS is defined
>>    in Section 5.8.1 of [I-D.ietf-ace-oauth-authz] and MAY contain the
>>    following parameters, which, if included, MUST have the corresponding
>>    values:
>>
>>    *  'scope', containing the identifier of the specific groups, or
>>       topics in the case of pub-sub, that the Client wishes to access,
>>       and optionally the roles that the Client wishes to take.
>>
>> [CS: I think we have to include that a pub-sub model may also group nodes
>> based on something other than topics, even though we've written the
>> pub-sub
>> profile based on topic(or topic filter)-based group identifiers. Maybe
>> this is
>> better given just as an example?]
>>
>>
>> ==>MT
>> How about simply the following?
>>
>> "'scope', containing the identifier of the specific groups, e.g. of
>> topics in the case of pub-sub, that ..."
>> <==
>>
> [CS: Yes, that's great.]
>
>>
>>
>>
>> Palombini & Tiloca       Expires 13 January 2022                [Page 8]
>>
>> Internet-Draft  Key Provisioning for Group Communication       July 2021
>>
>>
>>       By default, each entry is encoded as specified by
>>       [I-D.ietf-ace-aif].  The object identifier Toid corresponds to the
>>       group name and MUST be encoded as a tstr.  The permission set
>>       Tperm indicates the roles that the client wishes to take in the
>>       group.  It is up to the application profiles to define Tperm
>>       (REQ2) and register Toid and Tperm to fit the use case.  An
>>       example of scope using the AIF format is given in Figure 4.
>>
>>       Otherwise, each scope entry can be defined as a CBOR array, which
>>       contains:
>>
>> [CS: Two options. One recommended? (Though I see that this is better
>> clarified
>> below when explaining extended scope format and how KDC may support
>> multiple...
>> Maybe a forward reference?)]
>>
>>
>> ==>MT
>> I would recommend the option using AIF as more compact, but it really
>> depends on how important/necessary it is for the application to have roles
>> expressed in a compact way. I can see that the pub-sub profile uses text
>> strings for those.
>>
>> Maybe it's just fine to do something like the following:
>>
>> - Expand the paragraph above to mention that the default option based on
>> AIF allows for more compact scopes (since roles are expressed in a more
>> compact way), and thus is preferable for application profiles that aim to
>> achieve compact scopes, especially if they define multiple possible roles
>> and their coexistence for a same node.
>>
>> - Point to Section 6 as to the extended format for semantics
>> disambiguation. Note that this extension applies to a scope encoded as a
>> byte string (although beyond the scopes defined in this document and its
>> profiles), which is the case for both the alternatives in Figure 4 and
>> Figure 5, since the actual 'scope' claim is encoded as a byte string in
>> either case. This is also evident from the examples in Figure 28 and Figure
>> 29, respectively.
>> <==
>>
> [CS: I think what you suggest would read fine.]
>
>
>>
>>
>>       -  As first element, the identifier of the specific group or
>>          topic, encoded as a tstr.
>>
>>       -  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).
>>
>> [CS: What happens if a Client uses the option to select a role but
>> mismatches what
>> is pre-assigned. I expect it's overwritten with what's pre-programmed at
>> the AS?
>> Is there an error message for the mismatch? e.g., "Request inconsistent
>> with the current roles"]
>>
>>
>> ==>MT
>> I think you mean that: a role A was configured as legitimate for the
>> Client on the AS; the Client asks for a token that grants role B.
>>
>> In this case, the Client is simply not supposed to be authorized to take
>> role B. I would expect the AS to return an error response with code
>> "invalid_scope", i.e. "The requested scope is invalid, unknown, malformed,
>> or exceeds the scope granted by the resource owner" (see Section 5.2 of RFC
>> 6749).
>>
>> Overall, this does not deviate from what defined in the ACE framework, in
>> its Sections 5.8.1-5.8.3. The Section 3.1 of this document with the text
>> quoted above is pointing to Section 5.8.1 of the ACE framework.
>> <==
>> [CS: Actually my comment was more for the text: " Optionally, as second
>> element, the role (or CBOR array of roles) that the Client wishes to take
>> in the group." as if the client can wish for a role even if it is
>> pre-assigned, and thought the return of an error in this case should be
>> explained in the text.]
>>
>
> ==>MT2
> Ok, there is no intention to admit a Client sending an Authorization
> Request to extend the access policies pre-configured on the AS by the
> Resource Owner. Rephrased as follows in order to avoid confusion:
>
> In the section "Authorization Request"
>
> OLD
> ... that the Client wishes to access, and optionally the roles that the
> Client wishes to take.
>
> NEW
> ... that the Client requests to access, and optionally the roles that the
> Client requests to have in those groups.
>
>
> In the section "Authorization Response"
>
> OLD
> The Authorization Response sent from the AS to the Client is defined in
> Section 5.8.2 of [I-D.ietf-ace-oauth-authz].
>
> NEW
> The AS processes the Authorization Request as defined in
> [I-D.ietf-ace-oauth-authz], especially verifying that the Client is
> authorized to access the specified groups with the requested roles, or
> possibly a subset of those. In case of successful verification, the
> Authorization Response sent from the AS to the Client is also defined in
> [I-D.ietf-ace-oauth-authz].
> <==
>
>
>>       In each entry, the encoding of the role identifiers is application
>>       specific, and part of the requirements for the application profile
>>       (REQ2).  In particular, the application profile may specify CBOR
>>       values to use for abbreviating role identifiers (OPT7).
>>
>>       An example of CDDL definition [RFC8610] of scope using the format
>>       above, with group name and role identifiers encoded as text
>>       strings is given in Figure 5.
>>
>> [CS: is->are]
>>
>>
>> ==>MT
>> Isn't the subject "example" ? It can be anyway rephrased as "Figure 5
>> provides an example of ..."
>> <==
>>
> [CS: Ah, yes. I took it as "group name and role identifiers". Thanks for
> rephrasing.]
>
>>
>>
>> 3.3.  Token Post
>>
>>                     [Snip]
>>
>>    The joining node MAY ask for this information from the KDC in the
>>    same message it uses to POST the token to the RS.  In such a case,
>>    the message MUST have Content-Format set to application/ace+cbor
>>    defined in Section 8.16 of [I-D.ietf-ace-oauth-authz].  The message
>>    payload MUST be formatted as a CBOR map, which MUST include the
>>    access token.  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.
>>
>>    Alternatively, the joining node may retrieve this information by
>>    other means.
>> [CS: Reference to them?]
>>
>>
>> ==>MT
>> I can add a commented informative reference to
>> draft-tiloca-core-oscore-discovery.
>>
>> That document is practically focused on the Group OSCORE case covered by
>> ace-key-groupcomm-oscore (where it is in fact referred to), but the overall
>> idea has general applicability to the discovering of security groups where
>> different protocols are used. All in all, it's about discovering the links
>> to join a security group, along with attributes describing how the group
>> works.
>>
>> Beside that, "other means" can include pre-configuration or other early
>> discovery/learning processes that a group member would go through before
>> joining. I'm not sure what good, general references about that can be added.
>> <==
>> [CS: OK thanks, otherwise "other means" is too vague, and does not give
>> any hints to what may be acceptable.]
>>
>>
>>    After successful verification, the Client is authorized to receive
>>    the group keying material from the KDC and join the group.
>>
>>    The KDC replies to the Client with a 2.01 (Created) response, using
>>    Content-Format "application/ace+cbor".
>>
>>    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 3.3.2, specifying a
>>    dedicated challenge N_S generated by the KDC.  The Client uses this
>>    challenge to prove possession of its own private key (see the
>>    'client_cred_verify' parameter in Section 4).  Note that the payload
>>    format of the response deviates from the one defined in the ACE
>>    framework (see Section 5.10.1 of [I-D.ietf-ace-oauth-authz]), which
>>    has no payload.
>>
>>    The KDC MUST store the 'kdcchallenge' value associated to the Client
>>    at least until it receives a join request from it (see Section 4.3),
>>    to be able to verify that the Client possesses its own private key.
>>
>> [CS: OK, just to clarify? the kdcchallenge is generated and returned in
>> the Authorisation
>> response, and the client uses it to prove ownership of public key on join
>> request.
>> It may be useful to specify more clearly when the challenge parameter is
>> used.
>> (This is clarified much later; I feel explaining the possible flows using
>> the resources
>> beforehand would be better, as I comment later as well.]
>>
>>
>> ==>MT
>> 'kdcchallenge' is included in the response to the Token posting (the
>> Authorization Response is part of the earlier exchange with the AS).
>>
>> The paragraph above can explicitly mention the later Joining Request, and
>> that N_S is used as part of a PoP input to compute the PoP evidence.
>> <==
>>
> [CS: +1]
>
>>
>>
>>    The same challenge MAY be reused several times by the Client, to
>>    generate a new proof of possession, e.g., in case of update of the
>>
>>
>>
>> Palombini & Tiloca       Expires 13 January 2022               [Page 12]
>>
>> Internet-Draft  Key Provisioning for Group Communication       July 2021
>>
>>
>>    public key, or to join a different group with a different signing
>>    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.3.
>>
>>    If 'sign_info' is included in the request, the KDC MAY include the
>>    'sign_info' parameter defined in Section 3.3.1, with the same
>>    encoding.  Note that the field 'id' takes the value of the group name
>>    for which the 'sign_info_entry' applies to.
>>
>> [CS: This MAY mean that even if the client has sign_info, the KDC
>> may not return this information? What's the reason for this?]
>>
>>
>> ==>MT
>> A possible reason is that the group indicated in the token does not use
>> signatures to ensure source authentication. The client doesn't know that
>> and just uses 'sign_info' as usual in its request. In that case, the KDC
>> has nothing to say about 'sign_info'. Also, it is up to the application
>> profile and its associated secure group communication protocol to have
>> already defined alternative means to achieve source authentication in the
>> group. This will be clarified better.
>>
>> A case in point is in ace-key-groupcomm-oscore , when a group uses only
>> the pairwise mode of Group OSCORE. In that "extreme" but possible case,
>> communication among group members occurs only one-to-one, and source
>> communication is achieved by pairwise symmetric encryption keys. These are
>> in turn derived from the group key material and the asymmetric keys of the
>> two peers in question. Hence, there is no set of information to convey with
>> 'sign_info', while other specific parameters defined in
>> ace-key-groupcomm-oscore transport information required to perform those
>> operations (e.g. algorithms and parameters).
>> <==
>>
> [CS: With this explanation, it's more clear]
>
>>
>> [Snip]
>>
>>
>> 3.3.1.  'sign_info' Parameter
>>
>> [CS: It is confusing to read about sign_info in two places (in
>> the previous section and this section). Maybe defer
>> all sign_info -related information to this section?]
>>
>>
>> ==>MT
>> I've seen it as a common practice to have a parameter defined in a
>> dedicated section, here Section 3.3.1, so that its definition abstracting
>> from any particular use can be referred by possible other documents or by
>> IANA registrations. The intent here is to define a new parameter first of
>> all for OAuth and ACE (see the later registrations in Sections 10.3 and
>> 10.4).
>>
>> The previous Section 3.3.0 defines the specific use of 'sign_info' in
>> this document, consistent with the general definition.
>>
>> Does it make sense?
>> <==
>>
> [CS: OK]
>
>>
>>
>> [SNIP]
>>
>>
>> 3.3.2.  'kdcchallenge' Parameter
>> [CS: The same comment as above, either explained here or above...
>> Otherwise
>> repetitious]
>>
>>
>> ==>MT
>> See the comment above about 'sign_info'.
>> <==
>>
> [CS: OK. ]
>
>>
>> [SNIP]
>>
>> 4.  Keying Material Provisioning and Group Membership Management
>>
>> [SNIP]
>>
>>
>> 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.  Each application profile of this specification
>>    MUST register a Resource Type for the root url-path (REQ7), and that
>>    Resource Type can be used to discover the correct url to access at
>>    the KDC.  This Resource Type can also be used at the GROUPNAME sub-
>>    resource, to indicate different application profiles for different
>>    groups.  The Interface Description (if=) Link Target Attribute value
>>    ace.group is registered (Section 10.10) and can be used to describe
>>    this interface.
>>
>>    *  /ace-group: this resource is invariant once established and
>>       indicates that this specification is used.  If other applications
>>       run on a KDC implementing this specification and use this same
>>       resource, these applications will collide, and a mechanism will be
>>       needed to differentiate the endpoints.  This resource supports the
>>       FETCH method.
>>
>>    *  /ace-group/GROUPNAME: one sub-resource to /ace-group is
>>       implemented for each group the KDC manages.
>>
>>       If the value of the GROUPNAME URI path and the group name in the
>>       access token scope ('gname' in Section 3.2) do not match, the KDC
>>       MUST implement a mechanism to map the GROUPNAME value in the URI
>>       to the group name, in order to retrieve the right group (REQ1).
>>
>> [CS: While I understand the purpose of the statement above, it reads
>> confusing.
>> What if the mismatch is an error? E.g., the wrong token is provided
>> for the call, and it should be not authorised, no?]
>>
>>
>> ==>MT
>> Well, if the token was found valid and stored, the KDC grants access to
>> /ace-group/GROUPNAME , where GROUPNAME is the result of the (possibly
>> identity-)mapping from gname.
>>
>> At the same time, the Client has to target the correct URI
>> /ace-group/GROUPNAME . This does not require the Client to be aware of the
>> exact gname -> GROUPNAME mapping performed by the KDC, but just to know the
>> right URI (which is up to a separate discovering/learning task).
>>
>> If the mismatch is an actual mistake, meaning the Client uses a wrong URI
>> for the group gname, the KDC will reply with an error response as per the
>> ACE framework, in this case returning a 4.03 (Forbidden), see Section
>> 5.10.2 of the ACE framework document.
>>
>> Do you think it is worth to include these clarifications?
>> <==
>>
> [CS: OK, but it was not clear to me why KDC would want to keep an
> alternative naming. I think without understanding that, it felt awkward to
> read that KDC MUST implement the mapping.]
>
>
> ==>MT2
> The word "match" is probably the source of confusion here. Now rephrased
> as below. Admitting an alternative naming was an early design choice to
> simply allow flexibility.
>
> OLD
> If the value of the GROUPNAME URI path and the group name in the access
> token scope ('gname' in Section 3.2) do not match, the KDC MUST implement
> ...
>
> NEW
> If the value of the GROUPNAME URI path and the group name in the access
> token scope ('gname' in Section 3.2) are not required to coincide, the KDC
> MUST implement ...
> <==
>
>
>>
>>       Each resource contains the symmetric group keying material for
>>       that group.  These resources support the GET and POST methods.
>>
>>    *  /ace-group/GROUPNAME/pub-key: this resource is invariant once
>>       established and contains the public keys of all group members.
>>       This resource supports the GET and FETCH methods.
>>
>> [CS: All group members do not need to have public keys, e.g., For
>> pub-sub, its only publishers]
>>
>>
>> ==>MT
>> Right, this is also related to another comment in the review from Göran.
>> Some particular group members, e.g. depending on their role, may have no
>> use of some resources. This means they will not send requests to those
>> resources.
>>
>> On the other hand, the KDC provides such resources and an interface to
>> access them for the group members for which it makes sense. It's probably
>> up to an application profile to clarify that the interaction to a
>> particular resource is not expected/relevant by particular group members.
>> <==
>>
> [CS: OK]
>
>>
>>
>>    *  /ace-group/GROUPNAME/policies: this resource is invariant once
>>       established and contains the group policies.  This resource
>>       supports the GET method.
>>
>>
>> Palombini & Tiloca       Expires 13 January 2022               [Page 17]
>>
>> Internet-Draft  Key Provisioning for Group Communication       July 2021
>>
>>
>>    *  /ace-group/GROUPNAME/num: this resource is invariant once
>>       established and contains the version number for the symmetric
>>       group keying material.  This sub-resource supports the GET method.
>>
>>    *  /ace-group/GROUPNAME/nodes/NODENAME: one sub-resource to /ace-
>>       group/GROUPNAME is implemented for each node in the group the KDC
>>       manages.  These resources are identified by the node name (in this
>>       example, the node name has value NODENAME).  Each resource
>>       contains the group and individual keying material for that node.
>>       These resources support the GET, PUT and DELETE methods.
>>
>>    *  /ace-group/GROUPNAME/nodes/NODENAME/pub-key: one sub-resource to
>>       /ace-group/GROUPNAME/nodes/NODENAME is implemented for each node
>>       in the group the KDC manages.  These resources are identified by
>>       the node name (in this example, the node name has value NODENAME).
>>       Each resource contains the individual public keying material for
>>       that node.  These resources support the POST method.
>> [CS: It also supports FETCH and GET, as detailed later?]
>>
>>
>> ==>MT
>> No, this resource supports only POST requests, for the node with name
>> NODENAME to provide a new public key of its own.
>>
>> The resource related to public keys as supporting both GET and FETCH
>> requests is rather /ace-group/GROUPNAME/pub-key . This is not individually
>> associated to a group member, and it is accessible by any group member to
>> retrieve the public keys now used in the group.
>> <==
>>
> [CS: OK, makes sense - i missed the Uri difference]
>
>>
>>
>>    It is REQUIRED of the application profiles of this specification to
>>    define what operations (e.g., CoAP methods) are allowed on each
>>    resource, for each role defined in Section 3.1 according to REQ2
>>    (REQ8).
>>
>> [CS: Just to clarify again, this spec supports the above detailed
>> operations,
>> and it is REQUIRED that the profile, which uses this profile, further
>> constrains the operations
>> and who is allowed to access. And the access may not be based on only
>> role, e.g.
>> NODENAME may be able to PUT under nodes/NODENAME?]
>>
>>
>> ==>MT
>> The idea was that in every application profile the KDC supports all these
>> operations. At the same time, I can imagine that an application profile
>> really not needing some functionalities may just declare some of the KDC
>> resources not relevant and not have them altogether. Also, the KDC of an
>> application profile may add new resources to provide additional
>> functionalities.
>>
>> Taking the perspective of a group member:
>>
>> - It is already intended that a node with name NODENAME can access only
>> node-based sub-resources exactly under nodes/NODENAME. That is, it cannot
>> access node-based sub-resources of another node. This is ensured by the
>> consistency checks in the handlers of those resources (see, for instance,
>> Section 4.1.6.1).
>>
>> - The quoted sentence and REQ8 require application profiles to further
>> define/limit the access to the KDC resources, based on the role that a node
>> trying to access that resource has in the group. In
>> ace-key-groupcomm-oscore , this requirement is fulfilled in its Section 5.5
>> by means of Figure 2.
>> <==
>>
> [CS: OK]
>
>>
>>    [SNIP]
>>
>>
>> Palombini & Tiloca       Expires 13 January 2022               [Page 19]
>>
>> Internet-Draft  Key Provisioning for Group Communication       July 2021
>>
>>
>>    *  'scope', with value the specific resource at the KDC that the
>>       Client is authorized to access, i.e., group or topic name, and
>>       role(s).  This value is a CBOR byte string wrapping one scope
>>       entry, as defined in Section 3.1.
>>
>>    *  'get_pub_keys', if the Client wishes to receive the public keys of
>>       the other nodes in the group from the KDC.  This parameter may be
>>       present if the KDC stores the public keys of the nodes in the
>>       group and distributes them to the Client; it is useless to have
>>       here if the set of public keys of the members of the group is
>>       known in another way, e.g., it was provided by the AS.  Note that
>>       including this parameter may result in a large message size for
>>       the following response, which can be inconvenient for resource-
>>       constrained devices.
>>
>>       The parameter's value is either the CBOR simple value Null, or a
>>       non-empty CBOR array containing the following three elements.
>>
>>       -  The first element, namely 'inclusion_flag', encodes the CBOR
>>          simple value True.
>>
>> [CS: Maybe explained what this flag signifies, as I see it's true by
>> default for this handler, and may not be for other handlers (It's
>> explained
>> much later)]
>>
>>
>> ==>MT
>> Sure, will do. For example, some explanation can be moved up from the
>> later paragraph "Also note that the array of node identifiers ..."
>> <==
>>
> [CS: +1]
>
>> [SNIP]
>>
>> Palombini & Tiloca       Expires 13 January 2022               [Page 20]
>>
>> Internet-Draft  Key Provisioning for Group Communication       July 2021
>>
>>    [SNIP]
>>
>>
>>
>>    *  'control_uri', with value a full URI, encoded as a CBOR text
>>       string.  If 'control_uri' is supported by the Client, the Client
>>       acts as a CoAP server and hosts a resource at this specific URI.
>>       The KDC MAY use this URI to send CoAP requests to the Client
>>       (acting as CoAP server in this exchange), for example for
>>       individual provisioning of new keying material when performing a
>>       group rekeying (see Section 4.4), or to inform the Client of its
>>       removal from the group Section 5.
>>
>> [CS: So the above are KDC initiated? I think it needs to be clarified what
>> mechanisms are expected to be initiated by KDC. If this uri is not
>> present,
>> how does the KDC rekey?]
>>
>>
>> ==>MT
>> See the proposal in one of the comments at the beginning of the review.
>> Some key points are restated here:
>>
>> - Yes, the rekeying is initiated by the KDC (due to possibly different
>> reasons) and it's not something that can be requested. There will be a new
>> dedicated section on the possible approaches for the actual distribution.
>>
>> - An alternative to sending requests to the member's resource at
>> 'control_uri' is to rely on observe notifications. A group member not
>> wishing to observe must provide 'control_uri' in the Joining Request.
>> <==
>>
> [CS: OK - this is fine as proposed to be described.]
>
>>
>> [SNIP]
>>
>>    If an eligible public key for the Client is neither present in the
>>    'client_cred' field nor already stored, it is RECOMMENDED that the
>>    handler stops the processing and responds with a 4.00 (Bad Request)
>>    error message.  Applications profiles MAY define alternatives (OPT6).
>>
>>    If all the verifications above succeed, the handler performs the
>>    following actions.
>>
>>    *  The handler adds the Client to the list of current members of the
>>       group.
>>
>>    *  The handler assigns a name identifier NODENAME to the Client, and
>>       creates a sub-resource to /ace-group/GROUPNAME/ at the KDC (e.g.,
>>       "/ace-group/GROUPNAME/nodes/NODENAME").
>>
>>    *  The handler associates the node identifier NODENAME to the access
>>       token and the secure session for the Client.
>>
>>    *  If the KDC manages the group members' public keys:
>>
>>       -  The handler associates the retrieved Client's public key to the
>>          node identifier NODENAME and to the access token.
>>
>> [CS: shouldn't this be better  - (nodename, groupname, accesstoken,
>> public key),
>> or my assumption is invalid, one public key per client, not per group?]
>>
>>
>> ==>MT
>> Yes, you're right, and as you say, a public key is indeed possibly used
>> by the same client in multiple groups, as per the previous comment. So, the
>> same access token that possibly grants access to multiple groups might end
>> up being associated to the different involved public keys of the node.
>>
>> The missing link to groupname will be made explicit. That was the intent,
>> though perhaps carried out too concisely in the immediately following
>> paragraph here below, where the public key used by the client in the group
>> is added to the overall set of public keys in the group.
>> <==
>>
> [CS: OK]
>
>>
>>
>>
>>
>> [SNIP]
>>
>>
>>    *  'group_policies', with value a CBOR map, whose entries specify how
>>       the group handles specific management aspects.  These include, for
>>       instance, approaches to achieve synchronization of sequence
>>       numbers among group members.  The elements of this field are
>>       registered in the "ACE Groupcomm Policy" Registry.  This
>>       specification defines the three elements "Sequence Number
>>       Synchronization Method", "Key Update Check Interval" and
>>       "Expiration Delta", which are summarized in Figure 9.  Application
>>       profiles that build on this document MUST specify the exact
>>       content format and default value of included map entries (REQ17).
>>
>> [CS: So these MUST be specified, but I am still unclear whether Key
>> updates
>> are push/poll based, e.g., there are places where it reads like it is KDC
>> initiated.
>> So, key update check interval is 0, for example, if it's always
>> push-based?]
>>
>>
>> ==>MT
>> The inclusion of this parameter is optional in the Joining Response, but
>> profiles must specify details about its single information elements, for
>> the case when the parameter is included.
>>
>> On the group rekeying in general, please see earlier replies to comments
>> in this review.
>>
>> About "Key Update Check Interval", that's related to a poll-based action
>> for group members to perform, but it does not trigger a rekeying. By
>> polling the KDC at most every  Key Update Check Interval seconds, a group
>> member can regularly check whether it has the current group key material or
>> it has rather missed an earlier group rekeying.
>>
>> Note that the actual check is not necessarily a GET to
>> /ace-group/GROUPNAME or /ace-group/GROUPNAME/nodes/NODENAME , or at least
>> not right away. Instead, it can be a GET to /ace-group/num , followed by
>> querying one of the resources above only in case the response specifies a
>> key material version different than the version of the key material owned
>> by the group member.
>> <==
>> [CS: OK - I think this will be a lot more clear with the new explanations
>> on rekeying.]
>>
>>
>>
>> Palombini & Tiloca       Expires 13 January 2022               [Page 27]
>>
>> Internet-Draft  Key Provisioning for Group Communication       July 2021
>>
>>
>>   +--------------+-------+----------|---------------------|------------+
>>   |      Name    | CBOR  |   CBOR   |    Description      | Reference  |
>>   |              | label |   type   |                     |            |
>>   |--------------+-------+----------|---------------------|------------|
>>   | Sequence     | TBD1  | tstr/int | Method for a re-    | [[this     |
>>   | Number       |       |          | cipient node to     | document]] |
>>   | Synchroniza- |       |          | synchronize with    |            |
>>   | tion Method  |       |          | sequence numbers    |            |
>>   |              |       |          | of a sender node.   |            |
>>   |              |       |          | Its value is taken  |            |
>>   |              |       |          | from the 'Value'    |            |
>>   |              |       |          | column of the       |            |
>>   |              |       |          | Sequence Number     |            |
>>   |              |       |          | Synchronization     |            |
>>   |              |       |          | Method registry     |            |
>>   |              |       |          |                     |            |
>>   | Key Update   | TBD2  |   int    | Polling interval    | [[this     |
>>   | Check        |       |          | in seconds, to      | document]] |
>>   | Interval     |       |          | check for new       |            |
>>   |              |       |          | keying material at  |            |
>>   |              |       |          | the KDC             |            |
>>   |              |       |          |                     |            |
>>   | Expiration   | TBD3  |   uint   | Number of seconds   | [[this     |
>>   | Delta        |       |          | from 'exp' until    | document]] |
>>   |              |       |          | the specified UTC   |            |
>>   |              |       |          | date/time after     |            |
>>   |              |       |          | which group members |            |
>>   |              |       |          | MUST stop using the |            |
>>   |              |       |          | keying material to  |            |
>>   |              |       |          | verify incoming     |            |
>>   |              |       |          | messages.           |            |
>>   +--------------+-------+----------|---------------------|------------+
>>
>>                      Figure 9: ACE Groupcomm Policies
>>
>>    *  'mgt_key_material', encoded as a CBOR byte string and containing
>>       the administrative keying material to participate in the group
>>       rekeying performed by the KDC.  The application profile MUST
>>       define if this field is used, and if used then MUST specify the
>>       exact format and content which depend on the specific rekeying
>>       scheme used in the group.  If the usage of 'mgt_key_material' is
>>       indicated and its format defined for a specific key management
>>       scheme, that format must explicitly indicate the key management
>>       scheme itself.  If a new rekeying scheme is defined to be used for
>>       an existing 'mgt_key_material' in an existing profile, then that
>>       profile will have to be updated accordingly, especially with
>>       respect to the usage of 'mgt_key_material' related format and
>>       content (REQ22).
>>
>> [CS: so, there is an implicit admin group, which can receive this
>> information.
>> I assume this is pre-assigned, or is it in the token scope?]
>>
>>
>> ==>MT
>> This kind of admin group would work according to the specifically used
>> group key management scheme. Below I reuse some responses to two related
>> points from Göran's review [1][1reply]:
>>
>> * 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).
>>
>> * 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.
>>
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/ace/pr2gBhvqy9j8AfUdQVTZLwamXac/
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Face%2Fpr2gBhvqy9j8AfUdQVTZLwamXac%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524520321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6B23EfdqDXlQ9rm2hP7SuPuC8624jC8mAIw2BLh31Zo%3D&reserved=0>
>>
>> [1reply]
>> https://mailarchive.ietf.org/arch/msg/ace/dEU04pB3u-iYNBwSlfjJaqkEvgo/
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Face%2FdEU04pB3u-iYNBwSlfjJaqkEvgo%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524530272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xYmUL5Sw4Zkx3nUnDyahSX%2BT%2FZ8YMlTYMqwUAWUCpsE%3D&reserved=0>
>>
>>
>> Furthermore, the token scope does not need to cover this. The "admin
>> group" associated to the administrative key material is exclusively tight
>> to the main security group to be rekeyed by using such key material. Also,
>> the KDC as such is the entity authorized and capable to rekey the main
>> security group, while there is no additional authorization needed to allow
>> group members to participate in a rekeying instance.
>> <==
>> [CS: This sounds all fine.]
>>
>>
>>
>> 4.1.3.1.  FETCH Handler
>>
>>    The FETCH handler receives identifiers of group members for the group
>>    identified by GROUPNAME and returns the public keys of such group
>>    members.
>>
>>    The handler expects a request with payload formatted as a CBOR map,
>>    that MUST contain the following fields:
>>
>>    *  'get_pub_keys', whose value is encoded as in Section 4.1.2.1 with
>>       the following modification:
>>
>>       -  The element 'inclusion_flag' encodes the CBOR simple value True
>>          if the third element 'id_filter' specifies an empty CBOR array,
>>          or if the Client wishes to receive the public keys of the nodes
>>          having their node identifier specified in 'id_filter'.
>>          Instead, this element encodes the CBOR simple value False if
>>          the Client wishes to receive the public keys of the nodes not
>>          having the node identifiers specified in the third element
>>          'id_filter'.
>>
>> [CS: so, to clarify, id_filter becomes an exclusion list if
>> inclusion_flag is false?
>> if it is true, and id_filter is not empty, it returns the pub_keys in the
>> list, i.e.,
>> inclusion list? (Reading further, this seems correct. It may be explained
>> earlier when
>> inclusion_flag is first introduced]
>>
>>
>> ==>MT
>> Yes, that's a correct summary. We will fully define the meaning of
>> 'inclusion_flag' when introducing it in Section 4.1.2.1.
>> <==
>>
> [CS: +1]
>
>>
>>
>>       -  The array 'role_filter' may be empty, if the Client does not
>>          wish to filter the requested public keys based on the roles of
>>          the group members.
>>
>>       -  The array 'id_filter' contains zero or more node identifiers of
>>          group members, for the group identified by GROUPNAME.  The
>>          Client indicates that it wishes to receive the public keys of
>>          the nodes having or not having these node identifiers, in case
>>          the 'inclusion_flag' parameter encodes the CBOR simple value
>>          True or False, respectively.  The array may be empty, if the
>>          Client does not wish to filter the requested public keys based
>>          on the node identifiers of the group members.
>>
>>    Note that, in case both the 'role_filter' array and the 'id_filter'
>>    array are not empty:
>>
>>    *  If the 'inclusion_flag' encodes the CBOR simple value True, the
>>       handler returns the public keys of group members whose roles match
>>       with 'role_filter' and/or having their node identifier specified
>>       in 'id_filter'.
>>
>>    *  If the 'inclusion_flag' encodes the CBOR simple value False, the
>>       handler returns the public keys of group members whose roles match
>>       with 'role_filter' and, at the same time, not having their node
>>       identifier specified in 'id_filter'.
>>
>> Palombini & Tiloca       Expires 13 January 2022               [Page 30]
>>
>> Internet-Draft  Key Provisioning for Group Communication       July 2021
>>
>>
>>    Finally, as mentioned in Section 4.1.2.1, both arrays 'role_filter'
>>    and 'id_filter' MUST NOT be both empty.
>>
>> [CS: Why? Can't I ask to get all the public keys of nodes in this group,
>> which has a public key? (I see that this is a GET request, on reading
>> further,
>> a forward pointer here?)]
>>
>>
>> ==>MT
>> Yes, we'll include a forward pointer to the GET handler for retrieving
>> all public keys.
>> <==
>>
> [CS: Thanks]
>
>>
>>
>>   [SNIP]
>>
>>    The handler MAY enforce one of the following policies, in order to
>>    handle possible node identifiers that are included in the 'id_filter'
>>    element of the 'get_pub_keys' parameter of the request but are not
>>    associated to any current group member.  Such a policy MUST be
>>    specified by the application profile (REQ16).
>>
>>    *  The KDC silently ignores those node identifiers.
>>
>>    *  The KDC retains public keys of group members for a given amount of
>>       time after their leaving, before discarding them.  As long as such
>>       public keys are retained, the KDC provides them to a requesting
>>       Client.
>>
>> [CS: I think this is a wider policy e.g., how long does the KDC retain
>> any information about the historical group members?]
>>
>>
>> ==>MT
>> If I understand correctly, you'd like a policy of this kind to explicitly
>> define also how the retention time is determined, possibly on a per-node
>> basis. Correct?
>> <==
>>
> [CS: Yes, I suggest that KDC says what that "given amount of time" is - it
> could be uniform across group members, or per-node basis.]
>
>
> ==>MT2
> The paragraph describing the second policy has been expanded with the
> following new sentence.
>
> "If the KDC adopts this policy, the application profile MUST also specify
> the amount of time during which the KDC retains the public key of a former
> group member after its leaving, possibly according to a per-member basis."
> <==
>
>
>>
>> 4.1.5.  ace-group/GROUPNAME/num
>>
>>    This resource implements a GET handler.
>>
>> 4.1.5.1.  GET Handler
>>
>>    The handler expects a GET request.
>>
>>  [SNIP]
>> [CS: In general, in the SNIPPED text above, there is much repetition
>> across different sections, in terms of format expected, group membership
>> access control etc. Could that be said only once to apply to all
>> resources, or
>> all operations within a resource?]
>>
>>
>> ==>MT
>> Hopefully so :-)
>>
>> I'll try to identify a clear "boilerplate" with actions common to all
>> handlers to include once and for all.
>> <==
>>
> [CS: That would be great]
>
>>
>>
>> [SNIP]
>>
>> 4.1.6.  ace-group/GROUPNAME/nodes/NODENAME
>>
>>    This resource implements GET, PUT and DELETE handlers.
>>
>> 4.1.6.1.  PUT Handler
>> The PUT handler is used to get the KDC to produce and return
>>    individual keying material to protect outgoing messages for the node
>>    (identified by NODENAME) for the group identified by GROUPNAME.
>>    Application profiles MAY also use this handler to rekey the whole
>>    group.  It is up to the application profiles to specify if this
>>    handler supports renewal of individual keying material, renewal of
>>    the group keying material or both (OPT8).
>>
>> [CS: I am a bit puzzled that something that potentially is rekeying
>> the whole group is done under NODENAME resource.
>> On the other hand, POSTing the GROUPNAME adds a node to the group rather
>> than rekeying
>> the group. I would expect POSTing to ace-group/GROUPNAME/nodes would add
>> a node instead.
>> ]
>>
>>
>> ==>MT
>> This may require more explicit clarifications in the draft.
>>
>> This particular PUT request is sent by the group member with name
>> NODENAME, say node X, to ask for new individual keying material, as
>> abstractly put in this draft. A concrete example is in
>> ace-key-groucomm-oscore , where the group member asks for a new OSCORE
>> Sender ID.
>>
>> Following this PUT request, the KDC can decide to go for one of the
>> following options. What influences the KDC decision is really
>> application/context specific, and an application profile may give more
>> details as appropriate.
>>
>> * Only assigning new individual keying material to the group member X,
>> including it in the response to the PUT request.
>>
>> * Rekeying the whole group. For the sake of efficiency, the KDC can
>> provide the new group key material to the group member X in the response to
>> the PUT request.
>>
>> * Doing both things above, i.e. first providing the group member X with
>> new individual keying material in the response to the PUT request, and then
>> also perform a full group rekeying.
>>
>>
>> So, yes, this PUT request can potentially trigger a whole group rekeying
>> as a side effect, depending on what the KDC decides exactly to do. However,
>> it is not what the group member X is asking for, which is not its
>> prerogative as mentioned in previous comments.
>>
>> On the final part of the comment:
>>
>> * POSTing to ace-group/GROUPNAME does add a node to the group but does
>> not necessarily result in rekeying the group. That depends on the key
>> management policies adopted by the KDC for that group. A group rekeying
>> would especially happen if the application requires to enforce backward
>> security.
>>
>> * Early design discussions resulted in ace-group/GROUPNAME/nodes as just
>> the "root" resource (with no handlers) for the node-based sub-resources
>> ace-group/GROUPNAME/nodes/NODENAME, each of which is added only once when
>> the corresponding node is added as group member.
>> <==
>>
> [CS: OK, yes putting clarifications in the draft would be helpful on these
> choices.]
>
>>
>>
>>     [SNIP]
>>
>>    *  Can act as a publisher in a pub-sub scenario, and update the
>>       keying material by publishing on a specific topic on a broker,
>>       which all the members of the group are subscribed to.
>>
>> [CS: This is not a good scenario for pub-sub, as the broker should not
>> know the
>> keys. The whole idea of the pub-sub profile is the protect the content
>> of the messages from the broker. That means these keying materials should
>> be
>> encrypted, and hence, then, the distribution of that keying material ...
>> becomes a recursive problem.]
>>
>>
>> ==>MT
>> Before dismissing this option, let's think a bit more about it --- This
>> can possibly become a separate thread.
>>
>> This way of rekeying the main security group is not referring exactly to
>> the pub-sub profile of ACE to do that. It is referring only to a pub-sub
>> scenario where, for the sake of rekeying the main security group, the KDC
>> is a publisher and all the group members are subscribers of a "rekeying
>> topic".
>>
>
> [CS: OK, it want's clear to me what you meant by "a broker" in that
> paragraph. I understood it as the Broker for pub-sub communication, which
> the Clients engage in the first place. If the KDC is going to be a broker
> (or a published as you explain below) use pub-sub communication to send out
> keys, I don't have a problem with this. ]
>
>
>>
>> It is good that the broker does not see the exchanged messages. These
>> would be protected by the KDC at the application level, using additional
>> administrative key material shared between the KDC and the members of the
>> main security group. Such key material can be provided in the
>> 'mgt_key_material' parameter of a Joining Response, and depends on the
>> exact group key management scheme used.
>>
>> Since the KDC is acting as publisher, you would need to involve also the
>> KDC's public key. The best option is probably to provide it in the Joining
>> Response, using the dedicated parameter 'kdc_cred' recently introduced in
>> ace-key-groupcomm-oscore (see its Section 6.4), as required for other
>> reasons in the Group OSCORE case.
>>
>>
>> Actually, I believe the pub-sub profile of ACE may assist for this case
>> too. The KDC has to obtain from the AS a token and upload it to the broker
>> as a proof of authorization for publishing in the "rekeying topic" to rekey
>> a particular security group. Again, the administrative key material to
>> protect the rekeying messages is generated by the KDC itself, which
>> provides it to the members of the main security group in the respective
>> Joining Responses, when they join that security group.
>>
>> This is a just simple example with one single "rekeying topic" to deliver
>> a rekeying message to all the group members of the main security group. If
>> a rekeying message has to target only a subset of the group members, you
>> would need a respective sub-topic. For instance, the key hierarchy used by
>> the group rekeying scheme can be mapped to a hierarchy of rekeying topics,
>> all used to rekey the main security group.
>>
>> Does it make sense?
>> <==
>>
> [CS: Yes, this may work. But then the "administrative key" for rekeying
> topic, isn't that rolled over? And then how is that "re-keyed"?]
>
>
> ==>MT2
> Thinking of advanced rekeying schemes and regardless the method used to
> deliver the rekeying messages (i.e., pub-sub or multicast), the roll-over
> of the administrative keying material is something that the group rekeying
> scheme itself takes care of, through the sent rekeying messages. Actually,
> such a roll-over occurs every time a group rekeying is performed upon the
> leaving of group members to be excluded from future communication in the
> group.
>
> At a high level, each group member owns only a subset of the overall
> administrative keying material, obtained upon joining the group. Then, when
> a group rekeying occurs:
>
> * Each rekeying message is protected by using a (most convenient) key from
> the administrative keying material such that: i) the used key is not owned
> by any node leaving the group, i.e. the key is safe to use and doesn't have
> to be renewed; and i) the used key is owned by all the group members
> targeted by the rekeying message, that indeed have to be provided with new
> communication keying material.
>
> * Each rekeying message includes not only the new communication keying
> material intended to all the rekeyed group members, but also any new
> administrative keys that: i) are pertaining to and supposed to be owned by
> the group members targeted by the rekeying message; and i) had to be
> updated since leaving group members own the previous version.
>
> Details are really dependent of the specific rekeying scheme used in the
> group. At least at a high level, this should be clearer now from the
> explanations about group rekeying given in the new Section 6 "Group
> Rekeying Process".
>
> THE END
> <==
>
>
>>
>> 5.  Removal of a Node from the Group
>>
>>    [SNIP]
>>
>>
>>    Furthermore, in case of forced eviction, the KDC removes the public
>>    key of the evicted node if the KDC keep tracks of that, and possibly
>>    removes the evicted node from the list of observers of the resource
>>    at ace-group/GROUPNAME (if observable).
>>
>> [CS: Why only "possibly"?]
>>
>>
>> ==>MT
>> It was intended to mean "in case the evicted node was an observer at
>> all". We'll make it explicit; if the evicted node is an observer, it has to
>> be removed from the list of observers.
>> <==
>>
> [CS: OK]
>
>>
>>
>>  [SNIP]
>>
>>
>> 6.  Extended Scope Format
>>
>>    [SNIP]
>>
>>    The value of the 'scope' claim following the extended format is
>>    composed as follows.  Given the original scope using a semantics SEM
>>    and encoded as a CBOR byte string, the corresponding extended scope
>>    is encoded as a tagged CBOR byte string, wrapping a CBOR sequence
>>    [RFC8742] of two elements.  In particular:
>>
>>    *  The first element of the sequence is a CBOR integer, and
>>       identifies the semantics SEM used for this scope.  The value of
>>       this element has to be taken from the "Value" column of the "ACE
>>       Scope Semantics" registry defined in Section 10.12 of this
>>       specification.
>>
>>
>>
>> Palombini & Tiloca       Expires 13 January 2022               [Page 52]
>>
>> Internet-Draft  Key Provisioning for Group Communication       July 2021
>>
>>
>>       When defining a new semantics for a binary scope, it is up to the
>>       applications and application profiles to define and register the
>>       corresponding integer identifier (REQ24).
>>
>>    *  The second element of the sequence is the original scope using the
>>       semantics SEM, encoded as a CBOR byte string.
>>
>>    Finally, the CBOR byte string wrapping the CBOR sequence is tagged,
>>    and identified by the CBOR tag TBD_TAG "ACE Extended Scope Format",
>>    defined in Section 10.11 of this specification.
>>
>>    The resulting tagged CBOR byte string is used as value of the 'scope'
>>    claim of the access token.
>>
>>    The usage of the extended scope format is not limited to application
>>    profiles of this specification or to applications based on group
>>    communication.  Rather, it is generally applicable to any application
>>    and application profile where access control information in the
>>    access token is expressed as a binary encoded scope.
>>
>> [CS: Then should it be defined here in this profile or somewhere else?]
>>
>>
>> ==>MT
>> This document is defining the general extensibility method, as agreed to
>> have it exactly in this document. Other specifications that want to take
>> advantage of the extended format have to define some specific details.
>>
>> For instance, Section 4.2 of ace-key-groupcomm-oscore defines a
>> particular integer value to prepend to the CBOR sequence if the AS actually
>> uses the extended scope format. This reflects the specific scope semantics
>> defined in that application profile.
>> <==
>>
> [CS: OK]
>
>> 9.  Security Considerations
>>
>>   [SNIP]
>>
>>    That is, the KDC may not rekey the group at every membership change,
>>    for instance if members' joining and leaving occur frequently and
>>    performing a group rekeying takes too long.  The KDC may rekey the
>>    group after a minimum number of group members have joined or left
>>    within a given time interval, or after maximum amount of time since
>>    the last rekeying was completed, or yet during predictable network
>>    inactivity periods.
>>
>>    However, this would result in the KDC not constantly preserving
>>    backward and forward security.  Newly joining group members could be
>>    able to access the keying material used before their joining, and
>>    thus could access past group communications.  Also, until the KDC
>>    performs a group rekeying, the newly leaving nodes would still be
>>    able to access upcoming group communications that are protected with
>>    the keying material that has not yet been updated.
>>
>> [CS: I think the minimum number of group members should be just 1 if we
>> are talking about secure group communication]
>>
>>
>> ==>MT
>> Yes, it's still about joining a group with group key material to share
>> with next nodes to come. It will be said explicit.
>>
>> In particular, if the key material is revoked upon nodes' leaving, it has
>> to be also when the number of members goes from 1 to 0. Then new group key
>> material has to be provided to the next new member joining the group.
>> <==
>> [CS: OK]
>>
>>
>>   [SNIP]
>> 9.1.  Update of Keying Material
>>
>>    A group member can receive a message shortly after the group has been
>>    rekeyed, and new keying material has been distributed by the KDC.  In
>>    the following two cases, this may result in misaligned keying
>>    material between the group members.
>>
>>    In the first case, the sender protects a message using the old keying
>>    material.  However, the recipient receives the message after having
>>    received the new keying material, hence not being able to correctly
>>    process it.  A possible way to ameliorate this issue is to preserve
>>    the old, recent, keying material for a maximum amount of time defined
>>    by the application.  By doing so, the recipient can still try to
>>    process the received message using the old retained keying material.
>>    Note that a former (compromised) group member can take advantage of
>>
>>
>>
>> Palombini & Tiloca       Expires 13 January 2022               [Page 57]
>>
>> Internet-Draft  Key Provisioning for Group Communication       July 2021
>>
>>
>>    this by sending messages protected with the old retained keying
>>    material.  Therefore, a conservative application policy should not
>>    admit the storage of old keying material.
>>
>> [CS: Could it be an option to resend the message with the new keying
>> material? if the
>> rekeying happened within a window]
>>
>>
>> ==>MT
>> That's most likely what happens once the sender has also obtained the
>> latest group key material (either by actually receiving the rekeying
>> messages, of by asking for it to the KDC if it realizes it has missed a
>> rekeying). It can be added here.
>> <==
>>
> [CS: OK]
>
>>
>>
>>
>> [SNIP]
>>
>>
>> 10.  IANA Considerations
>>
>>    This document has the following actions for IANA.
>>
>> 10.1.  Media Type Registrations
>>
>>    [SNIP]
>>
>>
>>
>>
>> Appendix B.  Extensibility for Future COSE Algorithms
>>
>> [CS: Why not just use this format instead of reformatting sign_info_entry
>> In section 3.3.1]
>>
>>
>> ==>MT
>> Simply for the sake of readability. Considering that today's COSE
>> algorithms have only one capability (and always Key Type), for the time
>> being it is sufficient for an implementer to just refer to the simpler
>> format in Section 3.3.1.
>>
>> In other words, it was good to define the more general format as
>> future-ready, but it's not strictly necessary to be aware of it when
>> implementing a KDC today. Hence the preference to have it in Appendix B
>> rather than burdening Section 3.3.1.
>> <==
>> [CS: OK]
>>
>> [THE END]
>>
>>
>
>
>> On Tue, Aug 24, 2021 at 5:52 PM Göran Selander <goran.selander=
>> [e-mail]> wrote:
>>
>>> 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 [e-mail]" <
>>> [e-mail] on behalf of [e-mail]> 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
>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D08daa3fb-57419b19-08dae360-86073b36ea28-572fafc3ef6c5ed5%26q%3D1%26e%3Dfd87b927-3fdc-4d5a-ab71-6248ac68bf5d%26u%3Dhttps%253A%252F%252Fgithub.com%252Face-wg%252Face-key-groupcomm&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524530272%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Y33GOePFP%2FOBANVr6yh1mFy5wqcuoaGI6IX1DB5ZYd4%3D&reserved=0>
>>> .
>>>
>>>
>>>     The IETF datatracker status page for this draft is:
>>>     https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-key-groupcomm%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524540226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5v2E9dFrqpqzEO85INXeu18JftULOHMYkn2VDS%2FXPQs%3D&reserved=0>
>>>
>>>     There is also an htmlized version available at:
>>>
>>> https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-13
>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-key-groupcomm-13&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524540226%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=2PxALjTtXrp4IaAecxKGO22HLa%2FdT773uigl%2F2vYR7s%3D&reserved=0>
>>>
>>>     A diff from the previous version is available at:
>>>     https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-13
>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-key-groupcomm-13&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524550176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6g5kMubLln4PrEzkicJjyTsYPaS3YDjtXBi6xGtlSNc%3D&reserved=0>
>>>
>>>
>>>     Internet-Drafts are also available by anonymous FTP at:
>>>     ftp://ftp.ietf.org/internet-drafts/
>>> <https://eur02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524550176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BZ1yEjMrTBkHJuBDd3Bs%2FDiYxzA6sYBUiNqM9da2FWk%3D&reserved=0>
>>>
>>>
>>>     _______________________________________________
>>>     Ace mailing list
>>>     [e-mail]
>>>     https://www.ietf.org/mailman/listinfo/ace
>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524560136%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4TeWA4eikq7LOEergFQdxtD8x0b4fBokuwKK2tamCEo%3D&reserved=0>
>>>
>>>
>>> _______________________________________________
>>> Ace mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ace
>>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524560136%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4TeWA4eikq7LOEergFQdxtD8x0b4fBokuwKK2tamCEo%3D&reserved=0>
>>>
>>
>> _______________________________________________
>> Ace mailing [e-mail]://www.ietf.org/mailman/listinfo/ace <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524570098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ITTUNipdngkdQFXm9a4aoxmTAMjy5YiMyuULwVjQhIc%3D&reserved=0>
>>
>>
>> --
>> Marco Tiloca
>> Ph.D., Senior Researcher
>>
>> Division: Digital System
>> Department: Computer Science
>> Unit: Cybersecurity
>>
>> RISE Research Institutes of Swedenhttps://www.ri.se <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ri.se%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cb6979934b9d24425886208d98cccfd8c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637695635524570098%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wEPZPfihg07JeU1pROw7lm%2BHEFAE%2BDop4tpECp3G5SI%3D&reserved=0>
>>
>> Phone: [phone]
>> Isafjordsgatan 22 / Kistagången 16
>> SE-164 40 Kista (Sweden)
>>
>>
> _______________________________________________
> Ace mailing [e-mail]://www.ietf.org/mailman/listinfo/ace
>
>
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>
> Division: Digital System
> Department: Computer Science
> Unit: Cybersecurity
>
> RISE Research Institutes of Swedenhttps://www.ri.se
>
> Phone: [phone]
> Isafjordsgatan 22 / Kistagången 16
> SE-164 40 Kista (Sweden)
>
>