Subject: [6lowpan] Issue of the week: Security

From: Carsten Bormann <[email-masked]>
Date: Mon, 17 Mar 2008 15:44:27 +0100

Lowpanners,

as we discussed in Philadelphia, we need to make progress on our new
charter items.  A very important work item that will influence most of
the others is the security model.

First of all, there is the Internet-Draft
draft-daniel-6lowpan-security-analysis-02.txt, which in particular
describes the threats a 6lowpan is subjected to and various existing
specifications that may aid us in countering them.  In Philadelphia, I
said that I would like to see one more round of this document as an
individual contribution and then ask the WG to decide to take it on as
a WG document for charter item 5.  In addition to the existing
authors, Shoichi Sakane and Robert Moskowitz have volunteered to take
an active role in this.

To obtain more input to this document, I would like the mailing list
to discuss four aspects of 6lowpan security this week:

1) end-to-end security.  I have heard a lot of people saying IKE is
too heavy for a 6lowpan node; but there has been little evidence that
ESP can't be made to work.  What would be the right ciphersuite (and
how can we trade off security with our strict packet size
requirements)?  What is the field of application (i.e., where would
even ESP be too heavy)?  What key management solutions make sense here
instead of IKE?

2) where even ESP is too heavy for a node, a border device on the
6lowpan might act as a proxy, doing the heavy lifting.  This might
mean that we use existing AES-CCM on-chip hardware for the
intra-lowpan hop(s), and encapsulate in ESP on the proxy border device
(just as a VPN gateway would do).  Note that none of this is
application-specific, but we still need to understand how to split the
work between the low-capability end node and the security proxy.
(The security proxy might even speak IKE, making this solution more
compatible to today's security gateways in der Internet.)
What key management solutions work right in this three-party system?

3) how do we protect the network?  ND, routing/meshing, and
multicasting need availability protection beyond the end-to-end
integrity/confidentiality that ESP can afford.  In particular, we need
to protect the batteries of the devices.  From simple group keying
solutions to GDOI (see MSEC WG and KMART BOF the previous week), a lot
of alternatives are out there.  What role does the AES-CCM hardware
play here?  What key management solutions work to protect ND and
routing/meshing?  How much battery protection can we achieve?

4) how do the various forms of key management interface to
commissioning?  Commissioning (i.e., the process of "making friends"
as opposed to the process of "finding the friends" and building the
network that we call bootstrapping) will be a process that involves
user interfaces, special buttons on devices, bar code labels,
serial/USB/NFC communication -- clearly mostly outside of the scope of
the communication standards, but with much influence on
interoperability.

When replying to this message, please indicate which of the four items
above (or anything else that I forgot) you are addressing.

Gruesse, Carsten

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan