Moreover, because the group key is shared across multiple nodes, it may be easier for an attacker to determine the group key by attacking any member of the group (note that this group key is dynamically generated and is usually stored in volatile memory which offers some additional protection). The probability of a stolen key increases with the number of nodes that are in possession of the key. Moreover, subsequent to such an attack, it is also difficult to determine which of the group members was compromised and this makes it difficult to return the system to normal operation after an attack.
[JLS] I have no idea why storing a key in volatile memory would offer additional protections. [AS] This prevents the case of removing a device from the physical location and figuring out the group key. Not sure if it helps too much. We can remove it if the group consensus is that it does not help. [JLS] I have my doubts about this helping much for a lot of devices. Starting with those which are not on an external power supply, for instance my phone. Does this keep it in volatile memory or run the protocol to get the group key each time it needs it? This just does not seem to be a reasonable answer. [AS] I tend to agree with you. Will discuss this with the authors and maybe we can remove this for the next version of the draft. [JLS] Which group members are/were compromised. You don’t know that it has gone away. [JLS] This text does not address the questions of size and homogeneity of groups. One of the issues that has been brought up is about using the same key for multiple types of devices such as lights and doors. [AS] The specification does not allow the same key to be given out for multiple types of devices. All tokens are linked to a scope and an application group. You can not use the same key for two different applications. But you make a good point. We can add this to the applicability statement. [JLS] I do not remember ever seeing this. It is not part of the definition of an application group. Where is it? [AS] The key is always provided within the AT-R token. In Section 3.2 and 3.3 we have the text " 3. Scope: Permissions of the entity holding the token. This includes information about the resources that may be accessed with the token (e.g., access level) and application layer group IDs for the groups for which the tokens may be used.". I agree that these two sections need a bit more text but we were waiting for the ACE-OAuth and CWT draft to be further along and reference those drafts about how to specify the scope. Therefore, it is recommended that whenever possible, the architecture with source authentication SHOULD be used to secure all multicast communication. However, in less sensitive applications where low-latency group communication is important (e.g. controlling luminaires in non-emergency applications), the architecture without source authentication MAY be used. In sensitive applications such as health and safety, building security and emergency applications the symmetric key based solution SHOULD not be used. [JLS] Personally, I would not know how to test this, so I don’t believe that RFC 2119 language is appropriate. [AS] I agree that this is not testable. But I not sure how we should proceed here. Any suggestions would be great. One of the big objections has been "what if this solution is used for something else" and that guidance should be provided as to where this specification should be used and more importantly not used. [JLS] Part of this is going to be the question of if you believe that case matters, if it does then changing SHOULD to should is fine. I note that you do not have a reference to 2119 in the document currently so I guess in that respect it is academic. If you believe that case matters, then you can play games with English do things like use ‘ought’ rather than ‘should’. [AS] Okay. Will try to play English games! [JLS] Why should emergency applications be different? Does this mean that all devices need to implement both solutions and need to figure out which of the solutions should be used at any given time? What defines a sensitive application? The ability to monitor a sensor even if the state of the lights is not? [AS] See comment above. [JLS] which see above are you referring to. It is not obvious to me. [AS] I was referring to the comments about sensitive applications and the RFC2119 language. One of the applications that people objected to using group symmetric key is emergency and therefore we mention the symmetric architecture should not be used. With regards to implementing both solutions, we do need all devices to implement both symmetric and asymmetric crypto suites. Having said that, I do not think any luminaiers will implement both the architectures in Sections 3 and 4. Emergency applications generally do not need low latency multicast - usually emergency applications have little to no communication - the lights just turn on when loss of power is detected. Most of the communication after the lights go on probably use unicast serial communication. When using the symmetric key solution two mitigating factors could improve system security. It is possible to achieve source authentication of messages at lower layers by requiring unique MAC layer keys for all devices within the network. The symmetric group keys are dynamically generated and therefore SHOULD be stored in volatile memory. [JLS] Given the fact that it is “easy” to impersonate MAC addresses I am not sure how this will mitigate the problem. This would be killed by either MAC impersonation or having a message re-transmitted by a proxy agent. [AS] This was an idea for Eliot Leer. The idea is to have pairwise MAC layer keys and this has nothing to do with MAC addresses. It is to do with traceability of messages after an attack is detected so that the source of the multicast message can be determined. Maybe Eliot can comment more about this. [JLS] Ok – How does this help? Since I assume that you are not planning to make this a pairwise MAC key, then it just means that I have to steal one more key from the device as well. Oh look, the device has all of the MAC keys as well as the group key so it is not a real problem. [AS] No, Eliot was referring to networks that have pairwise MAC layer keys and not shared MAC layer keys across the network. ________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
