Hi Jim, thank you for the review and I apologise for the delayed response - I was on sick leave due to a surgery. Please see comments inline from the authors.
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. I am not sure what you mean by synchronous manner. Does this mean that the light needs to change state between the command and the response message? (As opposed to an asynchronous manner.) Or do you mean in a synchronized manner where everything happens at a given time relative to the command (which could be all at the same time). [AS] We mean the latter - the lights need to go on and off together and not serially. Will clarify in the next version of the draft. 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. The statement is made that AT-R tokens with references are more efficient from a bandwidth point of view. Does this mean that there is going to be a recommendation that these be provided prior to the first command so that all n devices dereferencing the pointer will not kill the bandwidth? [AS] Good point. Will add the recommendation. 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. How does section 5.2 Token Verification reconcile with the idea of doing references in AT-R tokens? [SK] I guess the current 5.2 should have been in an optimization section and not the security considerations section. In the rest of the document we say that the AT-R is either self-contained or by reference. I guess we wanted to keep both options possible. 5.2 then should only be mentioning about the security considerations when using a self-contained token (like revocation of the token not being known to the verifier). In section 6.3, if a device has multiple security domains, why could they not come from multiple KDCs? [SK] Multiple KDCs are okay. We need to ensure unique Application IDs assigned by different KDC since they indirectly map to the domains The term low latency needs to be much more clearly defined about what it means in this context. In a manufacturing facility, I might have a tighter latency requirement for communicating commands to valves that I would on dealing with lights that might take a while to come on anyway. Does that mean that you feel that this would be an ideal solution for such an environment? The same thing might easily be said for emergency alarms. I want all of them to come on and come on fast in the event of an emergency. A better description of what is meant by low-latency is clearly needed. [AS] Okay. We will try to include more details. In our current implementations we need 200 ms between an event and the action - this leaves about a 100 ms for security processing. We will add this in. 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. _______________________________________________ Ace mailing list Ace@ietf.org 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.
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
