From 27dbbf5511dcacddd11257ba7e3a62a5fcac7d8e Mon Sep 17 00:00:00 2001 From: ID Bot Date: Fri, 20 Sep 2024 07:39:26 +0000 Subject: [PATCH] Script updating gh-pages from 8580b48. [ci skip] --- draft-ietf-core-oscore-groupcomm.html | 43 +++++++-------- draft-ietf-core-oscore-groupcomm.txt | 77 ++++++++++++++------------- 2 files changed, 61 insertions(+), 59 deletions(-) diff --git a/draft-ietf-core-oscore-groupcomm.html b/draft-ietf-core-oscore-groupcomm.html index a89e804..d85330b 100644 --- a/draft-ietf-core-oscore-groupcomm.html +++ b/draft-ietf-core-oscore-groupcomm.html @@ -1617,7 +1617,7 @@

Group: a set of endpoints that share group keying material and security parameters (Common Context, see Section 2). That is, unless otherwise specified, the term group used in this document refers to a "security group" (see Section 2.1 of [I-D.ietf-core-groupcomm-bis]), not to be confused with "CoAP group" or "application group".

  • -

    Group Manager: an entity responsible for a group, neither required to be an actual group member nor to take part in the group communication. The responsibilities of the Group Manager are listed in Section 3.4.

    +

    Group Manager: an entity responsible for a group, neither required to be an actual group member nor to take part in the group communication. The operations of the Group Manager are defined in Section 3 and its responsibilities are listed in Section 3.4.

  • Silent server: a member of a group that performs only group mode processing on incoming requests and never sends responses protected with Group OSCORE. For CoAP group communications, requests are normally sent without necessarily expecting a response. A silent server may send unprotected responses, as error responses reporting a Group OSCORE error.

    @@ -1653,7 +1653,7 @@

    2. Security Context

    This document refers to a group as a set of endpoints sharing keying material and security parameters for executing the Group OSCORE protocol, see Section 1.1. All members of a group maintain a Security Context as defined in this section.

    -

    How the Security Context is established by the group members is out of scope for this document, but if there is more than one Security Context applicable to a message, then the endpoints MUST be able to tell which Security Context was latest established. How to manage information about the group is described in terms of a Group Manager (see Section 3).

    +

    How the Security Context is established by the group members is out of scope for this document, but if there is more than one Security Context applicable to a message, then the endpoints MUST be able to tell which Security Context was latest established. The management of information about the group (i.e., identifiers, OSCORE input parameters, and keying material) is described in terms of a Group Manager (see Section 3).

    An endpoint of the group may use the group mode (see Section 8), the pairwise mode (see Section 9), or both, depending on the modes it supports and on the parameters of the Security Context. The Security Context of Group OSCORE extends the OSCORE Security Context defined in Section 3 of [RFC8613] as follows (see Figure 1).

      @@ -2111,7 +2111,7 @@

      2.6.3.1. New Sender ID for the Endpoint
      -

      The Group Manager may assign a new Sender ID to an endpoint, while leaving the Gid, Master Secret and Master Salt unchanged in the group. In this case, the Group Manager MUST assign a Sender ID that has not been used in the group since the latest time when the current Gid value was assigned to the group (see Section 3.2).

      +

      The Group Manager may assign a new Sender ID to an endpoint, while leaving the Gid, Master Secret, and Master Salt unchanged in the group. In this case, the Group Manager MUST assign a Sender ID that has not been used in the group since the latest time when the current Gid value was assigned to the group (see Section 3.2).

      Having retrieved the new Sender ID, and potentially other missing data of the immutable Security Context, the endpoint can derive a new Sender Context (see Section 2.2). When doing so, the endpoint resets the Sender Sequence Number in its Sender Context to 0, and derives a new Sender Key. This is in turn used to possibly derive new Pairwise Sender Keys.

      From then on, the endpoint MUST use its latest installed Sender Context to protect outgoing messages.

      The assignment of a new Sender ID may be the result of different processes. The endpoint may request a new Sender ID, e.g., because of the exhaustion of the Sender Sequence Number space (see Section 2.6.2). An endpoint may request to re-join the group, e.g., because of losing its mutable Security Context (see Section 2.6.1), and is provided with a new Sender ID together with the latest immutable Security Context.

      @@ -2173,10 +2173,11 @@

      3. The Group Manager

      -

      As with OSCORE, endpoints communicating with Group OSCORE need to establish the relevant Security Context. Group OSCORE endpoints need to acquire OSCORE input parameters, information about the group(s) and about other endpoints in the group(s). This document is based on the existence of an entity called Group Manager that is responsible for the group, but it does not mandate how the Group Manager interacts with the group members. The list of responsibilities of the Group Manager is compiled in Section 3.4.

      -

      The Group Manager assigns unique Group Identifiers (Gids) to the groups under its control. Within each of such groups, the Group Manager assigns unique Sender IDs (and thus Recipient IDs) to the respective group members. The maximum length of Sender IDs depends on the length of the nonce for the algorithms used in the group (see Section 2.2).

      -

      According to a hierarchical approach, the Gid value assigned to a group is associated with a dedicated space for the values of Sender ID and Recipient ID of the members of that group. When an endpoint (re-)joins a group, it is provided with the current Gid to use in the group. The Group Manager also assigns an integer Key Generation Number counter to each of its groups, identifying the current version of the keying material used in that group. Further details about identifiers and keys are provided in Section 3.2.

      -

      The Group Manager maintains records of the authentication credentials of endpoints in a group, and provides information about the group and its members to other group members (see Section 3.1), and to external entities with a specific role (see Section 3.3).

      +

      As with OSCORE, endpoints communicating with Group OSCORE need to establish the relevant Security Context. Group OSCORE endpoints need to acquire OSCORE input parameters, information about the group(s) and about other endpoints in the group(s).

      +

      This document is based on the existence of an entity called Group Manager that is responsible for the group, but it does not mandate how the Group Manager interacts with the group members. The list of responsibilities of the Group Manager is compiled in Section 3.4.

      +

      The Group Manager assigns unique Group Identifiers (Gids) to the groups under its control. Within each of such groups, the Group Manager assigns unique Sender IDs (and thus Recipient IDs) to the respective group members. The maximum length of Sender IDs depends on the length of the nonce for the algorithms used in the group (see Section 2.2).

      +

      According to a hierarchical approach, the Gid value assigned to a group is associated with a dedicated space for the values of Sender ID and Recipient ID of the members of that group. When an endpoint (re-)joins a group, it is provided with the current Gid to use in the group. The Group Manager also assigns an integer Key Generation Number counter to each of its groups, identifying the current version of the keying material used in that group. Further details about identifiers and keys are provided in Section 3.2.

      +

      The Group Manager maintains records of the authentication credentials of endpoints in a group, and provides information about the group and its members to other group members (see Section 3.1), and to external entities with a specific role (see Section 3.3).

      @@ -2200,9 +2201,9 @@

      In order to establish a new Security Context for a group, the Group Manager MUST generate and assign to the group a new Group Identifier (Gid) and a new value for the Master Secret parameter. When doing so, a new value for the Master Salt parameter MAY also be generated and assigned to the group. When establishing the new Security Context, the Group Manager should preserve the current value of the Sender ID of each group member.

      The specific group key management scheme used to distribute new keying material is out of the scope of this document. A simple group key management scheme is defined in [I-D.ietf-ace-key-groupcomm-oscore]. When possible, the delivery of rekeying messages should use a reliable transport, in order to reduce chances of group members missing a rekeying instance.

      The set of group members should not be assumed as fixed, i.e., the group membership is subject to changes, possibly on a frequent basis.

      -

      The Group Manager MUST rekey the group without undue delay in case one or more endpoints leave the group. An endpoint may leave the group at own initiative, or may be evicted from the group by the Group Manager, e.g., in case an endpoint is compromised, or is suspected to be compromised. In either case, rekeying the group excludes such endpoints from future communications in the group, and thus preserves forward security. If a network node is compromised or suspected to be compromised, the Group Manager MUST evict from the group all the endpoints hosted by that node that are member of the group and rekey the group accordingly.

      +

      The Group Manager MUST rekey the group without undue delay in case one or more endpoints leave the group. An endpoint may leave the group at own initiative, or may be evicted from the group by the Group Manager, e.g., in case the endpoint is compromised, or is suspected to be compromised. In either case, rekeying the group excludes such endpoints from future communications in the group, and thus preserves forward security. If a network node is compromised or suspected to be compromised, the Group Manager MUST evict from the group all the endpoints hosted by that node that are member of the group and rekey the group accordingly.

      If required by the application, the Group Manager MUST rekey the group also before one or more new joining endpoints are added to the group, thus preserving backward security.

      -

      Separately for each group, the value of the Key Generation Number increases by one each time the Group Manager distributes new keying material to that group (see Section 3.2).

      +

      Separately for each group, the value of the Key Generation Number increases by one each time the Group Manager distributes new keying material to that group (see below).

      The establishment of the new Security Context for the group takes the following steps.

      1. @@ -2272,11 +2273,11 @@

      2. The group member re-joins the group with the same roles it currently has in the group, and, during the re-joining process, it asks the Group Manager for the authentication credentials of all the current group members.

        -Then, given Z, the set of authentication credentials received from the Group Manager, the group member removes every authentication credential which is not in Z from its list of group members' authentication credentials used in the group, and deletes each of its Recipient Contexts used in the group that does not include any of the authentication credentials in Z.

        +Then, given Z the set of authentication credentials received from the Group Manager, the group member removes every authentication credential which is not in Z from its list of group members' authentication credentials used in the group, and deletes each of its Recipient Contexts used in the group that does not include any of the authentication credentials in Z.

    By removing authentication credentials and deleting Recipient Contexts associated with stale Sender IDs, it is ensured that a recipient endpoint storing the latest group keying material does not store the authentication credentials of sender endpoints that are not current group members. This in turn allows group members to rely on stored authentication credentials to confidently assert the group membership of sender endpoints, when receiving incoming messages protected in group mode (see Section 8).

    -

    Such a strictness in managing the authentication credentials and Recipient Contexts associated with other group members is required for two reasons. First, as further discussed in Section 13.1, it ensures that the group mode can be used securely, even in a group where the Group Encryption Algorithm does not provide integrity protection (see Section 2.1.7) and external signature checkers are used (see Section 8.5). Second, it ensures that the wrong (old) authentication credential associated with a group member A is never used with a sender ID that used to be associated with A and has been later issued to a different group member B (see Section 3.2.1.2), thus preventing the need to recover from an identity mix-up.

    +

    Such a strictness in managing the authentication credentials and Recipient Contexts associated with other group members is required for two reasons. First, as further discussed in Section 13.1, it ensures that the group mode can be used securely, even in a group where the Group Encryption Algorithm does not provide integrity protection (see Section 2.1.7) and external signature checkers are used (see Section 8.5). Second, it ensures that the wrong (old) authentication credential associated with a group member A is never used with a Sender ID that used to be associated with A and has been later issued to a different group member B (see Section 3.2.1.2), thus preventing the need to recover from an identity mix-up.

    @@ -3057,7 +3058,7 @@

    8.3. Protecting the Response

    When using the group mode to protect a response, a server SHALL proceed as described in Section 8.3 of [RFC8613], with the following modifications.

    -

    Note that the server always protects a response with the Sender Context from its latest Security Context, and that establishing a new Security Context resets the Sender Sequence Number to 0 (see Section 3.2).

    +

    Note that the server always protects a response with the Sender Context from its latest Security Context, and that establishing a new Security Context resets the Sender Sequence Number to 0 (see Section 2.6.3.1 and Section 2.6.3.2).

    • In step 2, the Additional Authenticated Data is modified as described in Section 4 of this document.

      @@ -3243,7 +3244,7 @@

      The possible use of the pairwise mode is indicated by the Group Manager as part of the group data provided to candidate group members when joining the group, according to which the parameters AEAD Algorithm and Pairwise Key Agreement Algorithm in the Security Context are set (see Section 2).

      The pairwise mode takes advantage of an existing Security Context to establish keying material shared exclusively with any other member. For encryption and decryption operations in pairwise mode, the AEAD Algorithm from the Common Context is used (see Section 2.1.1).

      In order to use the pairwise mode in a group where the group mode is also used (i.e., Group Encryption Algorithm and Signature Algorithm in the Security Context are set), the signature scheme of the group mode MUST support a combined signature and encryption scheme. For example, this can rely on signing operations using ECDSA, and encryption operations using AES-CCM with keying material derived through ECDH.

      -

      The pairwise mode does not support external verifiers of source authentication and message integrity like the group mode does (see Section 8.5).

      +

      The pairwise mode does not support external verifiers of source authentication and message integrity like the group mode does, e.g., for external signature checkers (see Section 8.5).

      An endpoint implementing only a silent server does not support the pairwise mode.

      Endpoints using the CoAP Echo Option [RFC9175] in a group where the AEAD Algorithm and Pairwise Key Agreement Algorithm are set MUST support the pairwise mode. This prevents the attack described in Section 13.9, which leverages requests sent over unicast to a single group member and protected in group mode.

      The pairwise mode cannot be used to protect messages intended for multiple recipients. In fact, the keying material used for the pairwise mode is shared only between two endpoints.

      @@ -3330,7 +3331,7 @@

      What is specified in Section 8.3 of this document holds with respect to the following points.

      • -

        The protection of a response when using a different Security Context than the one used to protect the corresponding request. That is, the server always protects a response with the Sender Context from its latest Security Context, and establishing a new Security Context resets the Sender Sequence Number to 0 (see Section 3.2).

        +

        The protection of a response when using a different Security Context than the one used to verify the corresponding request (see Section 3.2). That is, the server always protects a response with the Sender Context from its latest Security Context, and establishing a new Security Context resets the Sender Sequence Number to 0 (see Section 2.6.3.1 and Section 2.6.3.2).

      • The use of the stored value of the 'kid' and 'kid context' parameters, if the server intends to reply with multiple responses within the long exchange established by the request.

        @@ -3592,7 +3593,7 @@

        The proof for uniqueness of (key, nonce) pairs in Appendix D.4 of [RFC8613] is also valid in group communication scenarios. That is, given an OSCORE group:

        • -

          Uniqueness of Sender IDs within the group is enforced by the Group Manager. In fact, from the moment when a Gid is assigned to a group until the moment when a new Gid is assigned to that same group, the Group Manager does not reassign a Sender ID within the group (see Section 3.2).

          +

          Uniqueness of Sender IDs within the group is enforced by the Group Manager. In fact, from the moment when a Gid is assigned to a group until the moment when a new Gid is assigned to that same group, the Group Manager does not reassign a Sender ID within the group (see Section 3.2.1.2).

        • The case A in Appendix D.4 of [RFC8613] concerns all requests as well as all responses including a Partial IV (e.g., Observe notifications [RFC7641] or any other subsequent responses after the first one). In this case, same considerations from [RFC8613] apply here as well.

          @@ -3623,7 +3624,7 @@

          This may result in a client using an old Security Context to protect a request, and a server using a different new Security Context to protect a corresponding response. As a consequence, clients may receive a response protected with a Security Context different from the one used to protect the corresponding request.

          In particular, a server may first get a request protected with the old Security Context, then install the new Security Context, and only after that produce a response to send back to the client. In such a case, as specified in Section 8.3, the server MUST protect the potential response using the new Security Context. Specifically, the server MUST include its Sender Sequence Number as Partial IV in the response and use it to build the nonce to protect the response. This prevents the nonce from the request from being reused with the new Security Context.

          The client will process that response using the new Security Context, provided that it has installed the new security parameters and keying material before the message processing.

          -

          In case block-wise transfer [RFC7959] is used, the same considerations from Section 10.3 of [I-D.ietf-ace-key-groupcomm] hold.

          +

          In case block-wise transfer [RFC7959] is used, the same considerations from Section 10.3 of [RFC9594] hold.

          Furthermore, as described below, a group rekeying may temporarily result in misaligned Security Contexts between the sender and recipient of a same message.

          @@ -4048,10 +4049,6 @@

          Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in Progress, Internet-Draft, draft-amsuess-core-cachable-oscore-09, , <https://datatracker.ietf.org/doc/html/draft-amsuess-core-cachable-oscore-09>.
          -
          [I-D.ietf-ace-key-groupcomm]
          -
          -Palombini, F. and M. Tiloca, "Key Provisioning for Group Communication using ACE", Work in Progress, Internet-Draft, draft-ietf-ace-key-groupcomm-19, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-19>.
          -
          [I-D.ietf-ace-key-groupcomm-oscore]
          Tiloca, M., Park, J., and F. Palombini, "Key Management for OSCORE Groups in ACE", Work in Progress, Internet-Draft, draft-ietf-ace-key-groupcomm-oscore-16, , <https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-16>.
          @@ -4132,6 +4129,10 @@

          Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, , <https://www.rfc-editor.org/rfc/rfc9200>.
          +
          [RFC9594]
          +
          +Palombini, F. and M. Tiloca, "Key Provisioning for Group Communication Using Authentication and Authorization for Constrained Environments (ACE)", RFC 9594, DOI 10.17487/RFC9594, , <https://www.rfc-editor.org/rfc/rfc9594>.
          +
          [Thormarker]
          Thormarker, E., "On using the same key pair for Ed25519 and an X25519 based KEM", , <https://eprint.iacr.org/2021/509>.
          @@ -4261,7 +4262,7 @@

          For each group, the Group Prefix is constant over time and is uniquely defined in the set of all the groups associated with the same Group Manager. The choice of the Group Prefix for a given group's Security Context is application specific. The size of the Group Prefix directly impact on the maximum number of distinct groups under the same Group Manager.

          The Group Epoch is set to 0 upon the group's initialization, and is incremented by 1 each time new keying material, together with a new Gid, is distributed to the group in order to establish a new Security Context (see Section 3.2).

          As an example, a 3-byte Gid can be composed of: i) a 1-byte Group Prefix '0xb1' interpreted as a raw byte string; and ii) a 2-byte Group Epoch interpreted as an unsigned integer ranging from 0 to 65535. Then, after having established the Common Context 61532 times in the group, its Gid will assume value '0xb1f05c'.

          -

          Using an immutable Group Prefix for a group with a Group Manager that cannot reassign Gid values (see Section 3.2) limits the total number of rekeying instances. With a Group Manager that does reassign Gid values, it limits the maximum active number of rekeying instances that a CoAP observation [RFC7641] can persist through. In either case, the group epoch size needs to be chosen depending on the expected rate of rekeying instances.

          +

          Using an immutable Group Prefix for a group with a Group Manager that does not reassign Gid values (see Section 3.2.1.1) limits the total number of rekeying instances. With a Group Manager that does reassign Gid values, it limits the maximum active number of rekeying instances that a CoAP observation [RFC7641] can persist through. In either case, the group epoch size needs to be chosen depending on the expected rate of rekeying instances.

          As discussed in Section 13.6, if endpoints are deployed in multiple groups managed by different non-synchronized Group Managers, it is possible that Group Identifiers of different groups coincide at some point in time. In this case, a recipient has to handle coinciding Group Identifiers, and has to try using different Security Contexts to process an incoming message, until the right one is found and the message is correctly verified. Therefore, it is favorable that Group Identifiers from different Group Managers have a size that result in a small probability of collision. How small this probability should be is up to system designers.

          diff --git a/draft-ietf-core-oscore-groupcomm.txt b/draft-ietf-core-oscore-groupcomm.txt index 3c8bfd3..7815932 100644 --- a/draft-ietf-core-oscore-groupcomm.txt +++ b/draft-ietf-core-oscore-groupcomm.txt @@ -365,8 +365,8 @@ Table of Contents * Group Manager: an entity responsible for a group, neither required to be an actual group member nor to take part in the group - communication. The responsibilities of the Group Manager are - listed in Section 3.4. + communication. The operations of the Group Manager are defined in + Section 3 and its responsibilities are listed in Section 3.4. * Silent server: a member of a group that performs only group mode processing on incoming requests and never sends responses @@ -412,9 +412,10 @@ Table of Contents How the Security Context is established by the group members is out of scope for this document, but if there is more than one Security Context applicable to a message, then the endpoints MUST be able to - tell which Security Context was latest established. How to manage - information about the group is described in terms of a Group Manager - (see Section 3). + tell which Security Context was latest established. The management + of information about the group (i.e., identifiers, OSCORE input + parameters, and keying material) is described in terms of a Group + Manager (see Section 3). An endpoint of the group may use the group mode (see Section 8), the pairwise mode (see Section 9), or both, depending on the modes it @@ -1156,7 +1157,7 @@ Table of Contents 2.6.3.1. New Sender ID for the Endpoint The Group Manager may assign a new Sender ID to an endpoint, while - leaving the Gid, Master Secret and Master Salt unchanged in the + leaving the Gid, Master Secret, and Master Salt unchanged in the group. In this case, the Group Manager MUST assign a Sender ID that has not been used in the group since the latest time when the current Gid value was assigned to the group (see Section 3.2). @@ -1242,11 +1243,12 @@ Table of Contents As with OSCORE, endpoints communicating with Group OSCORE need to establish the relevant Security Context. Group OSCORE endpoints need to acquire OSCORE input parameters, information about the group(s) - and about other endpoints in the group(s). This document is based on - the existence of an entity called Group Manager that is responsible - for the group, but it does not mandate how the Group Manager - interacts with the group members. The list of responsibilities of - the Group Manager is compiled in Section 3.4. + and about other endpoints in the group(s). + + This document is based on the existence of an entity called Group + Manager that is responsible for the group, but it does not mandate + how the Group Manager interacts with the group members. The list of + responsibilities of the Group Manager is compiled in Section 3.4. The Group Manager assigns unique Group Identifiers (Gids) to the groups under its control. Within each of such groups, the Group @@ -1343,7 +1345,7 @@ Table of Contents The Group Manager MUST rekey the group without undue delay in case one or more endpoints leave the group. An endpoint may leave the group at own initiative, or may be evicted from the group by the - Group Manager, e.g., in case an endpoint is compromised, or is + Group Manager, e.g., in case the endpoint is compromised, or is suspected to be compromised. In either case, rekeying the group excludes such endpoints from future communications in the group, and thus preserves forward security. If a network node is compromised or @@ -1357,7 +1359,7 @@ Table of Contents Separately for each group, the value of the Key Generation Number increases by one each time the Group Manager distributes new keying - material to that group (see Section 3.2). + material to that group (see below). The establishment of the new Security Context for the group takes the following steps. @@ -1448,7 +1450,7 @@ Table of Contents asks the Group Manager for the authentication credentials of all the current group members. - Then, given Z, the set of authentication credentials received from + Then, given Z the set of authentication credentials received from the Group Manager, the group member removes every authentication credential which is not in Z from its list of group members' authentication credentials used in the group, and deletes each of @@ -1472,7 +1474,7 @@ Table of Contents protection (see Section 2.1.7) and external signature checkers are used (see Section 8.5). Second, it ensures that the wrong (old) authentication credential associated with a group member A is never - used with a sender ID that used to be associated with A and has been + used with a Sender ID that used to be associated with A and has been later issued to a different group member B (see Section 3.2.1.2), thus preventing the need to recover from an identity mix-up. @@ -2546,7 +2548,7 @@ Table of Contents Note that the server always protects a response with the Sender Context from its latest Security Context, and that establishing a new Security Context resets the Sender Sequence Number to 0 (see - Section 3.2). + Section 2.6.3.1 and Section 2.6.3.2). * In step 2, the Additional Authenticated Data is modified as described in Section 4 of this document. @@ -2865,8 +2867,8 @@ Table of Contents through ECDH. The pairwise mode does not support external verifiers of source - authentication and message integrity like the group mode does (see - Section 8.5). + authentication and message integrity like the group mode does, e.g., + for external signature checkers (see Section 8.5). An endpoint implementing only a silent server does not support the pairwise mode. @@ -2986,11 +2988,12 @@ Table of Contents respect to the following points. - The protection of a response when using a different Security - Context than the one used to protect the corresponding request. - That is, the server always protects a response with the Sender - Context from its latest Security Context, and establishing a - new Security Context resets the Sender Sequence Number to 0 - (see Section 3.2). + Context than the one used to verify the corresponding request + (see Section 3.2). That is, the server always protects a + response with the Sender Context from its latest Security + Context, and establishing a new Security Context resets the + Sender Sequence Number to 0 (see Section 2.6.3.1 and + Section 2.6.3.2). - The use of the stored value of the 'kid' and 'kid context' parameters, if the server intends to reply with multiple @@ -3492,7 +3495,7 @@ Table of Contents Manager. In fact, from the moment when a Gid is assigned to a group until the moment when a new Gid is assigned to that same group, the Group Manager does not reassign a Sender ID within the - group (see Section 3.2). + group (see Section 3.2.1.2). * The case A in Appendix D.4 of [RFC8613] concerns all requests as well as all responses including a Partial IV (e.g., Observe @@ -3553,8 +3556,7 @@ Table of Contents material before the message processing. In case block-wise transfer [RFC7959] is used, the same - considerations from Section 10.3 of [I-D.ietf-ace-key-groupcomm] - hold. + considerations from Section 10.3 of [RFC9594] hold. Furthermore, as described below, a group rekeying may temporarily result in misaligned Security Contexts between the sender and @@ -4269,13 +4271,6 @@ Table of Contents . - [I-D.ietf-ace-key-groupcomm] - Palombini, F. and M. Tiloca, "Key Provisioning for Group - Communication using ACE", Work in Progress, Internet- - Draft, draft-ietf-ace-key-groupcomm-19, 30 April 2024, - . - [I-D.ietf-ace-key-groupcomm-oscore] Tiloca, M., Park, J., and F. Palombini, "Key Management for OSCORE Groups in ACE", Work in Progress, Internet- @@ -4395,6 +4390,12 @@ Table of Contents (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, . + [RFC9594] Palombini, F. and M. Tiloca, "Key Provisioning for Group + Communication Using Authentication and Authorization for + Constrained Environments (ACE)", RFC 9594, + DOI 10.17487/RFC9594, September 2024, + . + [Thormarker] Thormarker, E., "On using the same key pair for Ed25519 and an X25519 based KEM", April 2021, @@ -4689,11 +4690,11 @@ Appendix C. Example of Group Identifier Format in the group, its Gid will assume value '0xb1f05c'. Using an immutable Group Prefix for a group with a Group Manager that - cannot reassign Gid values (see Section 3.2) limits the total number - of rekeying instances. With a Group Manager that does reassign Gid - values, it limits the maximum active number of rekeying instances - that a CoAP observation [RFC7641] can persist through. In either - case, the group epoch size needs to be chosen depending on the + does not reassign Gid values (see Section 3.2.1.1) limits the total + number of rekeying instances. With a Group Manager that does + reassign Gid values, it limits the maximum active number of rekeying + instances that a CoAP observation [RFC7641] can persist through. In + either case, the group epoch size needs to be chosen depending on the expected rate of rekeying instances. As discussed in Section 13.6, if endpoints are deployed in multiple