Subject: [secdir] Security directorate review of draft-ietf-lwig-terminology-04

From: Ben Laurie <[email-masked]>
Date: Thu, 23 May 2013 12:48:11 +0100

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.

Status: Ready with nits.

This document discusses networks comprised of constrained nodes (i.e.
nodes with limited power, CPU, storage, etc.). It does cover whether
various classes of nodes can participate in secure networks, which is
good, but the Security Considerations section is empty - I would
suggest that this section could usefully contain a summary of the
security implications of the various constraints discussed.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 28 May 2013 08:58:36 +0200

On May 23, 2013, at 13:48, Ben Laurie <[email-masked]> wrote:

> I would

Ben,

thanks for reminding us.

Interestingly, I just put in something like this as a new subsection 11.6 in draft-ietf-core-coap-17, which I have reproduced below. That section is focused on three specific considerations.

I would expect security considerations to be more actionable when discussed in the context of a specific protocol, as opposed to the terminology that is used for describing the constraints.

Doing a more extensive discussion of security implications of constrainedness would be a great document on its own, which maybe we should start looking into in the LWIG WG.  There is also an activity to work on using DTLS properly in constrained environments, which would also benefit from such a document.

So I'm not sure how much we should be putting in the terminology document, but the WG will certainly need to discuss this.  I'm opening a ticket for now.

Grüße, Carsten

11.6.  Constrained node considerations

   Implementers on constrained nodes often find themselves without a
   good source of entropy [RFC4086].  If that is the case, the node MUST
   NOT be used for processes that require good entropy, such as key
   generation.  Instead, keys should be generated externally and added
   to the device during manufacturing or commissioning.

   Due to their low processing power, constrained nodes are particularly
   susceptible to timing attacks.  Special care must be taken in
   implementation of cryptographic primitives.

   Large numbers of constrained nodes will be installed in exposed
   environments and will have little resistance to tampering, including
   recovery of keying materials.  This needs to be considered when
   defining the scope of credentials assigned to them.  In particular,
   assigning a shared key to a group of nodes may make any single
   constrained node a target for subverting the entire group.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 28 May 2013 09:47:45 +0100

> Doing a more extensive discussion of security implications of constrainedness would be a great document on its own, which maybe we should start looking into in the LWIG WG.  There is also an activi…

Sounds like a great idea (and see below).

> So I'm not sure how much we should be putting in the terminology document, but the WG will certainly need to discuss this.  I'm opening a ticket for now.

I made the observation because there are various statements about
security spread throughout the document, so clearly it is a matter
already on your minds, for example:

" Class 0 devices are very constrained sensor-like motes. Most likely
   they will not be able to communicate directly with the Internet in a
   secure manner."

>    to the device during manufacturing or commissioning.

As it happens, I'm a FreeBSD developer and in the wake of the recent
low entropy attacks we had quite some discussion about constrained
nodes ... one thing we thought would be of great benefit was, rather
than create keys during manufacturing, add entropy - i.e. include a
block of randomness in the ROM (or whatever) that's unique per device.
Assuming the device itself is not physically attacked, even quite a
small amount (say 256 bits) would be sufficient for the lifetime of
the device, particularly when mixed with what little is available from
the environment. Note that it is important to mix in a counter of some
kind so the entropy is not re-used unmodified.

>    constrained node a target for subverting the entire group.

This is another reason per-device entropy is useful (clearly nothing
can defend against any particular device that's been tampered with -
for starters, it could easily be replaced with a malicious version).