Subject: [6lowpan] Re: Security considerations section of problem statement

From: Carsten Bormann <[email-masked]>
Date: Wed, 9 Nov 2005 09:35:57 -0800

Lowpanners,

a small editing group met in the Westin Bayshore lobby this morning,  
discussing the security considerations section of the problem  
statement document.

The most recent result of the editing is always at

http://www.writely.com/View.aspx?docid=adt3cwpc9qgf

Below is a current snapshot.

Quick comments would be appreciated, as we really want to close this  
remaining issue on the problem statement document.
(If you want to fix things directly on the Writely page, send me mail.)

Gruesse, Carsten

Security Considerations

6lowpan applications often require confidentiality and integrity  
protection.
This can be provided at the application or transport level, at the  
network layer, and/or at the link layer, i.e. within the 6lowpan set  
of specifications.
In all these cases, 6LoWPAN constraints will influence the choice of  
a particular protocol. Some of the more relevant constraints are  
small code size, low power operation, low complexity, and small  
bandwidth requirements.

It is understandable that these constraints have associated  
tradeoffs. Thus a threat model for 6LoWPAN devices needs to be first  
developed in order to weight any risks against the cost of security  
and at the same time make meaningful assumptions and  
simplifications.  Some examples for threats that would be considered  
are man in the middle attacks, denial of service attacks.

A separate set of security considerations might apply to  
bootstrapping a 6lowpan device into the network, in particular  
initial key establishment processes. This is generally involved with  
other application level transactions and may rely on an application- 
specific trust model; thus it will not be part of 6LoWPAN. Some  
choices may be to use out of band communication techniques such as  
USB, infrared or NFC (Near Field Communication) for the initial key  
establishment.

After the initial key establishment, subsequent key management  
protocols would fall under the purview of 6LoWPAN. In order to be  
able to select (or design) this next set of protocols, there needs to  
be a common model of the keying material created by the initial key  
establishment. There are a few cryptographic protocols to choose  
from. It is to be seen if the protocols available as part of IPsec  
meet the constraints of 6LoWPAN.

One argument for using link layer security is that most IEEE 802.15.4  
chips already have support for AES link layer security.  AES is a  
block cipher operating on blocks of fixed length, i.e., 128 bits. To  
encrypt longer messages, several modes of operation may be used. The  
earliest modes described, such as ECB, CBC, OFB and CFB provide only  
confidentiality, and this does not ensure message integrity. Other  
modes have been designed which ensure both confidentiality and  
message integrity, such as CCM mode, EAX mode and OCB mode. 6LoWPAN  
could choose to operate in one of the modes of operation, but it is  
desirable to utilize as much of link level security as possible and  
build upon it.

For network layer security, two models are applicable: end-to-end  
security, e.g. using IPsec transport mode, or security that is  
limited to the wireless portion of the network, e.g. using a security  
gateway and IPsec tunnel mode.  The disadvantage of the latter is the  
larger header size, which is significant at the 6lowpan frame MTUs.  
To simplify 6lowpan implementations, it would be beneficial to  
identify a preferred set of ciphersuites that are appropriate given  
the 6lowpan constraints.

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

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 09 Nov 2005 11:08:13 -0800

> To simplify

I am not in favor of  security gateway, but if we do, it will not 
necessarily increase the
packet overhead of lowpan  becuase I assume the security gateway will be 
at the edge
of the lowpan network - right ?
If we implement IPSec tunnel mode - in lowpan then there is a 
significant overhead  which
is not desirtable.  Should we even consider IPSec tunnel mode within the 
6lowpan network?  Or does the above mean that  the IPSec tunnel at the 
security gateway?

In conjunction with IPSec, we also need to mention that 6lowpan will 
need to choose an
appropriate key-management scheme applicable for 6lowpan characteristics.

Sorry, I don't have  a replacement text prepared to provide right away.

Regards,
-Samita

> 6lowpan implementations, it would be beneficial to  identify a 
> preferred set of ciphersuites that are appropriate given  the 6lowpan 
> constraints.
>
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 9 Nov 2005 14:02:12 -0800

>> limited to the wireless portion of the network, e.g. using a  
>> security  gateway and IPsec tunnel mode.  The disadvantage of the  
>> latter is the  larger header size, which is significant at the  
>> 6lowpan frame MTUs.  To simplify
>
>
> packet overhead of lowpan  becuase I assume the security gateway  
> will be at the edge

The security gateway is at the edge and converts unsecured packets on  
the outside into secured packets on the inside by encapsulating them  
in ESP.
This is called tunnel mode, so the whole packet is encapsulated, and  
we finally have two IP headers.
The inner IP header, as it is protected (integrity protected and  
encrypted) is not subject to 6lowpan header compression, unless we  
invent a new scheme for compressing within ESP (but see also draft- 
ertekin-rqts-hcoipsec-01.txt).

> is not desirtable.  Should we even consider IPSec tunnel mode  
> within the 6lowpan network?  Or does the above mean that  the IPSec  
> tunnel at the security gateway?

Well, it starts at the security gateway and ends at the 6lowpan  
device in order to secure the 6lowpan part of the path.

In effect, we are making the life of the 6lowpan device harder in  
order to make the life of the extra-6lowpan system easier.
Not a tradeoff I particularly like, which is why I prefer end-to-end  
security (transport mode).

> In conjunction with IPSec, we also need to mention that 6lowpan  
> will need to choose an

Right.
Bob proposed looking at IKEv2 and finding a suitable profile (subset)  
that is small enough implementable in 6lowpan devices.

Gruesse, Carsten