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

[Francesca Palombini <[e-mail]>]

Hi Jim,

Thanks for your reply! Comments inline.

Francesca





On 16 July 2020 at 23:01:47 CEST, Jim Schaad <[e-mail]> wrote:


> -----Original Message-----
> From: Francesca Palombini <[e-mail]>
> Sent: Tuesday, July 14, 2020 2:25 PM
> To: Jim Schaad <[e-mail]>; draft-ietf-ace-key-
> [e-mail]
> Cc: [e-mail]
> Subject: Re: Review of ietf-ace-key-groupcomm-07
>
> 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 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.

[JLS] Fine - but be prepared for pushback from the IESG on this.

FP: A possible alternative is to rephrase to mention the profiles rather than the protocols. For example:

OLD:
“Possible ways to provide a secure communication association are DTLS [RFC6347] and OSCORE [RFC8613].”

NEW:
“Possible ways to provide a secure communication association are described in the DTLS transport profile [I-D.ietf-ace-dtls-authorize] and OSCORE transport profile [I-D.ietf-ace-oscore-profile] of ACE.”

Would that be better?

>
>     * 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.

[JLS] No, the profile can dictate the media type between C and RS, but between C and AS is set by the framework.

FP: Ah, I see what you mean. I checked again in the framework, and to be nitpicking it does says “Profiles that use CBOR encoding of protocol message parameters at the
outermost encoding layer MUST use the media format 'application/
ace+cbor'. So in some sense the content-format depends on if the profile uses CBOR or not. That does not change the fact that we need to rephrase our text here to be completely correct.

OLD:
The Content-Format
used in the message is the one indicated by the used transport
profile of ACE. For example, ...
NEW:
The Content-Format
used in the message depends on the used transport
profile of ACE. For example, ...


>
>     * 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.

Sure, but why not express figure 4 in terms of AIF rather than as something that looks like a new structure?

FP: We can do that, we will port the example from the OSCORE application profile (the one in section 3 of https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-08 ).


>
>     * 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.

[JLS] Yes I know it is an example, but the gname cannot be anything other than a tstr unless you are going to completely break the connection between this value and the name in the URI.

FP: This is a good point, we might want to specify that if it’s not a tstr there needs to be something in place to make the translation between the group name and GROUPNAME used in the URI (ex: bstr gets translated into tstr 0x0123 becomes “0123”)


>     * 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.

[JLS] What seems odd is that if it is absent, then it is not clear what the grants are.  I don't know if you need to specify that the grant is the same as the request when it is not present.  On the other hand this is duplicating information in the framework document.

FP: Yes, that was the idea, that if it’s not present the granted scope is the same as the requested one. I am not against duplicating information if it might make things clearer.

>
>     * 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?

[JLS] Well - lets start with the use of the singular group in the text.  There are a number of problems here:  1.  It would make sense that this refer to the public key usage from group comm document.  2. The term "information concerning the public keys in the group" to me reads - get the public keys.  3.  There is no motivation about why you are getting this from the token post rather than from the group descriptor.

FP: 1. Right, we can add a reference to it. 2. I see, instead at this point we would like to get info about for example encoding, not public keys themselves. 3. Right, so what we need to add here is that this information is sent before the joining exchange so that the joining node can send its own public key directly in the joining request and does not need to do a separate exchange for that.

OLD:
Optionally, the Client might want to request information concerning
the public keys in the group, as well as concerning the algorithm and
related parameters for computing signatures in the group. In such a
case, the joining node MAY ask for that information to the KDC in
this same request. To this end, it sends the CoAP POST request to
the /authz-info endpoint using the Content-Format "application/
ace+cbor".

NEW:
Optionally, the Client might want to request encoding information about
the public keys in the group, as well as about the algorithm and
related parameters for computing signatures in the group, if those are used, as for example in [I-D.ietf-core-groupcomm-bis]. In such a
case, the joining node MAY ask for that information to the KDC in
this same request, so to get the information before the joining exchange itself (see Section 4.2). To this end, it sends the CoAP POST request to
the /authz-info endpoint using the Content-Format "application/
ace+cbor".


>     * 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).”

[JLS] That text does not say that one cannot do the following:  1) Get the token from the POST,  2) immediately return a success indicator, 3) do the validation of the token, including introspection if necessary, 4) Keep or discard the token depending on the outcome of the validation process.

I was working to get this in because I did not want to have no response go back to the client while waiting for the token to be validated in the event of needing to do introspection.  There is nothing really bad happening if I return a OSCORE nonce in the event that you send me a DTLS token because you would just ignore that as not being useful.  However, if I have to have the entire content of the token before I can respond then introspection is going to be harder to deal with.

