Subject: [secdir] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend)

From: Catherine Meadows <[email-masked]>
Date: Mon, 6 Apr 2015 17:37:42 -0400

I had the draft authors’ email address wrong on my last message, so I am resending it.

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

This document gives recommendations for the use of RPL in home automation and building control,
that typically provide support such things as climate and lighting control.  I reviewed a much earlier
version of this document, and I think this version is much improved in the way it scopes out the problem
and handles the security implications.  The Security Considerations section in particular is very
thorough.  There are a few improvements I would recommend, however:

Section 4.1.8   Security

You should  give justifications for these choices of parameters as you give justifications for the
other parameters described in this draft.

Section 7.1 Security considerations during initial deployment

New approaches to initial security deployment are being developed in
   [I-D.kumar-dice-dtls-relay] and
   [I-D.richardson-6tisch--security-6top].  They assume a partial
   ordering of the nodes, such that unsecured nodes are added
   sequentially with the restriction that a path between two secured
   nodes exists which passes through secured nodes only.

I found this a little hard to understand.  When does a node pass from being unsecured to secured?  Or does an unsecured node remain unsecured? If there is
a succinct way of saying this, it could go here.  Since this is only describing new approaches that could potentially be applied, you would not
want to go into a lot of detail. 

In the home, nodes can be visually inspected by the home owner
   and simple measures like pushing buttons simultaneously on joint and
   joining devices is probably sufficient.

I think this definitely needs to be clarified!  You need to say what is being accomplished by pushing the buttons (device pairing)?

7.2

When nodes are lost, no additional security measures are needed, the
   network remains secure as before by not allowing the addition of new
   nodes.

I’m not sure what this means.  Does it mean that if a node is lost, then it is treated as a “new node” if it reappears, and is not allowed
to rejoin the network?

New nodes can be added by using the same protocols used for
   initial deployment.

This came right after the sentence beginning “When nodes are lost” which said that new nodes are not added.  That contradiction needs to
be reconciled.  I’m also not sure what “using the same protocol” means.  Does it mean rerunning the protocol and rekeying all the nodes, or does
it mean using the features that protocol has for adding nodes?

Nits:

Section 1.1 

This applicability statement
   recommends more light weight security solutions and specify the
   conditions under which these solutions are appropriate.

Should be “specifies” instead of “specify”.  I’m also not sure what is meant by “conditions under which these solutions are appropriate.”  Do
you mean light-weight as opposed to no security, or light-weight as opposed to heavy-weight.  Or are you talking about conditions
under which different light-weight solutions are appropriate? From reading the rest of the draft, I would assume the last is what you mean.

I consider this document  ready with issues.

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: [email-masked]

---

From: peter van der Stok <[email-masked]>
Date: Tue, 07 Apr 2015 12:02:48 +0200

Hi Catherine,

thanks for pointing out sources of misunderstanding. Below some 
suggestions for new text.

Considering the values of section 4.1.8; I will look for an RFC that 
explains in more detail and cite that.
@Robert, can you recommend a RFC?

<old>
>  nodes exists which passes through secured nodes only.
</old>
<new>
New approaches to initial security deployment are being developed in
  [I-D.kumar-dice-dtls-relay] and
   [I-D.richardson-6tisch--security-6top]. In these drafts an already 
secured node assists in securing an unsecured 1-hop neighbour node.
Like an onion, a new layer of unsecured nodes is secured by a former 
layer of already secured nodes until all selected nodes are secured.
</new>

<old>
>  joining devices is probably sufficient.
</old>
<new>
In the home, nodes can be visually inspected by the home owner
  and simple measures like pushing buttons simultaneously on joint and
  joining devices are probably sufficient to guarantee that keys are 
exchanged between the two nodes without major risks of security 
breaches.
</new>

<old>
>  network remains secure as before by not allowing the addition of new
</old>
<new>
  When nodes are lost, no additional security measures are needed, the
  network remains secure as before by considering the lost nodes as new 
nodes which have to pass through the join process.
</new>

Thanks for finding the NIT.

I hope the new text above clarifies the obscure points you found.

Greetings,

Peter

