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

From: Francesca Palombini <[email-masked]>
Date: Tue, 14 Jul 2020 21:25:07 +0000

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" <[email-masked]> 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

---

From: Jim Schaad <[email-masked]>
Date: Thu, 16 Jul 2020 14:01:25 -0700

> -----Original Message-----
> From: Francesca Palombini <[email-masked]>
> Sent: Tuesday, July 14, 2020 2:25 PM
> To: Jim Schaad <[email-masked]>; draft-ietf-ace-key-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: Review of ietf-ace-key-groupcomm-07
> 
> Hi Jim,
> 
> 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
> 
> 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: 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: 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 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:  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:  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: 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
> “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: 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: 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: 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:  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: 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:  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: 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: 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, 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, 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: We do that to point the reader on where to find the encoding (which is the

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

> 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: 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, 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: 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: 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: 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: 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: 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: 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: 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: 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 tried changing to “Retrieval of New Individual Keying Material” Is

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

> 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

> all the current ongoing Observations with the group members Is this better?

[JLS] Yeah, better

Jim

---

From: Francesca Palombini <[email-masked]>
Date: Thu, 23 Jul 2020 11:58:59 +0000

Hi Jim,

Thanks for your reply! Comments inline.

Francesca

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?

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

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

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

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.

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

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

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

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.

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

FP: Will remove it.

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.

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.

FP: Thanks! Will change.

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

FP: Ok, thanks for confirming.

FP: Good, thanks.

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

[JLS] That explanation

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

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

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

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.

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

FP: Good.

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?

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.

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

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.

FP: Ok, we will add something about that.

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

FP: Right, that makes sense. will remove.

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

[JLS] Better

FP:  Ok, thanks.

[JLS] Yeah, better

FP: Good.

Jim

---

From: Jim Schaad <[email-masked]>
Date: Thu, 23 Jul 2020 10:46:21 -0700

From: Francesca Palombini <[email-masked]> 
Sent: Thursday, July 23, 2020 4:59 AM
To: Jim Schaad <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Review of ietf-ace-key-groupcomm-07

Hi Jim, 

Francesca

On 16 July 2020 at 23:01:47 CEST, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

> From: Francesca Palombini <[email-masked] <mailto:[email-masked]> >
> To: Jim Schaad <[email-masked] <mailto:[email-masked]> >; draft-ietf-ace-key-
> [email-masked] <mailto:[email-masked]> 
> Cc: [email-masked] <mailto:[email-masked]> 
> On 26/06/2020, 06:02, "Jim Schaad" <[email-masked] <mailto:[email-masked]> > wrote:
> 
> 

OLD:

NEW:

Would that be better?

[JLS] Yes – just pointing to the profile with out specifying the details of which version of DTLS seems just fine.

OLD:
The Content-Format

[JLS] Yes you are right that it depends on the encoding, I have application/ace+json defined and running in my AS for the MQTT code. 

[JLS] It should only take a couple of words to do that.

OLD:

NEW:

[JLS] That seems long winded and potentially misses the point:

Optionally, the Client might want to request encoding information about the public keys in the group, used for source authentication, as well as any other group parameters.  The joining node MAY ask for this information from the KDC in the same message as it uses to POST the token to the RS.

*	I am not sure if you need to give the content format as this is covered in many other places.

The RS

OLD:

[JLS] Probably better.

[JLS] I don't agree.

[JLS] Per our discussions today.  Note that when Marco and I were talking about the admin interface we may have come up with a good reason to be able to do this.

FP: Will remove it.

[JLS] The Client can retrieve new keying material for itself.  This is described in Section 4.4

[JLS] As discussed today.

FP: Thanks! Will change.

FP: Good, thanks.

[JLS] The problem is you start asking questions like is it the same identifier and it may not be.

[JLS] That explanation

[JLS] I was originally thinking about if a section was needed about initializing groups.  You might get pushback on this, but maybe not.

[JLS] Not intuitive to me, but ok.

FP: Good.

OLD

[JLS] But section 4.4 could be about a group rekeying.  It is going to be profile based how this is responded to.   A profile for which identifiers are fixed is going to re-key the entire group.  One for which they are fluid can just change the identifier.

Jim

[JLS] Better

FP:  Ok, thanks.

[JLS] Yeah, better

FP: Good.

Jim