FP: I see, I personally do not think the procedure you describe is valid from the point of view of the framework, in particular, Section 5.8.1 says:

The RS
receiving the token MUST verify the validity of the token. If the
token is valid, the RS MUST respond to the POST request with 2.01
(Created). Section Section 5.8.1.1 outlines how an RS MUST proceed
to verify the validity of an access token.

Although it does not say that it MUST NOT respond with 2.01 unless the token is valid, I do interpret the previous paragraph that way. I would think that 2.01 means “the token has been verified and passed verification” rather than “I received the token”. This following paragraph (from the framework) should cover the case you are talking about:

The RS MAY make an introspection request to validate the token before
responding to the POST request to the authz-info endpoint, e.g. if
the token is an opaque reference. Some transport protocols may
provide a way to indicate that the RS is busy and the client should
retry after an interval; this type of status update would be
appropriate while the RS is waiting for an introspection response.

I still interpret this as “only respond with success when the token is validated”. I don’t know what way to indicate that the RS is busy could be used in CoAP.

Also, in case the procedure you describe would be allowed, say the token does not verify and the RS wants to send an error response, that would be lost at the Client which has already received a 2.01.

Anyway, I do think this is a valid discussion for the framework and I do not want our draft to add any requirements to what the framework defines. I think we could rephrase the following to remove any implicit consequence:

OLD:
After successful verification, the Client is authorized to receive
the group keying material from the KDC and join the group. In
particular, the KDC replies to the Client with a 2.01 (Created)
response, using Content-Format "application/ace+cbor" defined in
Section 8.14 of [I-D.ietf-ace-oauth-authz].
NEW:
After successful verification, the Client is authorized to receive
the group keying material from the KDC and join the group.

The KDC replies to the Client with a 2.01 (Created)
response, using Content-Format "application/ace+cbor" defined in
Section 8.14 of [I-D.ietf-ace-oauth-authz].


>     * 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.

[JLS] Let's start with which "different key" you are referring to.  Is this a different signing key or a different POP key?  Depending on how you read this is completely changes the meaning of what you are saying to do in this paragraph.  A different POP key (token) will not be using the same kdcchallenge as a different POP key.  You might be able to use it for a different signing key for a second group in the same token.  But that is not how I read it.

FP: Right, we did mean a different signing key. We will clarify that.


>     * 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?

[JLS]  My problem is that application is a really overloaded term.  Just think of three different lighting applications:  Theater Lighting, Building Lighting and Emergency Lighting.  These are three different applications that are all going to use an OSCORE group keying protocol as part of their implementation.  Now you are saying that the profile is an application.  I am getting really confused about what is an application and what isn't.

FP: You are right, we should have used the term “application profiles”, consistently with the rest of the document and using the term defined in the terminology, to avoid confusions. We did mean “application profiles”, and not applications.


>     * 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).

[JLS] I don't agree.

FP: This comment is related to the one above where you say group name should be a tstr to map to the URI. I thought the flexibility would be good and would not add much to the complexity of implementations. I might bring this up in the WG, maybe you could expand on why that flexibility would be a bad idea?


>
>     * 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.

[JLS] Still and instance in section 1.1

FP: Will remove it.


>
>     * 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.

[JLS] Is this trying to say that a new clientId can be issued as oppose to the current set of material?   I would think that you always get material to derive it and never directly get a key.

FP: for OSCORE yes, but we don’t know that this individual key would always be derived from an identifier such as the clientId, hence the “new input material to derive it” terminology (rather than Client Idetifier). We can change the bullet as follows:
OLD
* The Client can retrieve a new individual key, or new input
material to derive it. This is described in Section 4.4.
NEW
* The Client can retrieve new input
material to derive a new individual key. This is described in Section 4.4.

But still don’t see how to clarify what an “individual key” is without going into details that don’t belong here.


>
>     * 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?

[JLS] That would make more sense to me.  I am not sure why you care about getting a new root however as a single root could, in theory support multiple KDC profiles.

FP: Say you have both ace key groupcomm OSCORE and pubsub application profiles implemented on the same KDC. Either the KDC knows what to return based on the URi root (“group-oscore” vs something like “pubsub”), or it needs to have the information about what profile it is together with the group keying material. Right now our document does the first and not the second. Are you saying you would like us to change that? Or allow both? This is also something I would bring to the WG to discuss.


>
>     * 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.