Catherine Meadows schreef op 2015-04-06 23:37:
> I found this a little hard to understand. When does a node pass from
> being unsecured to secured? Or does an unsecured node remain
> unsecured? If there is
> a succinct way of saying this, it could go here. Since this is only
> describing new approaches that could potentially be applied, you would
> not
> I think this definitely needs to be clarified! You need to say what is
> being accomplished by pushing the buttons (device pairing)?
> 
> 7.2
> 
> I’m not sure what this means. Does it mean that if a node is lost,
> then it is treated as a “new node” if it reappears, and is not
> allowed
> to rejoin the network?
> 
> This came right after the sentence beginning “When nodes are lost”
> which said that new nodes are not added. That contradiction needs to
> be reconciled. I’m also not sure what “using the same protocol”
> means. Does it mean rerunning the protocol and rekeying all the nodes,
> or does
> Should be “specifies” instead of “specify”. I’m also not
> sure what is meant by “conditions under which these solutions are
> appropriate.” Do
> you mean light-weight as opposed to no security, or light-weight as
> opposed to heavy-weight. Or are you talking about conditions
> under which different light-weight solutions are appropriate? From
> reading the rest of the draft, I would assume the last is what you
> mean.
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Robert Cragie <[email-masked]>
Date: Tue, 07 Apr 2015 15:40:49 +0100

Hi Catherine,

In addition to Peter's comments, here are my comments inline, bracketed 
by <RCC></RCC>

Robert

> other parameters described in this draft.
<RCC>
The parameters are in RFC 6550. Some explanation could be added, for 
example:

<new>
If RPL is used with secured messages, the following RPL security 
parameter values are recommended to provide a basic level of security:

    o  Counter Time Flag: T = '0': Do not use timestamp in the Counter 
Field. Counters based on timestamps are typically more applicable to 
industrial networks where strict timing synchronization between nodes is 
often implemented. Home and building networks typically do not implement 
such strict timing synchronization therefore a monotonically increasing 
counter is more appropriate.

    o  Algorithm = '0': Use Counter with Cipher Block Chaining Message 
Authentication Code (CBC-MAC Mode) (CCM) with Advanced Encryption 
Standard (AES)-128. This is the only assigned mode at present.

    o  Key Identifier Mode; KIM = '10': Use group key, Key Source 
present, Key Index present. Given the relatively confined perimeter of a 
home or building network, a group key is usually sufficient to protect 
RPL messages sent between nodes. The use of the Key Source field allows 
multiple group keys to be used within the network.

    o  Security Level; LVL = 0: Use MAC-32. This is recommended as 
integrity protection for RPL messages is the basic requirement. 
Encryption is unlikely to be necessary given the relatively 
non-confidential nature of RPL message payloads.
</new>
</RCC>
> describing new approaches that could potentially be applied, you would not
<RCC>
I would clarify as follows, in addition to Peter's suggestion:

