Thanks for all of this work. My comments inline with [DC]. The only remaining comment has to do with Section 4, para 5 that states that monitors are not required to authenticate...(see my comment inline).
Once that is addressed, I will clear my discuss. Deb On Sun, Feb 22, 2026 at 4:19 PM Marco Tiloca <[email protected]> wrote: > Hello Deb, > > Thanks a lot for your review! Please find in line below our detailed > replies to your comments. > > A GitHub PR where we have addressed your comments is available at [PR]. > > The corresponding Editor's copy is available at [EDITOR-COPY]. > > Best, > /Marco > > [PR] https://github.com/ace-wg/ace-key-groupcomm-oscore/pull/96 > > [EDITOR-COPY] > https://ace-wg.github.io/ace-key-groupcomm-oscore/deb-review/draft-ietf-ace-key-groupcomm-oscore.html > > ------------------------------ > *From:* Deb Cooley via Datatracker <[email protected]> > *Sent:* Tuesday, February 3, 2026 1:03 PM > *To:* The IESG <[email protected]> > *Cc:* [email protected] <[email protected]>; [email protected] < > [email protected]>; [email protected] < > [email protected]>; Rikard Höglund < > [email protected]> > *Subject:* Deb Cooley's Discuss on > draft-ietf-ace-key-groupcomm-oscore-19: (with DISCUSS and COMMENT) > > Deb Cooley has entered the following ballot position for > draft-ietf-ace-key-groupcomm-oscore-19: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C9562910ec0384c9326b108de631c4df7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057170403251402%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ecAolb07Sx9N5g0zvvLwwOk9ELl0uH1Qnjy7jhrbBJs%3D&reserved=0 > <https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-key-groupcomm-oscore%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C9562910ec0384c9326b108de631c4df7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C639057170403297715%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5YcCqxgXIFBdW1FHOUtKT8Ua72Pt3AXME2zGj%2FEZL3A%3D&reserved=0 > <https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/> > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I'm discussing two general ideas from the draft that I believe might lead > to > security vulnerabilities. Some of the specific comments in the comment > section > also help raise those concerns: > > Monitors: How does the Group Manager know that the monitor is > legitimately in > the group? What proof does a monitor have to provide? And what access > does a > monitor have to the group? Can they request authentication credentials of > other members? There needs to be a section in Security Considerations that > discusses the access a monitor has to the group and how that affects the > security of the group. > > ==>MT > > Replying to the different questions separately: > > > **How does the Group Manager know that the monitor is legitimately in the > group? What proof does a monitor have to provide?** > > Like for every group member and any group role, a node that wishes to be a > monitor has to prove to the Group Manager to be authorized to join the > group with that role. > [DC] but Section 4, para 5 asserts otherwise. 'a joining note is not required to provide', in the bulleted list following is the monitor. Is the provision of an authentication credential out of band somehow? Addressing this obvious discontinuity in the text of the draft with what you have written here will address this discuss point. > > This is achieved by uploading the node's access token to the Group Manager > before sending the Join Request where the wished roles are indicated in the > 'scope' parameter. > > The transfer of such authorization information is described in Section > 5.3, building on Section 3.3 of RFC 9594. That applies to every candidate > group member, including one that joins the group with the role of monitor. > > The processing of the Join Request at the Group Manager is defined in > Section 6.2, building on Section 4.3.1 of RFC 9594. As per the latter: > > > The handler considers the scope specified in the access token associated > with the Client and checks the scope entry related to the group identified > by the GROUPNAME associated with the endpoint. In particular, the handler > checks whether the set of roles specified in that scope entry includes all > the roles that the Client wishes to have in the group as per the Join > Request. > > Please note that the present document is intentionally not repeating what > is defined as a baseline in RFC 9594. For instance, quoting from Section 6 > of the present document: > > > Note that what is defined in [RFC9594] applies, and only additions or > modifications to that specification are defined in this document. > > > **And what access does a monitor have to the group?** > > Consistent with the term definition in Section 1.1, a monitor is > essentially a read-only member of the group. > > It does not send protected messages to other group members, but it can > receive and process responses that are protected with the group mode of > Group OSCORE. > > > **Can they request authentication credentials of other members?** > > If they are current members of the group, yes they can, as per Section 9.3. > > They need to do so in order to correctly process an incoming request > protected with the group mode of Group OSCORE, which includes a signature > by the message sender. > > > **There needs to be a section in Security Considerations that discusses > the access a monitor has to the group and how that affects the security of > the group.** > > The answers above hopefully clarifies that: > > * The access to the group builds on an access token and on the access > control enforced at the Group Manager as per the ACE framework. > > * Monitors are essentially read-only members and do not affect the > security of the group in any particular way. > > Therefore, additional content in the security considerations should not be > needed. > > <== > > > Dedicated nonces: The term 'dedicated nonce' is an oxymoron. The classic > definition of a cryptographic nonce is: an arbitrary number that can be > used > just once in a cryptographic communication. Any value that is 'dedicated' > or > used more than once is not a 'nonce', perhaps 'id' is a better term. - > Section > 16: The profile relies heavily on the clients and group managers ability > to not > leak these nonces. Yet, this is not mentioned in Section 16. > > ==>MT > > Thanks for this comment. > > Please note that the use of those values is just as defined in RFC 9594. > In particular, the definition and use of those values is specified in > Sections 3.3, 4.3.1, 4.5.1, and 4.9.1 of RFC 9594. Only additions or > modifications to that specification are defined in the present document. > > The detailed answer below is structured into two parts. > > > **Purpose and non-secrecy of values** > > Those values are not required to be kept secret. > > The secret involved in producing a PoP evidence is the private key of the > party that produces the evidence of owning such private key. Instead, the > values N_S and N_C (inappropriately) called nonces are in fact reusable > challenges that take part in computing a PoP evidence. The actual evidence > is a signature or a MAC, whose computation takes as input also the > challenge in question. > > The party A generating and offering the challenge as a fresh value can be > ensured of the freshness of the PoP evidence computed by the other party B, > proving that B possesses its own private key. The actual credibility of the > PoP evidence boils down to the involvement of B's private key in computing > the evidence. > > In fact, the value N_S is typically provided to a node by the Group > Manager by means of the 'kdcchallenge' parameter, in the unprotected Token > Transfer Response. The latter is sent in reply to the unprotected Token > Transfer Request uploading the access token. This is defined in Section 3.3 > of RFC 9594 and further elaborated in Section 5.3 of the present document. > > As to the specific use of N_S and N_C: > > * The Group Manager stores both the value N_S mentioned above and the > value N_C provided by the joining node in the Join Request, and associates > those with the access token of the joining node. The access token is in > turn associated with the secure communication association between the node > and the Group Manager. > > N_C is a challenge generated by the joining node for the Group Manager, > which the Group Manager uses for producing a PoP evidence about its own > private key, when preparing: > > - The Join Response, as a reply to the Join Request sent to > /ace-group/GROUPNAME at the Group Manager. > - The KDC Authentication Credential Response, as a reply to the KDC > Authentication Credential Request sent to /ace-group/GROUPNAME/kdc-cred at > the Group Manager. > > A new Join Request would provide the Group Manager with a new value N_C > that replaces the latest one. Until then, the latest value N_C is > preserved, to be reused as a challenge for the Group Manager when preparing > a KDC Authentication Credential Response. > > * The joining node stores both the value N_S mentioned above and the value > N_C included in the latest Join Request. > > N_S is a challenge generated by the Group Manager for the joining node, > which the node uses for producing a PoP evidence about its own private key, > when preparing: > > - The Join Request sent to /ace-group/GROUPNAME at the Group Manager. > - The Authentication Credential Update Request sent to > /ace-group/GROUPNAME/nodes/NODENAME/cred at the Group Manager. > > Some error responses from the Group Manager can provide a node with a > new value of N_S, which would replace the latest one. Until then, the value > N_S is preserved, to be reused as a challenge for the node when preparing a > new Join Request or an Authentication Credential Update Request. > > A PoP evidence is included in a message exchanged over the secure > communication association between the joining node and the Group Manager. > > > **Terminology** > > From a terminology point-of-view, the text in this document has so far > simply inherited the wording from RFC 9594, which uses "nonce" and > "dedicated nonce". > > Yet, you are right about your remarks. > > To address your comment, we have revised the Editor's Copy of the draft by > removing the word "dedicated", and by using the words "nonce" and > "challenge" more appropriately. In particular: > > * The values N_S and N_C discussed above are challenges that are not > supposed to be re-offered (e.g., a new Join Request has to include a new > value N_C from the joining node). However, the latest offered values can be > reused as stored challenges taken as input to compute a PoP evidence, hence > they should not be called nonces, but just challenges. > > * Other values are actually nonces, since they are used only once. These > values are: > > - The value N_KDC generated by the Group Manager and specified by the > 'kdc_nonce' parameter of two messages: the Join Response and the KDC > Authentication Credential Response. > > This value is not meant to be a challenge, but just a way for the > Group Manager to "salt" the computation of its PoP evidence with a fresh > value of its own. > > - The value N_C generated by the Client and specified in the 'cnonce' > parameter of the Authentication Credential Update Request. Granted: this > value N_C can be confused with the value N_C in the Join Request, but this > is the naming used in RFC 9594. > > This value is not meant to be a challenge, but just a way for the > Client to "salt" the computation of its PoP evidence with a fresh value of > its own. > > - The value N_C generated by the Client **signature verifier** and > specified in the 'cnonce' parameter of the FETCH Authentication Credential > Update Request. This value and this specific FETCH request are newly > introduced in Section 9.5.2 of the present document. > > This value is actually a nonce, although it is most importantly used > as a challenge for the Group Manager. > > > Consistent with the above, we have update the text in the document as > follows. > > OLD (Section 5.3) > > In the Token Transfer Response, the 'kdcchallenge' parameter contains a > dedicated nonce N_S generated by the Group Manager. As to the N_S value, it > is RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be a > random value. The joining node can use this nonce in order to prove the > possession of ... > > NEW (Section 5.3, emphasis mine) > > In the Token Transfer Response, the 'kdcchallenge' parameter contains a > **fresh challenge** N_S **newly** generated by the Group Manager. As to the > N_S value, it is RECOMMENDED to be at least 8-byte long and it is > RECOMMENDED to be a random value. The joining node can use this > **challenge** in order to prove the possession of ... > > > OLD (Section 6.1) > > The 'cnonce' parameter contains a dedicated nonce N_C generated by the > joining node. As to the N_C value, it is RECOMMENDED to be at least 8-byte > long and it is RECOMMENDED to be a random value. > > NEW (Section 6.1, emphasis mine) > > The 'cnonce' parameter contains a **fresh challenge** N_C **newly** > generated by the joining node. As to the N_C value, it is RECOMMENDED to be > at least 8-byte long and it is RECOMMENDED to be a random value. > > > OLD (Section 6.2) > > ... while N_C is the nonce provided in the 'cnonce' parameter of the > Join Request. > > NEW (Section 6.2, emphasis mine) > > ... while N_C is the **challenge** provided in the 'cnonce' parameter of > the Join Request. > > > OLD (Section 6.2.1) > > The 'cnonce' parameter contains a new dedicated nonce N_C generated by > the joining node. As to the N_C value, it is RECOMMENDED to be at least > 8-byte long and it is RECOMMENDED to be a random value. > > NEW (Section 6.2.1, emphasis mine) > > The 'cnonce' parameter contains a **fresh challenge** N_C **newly** > generated by the joining node. As to the N_C value, it is RECOMMENDED to be > at least 8-byte long and it is RECOMMENDED to be a random value. > > > OLD (Section 6.3) > > The 'kdc_nonce' parameter MUST be present, specifying the dedicated > nonce N_KDC generated by the Group Manager. As to the N_KDC value, it is > RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be a random > value. > > NEW (Section 6.3, emphasis mine) > > The 'kdc_nonce' parameter MUST be present, specifying **the nonce** > N_KDC generated by the Group Manager. As to the N_KDC value, it is > RECOMMENDED to be at least 8-byte long and it is RECOMMENDED to be a random > value. > > > OLD (Section 8.1.1) > > The handler expects a FETCH request, whose payload is a CBOR map > including a nonce N_C (see Section 9.5.2). > > NEW (Section 8.1.1, emphasis mine) > > The handler expects a FETCH request, whose payload is a CBOR map > including a **fresh challenge** N_C (see Section 9.5.2). > > > OLD (Section 9.5.2) > > 'cnonce': encoded as a CBOR byte string, whose value is a dedicated > nonce N_C generated by the Client. As to the N_C value, it is RECOMMENDED > to be at least 8-byte long and it is RECOMMENDED to be a random value. > > NEW (Section 9.5.2, emphasis mine) > > 'cnonce': encoded as a CBOR byte string, whose value is a **fresh > challenge** N_C **newly** generated by the Client **signature verifier**. > As to the N_C value, it is RECOMMENDED to be at least 8-byte long and it is > RECOMMENDED to be a random value. > > > OLD (Section 9.5.2) > > ... over the following PoP input: the nonce N_C (encoded ... > > NEW (Section 9.5.2, emphasis mine) > > ... over the following PoP input: the **challenge** N_C (encoded ... > > > OLD (Section 9.5.2) > > N_C is the nonce generated by the Client signature verifier and > specified in the 'cnonce' field of the received KDC Authentication > Credential Request. > > NEW (Section 9.5.2, emphasis mine) > > N_C is the **challenge** generated by the Client signature verifier and > specified in the 'cnonce' field of the received KDC Authentication > Credential Request. > > > OLD (Section 16.2 title) > > Size of Nonces as Proof-of-Possesion Challenge > > NEW (Section 16.2 title) > > Size of Proof-of-Possesion Challenges > > > OLD (Section 16.3 title) > > Reuse of Nonces for Proof-of-Possession Input > > NEW (Section 16.3 title) > > Reuse of Challenges for Proof-of-Possession Input > > > OLD (Section 16.3) > > When a party A provides a nonce to the other party B, it is beneficial > that A does not offer a nonce previously used with B. By doing so, A can > verify the freshness of the PoP evidence computed by B. > > > > This is practically ensured if parties generate nonces as recommended in > this document. If a party generates nonces that are not random values > (e.g., by using a counter), the party ought to ensure that values are not > reused, even in case of reboot and loss of state. > > NEW (Section 16.3, emphasis mine) > > When a party A provides a **challenge** to the other party B, it is > beneficial that A does not offer a **challenge** previously used with B. By > doing so, A can verify the freshness of the PoP evidence computed by B. > > > > This is practically ensured if parties generate **fresh challenges** as > recommended in this document. If a party generates **challenges** that are > not random values (e.g., by using a counter), the party ought to ensure > that **generated values were not used before with the other party**, even > in case of reboot and loss of state. > > > OLD (Section 16.3) > > As long as the Group Manager preserves the same N_S value currently > associated with an access token, i.e., the latest value provided to a > Client in a 'kdcchallenge' parameter, the Client ... > > NEW (Section 16.3, emphasis mine) > > As long as the Group Manager preserves the same N_S value currently > associated with an access token, i.e., the latest value provided to a > Client in a 'kdcchallenge' parameter **or computed by other coordinated > means (e.g., see Section 6.1.1)**, the Client ... > > > OLD (Section 16.3) > > Unless the Group Manager maintains a list of N_C values already used by > that Client since the latest update to the N_S value associated with the > access token, the Group Manager can be forced to falsely believe that the > Client possesses its own private key at that point in time, upon verifying > the PoP evidence in the 'client_cred_verify' parameter. > > NEW (Section 16.3) > > In such a case, the Group Manager would still attempt to verify the PoP > evidence in the 'client_cred_verify' parameter. However, the Group Manager > will then use the same unchanged N_C value when preparing the following > Join Response, as a challenge for computing the PoP evidence to prove the > possession of its own private key, which would ultimately be against the > Client's interest of freshness. > > > OLD (Appendix A.1) > > REQ15: Specify how the nonce N_S is generated, ... > > NEW (Appendix A.1, emphasis mine) > > REQ15: Specify **how N_S** is generated, ... > > <== > [DC] so much work! But it definitely addresses my discuss. [I'm a little sad that the pre-publication reviews of RFC 9594 didn't surface the non-standard terminology. But turning back time isn't something we can do.] > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to Yoav Nir for their secdir review. > > General: As I have stated before (on other drafts for this protocol), this > protocol presents a complex and complicated set of requirements. This is > no > different, and it is coupled with at least 8 RFC/drafts that have to be > understood to use it. Classically, complex protocols lead to developments > that > contain flaws due to misunderstanding the requirements to implement. Time > will > tell for this protocol, maybe only the designers of the protocol will be > able > to implement correctly. > > Section 4, para 3: Does the Group Manager supply a member of the group > who has > not provided authentication credentials themselves (as a monitor is > described > in para 5) other group members' authentication credentials? > > ==>MT > > As explained in the answer to the first DISCUSS point, the answer is yes. > > Monitors need the authentication credential of other group members, and > they can retrieve those from the Group Manager. > [DC] See my comment on Section 4 in my response to your responses on my discuss (wow...). > > <== > > > Section 5.3: The organization of this section is confusing. The top level > section outlines requirements of the form: if X appears, then Y > requirements > apply, with little explanation as to why one might require or exclude X. > Section 5.3.1 and 5.3.2 provide explanatory text for two of the 5 or 6 > value/requirements. This whole section would be clearer if the explanatory > text was first (in 5.3) and the specific requirements are in subsections > after. > > ==>MT > > Please note that Section 5.3 is written in the same spirit and style of > the corresponding Section 3.3 of RFC 9594, which Section 5.3 of the present > document builds on and complements. > > Therefore, also in the interest of consistency, we would prefer to keep > the current organization of content. > > To clarify on some specific points raised: > > * Section 5.3.0 first covers the Token Transfer Request. When doing so, it > does mention why the Client would include the parameters 'ecdh_info' and > 'kdc_dh_creds', in order to ask the Group Manager to provide certain > corresponding information in the Token Transfer Response. > > * Section 5.3.0 continues by covering the Token Transfer Response. When > doing so, it details the use of the response parameters in the present > document. This applies to 'ecdh_info' and 'kdc_dh_creds' defined in this > document, and to 'kdcchallenge' and 'sign_info' defined in RFC 9594. > > As to 'ecdh_info' and 'kdc_dh_creds', they are present in the response > if they are present in the request (in the context of which, the reason for > their inclusion is given). > > As to 'kdcchallenge' and 'sign_info', their presence and possibly due to > what reason is defined in RFC 9594 and taken here as a starting point to > build on. > > * Sections 5.3.1 and 5.3.2 only cover 'ecdh_info' and 'kdc_dh_creds', > respectively, just like Sections 3.3.1 and 3.3.2 in RFC 9594 cover > 'sign_info' and 'kdcchallenge', respectively. > > Unlike Section 5.3.0, these sections are meant to provide a more general > definition of the two parameters, which abstracts away from this particular > application profile of RFC 9594 and can also be used as reference material > for the IANA registrations in Sections 17.1 and 17.2. This is also the same > approach taken by Sections 3.3.1 and 3.3.2 in RFC 9594. > [DC] this is fine. > <== > > > Section 6.2: When a MAC is used as PoP, is it a keyed MAC? If not, then > what > exactly is being proven? Is it possession of the static 'dedicated nonce'? > Then one has to explain the risks (in Section 16) of leakage of this static > value. > > ==>MT > > Short answer: yes, it is a keyed MAC. > [DC] good. > > Here in Section 6.2, the Group Manager is recomputing the MAC on its side, > to compare the result with the MAC conveyed in the 'client_cred_verify' > parameter of the received Join Request. > > Quoting from Section 6.2 (emphasis mine): > > > If the group is a pairwise-only group, the PoP evidence is a MAC. **The > Group Manager recomputes the MAC through the same process that is taken by > the joining node when preparing the value of the 'client_cred_verify' > parameter for the Join Request (see Section 6.1), with the difference that > the Group Manager uses its own Diffie-Hellman private key and the > Diffie-Hellman public key of the joining node.** The verification succeeds > if and only if the recomputed MAC is equal to the MAC conveyed as PoP > evidence in the Join Request. > > The referred Section 6.1 defines how the MAC is computed by the Client, > with the same construction used later on by the Group Manager for its > recomputation: > > > * If the group is a pairwise-only group, the PoP evidence MUST be a MAC > computed as follows, by using the HKDF Algorithm HKDF SHA-256, which > consists of composing the HKDF-Extract and HKDF-Expand steps [RFC5869]. > > > > MAC = HKDF(salt, IKM, info, L) > > > > The input parameters of HKDF are as follows: > > > > * salt takes as value the empty byte string. > > > > * IKM is computed as a cofactor Diffie-Hellman shared secret, see > Section 5.7.1.2 of [NIST-800-56A], using the ECDH algorithm used in the > OSCORE group. The joining node uses its own Diffie-Hellman private key and > the Diffie-Hellman public key of the Group Manager. For X25519 and X448, > the procedure is described in Section 5 of [RFC7748]. > > > > * info takes as value the PoP input. > > > > * L is equal to 8, i.e., the size of the MAC, in bytes. > > Fundamentally, the MAC is keyed by means of the Diffie-Hellman shared > secret that is used as IKM parameter of the HKDF. > > In this context, what is proven is the Client's possession of its own > private key. When addressing the SECDIR review, we explicitly mentioned > that, wherever it was applicable in the document. This includes Section > 6.1, a little before the quoted text above: > > > If the conditions above do not hold or the joining node prefers to > compute a non-empty PoP evidence, then the joining node proceeds as follows > to prove the possession of its own private key. ... > > <== > > > Section 7.1: This is complicated. Why not merely state that 'stale' > OSCORE > Sender IDs need to be maintained as unusable until after the group is > rekeyed? > Why is it appropriate to delete older stale IDs (if this is appropriate for > whatever reason, please add a warning in Section 16)? > > ==>MT > > Regarding: > > > Why not merely state that 'stale' OSCORE Sender IDs need to be > maintained as unusable until after the group is rekeyed? > > That is indeed the case, but it pertains to retiring Sender IDs **while a > given version of the group keying material is in use**, i.e., during the > current "epoch". > > The scope of Section 7.1 is beyond that, and defines the historical > archiving of stale Sender IDs **from past epochs** at the Group Manager, up > to a pre-defined maximum amount of epochs. > > Before further clarifying, some more background is needed. > > === Beginning of background === > > With reference to draft-ietf-core-oscore-groupcomm : > > * Its Section 12.2.1.2 defines constraints in the assignment of Sender IDs > during an epoch. > > * Its Section 12.2 specifically defines what makes Sender IDs stale > **during the current epoch**. > > See in particular Step 2 of the bullet list introduced by "The > establishment of the new Security Context for the group takes the following > steps." > > Upon rekeying the group, the Group Manager provides the set of such > stale Sender IDs to the group members intended to stay, allowing them to > delete corresponding stale authentication credentials and Recipient > Contexts. > > Also in Section 12.2 of draft-ietf-core-oscore-groupcomm , it is raised > that: > > > A group member might miss one or more consecutive instances of group > rekeying. As a result, the group member will retain old group keying > material with Key Generation Number GEN_OLD. > > That group member eventually realizes, and it obtains from the Group > Manager the latest group keying material in the current epoch with Key > Generation Number GEN_NEW. > > It is important for that group member to gain knowledge of what Sender IDs > were stale **throughout all the epochs between GEN_OLD and GEN_NEW**. See > in particular Steps 2 and 3 of the bullet list introduced by "Then, the > group member proceeds according to the following steps." > > Essentially, the group member asks the Group Manager for all Sender IDs > that are currently stale or were stale during the epochs while it was > misaligned. After that: > > * If no "exact and complete indication" can be obtained from the Group > Manager, the group member deletes all the stored authentication credentials > and Recipient Contexts associated with other group members. > > * Otherwise, the group member deletes the stored authentication > credentials and Recipient Contexts associated with the retrieved stale > Sender IDs. > > === End of background === > > > In the present document draft-ietf-ace-key-groupcomm-oscore: > > * Section 7.1 defines how this particular realization of Group Manager > builds and maintains an archive of stale Sender IDs, **separately** > collected for the N > 1 most recent epochs. > > As explained in this section, the archive is maintained throughout the > group's lifetime, as to the new tracking of Sender IDs that become stale in > the present epoch and as to extending/pruning the recorded history upon > rekeying the group. > > The possible pruning is due to the Group Manager reaching the maximum > amount of tracked past epochs for which stale Sender IDs are currently > stored, hence forgetting about the stale Sender IDs stored in the context > of the oldest tracked epoch. > > * Section 11 (referred to in Section 7.1) also describes how the Group > Manager produces and uses the history of stale Sender IDs, as epochs > advance in the group. > > In particular, Section 11.3.1 defines how the Group Manager uses such > historical information for replying to a request sent by a group member to > the Group Manager's resource at /ace-group/GROUPNAME/stale-sids. > > In that request, the group member indicates the version number > corresponding to the old epoch where the group member was left behind, due > to its missing of past group rekeying instances. > > If the distance between the version numbers of that old epoch and of the > current epoch is greater than N, then the Group Manager does not have the > full history requested by the group member and will return a response with > no payload. For the group member, that will be an indication that no "exact > and complete indication" can be obtained from the Group Manager (see above). > > Regarding: > > > Why is it appropriate to delete older stale IDs (if this is appropriate > for whatever reason, please add a warning in Section 16)? > > Of course, **during a given epoch**, it is not appropriate to delete > Sender IDs that are marked stale in that epoch. > > What is defined here allows the Group Manager to have a maximum number of > past epochs about which stale Sender IDs have to be remembered and provided > to group members upon request. > > If such request is not satisfied by providing all the relevant stale > Sender IDs that the group member asks for, the group member takes the safe > path by deleting all the stored authentication credentials and Recipient > Contexts associated with other group members. > > Section 11.3 takes the perspective of a group member that has missed past > rekeying instances and relies on this service from the Group Manager. > > <== > [DC] ok. I missed the part where group members might miss rekeying and lists of stale Sender IDs. > > > Section 16.1 states that > rekeys are done when one or more members leave the group, if that is done, > how > does the stale list gets to be too large. > > ==>MT > > Related to the previous answer, what gets too large is not the list of > stale Sender IDs in the current epoch. > > In that respect, the Group Manager has to be able to track all the Sender > IDs that become stale in the current epoch, to ensure that they are not > re-assigned during the same current epoch. > > What can get too large is the collection of multiple lists, each > pertaining to one of the most recent N epochs. > > <== > [DC] I understand now. TY. > > > Section 16.2: So possession of a value (called a nonce in this draft) can > be > used as a PoP? Seems odd. > > ==>MT > > As explained in the answer to the second DISCUSS point, these values > (inappropriately) called nonces are reusable challenges that take part in > computing a PoP evidence. The actual evidence is a signature or a MAC, > whose computation takes as input also the challenge in question. > > The party A generating and offering the challenge as a fresh value can be > ensured of the freshness of the PoP evidence computed by the other party B, > proving that B possesses its own private key. The actual credibility of the > PoP evidence boils down to the involvement of B's private key in computing > the evidence. > > In particular, N_S is a challenge that the Group Manager offers upfront to > the Client (see Section 5.3). Instead, N_C is the challenge that the Client > offers to the Group Manager within the latest Join Request (see section > 6.3). Both the Client and the Group Manager store the latest N_C and N_S. > > As mentioned when discussing the related DISCUSS point, the use of the > terms "challenge" and "nonce" has been revised in the Editor's Copy of the > draft. > > <== > [DC] thanks for this.
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
