Network Working Group S. Daniel Park
Internet-Draft SAMSUNG Electronics
Expires: June 6, 2006 K. Kim
Ajou University
E. Seo
Samsung AIT
December 6, 2005
IPv6 over Low Power WPAN Security Analysis
draft-daniel-6lowpan-security-analysis-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes IPv6 over Low Power WPAN security analysis.
Daniel Park, et al. Expires June 6, 2006 [Page 1]
Internet-Draft 6LoWPAN Security Analysis December 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Assumption . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. 6lowpan security analysis . . . . . . . . . . . . . . . . . . 4
6.1 IEEE 802.15.4 Security analysis . . . . . . . . . . . . . 5
6.2 IP Security analysis . . . . . . . . . . . . . . . . . . . 6
7. 6lowpan trust models . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
11. No I-D References . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 7
12.2 Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Daniel Park, et al. Expires June 6, 2006 [Page 2]
Internet-Draft 6LoWPAN Security Analysis December 2005
1. Introduction
6lowpan (IPv6 over Low Power WPAN) was formed as a IETF working group
newly this year. The principal object of the 6lowpan working group
is to newly design IPv6 transmission over IEEE 802.15.4
[ieee802.15.4] networks.
In occation, IEEE 802.15.4 applications do not require at least
strict security models. However, many of application are security
sensitive.
Specifically, some of the IEEE 802.15.4 optional features actually
reduce security and implementation would be limited for their
extensions.
To improve security for IEEE 802.15.4, many efforts are in the
progress of proposing several change and adding new schemes to the
IEEE 802.15.4 specification. But almost approaches are certain to
target for link layer security improvement not any upper layers even
though IPv6 enhanced security is able to be applied to 6lowpan.
This document tries to analyze what security threats are feasible
during the deployment of 6lowpan and discuss 6lowpan trust model
using both link layer and IP layer security packages if necessary.
2. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Terminology
This document uses terminology specific to IPv6 and DHCPv6 as defined
in "Terminology" section of the DHCPv6 specification [RFC3315].
4. Overview
As described in [I-D.ietf-6lowpan-problem], 6lowpan has some of the
characteristics against existing IP networks such as small packet
size, low bandwidth of IEEE 802.15.4 standard [ieee802.15.4], low
power, low cost, large number of devices, etc. The security aspect,
however, seems a bit tradeoff element in the 6lowpan since security
is always a costly function, and this is particular true to low rate
WPAN. Obviously, adding security makes the issue even more
challenging. For instance, when putting IPv6 on top of 6lowpan, it
would be better to use IP security and turn off the security of WPAN
since the security architecture defined by IEEE 802.15.4 seems
Daniel Park, et al. Expires June 6, 2006 [Page 3]
Internet-Draft 6LoWPAN Security Analysis December 2005
somewhat loose and more work needs to be done today. But on the
other hand, IP security is relatively mature for services at IP or
other upper layers.
But of course, it is a question whether those 6lowpan devices can
support IP security as it is. for low layer services, for example
MAC sublayer association, beaconing, orphanning, etc. WPAN security
must be used since IP security is not supposed to take care of lower
layers.
Further study in the next version.
5. Assumption
The [I-D.ietf-6lowpan-problem] describes two security concerns as
follows;
In Section 4.6 Security: Although IEEE 802.15.4 provides AES link
layer security, a complete end-to-end security is needed.
In Section 5 Goals: Security threats at different layers must be
clearly understood and documented. Bootstrapping of devices into a
secure network could also be considered given the location, limited
display, high density and ad hoc deployment of devices.
This document will try to meet the above considerations.
In addition, existing IP security technologies will be simplified to
be implemented on the 6lowpan small devices. 6lowpan security
architecture will shed off lots of fat from IP security technologies
whenever available.
IEEE 802.15.4 AES (Advanced Encryption Standard) will be used for
6lowpan security architecture in conjunction with IP security
whenever available.
Further study in the next version.
6. 6lowpan security analysis
In this section, both IEEE 802.15.4 MAC security and IP security are
tackled to search for a new 6lowpan trust models and available
solution spaces if feasible. The principal object of these analysis
is to improve 6lowpan security level as we use IP layer security
mechanism as possible regardless of 802.15.4 vulnerable MAC security.
802.15.4 MAC enhancement and amendment are not scope of this document
but IEEE 802 standard stuff.
Daniel Park, et al. Expires June 6, 2006 [Page 4]
Internet-Draft 6LoWPAN Security Analysis December 2005
6.1 IEEE 802.15.4 Security analysis
The MAC of IEEE 802.15.4 provides security services that are
controlled by the MAC PIB (PAN Information Base). For security
purpose, the MAC sublayer maintains an access control list (ACL) in
its MAC PIB. By specifying a security suite in the ACL for a
communication peer, a device can indicate what level security should
be used (i.e., none, access control, data entryption, frame
integrity, etc.) for communications with that peer. In addition, MAC
sublayer offers a secured mode and an unsecured mode.
A critical function of IEEE 802.15.4 MAC is frame security. Frame
security is actually a set of optional services that may be provided
by the MAC to the upper layers (applications). The standard strikes
a balance between the need for these services in many applications,
and the desire to minimize the burden of their implementation on
those applications that do not need them. As described in
[802.15.4-ACM], if an application does not set any security
parameters, then security is not enabled by default. The
[ieee802.15.4] defines four packet types: beacon packets, data
packets, acknowledgements packets and control packets for the media
access control layer. It does not support security for
acknowledgement packets. But on the other hand, other packet types
can optionally support integrity protection and confidentiality
protection for the packet's data field.
Due to the variety of applications targeted by IEEE 802.15.4, the
processes of authentication and key exchange are not defined in the
standard. Devices without the key cannot decrypt the encryped
messages.
In addition, unsecured mode is suitable for some applications in
which implementation cost is important, and security is either not
required or obtained in other ways. In this case, 802.15.4 node is
very vulnerable.
The security service enables the MAC to select the devices with which
it is willing to communicate. The device may decide to communicate
with some devices, and not others. To minimize complexity, the
access control service is performed on an individual device basis,
rather than on groups or collections of devices.
Unlike file transfer or voice communication applications common with
other protocols, IEEE 802.15.4 applications often transmit messages
that do not convey secret information.
Further study in the next version.
Daniel Park, et al. Expires June 6, 2006 [Page 5]
Internet-Draft 6LoWPAN Security Analysis December 2005
6.2 IP Security analysis
IPsec (IP security protocol) provides per-packet authenticity and
confidentiality guarantees between peers communicate using IPsec. It
is available for both IPv4 and IPv6.
Basically, IPsec targets to general IP nodes operated over ethernet.
It means each node has some of fluent stack size, bandwidth and
non-low cost limitations like 6lowpan.
Given the IPsec background, it is at least not suitable for 6lowpan
nodes. Especially, 6lowpan node may not be able to operate all IPsec
algorithms on its own capability either FFD or RFD.
Bandwidth is very sensitive element in the 6lowpan, but IPsec
generates some of redundant packets such as AH/ESP header.
IPsec needs shared secret key between nodes called IKE (Internet Key
Exchange), and it will make the key exchange in secrecy possible. It
can, however cause some of redundant packets over the 6lowpan
networks.
if NDP (Neighbor Discovery Protocol) is applied to 6lowpan, SeND
(Secure Neighbor Discovery) should at least considered to provide
security in conjunction with neighbor discovery protocol. So far,
CGA (Cryptographically Generated Addresses) [RFC3972] and SeND
options [RFC3971] are newly designed by IETF and it works well over
existing IP networks. However, CGA seems very complex to be applied
to 6lowpan networks. Furthermore, SeND options requires huge
additional options (i.e., CGA option, RSA Signature option, Timestamp
and Nonce option and etc.) in which increase the packet size
accordingly.
Further study in the next version.
7. 6lowpan trust models
To meet the security requirement of 6lowpan, a new trust models
including new IPsec hashing algorithms, new key exchange schemes,
etc.
6lowpan bootstraping should be at least considered as one of 6lowpan
trust models.
Further study in the next version.
Daniel Park, et al. Expires June 6, 2006 [Page 6]
Internet-Draft 6LoWPAN Security Analysis December 2005
8. Security Considerations
This document addresses only security issues around IPv6 over Low
Power WPAN.
9. IANA Considerations
There is no IANA considerations.
10. Acknowledgements
Thanks to Myungjong Lee of CUNY for his valuable comments on this
document.
11. No I-D References
All references shown in this section MUST be added into the
Informative References before publishing it officially.
[ieee802.15.4] IEEE Std., 802.15.4-2003, ISBN 0-7381-3677-5, May
2003.
[802.15.4-ACM] Sastry, N. and Wagner, D., Security Considerations
for IEEE 802.15.4 Networks, ACM WiSE'04, October 2004.
12. References
12.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
12.2 Informative References
[I-D.ietf-6lowpan-problem]
Kushalnagar, N. and G. Montenegro, "6LoWPAN: Overview,
Assumptions, Problem Statement and Goals",
draft-ietf-6lowpan-problem-01 (work in progress), October
2005.
[RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
Daniel Park, et al. Expires June 6, 2006 [Page 7]
Internet-Draft 6LoWPAN Security Analysis December 2005
RFC 3972, March 2005.
Authors' Addresses
Soohong Daniel Park
Mobile Platform Laboratory, SAMSUNG Electronics.
EMail: soohong.park@samsung.com
Ki-Hyung Kim
Ajou University
EMail: kkim86@ajou.ac.kr
Eunil Seo
Samsung AIT
EMail: eunil.seo@samsung.com
Daniel Park, et al. Expires June 6, 2006 [Page 8]
Internet-Draft 6LoWPAN Security Analysis December 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Daniel Park, et al. Expires June 6, 2006 [Page 9]