Hi Jim, Thanks for your prompt reply! I cut out the comments that were okayed, and only kept those that either are not okayed, need more discussion, or for which we have proposed new APs following your response. Approved APs are now tracked as github issues and we will be working on those in the branch v-02-WIP. New comments in red, prefaced with [FP].
Thank you again, Francesca and Marco ------------------------ Security Model and other issues for group messaging - 09/04/2019 I need to look at this more closely – will respond later [FP] Ok. Thanks Jim for taking the time I have been going through the design process for getting software running for Montreal and I have come across the following issues that I think need some discussion. Some of these may just need clarification in documents but other are more substantive. It took me a while to determine that one of the strange issues I was having is that when looking just at the multicast case my mental model of who was making the decisions on if access was allowed did not seem to make a good match to what was being documented. I rather expected that all of the ACL decisions were going to be made on the AS and none on the KDC. This is correct. The model for the ace-key-groupcomm (and consequently ace-key-groupcomm-oscore and ace-coap-pubsub) is that the AS does all of the ACL and KDC does the key distribution. This meant that the inclusion of scope in all of the messages was redundant if sending messages to a per group resource. You are correct, scope is indeed redundant in some messages, for example in the Key Distribution Request, as it is present in the token. (See point 12 below) Part of the questions involved here are who does the configuration for what key groups are associated with what application groups. I was always thinking of a single key group which was identified by the AS and sent to the KDC without the KDC needing to know the details of multiple resources for that key group. This of course does not match the model in the document. Some text on what model is being laid out is probably worthwhile. We’d like clarifications here: why do you say that this does not match the current model? That was the objective anyway. There was discussions for the ACE OAuth document about how to handle multiple access tokens for a single entity that need to be looked at in the context of a KDC. The current rule is that a resource server needs only to keep one token for any single supplicant. This was mostly discussed in the context of adding and subtracting privileges for the supplicant. It may be that this also needs to be viewed in the context of having completely disjoint resources on a single RS which are going to have different AS tokens issued. Thus for example, if there is a KDC which is servicing two different key groups. The supplicant gets a token for group1, gets the keys from the KDC. It then asks for a token for group2. Given that the lifetimes of these different tokens could be radically different does it really make sense to require that the two AS tokens be merged together (assuming they are from the same source) or would it make more sense to relax the RS only needs to keep one token rule. An easy way out of this might be to say one token per resource, but for constrained devices it could be one token per RS. We agree with relaxing the “one token per RS per client”. The requirement makes sense when one RS is associated with one AS, but in our case the KDC could be associated with several AS for different scopes. draft-ietf-ace-oauth-authz-24#section-5.1<https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-24#section-5.1> says "... the AS in charge of a resource hosted at the RS ..." So this is a more general problem, as it is allowed in the ACE framework to have multiple ASs covering different resources/scopes at a same RS. We think this requirement should be relaxed in the general case, as merging tokens from different ASs would definitely be a problem. We’d like to raise this issue to the ACE framework authors and get feedback from the WG. Jim ------------------------ draft-ietf-ace-key-groupcomm - 03/04/2019 03:00 3. The document does not have a table which deals with abbreviations, does this mean that the full text string is what is going to be the key? Depending on the content type being considered, these values could be assigned (new registry) or marked as TBD, but if this is supposed to happen then it needs to be placed in the document. Yes, we need to do this. We will create a new registry for them, and re-use the same number as ACE as much as possible (for parameters that appear in both, such as ‘profile’, ‘exp’) (AP3) [JLS] Sounds reasonable. I am currently building a spreadsheet with some of this date and will forward it to you. [FP] Got it, thank you for that, it will be very useful! 6. Section 3.1 - Is there a reason why one cannot request access from the AS for multiple groups/topics in the same request to the AS? 'scope' This was the case in a previous version of the document. We got feedback that this was too complicated and not a hot need. We can reconsider if more people in the WG want this. [JLS] I can understand this reaction. You might also look at the MQTT document which is allowing for this and see if alignment is needed. [FP] Ok, we will (AP29) 7. Section 3.1 - Is there a definition of the values for "role" that can be requested. What is the type of this field for a single value, or for elements of the array? Is there a default if role is omitted on the request? There is no definition in this doc for specific admitted values, that is defined on the additional instances (ace-key-groupcomm-oscore, ace-coap-pubsub). Roles are specific to the applications, so it makes little sense to specify them in general. The default value, if any, would also be defined in the instances. What we will do is to clarify this in the text. Moreover, this will be part of the “Mandatory to define” (see point 39). (AP6) [JLS] I will need to think about this. It may make things hard on the AS depending on how it is designed. [FP] Ok, we will hold off on this AP until we get more discussion. 8. Section 3.2 - IN the last paragraph did you mean to say that a new token would be returned or that the existing token can be returned. That a new token would be returned. How can we clarify? [JLS] The string “can simply replay with” is what messed me up. Better would be “the AS replies with an Authorization Response with a new access token.” The use of “can” is not the same as “will”. [FP] Ok, thanks for the clarification. Will fix (AP30) 9. Section 4.1 - If the 'client_cred' field in a request is filled in, and it is not the same as the public key used to establish the TLS session between the client and the KDC, what is the procedure to do a POP on this key? In the specific case you describe, an easy solution would be to require the client to use the same key in ‘client_cred’ and to establish the TLS session, and that would solve the POP. But we do have the open point on POP for the public key in the general case. Until now, we kept that out of the scope of this and dependent documents (see section 8 of ace-key-groupcomm-oscore), but we are looking to include it. One possibility we are considering is to sign the key distribution request together with a nonce that was sent from the KDC (for the sake of freshness), using the private key paired to the public key sent in ‘client_cred’. Do you have feedback about this? [JLS] that would be a reasonable solution. You could potentially also use a TLS exporter value as that would be channel bound. [FP] Ok, we will start by sketching this solution, we can discuss more after we have a proposal. (AP31) 12. Section 4.2 - I am not completely sure that I understand what verification checking means in the first paragraph. The KDC verifies that the ‘scope’ received in the Key Distribution Request is the same as ‘scope’ stored in the access token associated to this client. This scope field is not strictly necessary, as all the info is in the token anyway (which is why it is optional). But implementation feedback was that it is good to have. [JLS] Does it have to be equal or can it be a subset? [FP] Right, it can be a subset. Will add that (AP32) 13. Section 4.2 - What is the profile that I am checking for the 'kty' field? Was I supposed to have a chance to request a profile someplace? The profile checking is against the ACE Groupcomm Profile registry defined here, i.e. for now either "coap-group-oscore" of "coap-pubsub" (so not the same as the ACE profile). This is to make sure that the correct type of key is used, as defined in the instance document used (such as ace-key-groupcomm-oscore). No, the client do not request the profile, the AS determines it and sends it to the Client in the Key Distribution Response. [JLS] I’ll have to look at this during implementation. [FP] Ok. To make this easier, we will also clarify in the text the difference between “transport profiles” (such as DTLS profile, OSCORE profile, MQTT profile) and “application profiles” (such as ace-key-groupcomm-oscore or ace-coap-pubsub) (AP33) 14. Section 4.2 - Put the fact that the 'key' field is profile dependent on the 'kty' in the 'key' paragraph. Is it legal to define a 'kty' which does not have a 'key' field? If so then should this field be defined by the profile? Ok, I just read the full next paragraph and now I am just confused. Yes, 'key' format is dependent on 'kty'. Also yes, in theory one profile could define a ‘kty’ for which ‘key’ is empty (Note that the ‘key’ field itself MUST be present in the CBOR map). What is unclear and what paragraph are you referring to? 15. Section 4.2 - What is the type of profile? Int, as specified in the "CBOR Value" column of the ACE Groupcomm Profile in Section 9.2. [JLS] Text gives a type for the other fields, or says is profile specific, but not that one [FP] Ok, we will add that in the text as well. (AP34) 21. Section 5 - Is there some type of requirement for positive delivery of new keys in the event of a KDC changing the key. I put this here wrt a node leaving, but it applies equally to a node getting itself added. We are not sure we understand this question. Are you asking about ACK of (successful) delivery of new keys? In that case, if the rekeying is performed node-by-node as described in this document, using confirmable messages should be enough. Otherwise, it would be mostly left to the single nodes to eventually find out that they are using stale key material and should individually ask for the latest one. [JLS] For some types of lists, it makes sense that there should be some type of forcing function that a sender is going to understand that there are new keys before sending a message out. This would require a positive delivery or a policy that says always check before sending. Doing a multicast message cannot be done confirmable according to the normal specifications so you would not necessarily do a fast notification if it needs to be done on individual messages. I am not sure what, if anything, needs to be said here. This may just be considerations someplace [FP] Ok, we will add the following consideration “In the case where it is required that a node only uses up-to-date keys for sending group messages, since CON is not supported in group communication, the application needs to set up a mechanism to check the successful delivery of the message, or policies to always update the keys before sending. Such mechanisms are out of scope of this document.” Would that cover your point? (AP35) 22. Section 5.1 - There currently is no way for an AS to communicate to the KDC that an authorization has been revoked. There is only a way for a KDC to ask the AS by introspection. The first sentence is problematic. Do we need some type of extension to support this? Right, that is not defined in ACE, we will remove this sentence. We’d also like to get feedback from the WG about this. (AP14) [JLS] Makes sense. I think this just needs to be highlighted as introspection. It might be nice to define a multiple token introspection message at some point to the KDC could, in a single message, get all of the statuses before doing a key update operation. [FP] Ok, we will delete that first sentence and replace with “If the node is not authorized anymore, the KDC can optionally get that information from the AS via the Introspection Endpoint (see Section 5.7 of draft-ietf-ace-oauth-authz)”. (AP14) Yes, we agree it would be nice (it would be enough to allow for an arrays of tokens rather than one token in the payload of the introspection request, section 5.7.1 of draft-ietf-ace-oauth-authz). It would be also nice for the Client to be able to Observe the introspection endpoint at the AS. We should definitely discuss these 2 points with Ludwig and the WG, as this might be more general than ace-key-groupcomm, although we would definitely make use of it. 23. Section 5.2 - If a topic is provided and the user is authorized for two topics which use the same group, what happens if the user asks to leave one of those two topics but wants to say on the other? See section 5.2: Note that the 'role' field is omitted since such a request should only be used to leave a group altogether. If the leaving node wants to be part of a group with fewer roles, it does not need to communicate that to the KDC, and can simply stop acting according to such roles. If two topics (application groups) are covered by the same security group, and a user wants to stop following one topic while still being authorized, it does not need to leave the security group, it can just discard future messages related to that topic. The actual leaving of application groups, e.g. unsubscribing from a topic, is out of the scope of this document. [JLS] But the scope field is included in the token. I am not sure that I see any use of the scope field here at all. [FP] Right. We propose the following change: make scope optional in the message (same reasoning as Key distribution request, it is not necessary but it might be useful for implementations). (AP36) 26. Section 5.2 - It is not clear to me if the last paragraph means that the KDC can remove the AS access token from it's database when a leave occurs, or if it can only be removed when it expires. That paragraph was meant to mean that the token can be removed only when it expires (or when you update it). What are we missing? [JLS] You are not necessarily missing something. However this could be done by the KDC forgetting the token when the leave occurs and the client supplying the token again when it does a later join. This means that the KDC only needs to have tokens for currently active members and not for all past members which still have valid tokens. [FP] That’s right, and there are pros and cons for both cases: the current one has less messages exchanged but more memory on the KDC (to keep track of not-expired tokens), the one you mention require less memory on the KDC, but more messages. I think message exchanges are more impactful, so I would keep that option. But we could add a sentence clarifying that if the KDC memory is not sufficient, it might discard past-members valid tokens, in which case the joining old members will need to repost the token after receiving an error response to the key distribution request. (AP37) 33. Section 6.1 - What happens if I ask for a key re-distribution, but supply a different scope than for the original message < assumes a multi-topic scope>. I am not sure what the purpose of the scope is at this time given that you are not checking roles as well. Role is not checked as the Key Re-Distribution Request is done to retrieve the group keying material, not the public keys for signature verification. For example, in pubsub, the node is re-requesting the symmetric key to protect the communication. The KDC does not need to know nor check if the node is an authorized pub or a sub, but only that it is authorized to that topic. Checking the scope make sure that a node that is authorized for a certain topic does not request the material for another topic. Why would you want to ask key distribution for one scope only when both scopes map to the same security keying material? [JLS] Because it is easier on the client. I can ask for the specific token that caused the problem and not have to remember all of the different topics that are associated with the group. [FP] That’s a good point. We will add something about this if we reconsider about the multi-topic/group scope (see point 6 from previous email). 34. OUT OF ORDER - Should a KDC have a single resource which allows for it to return a group based on what the topic/scope is that is passed in without the client first knowing what the group id is going to be? I interpret your question as follows: you are wondering if the following mechanism is/should be supported: the client sends a request to a well known resource on the KDC asking "what is the sec group for this topic/application group?" (topic could be in the payload for example). The KDC responds with info about the security group (Group ID, etc). If that is the case, that is taken care of by the resource directory, as described in draft draft-tiloca-core-oscore-discovery. The KDC could take that role too. If that is not the correct interpretation of this comment, then could you expand? [JLS] Actually I was thinking of something more general. I can post the request to a single common resource name and the KDC would lookup what the correct group id would be for the request and internally dispatch it to the correct internal resource. Might be easier on clients if only one point is needed and no directory lookup is needed. [FP] Ok, we will try to sketch something in Appendix about this, anyway we suggest this to be an optional mechanism that MAY be supported by GM. (AP38) 35. OUT OF ORDER - are all of the resource names required to be at the root? If I have a KDC which is shared with something else (say a Pub Sub server) then it would make sense to have post to /KDC/group-id. No, they don’t need to be at the root, they just need to be associated to the group. [JLS] Take a look at the resource directory and pub sub more the set of templates that they are using. Would this makes sense to use here to address such issues? [FP] Are you saying you would like us to define a .well-known uri-path that should be used? I.e. that each application profile should define it (for example “.well-known/kdc/.../GID1”, or “.well-known/pubsub/.../topic1”), and ace-key-groupcomm defines a registry for it? That is a possibility, although I am not sure I see the point of mandating it. What is the issue you refer to? (AP39) 36. Section 7.1 - what is the format of get_pub_keys when group member ids are included? We propose bstr as default type. Instances may change that if they need to. (AP23) [JLS] What would be a case where something else would really make sense? The group member id is currently define as something set for OSCORE are you thinking that a different protocol might format them differently? [FP] Sorry, let’s clarify. When we say bstr we refer to the group member ids contained into the get_pub_keys, which is a CBOR array. I don’t know if something else would make sense, yes, we were trying to be general in case a different protocol might want to format differently. Although they could always wrap as bstr, so we suggest we don’t mention “instances may change that” (AP23) 37. Section 7.2 - There is a race condition caused by the last paragraph in this section. Entity A sends a message, leaves the group, Entity B receives the message and asks for the public key. Is this an issue? We don't think this as an issue. In fact, A could wait for a reply from B before leaving the group if it is critical that B receives A's message. Otherwise, we could add some text about a policy for KDC to maintain leaving group members’ Public Keys for a certain amount of time after their leaving, before discarding them. Would that solve the issue? (AP24) [JLS] If the message is just a broadcast then I would not expect A to wait for a response. Yes what you suggest would solve the issue, it would also solve the issue if you decided that this is totally reasonable as A should not expect its message to be processed after it has left the group. [FP] Ok, we will formulate something about that (taking into considerations both possibilities). (AP24) ----------------------------------------- Mail regarding draft-ietf-ace-key-groupcomm - 04/04/2019 03:42 Some additional things that need to be thought about. 1. Someplace as part of the re-key discussions there ought to be some commentary on the wisdom of rate limiting the frequency of doing re-keying operations. Ok, we can expand on some considerations that are now just quickly mentioned. Our proposal is to add that other than rekeying due to membership changes (if relevant to the application), periodic rekeying should occur at the minimum rate necessary to discourage an adversary to derive the key material out of brute force and traffic collection/analysis. (AP27) [JLS] The case that I was actually thinking about was the membership change rekeying. If you have 30 joins in the course of a minute, you might want to delay the rekey messages slightly or make the presumption that there is not traffic that needs to be protected on a backwards basis to the first join. Similar issues will arise for leaves. [FP] Ah ok, thanks for the clarifications. We will definitely add some considerations about that. (AP27) 3. What happens in the following situations: a) The key context is changed between a request being sent and the server receiving the request. This could just be because the sender did not get the notification of the key context changing. b) The response takes "a while" to generate and the key context is changed after the request is received, but before the response is sent. Situations a) and b) are essentially the same, with the difference that they happen either on client or on server (the node receives a message encrypted with old/non recognized context). What happens in that case is that the receiver would contact the KDC to verify that its own keying material has not being updated (using the new “update” method defined in point 32). When it realizes it has the latest one, it discards the message, and optionally sends back an error response (in case a) that would hint that the message did not go through. In case b), when verification fails on the client, I would expect the client to be configured to try again, and this time it should hit the new security context on the server. See also https://core-wg.github.io/oscore-groupcomm/draft-ietf-core-oscore-groupcomm.html#rfc.section.8.4about keeping old security context for a while. Did you want the same type of considerations in ace-key-groupcomm as well? [JLS] In the first case it is a simple race condition and some type of configurable keep the last context for a while does deal with this. The second case is a bit different in terms of – does the response get sent under the new context, the old context or not at all. I don’t know that I have any idea of what the right answer is and having this described would be useful. [FP] Ok, for the first case we will add these type of considerations here. (AP40). I understand better your case b): the request is actually accepted. We would say: if there are policies for keeping the old context for a while, it could be accepted that the server protects the response with the new sec ctx. In the general case, it would discard. It definitely need to be described (AP41) c) The key context is changed in the middle of a block-wise transfer. To me this is no different than the cases above. If one block fails, the total message would fail. Considerations above apply. Do you think we need additional considerations about blockwise here? [JLS] One could say that the sender of the blocks just changes the keys and continues. As long as both sides get the new keying I don’t think that this would cause a problem. But again yes it has much of the same issues as above although it does have fun that it applies to both the sender and the recipient. It is more problematic than the above message in that depending on how fast keys are changed, you are going to consume a large amount of the network resending the message from start again and again. This is more of a problem than it is for case b above. [FP] That’s right. We will try to sketch some considerations about this as well (AP42). Jim -------------
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
