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

[Ben Laurie <[e-mail]>]

On 28 May 2013 07:58, Carsten Bormann <[e-mail]> wrote:
> On May 23, 2013, at 13:48, Ben Laurie <[e-mail]> wrote:
>
>> I would
>> suggest that this section could usefully contain a summary of the
>> security implications of the various constraints discussed.
>
> 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.

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."


>
> 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.

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.

>    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.

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).