Skip to main content

Early Review of draft-ietf-roll-applicability-home-building-01
review-ietf-roll-applicability-home-building-01-secdir-early-meadows-2013-12-12-00

Request Review of draft-ietf-roll-applicability-home-building
Requested revision No specific revision (document currently at 12)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2015-04-07
Requested 2013-11-28
Authors Anders Brandt , Emmanuel Baccelli , Robert Cragie , Peter Van der Stok
Draft last updated 2013-12-12
Completed reviews Genart Last Call review of -08 by Meral Shirazipour (diff)
Genart Telechat review of -09 by Meral Shirazipour (diff)
Secdir Early review of -01 by Catherine Meadows (diff)
Secdir Telechat review of -09 by Catherine Meadows (diff)
Assignment Reviewer Catherine Meadows
State Completed Snapshot
Review review-ietf-roll-applicability-home-building-01-secdir-early-meadows-2013-12-12
Reviewed revision 01 (document currently at 12)
Result Has Issues
Completed 2013-12-12
review-ietf-roll-applicability-home-building-01-secdir-early-meadows-2013-12-12-00
This is  a resend of my review.  I had incorrectly entered the alias for the
authors and it got bounced.

My apologies to everyone who receives this twice.

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 ID gives recommendations on the use of the RPL protocol in building and
home environments, which are characterized as relatively small networks

that integrate a number of different devices, many including computers, alarm
systems, light switches, remote controls ,etc.  Many of the network

components are resource and power-constrained.   The ID  characterizes the
different types

of networks that can arise in these environments, and gives recommendations
such  as which versions of the protocol to use and how

to set the parameters, depending on the type of home network.

For the security considerations the authors mainly refer the reader to RFC6997,
 RFC6550, and I-D.ietf-roll-trickle-mcast.  However, there is one issue that
these

documents do not cover.  RPL makes the assumption that all the members of the
network share a key, but intentionally does not give any information as to how

the key gets there.  Thus this document includes a section on Security
Considerations for distribution of certificates required by RPL.  It explains
that for RPL the

credential is a shared key, and then goes on to say:

Therefore, there MUST be a mechanism in place which

allows secure distribution of a shared key and configuration of

network identity. Both MAY be done using (i) pre-installation using

an out-of-band method, (ii) delivered securely when a device is

introduced into the network or (iii) delivered securely by a trusted

neighboring device. The shared key MUST be stored in a secure

fashion which makes it difficult to be read by an unauthorized party.

An example of a method whereby this can be achieved is detailed in

[SmartObj]

I found the wording of this confusing.  I took the “this” in the last sentence
to refer to the storage of a key in

a secure fashion, and wondered why it there were no references to means of
achieving secure key distribution.  It wasn’t until I looked at the SmartOb
reference that I found that it

actually was such a reference.  This should be made more clear,

e.g. "An example of a method whereby this secure key distribution can be
achieved in detailed in [SmatObj]."

I notice also that the SmartObj  paper does not seem to be finished (there are
several sections labeled TODO), and that it also

appears to be intended as an Internet Draft.  What is the status of it?  Is it
intended to be developed in tandem with this I-D?

Also, it would be good to be more specific about what is meant by “securely”
here.  For example, the key must be authenticated and kept secret between its
intended users, and must not

be repeated (replay protection).

It might also be helpful to include of a discussion as to when it is more
advantageous to use link encryption or group keys.

In the case that a network consists of both highly security-relevant and
well-protected devices (such as alarm systems), and

non-security relevant and not so well-protected devices (such as TV remotes),
group keying means that either the remote must

be as well-protected as the alarm system, or the entire network must be rekeyed
if the remote is lost.  I don’t whether or not

it would be necessary to give any MUST or SHOULD recommendations, but it would
be helpful to give the reader an understanding

of the issues involved when making decisions about link encryption versus group
keys.  As far as I can see this subject is not addressed

in any of the documents cited at the beginning of the security considerations.

Cathy Meadows

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 at nrl.navy.mil