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]