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

Robert Cragie <robert.cragie@gridmerge.com> Tue, 07 April 2015 14:42 UTC

Return-Path: <robert.cragie@gridmerge.com>
X-Original-To: expand-draft-ietf-roll-applicability-home-building.all@virtual.ietf.org
Delivered-To: roll@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7FD3A1B3667; Tue, 7 Apr 2015 07:42:01 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D221B3665 for <xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com>; Tue, 7 Apr 2015 07:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id makPKBMayyE2 for <xfilter-draft-ietf-roll-applicability-home-building.all@ietfa.amsl.com>; Tue, 7 Apr 2015 07:41:57 -0700 (PDT)
Received: from merlot.tools.ietf.org (merlot.tools.ietf.org [IPv6:2a01:3f0:0:31::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10BC1B3662 for <draft-ietf-roll-applicability-home-building.all@ietf.org>; Tue, 7 Apr 2015 07:41:54 -0700 (PDT)
Received: from mailscan39.extendcp.co.uk ([176.32.230.33]:47511 helo=mailscan1.extendcp.co.uk) by merlot.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84) (envelope-from <robert.cragie@gridmerge.com>) id 1YfUhH-0002ua-Ov for draft-ietf-roll-applicability-home-building.all@tools.ietf.org; Tue, 07 Apr 2015 16:41:52 +0200
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan2.hi.local) by mailscan-g74.hi.local with esmtp (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1YfUgk-0007bn-2G; Tue, 07 Apr 2015 15:41:14 +0100
Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail41.extendcp.co.uk) by mailscan2.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from <robert.cragie@gridmerge.com>) id 1YfUgi-0006UG-Cw; Tue, 07 Apr 2015 15:41:14 +0100
Received: from host86-156-208-9.range86-156.btcentralplus.com ([86.156.208.9] helo=[192.168.0.6]) by mail41.extendcp.com with esmtpsa (UNKNOWN:DHE-RSA-AES128-SHA:128) (Exim 4.80.1) id 1YfUgQ-0007KV-7F; Tue, 07 Apr 2015 15:40:54 +0100
Message-ID: <5523EC71.1020701@gridmerge.com>
Date: Tue, 07 Apr 2015 15:40:49 +0100
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Routing Over Low power and Lossy networks <roll@ietf.org>, secdir@ietf.org, iesg@ietf.org, draft-ietf-roll-applicability-home-building.all@tools.ietf.org
References: <F189CF1A-B989-4326-9B1C-0856164687D7@nrl.navy.mil>
In-Reply-To: <F189CF1A-B989-4326-9B1C-0856164687D7@nrl.navy.mil>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030903090900070502060301"
X-Authenticated-As: robert.cragie@gridmerge.com
X-Extend-Src: mailout
X-SA-Exim-Connect-IP: 176.32.230.33
X-SA-Exim-Rcpt-To: draft-ietf-roll-applicability-home-building.all@tools.ietf.org
X-SA-Exim-Mail-From: robert.cragie@gridmerge.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:57:07 +0000)
X-SA-Exim-Scanned: Yes (on merlot.tools.ietf.org)
Resent-To: draft-ietf-roll-applicability-home-building.all@ietf.org
Resent-Message-Id: <20150407144154.D10BC1B3662@ietfa.amsl.com>
Resent-Date: Tue, 7 Apr 2015 07:41:54 -0700 (PDT)
Resent-From: robert.cragie@gridmerge.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/draft-ietf-roll-applicability-home-building.all@tools/goxa-jt0hUSvqhBnqDm664axwuM>
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/9SL4tD43-WsFOEUvj9sTxi7lbG0>
Cc: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Subject: Re: [Roll] Secdir review of draft-ietf-roll-applicability-home-building-09 (resend)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: robert.cragie@gridmerge.com, Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Apr 2015 14:42:01 -0000

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: 202-767-3490
> fax: 202-404-7942
> email: catherine.meadows@nrl.navy.mil 
> <mailto:catherine.meadows@nrl.navy.mil>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll