Subject: Re: [Ace] draft-somaraju-ace-multicast

From: Somaraju Abhinav <[email-masked]>
Date: Thu, 2 Feb 2017 11:48:17 +0000

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
[email-masked]
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.

---

From: Jim Schaad <[email-masked]>
Date: Fri, 3 Feb 2017 10:02:42 -0800

See comments inline

From: Ace [mailto:[email-masked]] On Behalf Of Somaraju Abhinav
Sent: 02 February 2017 03:48
To: Jim Schaad <[email-masked]>;
[email-masked]
Cc: 'ace' <[email-masked]>
Subject: Re: [Ace] draft-somaraju-ace-multicast

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.

[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.

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.  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.

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.

[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.

[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] 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.

_______________________________________________
Ace mailing list
[email-masked] <mailto:[email-masked]> 
 <https://www.ietf.org/mailman/listinfo/ace>
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.

---

From: Somaraju Abhinav <[email-masked]>
Date: Sat, 4 Feb 2017 15:46:43 +0000

[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.

[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.

[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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

---

From: Somaraju Abhinav <[email-masked]>
Date: Mon, 6 Feb 2017 20:00:51 +0000

Jim, All,

please see a proposal for the Applicability statement that can be used as a starting point for the Webex.

Abhinav

5.1 Applicability statement

This document describes two architectures based on symmetric group keys in Section 3 and asymmetric keys in Section 4.

The symmetric key solution is based on a group key that is shared between all group members including senders and receivers.  As all members of the group posses the same key, it is only possible to   authenticate group membership for the source of a message. In   particular, it is not possible to authenticate the unique source of a   message and consequently it is not possible to authorize a single node to control a group. This implies in particular that any hacked receiver in a group could then be used to control all the receivers in the group.

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.

The asymmetric key solution distinguishes between a sender in the group and the receivers. In particular, the sender is in possession of a private key and the receivers are in possession of the corresponding public key.  This allows the unique source of any group message to be authenticated. Moreover, an attacker cannot compromise   the system by breaking into any of the receiving nodes. However, for constrained devices, the asymmetric key solution comes at a processing cost with cryptographic computations taking rather long.

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.

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.

________________________________
From: Jim Schaad <[email-masked]>
Sent: Friday, February 3, 2017 7:02:42 PM
To: Somaraju Abhinav; [email-masked]
Cc: 'ace'
Subject: RE: [Ace] draft-somaraju-ace-multicast

See comments inline

From: Ace [mailto:[email-masked]] On Behalf Of Somaraju Abhinav
Sent: 02 February 2017 03:48
To: Jim Schaad <[email-masked]>; [email-masked]
Cc: 'ace' <[email-masked]>
Subject: Re: [Ace] draft-somaraju-ace-multicast

Hi Jim,

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.  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.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 7 Feb 2017 20:38:37 -0500

I haven't had a chance to comment on the document, but I have a few 
comments on the below that will depend on getting the requirements correct.

In the introduction of the document you list three requirements and Jim 
has taken you to task for them.  There are actually four requirements, 
one of which no one is willing to state in this document.  The fourth 
being "The security can't cost anything in terms of either latency or 
hardware assistance" - or something similar.  Otherwise, we wouldn't be 
having the argument about symmetric key multicast.

Finally, we're missing an actual security requirement that may or may 
not be optional:  "The compromise of any given end point will not give 
the attacker more privileges in the group that the compromised end point 
nominally has been granted".  This one is where the applicability 
statement comes in.

On 2/6/2017 3:00 PM, Somaraju Abhinav wrote:
> This document describes two architectures based on symmetric group 
> keys in Section 3 and asymmetric keys in Section 4.
>
>
> The symmetric key solution is based on a group key that is shared 
> between all group members including senders and receivers.  As all 
> members of the group posses the same key, it is only possible to   
> authenticate group membership for the source of a message. In   
> particular, it is not possible to authenticate the unique source of 
> a   message and consequently it is not possible to authorize a single 
> node to control a group. This implies in particular that any hacked 
> receiver in a group could then be used to control all the receivers in 
> the group.
>
>
> 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.
>
>
> The asymmetric key solution distinguishes between a sender in the 
> group and the receivers. In particular, the sender is in possession of 
> a private key and the receivers are in possession of the corresponding 
> public key.  This allows the unique source of any group message to be 
> authenticated. Moreover, an attacker cannot compromise   the system by 
> breaking into any of the receiving nodes. However, for constrained 
> devices, the asymmetric key solution comes at a processing cost with 
> cryptographic computations taking rather long.
>
See below - you need to provide some proof of this.  Or at least figure 
out the asymmetric key size and implementation where it takes too long.

>
> 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.
>

This paragraph is pretty much wishful thinking and hand waving. It makes 
an unproved assumption that source authentication is too expensive (in 
latency or hardware) and that some measure of security may be gained by 
using the group key to protect the group message integrity - including 
the control messages.

Even a weak asymmetric key (which evidence suggests *can* be used in a 
manner to meet latency requirements)  will provide a more secure source 
authentication mechanism than a symmetric key system.

>
> 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.
>

Seriously - no.   To validate a MAC signed object, you need the MAC key 
which means you can forge things as if they came from the MAC key 
owner.  Unless you're talking specifically about pair-wise MAC keys, 
this makes no sense whatsoever.

For the meeting, what I'd like to hear about is:

1) The actual minimum latency value and how it was picked.
2) The target minimum hardware and how it was picked.
3) The security policy for "Controlling luminaries in a non-emergency 
application".  E.g. Do you actually care about security here, or is this 
just marketing?  Or put another way, what security assurances do you get 
from implementing symmetric key multicast in a control system?  What is 
the liability to the product provider if the system is hacked?  What's 
the detection mechanism for figuring out you've been hacked (besides the 
obvious one of the lights going on and off without the switch being 
thrown)?  Can this protocol be used in this specific mode for any other 
application - and if so, which ones?

---

From: Jim Schaad <[email-masked]>
Date: Tue, 7 Feb 2017 19:03:26 -0800

See Below

From: Somaraju Abhinav [mailto:[email-masked]] 
Sent: Monday, February 6, 2017 12:01 PM
To: Jim Schaad <[email-masked]>;
[email-masked]
Cc: 'ace' <[email-masked]>
Subject: Re: [Ace] draft-somaraju-ace-multicast

Jim, All,

please see a proposal for the Applicability statement that can be used as a
starting point for the Webex.

Abhinav

[JLS] Did you actually change anything from the current document.  At first
glance it looks like a cut and paste with absolutely no response to any of
the issues that have been raised on the list.

[JLS] This should have a description of the criteria which should be used to
determine if any of the solutions here are needed.  Without this
information, it seems that the solution could be applied to anything.  Is
this really just a lighting solution or is it a more general solution?

This document describes two architectures based on symmetric group keys in
Section 3 and asymmetric keys in Section 4. 

[JLS] Based on the mails we have exchanged; this statement is either wrong
or insufficiently qualified.  You have stated that even the messages in
section 4 need to be encrypted and thus might have a group key.

The symmetric key solution is based on a group key that is shared between
all group members including senders and receivers.  As all members of the
group posses the same key, it is only possible to   authenticate group
membership for the source of a message. In   particular, it is not possible
to authenticate the unique source of a   message and consequently it is not
possible to authorize a single node to control a group. This implies in
particular that any hacked receiver in a group could then be used to control
all the receivers in the group. 

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.

[JLS] Losing power is going to lead to potentially very long delays at power
and missed processing of messages if every recipient needs to individually
generate a new dynamic key and distribute it, not to mention the potential
problems with the question of who has good randomness for the generation of
new keys.

[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.

The asymmetric key solution distinguishes between a sender in the group and
the receivers. In particular, the sender is in possession of a private key
and the receivers are in possession of the corresponding public key.  This
allows the unique source of any group message to be authenticated. Moreover,
an attacker cannot compromise   the system by breaking into any of the
receiving nodes. However, for constrained devices, the asymmetric key
solution comes at a processing cost with cryptographic computations taking
rather long.   

[JLS] The last sentence does not belong here.  The term "rather long" is
extremely vague and is even worse than the term "low-latency" in terms of
what has been defined.

[JLS] Should also know that the sender that was compromised is immediately
known and can be dealt with.

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.

[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?

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.

[JLS] As stated above, I am not sure how keeping keys in volatile memory
will be a mitigating factor.  The only think that I see is that I cannot
physically steal the device and work on it later rather than having to do it
"in place".

  _____  

From: Jim Schaad <[email-masked] <mailto:[email-masked]> >
Sent: Friday, February 3, 2017 7:02:42 PM
To: Somaraju Abhinav; [email-masked]
<mailto:[email-masked]> 
Cc: 'ace'
Subject: RE: [Ace] draft-somaraju-ace-multicast 

See comments inline

From: Ace [mailto:[email-masked]] On Behalf Of Somaraju Abhinav
Sent: 02 February 2017 03:48
To: Jim Schaad <[email-masked] <mailto:[email-masked]> >;
[email-masked]
<mailto:[email-masked]> 
Cc: 'ace' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Ace] draft-somaraju-ace-multicast

Hi Jim,

---

From: Somaraju Abhinav <[email-masked]>
Date: Thu, 9 Feb 2017 10:46:31 +0000

Comment inline

Jim, All,

Abhinav

[JLS] Did you actually change anything from the current document.  At first glance it looks like a cut and paste with absolutely no response to any of the issues that have been raised on the list.

[AS] We have changes from the current document. I have highlighted in red below the changes.

[JLS] This should have a description of the criteria which should be used to determine if any of the solutions here are needed.  Without this information, it seems that the solution could be applied to anything.  Is this really just a lighting solution or is it a more general solution?

[AS] We are mainly interested in the lighting application. The only other field I am aware of is blinds but I do not know enough about their requirements. It will be interesting to hear from others if they have applications where this is interesting.

[JLS] Based on the mails we have exchanged; this statement is either wrong or insufficiently qualified.  You have stated that even the messages in section 4 need to be encrypted and thus might have a group key.

[AS] Fair point. This is the current status. Will have to fix this part.

[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] Losing power is going to lead to potentially very long delays at power and missed processing of messages if every recipient needs to individually generate a new dynamic key and distribute it, not to mention the potential problems with the question of who has good randomness for the generation of new keys.

[AS] Agree. See comment above. We can remove it if the group consensus is that it does not help.

[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] The last sentence does not belong here.  The term “rather long” is extremely vague and is even worse than the term “low-latency” in terms of what has been defined.

[AS] Will discuss this point during the call today.

[JLS] Should also know that the sender that was compromised is immediately known and can be dealt with.

[AS] Okay. Will add this point.

[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] 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] 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] As stated above, I am not sure how keeping keys in volatile memory will be a mitigating factor.  The only think that I see is that I cannot physically steal the device and work on it later rather than having to do it “in place”.

