Re: [Ace] Review of ietf-ace-key-groupcomm-07

[Francesca Palombini <[e-mail]>]

Hi Jim,

Thank you so much for another extensive review! We have submitted v-08 of the draft to answer it.
Comments inline. If there is any answer/update that does not satisfy you, hopefully we can continue the discussion by mail and figure out the major points to discuss during IETF108.

Thanks,
Francesca and Marco

On 26/06/2020, 06:02, "Jim Schaad" <[e-mail]> wrote:

    * Section 1 para 1 - I have a vague memory of deciding that we were going to
    become CBOR only with this document per the argument from Carsten.  I did
    not find this in the minutes so this could easily be some other document
    that I am thinking of.

FP: Yes, and we are in fact limiting this document to CBOR, since we don’t have any JSON media-type registered anymore (there used to be). This sentence was included just to mention that a conversion to JSON is possible to, while not explicitly supported here.

    * Section 2 - I have a problem with Figure 1 in terms of what is labeled as
    an RS.  The text below calls the KDC and RS and not the Dispatcher.  

FP: : Yes, in terms of ACE the KDC is the RS. In general terms, the RS can be a dispatcher (e.g. pubsub) or the group members (e.g. multicast). But I agree this is confusing, we have removed the “RS” from the Dispatcher in the picture.

    * Section 2 - update DTLS reference

FP: The Ace profile of DTLS is defined to set up DTLS 1.2, there is no profile defined to set up DTLS 1.3, so I don’t think we should update to 1.3 here.

    * Section 2 - I think you might want the last sentence to refer to step 3
    rather than section  - The pointer to the section has already been provided
    but pointing back to the figure makes a degree of sense.

FP: Ok, fixed now.

    * Section 2 - KDC - This is the first time that I have heard about the fact
    that this is a two part protocol - You should tell me about the phases
    before you get here.

FP: Ok, we have added some text in the beginning of Section 2, before the figure.

    * Section 2 - "Leaving or removing" this is a sentence which does not read
    well.  (Also why is this current when no other line is.)

FP: Ok, we have tried rephrasing the bullet list again.

    * Section 2 - You should probably have a numbered item that corresponds to
    the secure group communication line in the picture.

FP: Ok, we have added that and added the 2 paragraphs after the picture to the bulleted list, as we felt it fitted better there.

    * Section 3 - The content format application/ace+cbor is not defined by the
    transport profiles but by the framework.

FP: The point is that the profiles might change the content format, so even if this specific one ace+cbor is defined in Ace, profiles might define and use other ones. Rephrased to clarify.

    * Section 3.1 - Given that a role is defined as a tstr, that format is not
    usable if one wishes to assign an integer abbreviation per OPT7.

FP: I tried to reformulate here that the aif is the default encoding, and specify that the other format defined is an example. In the end it is up to the application profile to specify the format of scope.

    * Section 3.1 - the "Other additional" seems to be a strange thing to have
    in this list because it does not match the lead in paragraph.

FP: Right, we have moved it out of the list.

    * Section 3.1 - Is there a reason that a gid is a bstr and not a tstr.  I
    assume that this is the same as GROUPNAME which much be a text string to be
    in a url-path.

FP: We have modified that to be tstr to be consistent with ace key groupcomm oscore, but please note this is only an example.

    * Section 3.2 - s/non expired/non-expired/

FP: Fixed.

    * Section 3.2 - the def of scope seems odd because it is not well defined if
    it would be the same as the requested scope. (AS response)

FP:  I need more clarifications: Is it the following that is strange “'scope' containing the granted scope, if different from the scope requested by the client. “ ? Note that the terminology “requested and granted scope” comes  from OAuth: https://tools.ietf.org/html/rfc6749#section-3.3. I removed the second part of the sentence as per comment below.

    * Section 3.2 - the text w/ scope can be simplified to the scope that the AS
    grants access to and skip the last sentence.

