> -----Original Message----- > From: Francesca Palombini <francesca.palomb...@ericsson.com> > Sent: Tuesday, July 14, 2020 2:25 PM > To: Jim Schaad <i...@augustcellars.com>; draft-ietf-ace-key- > groupc...@ietf.org > Cc: ace@ietf.org > 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" <i...@augustcellars.com> 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. > > * 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. > > * 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? > > * 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. > * 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. > > * 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. > * 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. > * 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. > * 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. > * 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. > > * 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 > > * 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. > > * 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. > > * 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. > > * 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. > > * 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. > > * 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. > > * 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. > > * 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 > * 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. > > * 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? > * 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. > * 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. > * 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 > * 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. > > * 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. > > * 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 > > * 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 > > * 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. > > * 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 > > * 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. > * 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. > > 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 > > 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 Jim > > Jim > > > > > > > > > > > > > _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