[AS] Yes, this is about physically stealing devices not helping.

From: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Sent: Friday, February 3, 2017 7:02:42 PM
To: Somaraju Abhinav; [email-masked]<mailto:[email-masked]>
Cc: 'ace'
Subject: RE: [Ace] draft-somaraju-ace-multicast

See comments inline

From: Ace [mailto:[email-masked]] On Behalf Of Somaraju Abhinav
Sent: 02 February 2017 03:48
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: 'ace' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] draft-somaraju-ace-multicast

Hi Jim,

---

From: Jim Schaad <[email-masked]>
Date: Fri, 10 Feb 2017 13:54:03 -0800

See inline

Sent: Thursday, February 9, 2017 2:47 AM

Comment inline

Jim, All,

Abhinav

[AS] We have changes from the current document. I have highlighted in red
below the changes.

[AS] We are mainly interested in the lighting application. The only other
field I am aware of is blinds but I do not know enough about their
requirements. It will be interesting to hear from others if they have
applications where this is interesting. 

[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] Agree. See comment above. We can remove it if the group consensus is
that it does not help.  

[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] 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] See comment above. 

[JLS] which see above are you referring to.  It is not obvious to me.

[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.

  _____  

See comments inline

Hi Jim,

---

From: Somaraju Abhinav <[email-masked]>
Date: Tue, 14 Feb 2017 08:40:00 +0000

[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] 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.

[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!

[AS] See comment above.

[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.

[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.