FP: Ok, simplified. I kept the last sentence as it is more precise in my opinion to keep the pointer to the encoding.

    * Section 3.2 - ditto w/ above on "other additional"

FP: Ok, fixed.

    * Section 3.3 - s/request necessary information/request information/

FP: Ok, fixed.

    * Section 3.3 - Am I supposed to know why I care about public keys at this
    point?

FP:  I thought this sentence was supposed to cover it (second paragraph of 3.3): “Optionally, the Client might want to request necessary information concerning the public keys in the group, as well as concerning the algorithm and related parameters for computing signatures in the group.” What’s missing?

    * Section 3.3 - last sentence of the text implies that sign_info and
    pub_key_enc are required.  Last sentence of para 2 needs to be re-written

FP: Right, fixed now.

    * Section 3.3 - should identify what sign_info is for.

FP: Ok, fixed.

    * Section 3.3 - are you imposing a new requirement that the token be
    validated prior to returning the response to a token post?  As I remember
    it, this is not required to happen prior to the response being returned just
    before access is granted.  (I.e. you can validate the token in parallel)
    (After successful verification...)

FP: It seems to us this is already defined in the framework: from https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-35#section-5.8.1
“When an RS receives an access token, it MUST verify it before storing it.”
And later
“If token or claim verification fails, the RS MUST discard the token and, if this was an interaction with authz-info, return an error message with a response code equivalent to the CoAP code 4.01 (Unauthorized).”

    * Section 3.3 - "payload of response deviates"  I don't believe that this is
    a true statement.  However, you should state at tis point how it deviates if
    you believe it does.  I assume that you mean that there is a payload as
    oppose to no payload.

FP: Yes, it’s about having a payload. This clarification was requested by Ludwig in a previous review. We have tried to clarify that “as opposed to no payload”.

    * Section 3.3 - You would not be able to reuse the same kdcchallenge value
    with a different key.  It would not have any way of being associated with
    that key and would look like somebody else was attempting to use the value.

FP: Not sure we understand the problem here. Does “different key” refer to a following new public key that the client wants to upload? There is in fact no association between ‘kdcchallenge’ and the public key itself, not even with the first one that the client provides at its first joining (and it is also unknown to the KDC at the time when ‘kdcchallenge’ is issued). It’s important the ‘kdcchallenge’ is associated to that exact client, meaning to that exact Token and PoP key.

    * Section 3.3 - s/were included in the request/are included in the request/
    present tense.

FP: Ok, fixed.

    * Section 3.3 - Do you really mean to say "request includes pub_key_enc",
    "response does not include pub_key_enc"?  That seems to be wrong in the
    general case.  Also seems to say the same thing about 'sign_info'.  Also
    seems to contradict the next paragraph.

