Why restriction on reading messages? It is not like an external observer is not going to be able to see the lights go on or off. [AS] There are several situations where lights are not visible but (multicast) network data is accessible. Moreover, sensors (e.g. presence detectors) are continuously talking to actuators and controllers without necessarily having a visible effect on the lights. For several customers privacy is a very important concern and is almost a given. The statement "anybody can listen to the traffic and tell when sensors detect presence in a building without even being in the building" is a very difficult sell. Having said that, it is true that simply encrypting the multicast traffic at the application layer is only a prerequisite to provide the privacy needed and additional work is required (e.g. generating random messages at different times). In that sense the symmetric solution is probably not much better than the asymmetric solution. But the demand for privacy from customers is very clear and the perception among them is that unencrypted data implies poor security.
[JLS] I am sensing a problem here. You have stated that there is a requirement that encryption is a requirement that people are going to say must be me. However, below you have stated that if authentication is a requirement then encryption suddenly becomes a non-requirement? You appear to be stating that there are circumstances where it is fine not to have the data encrypted if one needs to know where it came from. Consider the following case I have a sensor in a room. When the sensor sees movement, it broadcasts a lights one command. The command is picked up by both the lightbulbs and by the security system. The security system must know which sensor provided the command and therefore no encryption is going be needed here? That just seems wrong. [AS] No, we are not suggesting that encryption is a non-requirement if (source) authentication is a requirement. I was just merely pointing out below that encryption would add additional latency in the asymmetric case. We take your point that our current draft does not have encryption specified in the asymmetric solution. We will add the possibility of encrypting with a group key in addition to the authentication in the asymmetric architecture in the next version of the draft. Additionally, the situation where things are “continuously” talking would seem to be a good place where one would want to install a controller and not have the sensor directly talking to the actuator. You don’t want to flood the actuators with trying to constantly turn on the lights. [AS] You make a good point. However, the lighting deployments are very varied. We will always have sensors talking to control functions which in turn talk to actuators. The main question is where is a control function, which is just a piece of software, deployed. In bigger installations, we typically have more centralized controls on dedicated hardware. In smaller installations, the control function software could be running directly on the luminaire hardware. In this case the sensors talk to the luminaires directly even though they are talking to a control function. At manufacturing time, we typically do not know the type of installations the luminaires/sensors would end up in. So, we have to usually take care of both situations with a stacked controller approach where bigger controllers take over if available. Also the use of actuators in this sense makes one think that this is a solution for things other than lighting systems which is what people are complaining about. [AS] This is not the intention. We can put this in the security guidelines section. The solution in section 4 does not seem to meet the following requirement "Only authorized members of the application group must be able to read and process messages." [AS] You are right, we cannot satisfy the privacy requirement in Section 4. We could extend the current solution to include a group wide encryption key to meet this requirement. However, this will add additional latency to the asymmetric solution. This document needs to have a solution for dealing with nonce space allocation for the cases where more than one sender is going be able to use the same key. This is going to be part of the problems with replay detection as well as security considerations. [AS] Okay. Will add some text in the next version of the draft for better clarification. The idea as written in 4.3 (Nonce value) is to use the Client ID along with the sender’s sequence number to create the complete nonce for replay and CCM processing. Should the algorithms be using high water detection of sequence numbers rather than the case of not yet used? Or is that an application specific type thing? [SK] This is tricky since it can create all kind of new issues. One way to handle if the sequence number of a sender is about to roll over is that the sender requests a new key issued for the group by the KDC. Tricky part is if there are multiple senders who are not reaching the roll over of their sequence number then have to be forced to use a new key or there needs to be some overlap between the old key and new key before every sender in the group starts using the new key. [JLS] Lots of spinning in graves from the idea of having a sequence number roll over given the harsh requirements that a nonce (built from the sequence number) must never be re-used twice for many of the algorithms that are going to be used here. [AS] Definitely we will not have sequence numbers rolling over. The current proposal is that a concatenation of a [Unique client ID] and [individual client sequence number] form the nonce. The only point of debate is whether we want to roll over keys for all senders if the sequence number space of one client is exhausted. Note that because the (unique) client ID is always a part of the nonce, we will never have re-use of the same nonce. I do not think that the current security requirements is sufficiently strident to reflect both the threat of breakage, cross-breakage and restrictions on where it should be used to pass muster. [AS] I thing this will be the main discussion item in the webex. We will make a proposal for the security guidelines section after the interim webex. [JLS] A proposal before the call is better because then we have a starting point for discussions as well as allowing people who will not make the call be able to have some initial input on where discussions points should be directed. [AS] Okay. I am currently preparing slides for the webex and I will add proposals for what else we can add to the security guidelines section in the slides. _______________________________________________ Ace mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ace ________________________________________________________ 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. ________________________________________________________ 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
