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

[Catherine Meadows <[e-mail]>]

Thanks much, Robert and Peter!

These make things much clearer.

Cathy


Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: [phone]
fax: [phone]
email: [e-mail]

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

> Hi Catherine,
> 
> In addition to Peter's comments, here are my comments inline, bracketed by <RCC></RCC>
> 
> Robert
> 
> On 06/04/2015 22:37, Catherine Meadows wrote:
>> 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.
> <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>
>> 
>> 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. 
> <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>
>> 
>> 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)?
> <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>
>> 
>> 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?
> <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>
> 
>> 
>> 
>> 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.
> <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>
>> 
>> 
>> I consider this document  ready with issues.
>> 
>> Catherine Meadows
>> Naval Research Laboratory
>> Code 5543
>> 4555 Overlook Ave., S.W.
>> Washington DC, 20375
>> phone: [phone]
>> fax: [phone]
>> email: [e-mail]
>> 
>> 
>> 
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
>