FP: You are right, there was a contradiction between the two paragraphs. We have tried to clarify and have only kept the MAY. The reason being that the final decision of including or not those parameters is taken by the KDC.

    * Section 3.3 - The forward reference for sign_info is incorrect - it should
    be 3.3.1.  (I also don't know if you need this two paragraphs in a row.)

FP: Ok, merged to simplify.

    * Same paragraph - group identifier or group name?  You need to do a
    detailed pass through the document and look at every instance of this string
    and either make it an identifier or a name and perhaps add these to the
    terminology section so that one can quickly look back to distinguish them.
    Perhaps you should be using context identifier rather than group identifier
    just to make it clearer the difference between what goes into the different
    locations.  The problem with that is it is OSCORE specific so it may not
    work well.

FP: Right, we definitely want to avoid all OSCORE specific terms, so context identifier is not a good idea. In this document we used group identifier as group name  “the group identifier has value "GROUPNAME"” (and is different from OSCORE group id). I replaced it everywhere with group name, for clarity.

    * Section 3.3 - last paragraph - should this be referring to applications or
    profiles?  -- really a global question.  Consider - is the OSCORE profile
    attached to a specific application or to a set of unknown applications?

FP: Here we meant application profiles of this doc such as “ace-key-groupcomm-oscore”. I don’t understand the second part of his comment, could you explain?

    * Section 3.3.1 - s/one ore more/one or more/

FP: Ok fixed.

    * Section 3.3.1 - s/is lower or at most equal to/is at most/ - also what
    happen if the response would include zero elements?  You asked and nothing
    needs to be returned?

FP: Yes, the KDC can essentially ignore or partially ignore the request for information from the Client. I think we want to let the KDC be able to do that.

    * Section 3.3.1 - second bullet - kill the "if included" text.  This is
    covered above.

FP: I don’t think we can remove the “if included” text as it gives information about the encoding: 
- If included in the request, sign_info in the response encodes like this ...
- If not included in the request, sign_info in the response encodes like this ...
That is not covered above.

    * Section 3.3.1 - s/sign_info/sign_info/

FP: Fixed sing_info.

    * Section 3.3.1 - This is looking really complicated and I don't know why
    you don't just simplify it down to a single request/response pair.  Define a
    value for use when the server either does not know or does not want to share
    a value and so forth.  The size of data if sign_info were to be omitted is
    almost the same size as if it where present so that does not seem to be much
    of a win.  Making the answer one byte longer for adding the pub_key_enc_res
    field does not seem to be a huge problem for a one-time message.

FP: Thank you for your suggestion, we do agree that simplifying is a good improvement. We have made the following changes: sign_info in the request implies that the client wants to know encoding of pub keys too. Pub_key_enc is always included in the sign_info in the response, with value null if the KDC can’t provide that information. As a consequence, we do not need to register the “pub_key_enc” parameter as a ace parameter.

     * Section 3.3.1 - The first paragraph implies that pub_key_enc would be in
    the reply but don't have any information about what that would look like.
    See also previous item.

FP: Since we implemented the previous change, we do not need to have a separate section for pub_key_enc, since in practice  that parameter is now part of the sign_info parameter, and defined in that section.

    * Section 3.3.3 - s/((/(/

FP: Fixed.

    * Section 4 - why are you calling this the first exchange with the KDC - who
    was I talking to in section 3?

FP: The reason for calling it “the first exchange” was to highlight the fact that the joining process happens first, and more requests can follow with different goals (update of keys etc). We have now clarified that this is the “first exchange after posting the Token”.

    * Section  4 - are the policies new or just retrieved?  May want to swap
    order.

FP: Right, just retrieved. Fixed the order.

    * Section 4 - are we still specifying a group to join or is that implicit in
    the URL?  Tell me how it is specified?

FP: It’s specified in the ‘scope’ of the Joining Request, as the group name in the single scope_entry for that Joining Request. I think it’s good not to mandate that the URI reflects the group name in the path (though it makes sense and we do it in the examples).

    * Section 4 - I don't think that the (re-) is helping understanding here.

FP:  The point we were trying to make clear with that (re-) is that it can be used to retrieve those several following times, not only once. But I don’t know how to express that clearly, and since that does not help understanding we have removed them.

    * Section  4 - what type of individual key is being obtained in bullet 2 -
    how is this different than getting the current keying material?

FP: The individual key is the equivalent of the Sender Key in OSCORE (or input material to derive it, i.e. the Sender ID), vs the group keying material such as the master secret, master salt, context id. The difference is that using bullet 2 only the personal node’s keying material is updated, not the group keying material. We’d welcome proposals on how to clarify it without going into OSCORE details.

    * Section  4 - Who is enforcing the policies?  Just retrieve the policies.

FP: Ok, fixed.

    * Section 4 - I don't think the e.g. in getting public keys serves a purpose
    here.

FP: Ok, fixed.

    * Section 4 - I am not sure what the "at hand" is supposed to be providing.
    /for the requested group identifier/

FP: Ok, fixed.

    * Section  4.1 - do we want to make the if value be a dot tree?  ace.group

FP: Ok, changed to ace.group.

    * Section 4.1 - The bullet for /ace-group seems to indicate that the name is
    fixed which is the opposite of what the previous paragraph says.  I find
    this confusing.  I really find it confusing that this document is specifying
    a url-path name is being specified, and the oscore document immediately uses
    a different value.

FP:  The part about “fixed” was meant to say that once defined it will not change, whatever the application profiles define to use, either the default or other, opposed to the /ace-group/GROUPNAME for example, which have a variable part. Since that was not clear, and not to make it inconsistent, we have removed the term fixed.
About OSCORE using a different resource name: should we then specify as a requirement that the profiles MUST set the root uri-path, rather than providing a default?

    * Section 4.1 - what does it mean for a sub-resource to be "fixed".  Does
    that mean it never changes?

FP: See previous answer. Yes it means that once defined it does not change depending on other parameters (such as GROUPNAME or NODENAME). We have removed it now as it was not clear.

    * Section 4.1 - a brief description of what is in the resource would be
    helpful here.  "pub-key: this resource contains the public keys of all group
    members.  The resource supports the GET and FETCH methods."

FP: Ok, we have added some text about that.

    * Section 4.1 - Yes but what is a NODENAME and why do I care about it?

FP: Hopefully adding the following “Each resource contains the individual keying material for that node. “ gives an intuition why the NODENAME is used. The fact that it is a node identifier should be clear by the following sentence: “ These resources are identified by the node name (in this example, the node name has value "NODENAME")” More details about how precisely NODENAME is used to verify the request are given in 4.1.2.1, but we only want to talk about it high level here.

    * Section 4.1.2.1 - It would be useful in the first paragraph to re-iterate
    that this is the "join" operation  The current description seems to be
    really odd.

FP: Ok, I added a note about that. The idea was that this section is really about the handler, and the joining is described using this handler later on, in section 4.2.

    * Section 4.1.2.1 - get_pub_keys - One consideration that needs to be
    highlighted for a constrained device is that this may result in a large
    return value and it may be better to get them only as needed.

FP: Ok, added the following sentence: “Note that including this parameter may result in a large message size for the following response, which can be inconvenient for resource-constrained devices.” Anything more we need to add?

    * Section 4.1.2.1 - It would be nice to be able to use get_pub_keys with a
    filter so that only responders are returned.

FP: Ok, we have moved the format of get_pub_keys that was used in the /pub-key resource, and use that in the join as well. We have also clarified what id and role are used for.

    * Section 4.1.2.1 - 'client_cred' the description of when this field is used
    does not seem to include a server which only responds to an individual. It
    could be said in that case that it is not sending messages "to the group"
    but only to a member of the group.

FP: Ok, rephrased in “to one or more group members”.

    * Section 4.1.2.1 - 'conce' why bother pointing to ACE for a description of
    this document.  This is not a framework message so I am not sure why this is
    interesting.

FP: We do that to point the reader on where to find the encoding (which is the same as in Ace).

    * Section 4.1.2.1 - Which scope is being used, the one in this message
    (assuming it exists) or the one in the token?  If the message does not have
    one then what happens?  Deterministic encoding?

FP: By “used” I assume you mean by the KDC? The KDC extract the granted scope from the Token, and checks this requested one against the token one. If this join message does not have one we are in the case where the KDC understands which group and role the Client is requesting (say there is only one that the client has been granted). What are we missing?

    * Section 4.1.2.1 - s/token is not being posted/token was not posted/

FP: Ok, fixed.

    * Section 4.1.2.1 - formatting - the follow on paragraph to
    'client_cred_verify' should be indented a level

FP: Ok, fixed.

    * Section 4.1.2.1 - You missed the merge of sign_info and pub_key_enc in the
    error handling paragraph.

FP: I think this should be fixed with the previous modifications of sign_info and pub_key_enc, but if it’s not please let us know.

    * Section 4.1.2.1 - What is the reasoning behind returning the sign_info_res
    field if the group is not in the scope.  This is not related to the failure
    in any way.  Seems more like this would return a pointer to the AS rather
    than anything else.

FP: The reasoning was that we wanted to say: “if verification fails, return the same error as the Token post error”. But it’s true it does not make sense to return sign_info here. We have modified this to MAY return AS Creation Hints message, as defined in Ace.

    * Section 4.1.2.1 - How much can I just ignore rather than error?  If you
    send me a public key and I don't care about it why can I not just ignore
    that fact and go forward?  I both agree and disagree with the idea that
    erroring on unknown fields is the correct way to proceed.

FP: Ok, we have changed that to “if required parameters are not formatted correctly, error. If unknown or non-expected parameters, then ignore and continue processing”.

    * Section 4.1.2.1 /succed/succeeded/

FP: Ok, fixed

    * Section 4.1.2.1 - (para before bullet) I don't like the idea that if you
    send me a public key, I would use the stored one before looking at the one
    that is in the join message.  This seems to be backwards behavior.  Note the
    paragraph following the bullets is saying exactly the opposite thing a this
    one is.

FP: Good point, we have now swapped the order: first check if in message, and possibly overwrite the one in memory. If not in message, check existing association. If no pub key is provided or retrievable, then respond with 4.00 Bad Request error message.

    * Section 4.1.2.1 - I am not clear on the following situation:  Key P1 is
    associated with groupX,  I do a second join and send key P1 but have a cred
    verify that would fail.  Am I expected to detect this and error or say that
    because you have already verified P1 it does not matter?

FP: Following the previous point, we have clarified that in the text, it would fail if the cred verify fails. But we welcome more opinions on this.

    * Section 4.1.2.1 - both bullets are talking about failed verification -
    kill the redundancy.

FP: Yes, but the error processing is different in the 2 bullets: in case the verification fails because client_cred_verify fails, we specify what the handler needs to do with regard to the kdcchallenge. So it is not really redundant. We haven’t made any changes, but please let us know if you have ideas on how to improve.

    * Section 4.1.2.1 - 'num' the rule on the initial value of num should be put
    into a section about setting up a group not here.

FP: Ok, we have added a requirement that it is up to the application profile to specify what the initial value should be. For OSCORE, this can be defined in draft-tiloca-ace-oscore-gm-admin and referenced in the profile.

    * Section 4.1.2.1 - 'num' vs 'ctx-num' should be harmonized.

FP: They were not the same thing (uri-path vs ace-groupcomm parameter) so it was not necessarily wrong that they were different. But for consistency, we have changed the ctx-num for num.

    * Section 4.1.2.1 - exp_delta should specify a default if it is not in the
    message.  I there a reason that this is not a policy for the group?

FP: Ok, we have moved this to the policies. It is worth noting though that the group_policies parameter is optional (meaning the KDC might not send this info in the message), we have explicitly added that the default values MUST be specified by the application profiles.

    * Section 4.1.2.2 - Ditto to above on the field being returned in the event
    of 4.01

FP: Yes, we have done the same modification as above.

    * Section 4.1.2.2 - I don't understand the need for 'gkty' as that I should
    know from the join and it should never change in the life of the group.  I
    would also expect that 'exp' is something that at least SHOULD be included
    as that does change and is useful to have.

FP: Ok for exp, we changed it to SHOULD. About gkty in the GET response, it allows a node acting as “monitor” to only request the group key and get all the information it needs without needing to do the full POST, especially if the KDC maintains the pub keys and would fail its request if it does not contain a pub key. We could make gkty optional in the response to GET, but I think that would just be more complicated (when does the KDC sends it? When not?) I don’t think the saving 2 bytes is motivation enough for removing it, given that we have a reason for having it.

    * Section 4.1.2.2 - Is the 'key' value expected to be modified for the
    requester?

FP: Yes, ‘key’ contains the equivalent of the whole OSCORE Security Context in the OSCORE profile of this spec, including the Sender ID, which is unique to the requester. Also if the KDC rekeys the group, then ‘key’ is the new keying material distributed with rekeying.

    * Section 4.1.3.1 - What is the reason for having a map in this request
    type.  Why not just have the array itself?

FP: Map in this case is not strictly necessary because we don’t have optional parameters, but to keep the consistency with other messages to the rest of the interface where map is necessary because of optional parameters, I would keep this as a map with the same content format.

    * Section 4.1.3.1 - Looks like a formatting error 2 paragraphs after figure
    7

FP: Right, fixed.

    * Section 4.1.3.1 - The text on the first selection criteria has me really
    messed up because I am not sure that 

FP: Broken comment. But we have assumed this was about the parenthesis (including the exact combination of roles requested) and have tried to rephrase to clarify.

    * Section 4.1.3.1 - If not storing keys, should this return either resource
    not found or not supported as an error code instead of an empty response?

FP: Good point. We have added a sentence that specifies that any request returns 4.05 Method Not Allowed in case the KDC does not maintain keys. Http (and subsequently CoAP) defines: "405 Method Not Allowed response status code indicates that the request method is known by the server but is not supported by the target resource."
 The Not found is another option if we make that resource endpoint optional to implement, which is not the case right now. We prefer this option, but if the WG thinks Not Found is better we can go for that too.

    * Section 4.1.3.1 - s/resource handlers only verify/resource handler only
    verifies/  Unless you move it up one level.

FP: Ok, fixed.

    * Section 4.1.4.1 - can we get rid of the map?

FP: Again, I’d rather not for the same reasons above.

    * Section 4.1.6.1 - I have no idea from the text why I would use this
    method.

FP: It’s difficult to give a clearer idea avoiding profile-specific details. Would it help to have an informational reference to key groupcomm oscore to give an example? (I’d rather avoid the circular dependency, so if you have other ideas on how to improve, I’ll take them).

    * Section 4.1.6.3 - para 2 - the first sentence does not make any sense to
    me.  How could the handler accept a request for a node does not match
    "NODENAME" as that is the url-path?

FP: The point is that the KDC MUST NOT accept a request from a node N1 sending a DELETE to ace-group/GROUPNAME/nodes/N2.The KDC can identify the node name from the secure session it has set up with it (it has given the node a name and associated it to the secure channel once the node has done the join process). We have tried to reformulate to clarify.

    * Section 4.2 - "retrieve individual or group keying material"  What
    individual material?

FP: Same answer as before: this could be for example the sender ID to derive the Sender Key in OSCORE. It’s difficult to give a clearer idea avoiding profile-specific details. Would it help to have an informational reference to key groupcomm oscore to give an example? (I’d rather avoid the circular dependency, so if you have other ideas on how to improve, I’ll take them).

    * Section 4.3 - /target the URI path possibly provided by/ This text either
    needs to be a definitive method or some type of alternative method needs to
    be provided.

FP: Ok, this was an editorial mistake, as we included “possibly” because this method of keying material distribution is an optional method, and the control_path is in general optional. But if this method is used, then yes the control_path is not optional. We have removed “possibly”.

    * Section 4.3 - I am worried about congestion in more places than just for
    Observe.  If a server is sending lots of messages out to clients on a
    one-to-one basis it could easily flood the network.

FP: We had added some security considerations about it, referencing to Section 4.7 of 7252. Now we added this reference in this section as well. Is that enough or what is missing?

    * Section 4.4 - What does the first sentence even mean?  It seems to be
    almost a circular argument.  

FP: Tried rephrasing as follows: “Beside possible expiration, the client may need to communicate to the KDC its need for part of the keying material to be renewed. “ Let us know if this is still unclear.

    * Section 4.4 - I find the title of 4.4 to be somewhat misleading.  As far
    as I can tell this is only talking about one type of renewal, but even that
    is not clear to me.

FP: Ok, we tried changing to “Retrieval of New Individual Keying Material” Is this better?

    * Section 4.4 - Why would it require an error in the event that a full rekey
    is going to be done by the server, can't it just do the full renewal and
    return the answer to the PUT?

FP: Ok, we have rephrased to express that. We have kept the possibility to perform the rekey before or after replying, so that it is up to the application profile to define that:
OLD:
Furthermore, policies can be set up so that, upon receiving a Key Renewal Request, the KDC replies to the client with an error response, and then performs a complete group rekeying (OPT8).
NEW:
Furthermore, policies can be set up so that, upon receiving a Key Renewal Request, the KDC performs a complete group rekeying before or after replying to the client (OPT8).

    * Section 4.5 - Is the second paragraph in the wrong place?  I don't really
    care what the client does only what the server does.

FP: Why? It is important that the client processes the response correctly. It makes sense this would not be in the “handler” section, but here we think we should have this type of details. Would it be better to have this paragraph after the figure?

    * Section 4.6 - /After distributing the new group keying material/ This
    should be done before doing that - it should also be committed long term
    storage if one expects the KDC to restart w/o a forced rekey event.  And
    even then it potentially should have a new context number.

FP: Ok, we have modified everywhere (4.6 but also 4.1.5.1, 4.8 and 5) so that the version number is incremented before the keying material is distributed.

    * Section 5 - see previous comment

FP: Yes, fixed.

    * Section 5 - Does the use of the DELETE method to inform a client that it
    is no longer part of the group imply that a different control path is needed
    for every group that the client joins?  I don't know that I was expecting
    that.

FP: That’s correct. An alternative would be that the KDC sends a POST, indicating the group name in the payload. This would be sent to a single resource on the Client used for any joined group under any KDC. Would you prefer this? (not implemented right now)

    Section 7 - / end of the rekeying process and the next loss of security
    state/  This is not what I was trying to get at and it makes no sense to me.
    The question is the interval between the end of the last rekey process and
    the client joining the group.  If that is small enough then replay will not
    work.

FP: Ok, we have rephrased in the following way:
OLD
If the group has renewed its group keying material, the time window between the end of the rekeying process and the next loss of security state is safe for recipients, as replayed older messages protected with previous keying material will not be accepted.
NEW
Besides, if the KDC has renewed the group keying material, and the time interval between the end of the rekeying process and the joining of the Client is sufficiently small, that Client is also on the safe side, since replayed older messages protected with the previous keying material will not be accepted.

    Section 7 /the Observations up to that point/ this does not make any sense.
    You can lose who I currently doing the observation but you have already
    tossed all of the observations themselves even without a reboot.

FP: Ok, we have rephrased:
OLD
the Observations up to that point
NEW
all the current ongoing Observations with the group members
Is this better?

    Section 7 - I don't understand the conditions you have laid out for doing
    delayed rekeying  I would expect that it is a minimum number OR a maximum
    interval.  But I don't think that is what this says.

FP: We have rephrased in the following way:
OLD
Instead, the KDC may rekey the group after a minimum number of group members have joined or left within a given time interval, or during predictable network inactivity periods.
NEW
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.

    Section 7 - This is a tic that I am trying to stop in my own writing.  Look
    at all instances of "In fact," and they can probably be removed.  The other
    one that I use a lot is "Actually,"

FP: Thanks, we have removed all instances of In fact and Actually that we could find.

    Section 7 - s/initiating rekeys/initiating rekey events/

FP: Ok, fixed.

    Section 7.1 - Para 2 - it would not be a second try as the KID context field
    would be different in general.

FP: Ok, removed “as second attempt”.

    Jim