<old>
New approaches to initial security deployment are being developed in 
[I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. 
They assume a partial ordering of the nodes, such that unsecured nodes 
are added sequentially with the restriction that a path between two 
secured nodes exists which passes through secured nodes only.
</old>
<new>
New approaches to initial security deployment are being developed in 
[I-D.kumar-dice-dtls-relay] and[I-D.richardson-6tisch-security-6top]. In 
these drafts an already secured node at the perimeter of the network, 
which is one hop away from an unsecured node wishing to access the 
network, assists in transporting security and configuration traffic 
between the unsecured node and the authenticator/commissioner. Once 
secured and configured, the new node extends the perimeter of the 
network in an "onion ring" fashion until all nodes have been secured and 
configured.
</new>
</RCC>
> I think this definitely needs to be clarified!  You need to say what 
> is being accomplished by pushing the buttons (device pairing)?
<RCC>
I would clarify as follows, in addition to Peter's suggestion:

<old>
In the home, nodes can be visually inspected by the home owner and 
simple measures like pushing buttons simultaneously on joint and joining 
devices is probably sufficient.
</old>
<new>
In the home, nodes can be visually inspected by the home owner and a 
simple procedure, e.g. pushing buttons simultaneously on an already 
secured device and an unsecured joining device is usually sufficient to 
ensure that the unsecured joining device is authenticated and configured 
securely, and paired appropriately.
</new>
</RCC>
> then it is treated as a “new node” if it reappears, and is not allowed
> to rejoin the network?
>
> means.  Does it mean rerunning the protocol and rekeying all the 
> nodes, or does
<RCC>
I would rewrite this somewhat as the intent is unclear. I believe the 
intent is as follows:

<old>
When nodes are lost, no additional security measures are needed, the 
network remains secure as before by not allowing the addition of new 
nodes. New nodes can be added by using the same protocols used for 
initial deployment.  Some protocols may need a state change to a subset 
of the secured nodes, other protocols only need the presence of a 
"trusted" installation node [RFC6345], [RFC5191], or 
[I-D.kumar-dice-dtls-relay].
</old>
<new>
Normally, the network remains secure by not allowing the addition of new 
nodes. If a new node needs to be added to the network, the network is 
usually configured to allow the new node to join via an assisting node 
in the manner described in Section 7.1. If an existing node becomes 
lost, it is usually possible to re-key all other existing nodes to 
isolate the lost node to ensure that, should it be found again, it has 
to re-join as if it were a new node.
</new>
</RCC>

> Should be “specifies” instead of “specify”.  I’m also not sure what is 
> meant by “conditions under which these solutions are appropriate.”  Do
> reading the rest of the draft, I would assume the last is what you mean.
<RCC>
I would reword as follows:

<old>
This applicability statement recommends more light weight security 
solutions and specify the conditions under which these solutions are 
appropriate.
</old>
<new>
This applicability statement recommends lighter weight security 
solutions appropriate for home and building environments and indicates 
why these solutions are appropriate.
</new>
</RCC>
> <mailto:[email-masked]>
>
>
>

---

From: Catherine Meadows <[email-masked]>
Date: Wed, 8 Apr 2015 18:29:34 -0400

Thanks much, Robert and Peter!

These make things much clearer.

Cathy

Catherine Meadows

On Apr 7, 2015, at 10:40 AM, Robert Cragie <[email-masked]> wrote:

> Hi Catherine,
> 
> In addition to Peter's comments, here are my comments inline, bracketed by <RCC></RCC>
> 
> Robert
> 
> The parameters are in RFC 6550. Some explanation could be added, for example:
> 
> <new>
> If RPL is used with secured messages, the following RPL security parameter values are recommended to provide a basic level of security:
> 
>    o  Counter Time Flag: T = '0': Do not use timestamp in the Counter Field. Counters based on timestamps are typically more applicable to industrial networks where strict timing synchronization between nodes is often implemented. Home and building networks typically do not implement such strict timing synchronization therefore a monotonically increasing counter is more appropriate.
> 
>    o  Algorithm = '0': Use Counter with Cipher Block Chaining Message Authentication Code (CBC-MAC Mode) (CCM) with Advanced Encryption Standard (AES)-128. This is the only assigned mode at present.
> 
>    o  Key Identifier Mode; KIM = '10': Use group key, Key Source present, Key Index present. Given the relatively confined perimeter of a home or building network, a group key is usually sufficient to protect RPL messages sent between nodes. The use of the Key Source field allows multiple group keys to be used within the network.
> 
>    o  Security Level; LVL = 0: Use MAC-32. This is recommended as integrity protection for RPL messages is the basic requirement. Encryption is unlikely to be necessary given the relatively non-confidential nature of RPL message payloads.
> </new>
> </RCC>
>> 
> New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and [I-D.richardson-6tisch--security-6top]. They assume a partial ordering of the nodes, such that unsecured nodes are added sequentially with the restriction that a path between two secured nodes exists which passes through secured nodes only.
> </old>
> <new>
> New approaches to initial security deployment are being developed in [I-D.kumar-dice-dtls-relay] and[I-D.richardson-6tisch-security-6top]. In these drafts an already secured node at the perimeter of the network, which is one hop away from an unsecured node wishing to access the network, assists in transporting security and configuration traffic between the unsecured node and the authenticator/commissioner. Once secured and configured, the new node extends the perimeter of the network in an "onion ring" fashion until all nodes have been secured and configured.
> </new>
> </RCC>
>> 
> In the home, nodes can be visually inspected by the home owner and simple measures like pushing buttons simultaneously on joint and joining devices is probably sufficient. 
> </old>
> <new>
> In the home, nodes can be visually inspected by the home owner and a simple procedure, e.g. pushing buttons simultaneously on an already secured device and an unsecured joining device is usually sufficient to ensure that the unsecured joining device is authenticated and configured securely, and paired appropriately.
> </new> 
> </RCC>
>> 
>> 7.2
>> 
> I would rewrite this somewhat as the intent is unclear. I believe the intent is as follows:
> 
> <old>
> When nodes are lost, no additional security measures are needed, the network remains secure as before by not allowing the addition of new nodes. New nodes can be added by using the same protocols used for initial deployment.  Some protocols may need a state change to a subset of the secured nodes, other protocols only need the presence of a "trusted" installation node [RFC6345], [RFC5191], or [I-D.kumar-dice-dtls-relay].
> </old>
> <new>
> Normally, the network remains secure by not allowing the addition of new nodes. If a new node needs to be added to the network, the network is usually configured to allow the new node to join via an assisting node in the manner described in Section 7.1. If an existing node becomes lost, it is usually possible to re-key all other existing nodes to isolate the lost node to ensure that, should it be found again, it has to re-join as if it were a new node.
> </new>
> </RCC>
> 
>> 
>> 
>> Nits:
>> 
>> Section 1.1 
>> 
> This applicability statement recommends more light weight security solutions and specify the conditions under which these solutions are appropriate.
> </old>
> <new>
> This applicability statement recommends lighter weight security solutions appropriate for home and building environments and indicates why these solutions are appropriate.
> </new>
> </RCC>
>> 
>>