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 protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