[JLS] The term normally used is "invariant once established" for that type of meaning.  Fixed would seem to imply that it is fixed prior to that.

FP: Thanks! Will change.

>
>     * 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.

[JLS] This is the first time that I have seen the term in the document.  Using it without any type of definition is not very useful.  Even defining it in the terminology section would be helpful.

FP: Ok, we will add it to the terminology section.

>
>     * 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.

[JLS] Yes that is the sort of thing I was looking for.  Getting a correspondence between the resources and the operations is always helpful.

FP: Ok, thanks for confirming.


>
>     * 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?

[JLS] I don't think so.  The details on blockwise and ETag should be clear already.

FP: Good, thanks.

>
>     * 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).

[JLS] Ok - that seems a bit odd because this is not the same media-type.

FP: That’s right. We could just repeat the encoding, but we thought it was good to make the parallel.


>
>     * 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?

[JLS] That explanation

FP: You are right, that is missing. We will clarify.


>     * 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.

[JLS] But I don't see any reason why I could not return a payload w/ a new kdcchallenge in the first case as well.

FP: Ok, although it is not necessarily needed, if the simplification helps, we can make the change.


>
>     * 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.
[JLS] Do you want a normative reference to the admin document?

FP: No, I think we don’t need it. We give it as an example.


>     * 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.

[JLS] Yes, but you would use an exp_delta of 0 if you did not retrieve it from the policy.

FP: No, you would use whatever default the application profiles specifies. It is REQUIRED of application profiles to specify what is the default value of it’s not sent.

>     * 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.

[JLS] I think that is probably reasonable.

FP: Ok, so we won’t do any change here.

>     * 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.

I am not sure what the matching rules are supposed to be for role identifiers.   It looks like this might have been clarified

FP: Good.


>     * 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).

[JLS] This handler is used by a node either to 1) get a new identifier within the current group or 2) force a rekeying of the group.  This is normally done due to usage limits on the AEAD algorithm.

FP: Thanks for the suggestion! As mentioned above though I would not talk about identifiers, the more precise term would be “input material to generate an individual key to protect outgoing messages”, would that be ok? Or is it still not clear enough?


>
>     * 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.

[JLS] The text in 4.1.6.2 was clearer about that.

FP: Ok, we will revert to that and remove the first part of the paragraph, which does not seem to help anyway:

OLD
The handler only accepts a request from the node identified by
"NODENAME" via the secure session, where NODENAME is used in Uri-
Path, and that is part of the "GROUPNAME" group: the handler verifies
that the group name "GROUPNAME" is a subset of the 'scope' stored in
the access token associated to this client, and that this client is
identified by "NODENAME". If verification fails, the KDC MUST
respond with a 4.01 (Unauthorized) error message.
NEW
The handler verifies that the group name of the /ace-group/GROUPNAME
path is a subset of the 'scope' stored in the access token associated
to this client, identified by "NODENAME". If verification fails, the
KDC MUST respond with a 4.01 (Unauthorized) error message.


>
>     * 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).

[JLS] Retrieve group keying material for the individual

FP: Ok, I think we can simplify here and not talk about the “individual keying material” but only talk about group keying material.


>
>     * 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?

[JLS] I would have just put the text into the security considerations or network considerations sections and not bothered to have it here.  No big deal

FP: We had those already into the security considerations, and we thought you wanted more text here specifically. We can remove them from here, as we don’t want duplicate text.


>
>     * 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.

[JLS] I would not bother with 'part of' And putting in text about why this is needed (i.e. AEAD integrity/confidentially limits) is going to motivate things better.

FP: Ok, we will add something about that.

>
>     * 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?

[JLS] Not really - that would seem to imply that I would not get "new" material in section 4.3 either.
4.3 - Retrieval of keying material
4.4 - Requesting a change of keying material

FP: I would be against renaming section 4.4 so because it seems to imply a group rekey, while that is not what this exchange is. I think we still need something in the title with “individual”, as opposed to “group keying”.


>
>     * 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?

[JLS] What about a client which retrieves the key, verifies the one signature and promptly forgets the key w/o any long term storage?  I'm going to sleep almost immediately and it will have probably changed by the time I wake up again.

FP: Right, that makes sense. will remove.

>     * 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)

[JLS] I don't know, but probably yes.

FP: Ok, we can make this change for the next update.

>
>     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.

[JLS] Better

FP:  Ok, thanks.


>
>     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?

[JLS] Yeah, better

FP: Good.

Jim


>
>     Jim
>
>
>
>
>
>
>
>
>
>
>
>
>