IPv6 over Low Power WPAN (6lowpan) S. Park Internet-Draft Samsung Electronics Intended status: Informational K. Kim Expires: January 14, 2010 Ajou University W. Haddad (Ed.) Ericsson S. Chakrabarti IP infusion J. Laganier Qualcomm July 13, 2009 IPv6 over Low Power WPAN Security Analysis draft-daniel-6lowpan-security-analysis-03 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 14, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights Park, et al. Expires January 14, 2010 [Page 1] Internet-Draft 6LoWPAN Security Analysis July 2009 and restrictions with respect to this document. Park, et al. Expires January 14, 2010 [Page 2] Internet-Draft 6LoWPAN Security Analysis July 2009 Abstract This document discusses possible threats and security options for IPv6-over-IEEE802.15.4 networks. Its goal is to raise awareness about security issues in IPv6 lowPan networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Challenges . . . . . . . . . . . . . . . . . . . . . 10 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 7. Security Threats . . . . . . . . . . . . . . . . . . . . . . . 12 8. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. 6Lowpan Security Analysis . . . . . . . . . . . . . . . . . . 16 9.1. IEEE 802.15.4 Security analysis . . . . . . . . . . . . . 16 9.2. IP Security analysis . . . . . . . . . . . . . . . . . . . 17 10. Key Management in 6Lowpan . . . . . . . . . . . . . . . . . . 18 10.1. Existing Key Management Methods . . . . . . . . . . . . . 18 10.2. Issues With Key Management in 6Lowpan . . . . . . . . . . 19 11. Security Consideration in Bootstrapping a 6lowpan Node . . . . 20 12. Possible Scenarios Using Different Levels of Security . . . . 21 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 16. No I-D References . . . . . . . . . . . . . . . . . . . . . . 25 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 17.1. Normative References . . . . . . . . . . . . . . . . . . . 26 17.2. Informative References . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Park, et al. Expires January 14, 2010 [Page 3] Internet-Draft 6LoWPAN Security Analysis July 2009 1. Introduction IEEE 802.15.4 [ieee802.15.4] specification defines Physical and MAC layers targeted for the Low Rate Wireless Personal Area Networks (LR- WPAN) using short distance applications with low power and low cost communication networks, particularly for the short range applications such as Wireless Sensors Network (WSN). In an IEEE 802.15.4 compliant WPAN, a central controller device, i.e., the PAN coordinator, builds a WPAN with other devices within a small physical space known as the personal operating system. IEEE 802.15.4 is designed to support a variety of applications in personal area networks; many of these applications are security sensitive. The principal goal of the 6lowpan working group is to design IPv6 transmission over IEEE 802.15.4. In fact, some of the IEEE 802.15.4 optional features actually reduce security and implementation would be limited for their extensions. The applications range from defense systems to building monitoring, fire-safety, patient monitoring, etc. If the network is not secured, an intruder can inject incorrect messages to trigger false situations. IEEE 802.15.4 working group is trying to improving the link-layer security specification. However, this document will focus on discussing different security threats from the 6lowpan perspective and discuss different options for applying existing security methods to overcome/alleviate these threats. The main goal is to provide a trust model using both link-layer and IP layer security packages if/ whenever possible. Designing a new security protocol for 6lowpan network is out of scope of this document. However, the document states desired security requirements, which can be fed into the appropriate IETF security working group in order to design appropriate security protocols. Park, et al. Expires January 14, 2010 [Page 4] Internet-Draft 6LoWPAN Security Analysis July 2009 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]. Park, et al. Expires January 14, 2010 [Page 5] Internet-Draft 6LoWPAN Security Analysis July 2009 3. Terminology This document uses terminology specific to IPv6 and DHCPv6 as defined in the "Terminology" section of the DHCPv6 specification [RFC3315]. Park, et al. Expires January 14, 2010 [Page 6] Internet-Draft 6LoWPAN Security Analysis July 2009 4. Overview As described in [RFC4919], unlike regular IP network, 6lowpan has some special characteristics such as small packet size, low bandwidth, large number of devices, etc. 6lowpan devices are generally assumed to be resource-limited with respect to computation power, storage, memory and especially battery life. One common feature, which is worthy to remember is the disproportionately high cost of transmitting information as compared to performing local computation. For example, a Berkeley mote spends approximately 800 instructions as it does in sending a single bit [Madden]. It thus become a main design criteria for 6lowpan to reduce the number of bits forwarded by intermediate nodes, in order to extend the entire network's lifetime as recharging may not be practical in some deployment scenarios. IEEE 802.15.4 nodes can operate in either secure mode or non-secure mode. Two security modes are defined in the specification in order to achieve different security objectives: - Access Control List (ACL) mode which provides limited security services and requires each device to maintain its own ACL. This mode allows receiving frames only from nodes that are present in the devices's ACL, i.e., considered as trusted nodes. Frames from non- registered devices are filtered. However, cryptographic protection is not provided in this mode. - Secure mode provides all the security services according to the defined security suite. It provides confidentiality of the frame along with the message integrity, access control, and sequential freshness. However, the specification is not clear about key management methods, state of ACL table in the event of power loss and support of group keying in which case, network shared common key may be an answer for the link layer security but is vulnerable to replay attacks launched from stolen devices. Yet, in most common cases, network shared keying can be the simple answer to the link layer security as it is easily configurable among large number of devices. The security aspect, however, seems a bit tradeoff in the 6lowpan since security is always a costly function. This is particularly true to low rate WPAN. Obviously, adding security makes the issue even more challenging. For instance, when putting IPv6 on top of 6lowpan, it may seem possible to use IP security protocol [RFC4301] and turn off the security mechanism defined by IEEE 802.15.4. But on the other hand, IPsec is relatively mature for services at IP or upper layers. Furthermore, due to their inherent properties and/or Park, et al. Expires January 14, 2010 [Page 7] Internet-Draft 6LoWPAN Security Analysis July 2009 constraints mentioned earlier, 6lowpan poses unique challenges to which, traditional security techniques cannot be applied directly. For example, public key cryptography primitives are typically avoided (as being too expensive) as are relatively heavyweight conventional encryption methods. Consequently, it becomes questionable whether the 6lowpan devices can support IPsec as it is. This document explains some of the difficulties resulting from adopting IPSec in the following sections. However, Layer 2 security must be used for all associated operations such as MAC sub-layer association, beaconing, orphaning, etc. While IPsec is mandatory with IPv6, considering the power constraints and limited processing capabilities of IEEE802.15.4 capable devices, IPsec is computationally expensive; Internet key exchange (IKEv2) messaging described in [I-D.ietf-ipsecme-ikev2bis] will not work well in 6lowpans as we want to minimize the amount of signaling in these networks. Thus, 6lowpan may need to define its own keying management method(s) that requires minimum overhead in packet-size and in number of signaling messages exchange. IPsec will provide authentication and confidentiality between end-nodes and across multiple lowpan- links, and may be useful only when two nodes want to apply security to all exchanged messages. However, in most cases, the security may be requested at the application layer as needed, while other messages can flow in the network without security overhead. Attacks against 6lowpands can be classified into external attacks and internal ones. In an external attack, the attacker is not an authorized entity of the 6lowpan. External attacks can be further divided into two categories: passive and active. Passive attacks involve mainly eavesdropping on network's radio frequency range in an attempt to discover sensitive information. Among active attacks against 6lowpans, denial-of service (DoS) attack at the physical layer can produce devastating consequences. To this end, the attacker can broadcast a powerful signal within the WPAN zone, i.e., jamming, and paralyzes part(s) or even the entire network. An attacker may also disable a 6lowpan node (e.g., by smashing it!) or capture one, extracts the key(s) and uses it for eavesdropping purposes and/or to directly intervene at some point in time, by injecting false but valid data in order to disturb the overall system, e.g., trigger an undesired chain of events. Consequently, a challenging issue facing 6lowpans is to provide resiliency against node capture attack. Data collection and dissemination being their ultimate goals, 6lowpans also highlights privacy concerns. In fact, as devices are getting smaller (i.e., easier to conceal) and cheaper (i.e., easier to obtain), an obvious risk is that 6lowpan technology might be used Park, et al. Expires January 14, 2010 [Page 8] Internet-Draft 6LoWPAN Security Analysis July 2009 for privacy violation purposes, e.g., employers might spy on their employees, neighbors might spy on each other. Possible threats in 6lopwan include intrusion, sink-hole and replay attacks. As in traditional networks, routing mechanisms in 6lowpan presents another window from which, an attacker might disrupt and significantly degrade the 6lowpan overall performance. Attacks against unsecure routing aim mainly to contaminate WPAN networks with false routing information resulting in routing inconsistencies. A malicious node can also snoop packets and then launch replay attacks on the 6lowpan nodes. These attacks can cause harm especially when the attacker is a high-power device, such as laptop. It can easily drain 6lowpan devices batteries by sending broadcast messages, redirecting routes etc. A possible solution to address security issues in the 6lowpan networks might consist of implementing application level security, e.g., SSL, on top of link layer security. In such case, link layer security protects from intrusion and the application level security protects from another user peeking at the data and impersonation. Park, et al. Expires January 14, 2010 [Page 9] Internet-Draft 6LoWPAN Security Analysis July 2009 5. Security Challenges We summarize the security challenges in 6lowpan networks as it follows. (For more information about this section and the following ones, please check the references): - Minimizing resource consumption and maximizing security performance. - 6lowpan deployment enables link attacks ranging from passive eavesdropping to active interfering. - In-network processing involves intermediate nodes in end-to-end information transfer. - 6lowpan communication characteristics render traditional wired based security schemes unsuitable. Park, et al. Expires January 14, 2010 [Page 10] Internet-Draft 6LoWPAN Security Analysis July 2009 6. Security Requirements Security requirements for 6lowpan can be listed as it follows: - Data Confidentiality: make information inaccessible to unauthorized users. For example, a 6lowpam node should not leak some of its collected data to neighboring networks. - Data Authentication: since an adversary can easily inject messages, the receiver needs to ensure that data are originated from a trusted sources. - Data Integrity: ensures that the received data is not altered in transit by an adversary. - Data freshness: this could mean data freshness as well as key freshness. Informally, data freshness implies that each data is recent, and it ensures that no adversary replayed old messages. - Availability: ensures the survivability of network services to (only) authorized parties when needed, despite a DoS attack(s). - Robustness: ensures operation continuity despite abnormalities, such as attacks, failed nodes, etc. - Resiliency: is the network ability to provide and maintain an acceptable level of security in case some nodes are compromised. - Resistance: is the network ability to prevent the adversary from gaining full control of the network by node replication attack in case some nodes are compromised. - Energy efficiency: a security scheme must be energy efficient so as to maximize network lifetime. - Assurance: is the ability to disseminate different information at different assurance levels. Park, et al. Expires January 14, 2010 [Page 11] Internet-Draft 6LoWPAN Security Analysis July 2009 7. Security Threats Most of the attacks and threats against user and data security in 6lowpan are plausible and MAY be very destructible in effect, because of its wireless radio access and connectivity to the Internet. The security analysis of 6lowpan starts with the appreciation of various threats posed at respective ISO OSI layers. In this section, we classify and discuss the threats in layer-wise order. The suggested threat model assumes that the attacker is fully capable at all times except during the deployment phase. 6lowpan is highly susceptible to physical attacks. i.e., threats due to physical node destruction relocation and masking. By physical attacks, one or multiple 6lowpan nodes can be knocked out permanently, so the losses are irreversible. Physical attack can extract cryptographic secrets from the associated circuitry, modify programming in the nodes, and may allow the malicious node to take control over them. These compromises can result into code modification inside the node and to change the mission-oriented role of full fledged networks, let alone sensors. In 6lowpan environment, several types of DoS attacks can be triggered in different layers. At the physical Layer, the DoS attacks can be launched by tampering and jamming electromagnetic (EM) signals by swarming the limited resources of 6lowpan devices with the high resource devices very easily. Attacks on MAC layer involves collision, exhaustion and unfairness. Being always power hungry, 6lowpan devices try to sleep as often as possible in order to conserve it. Such constraints open the door for an attacker to let the device execute a large number of tasks in order to deplete its battery. This is called "sleep deprivation torture" [Stajano]. To achieve such goal, an attacker can for example, target different destination devices with unnecessary packets, possibly in other WPANs, regardless of whether the destination WPAN and/or device actually exist or not. Such attack can also lead to depleting the PAN coordinator battery power, i.e., since the downlink packets have to be explicitly requested from the PAN coordinator, this will keep it busy (as well as an eventual destination). An attack against network availability can consist of flooding the network by simply transmitting a large number of large(st) packets size. In such case, the attacker may degrade the network performance and drastically reduce the throughput. In WPAN specification, the replayed message is prevented by the replay protection mechanism, i.e., sequential freshness. In a Park, et al. Expires January 14, 2010 [Page 12] Internet-Draft 6LoWPAN Security Analysis July 2009 replay-protection attack, the malicious node sends many frames containing large counters to a particular receiver, which in turn raises the replay counter up. Then, when a normal device sends a frame with a lower frame counter, it will be rejected by the receiver and thus, leading to DoS attack. As the ACK frame integrity is not protected, it also opens the door for a malicious node to prevent a legitimate device from receiving a particular frame. This is possible by forging an ACK using the un- encrypted sequence number from the data frame and sending it to the source while creating enough interference, in order to prevent the legitimate receiver from receiving the frame. In such scenario, the source device is led to believe that the frame has been received. A corrupted device can also attack the key distribution process since the WPAN coordinator announces the IDs of devices who are about the change the link key in plain-text in the beacon frame. Therefore, the attacker can send request packet with the ID of the legitimate node. The goal from such request is to push the coordinator to trigger a key exchange process while the legitimate recipient may not be ready. Attacks against network layer fall into one of the following categories: - Spoofed, altered, or replayed routing information: in this attack, the malicious node uses spoofing, altering and/or replaying to target routing information exchanged between nodes in an attempt to create routing loops, attract/repel network traffic, extend/shorten source routes, generate false error messages, etc. - Selective forwarding: in this attack, the malicious device may refuse to forward certain messages (e.g., by dropping them). In this case, neighboring devices may conclude that the malicious device has failed and thus, try to seek another route. A more subtle form of this attack is when the malicious device selectively forward packets in which case, neighboring nodes won't be able to reach the conclusion that another route is needed which in turn, would encourage them to re-send the data packets. - Sinkhole attack: in a sinkhole attack, the malicious device tries to get all traffic from one particular area which can potentially result in a DoS attack. In order to launch a sinkhole attack (aka blackhole attack), the attacker can listen to requests for routes then replies to the requesting nodes that it contains the high quality or shortest path to the base station. Once the malicious device is able to insert itself between the communicating nodes, he/ she is able to do anything with the packets passing through it. In Park, et al. Expires January 14, 2010 [Page 13] Internet-Draft 6LoWPAN Security Analysis July 2009 fact, this attack can affect even the nodes that are spatially located farther from the malicious node. - Sybil attack: in a Sybil attack, a single node presents multiple identities to other nodes in the WPAN. Sybil attacks pose a significant threat to geographic routing protocols and MAY be performed against the distributed storage, routing mechanism, data aggregation, voting, fair resource-allocation and misbehavior detection, etc. Note that it is not easy to detect a Sybil attack in progress (measuring the usage of radio resources MAY lead to detect it, though with very little probability). - Wormhole attack: in a Wormhole attack, the attacker records packets (or bits) at one location in the network and tunnels them to another one. Such attacks can be devastating to the working of the 6lowpan since it does not require compromising a node in the WPAN; instead, it could be performed at the initial phase when 6lowpan nodes start to discover the neighboring information. Wormhole attacks can target for example, routing function or application. - Neighbor Discovery attacks: a modified version of the IPv6 Neighbor Discovery protocol (described in [RFC4861]) has been specifically designed for WPAN. However, the modified version (described in [I-D.ietf-6lowpan-nd] inherits threats which applies in the WPAN deployment. This includes unsecured router advertisement, neighbor discovery DoS attacks. Threats against neighbor discovery protocol are described in [RFC3756]. At the transport layer, attacks could be performed by half open and half closed TCP segments. A malicious device can repeatedly forge messages carrying sequence numbers or control flags which will ultimately cause the endpoints to request retransmission of missed frames. Park, et al. Expires January 14, 2010 [Page 14] Internet-Draft 6LoWPAN Security Analysis July 2009 8. Assumptions [RFC4919] 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 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. Park, et al. Expires January 14, 2010 [Page 15] Internet-Draft 6LoWPAN Security Analysis July 2009 9. 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 this 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. 9.1. IEEE 802.15.4 Security analysis As mentioned earlier, IEEE 802.15.4 MAC layer 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 security level should be used (i.e., none, access control, data encryption, frame integrity, etc.) for communications with that peer. 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. IEEE 802.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 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 encrypted 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. An example of this is that all 6lowpan devices are assigned a default key by the administrator they can exchange data encrypted with that key. This may work in some situations, but this solution is not quite scalable. In this case, 802.15.4 node is very vulnerable. The security service enables the MAC to select the devices with which Park, et al. Expires January 14, 2010 [Page 16] Internet-Draft 6LoWPAN Security Analysis July 2009 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. 9.2. IP Security analysis IPsec can guarantee integrity and optionally confidentiality of IP (v4 or v6) packets exchanged between two peers. Basically, IPsec works well on non-low-power devices which are not subject to severe constraints on host software size, processing and transmission capacities. IPsec supports AH for authenticating the IP header and ESP for authenticating and encrypting the payload. The main issues of using IPsec are two-fold: (1) processing power and (2) key management. Since these tiny 6lowpan devices do not process huge number of data or communicate with many different nodes, it is not well understood if complete implementation of SADB, policy-database and dynamic key-management protocol are appropriate for these small battery powered devices. Given existing constraints in 6lowpan environments, IPsec may not be suitable to use in such environments, especially that 6lowpan node may not be able to operate all IPsec algorithms on its own capability either FFD or RFD. Bandwidth is a very scarce resource in 6lowpan environments. The fact that IPsec additionally requires another header (AH or ESP) in every packet makes its use problematic in 6lowpan environments. IPsec requires two communicating peers to share a secret key that is typically established dynamically with the Internet Key Exchange (IKEv2) protocol. Thus, it has an additional packet overhead incurred by IKEv2 packets exchange. As neighbor discovery protocol will be applied to 6lowpan, Secure Neighbor Discovery (SeND) protocol [RFC3971] should be considered to provide security in conjunction with 6lowpan NDP. SeND works well over existing IP networks. However, the crypto-generated address (CGA) (described in [RFC3972]) used in SeND is based on RSA based and thus, requires larger packet-size and processing time than in the case where Elliptic Curve Cryptography (ECC) keying algorithm is used. Therefore, it could be reasonable to use the SeND protocol if it is extended to support ECC for 6lowpan networks application. Park, et al. Expires January 14, 2010 [Page 17] Internet-Draft 6LoWPAN Security Analysis July 2009 10. Key Management in 6Lowpan In order to provide security in 6lowpans, a robust encryption mechanism MUST be in place. Only the non-tamperable keys can provide an encryption infrastructure that is thorough enough to provide a wide range of security services such as but not limited to authentication, authorization, non-repudiation and prevention from replay attacks. Key management issues are discussed in the following section. 10.1. Existing Key Management Methods The characteristics of 6lowpan communicating devices and resulting WPANs, such as limited resources at the node and network level, lack of physical protection, unattended operation, and a close interaction with the physical environment, all make it infeasible to implement some of the most popular key exchange techniques in their literal forms for 6lowpans. In this section, we visit three widely known schemes such as trusted-server scheme, pre-distribution scheme and public key cryptography schemes in order to reach a pragmatic key management mechanism for 6lowpans. The trusted-server scheme relies solely on the server for key agreement between nodes, e.g., Kerberos. If the server is compromised, the trust amongst nodes is severed. Such scheme is not suitable for 6lowpan networks because there is usually no guarantee of seamless communication with a trusted server at anytime. The key agreement scheme is key pre-distribution, where key information is distributed among all 6lowpan nodes prior to deployment. If the network deployers were to know which nodes were more likely to stay in the same neighborhood before deployment, keys MAY be decided a priori. However, because of the randomness of the deployment, knowing the set of neighbors deterministically might not be feasible. Furthermore, the presence of intruder nodes right from the network deployment and initiation time cannot be rejected outright as implausible. Some schemes like network shared keying, pair-wise keying, and group keying, have been defined as variants of key distribution. On-site key management mechanisms, while warranting the same level of security as key pre-distribution schemes have an obvious edge to cope up with network dynamics. This class of key management scheme depends on asymmetric cryptography, such as public key certificates that are irreversible singularly. This irreversibility comes at a price-often staked by the limited computation and energy resources of 6lowpan nodes. However, these are the hardest cryptanalyze. Some of the most popular examples include, but are not limited to Diffie-Hellman key Park, et al. Expires January 14, 2010 [Page 18] Internet-Draft 6LoWPAN Security Analysis July 2009 agreement, RSA or ECC [RFC2631]. Recent works on ECC implementation for low power devices has proven its feasibility for sensor networks. ECC provides security with smaller key size that is comparable to security provided by RSA or AES with much higher key size. Network topologies for 6LowPan (i.e., star and mesh) and presence of FFD and RFD makes cluster based dynamic key management schemes seem the most appropriate. These schemes use Master Keys; Network Keys and Links keys which could be pre-installed for first round and can be distributed by key transport mechanism during later rounds. This scheme provides ease in key distribution and key revocation [ZigBee]. 10.2. Issues With Key Management in 6Lowpan - In a 6lowpan, a malicious node MAY sit amongst other nodes at the deployment phase-a problem of secure key assignment at bootstrap time. - A node is compromised during the operating time of 6lowpan-A key revocation system MUST be employed. - In a sleep-mode enabled 6lowpan, keys to sleeping nodes MUST be deprived and reinstated after such nodes resume active state. - In case the keys are compromised, a mechanism to diagnose security violation MUST be invoked. - It SHOULD allow and support dynamic addition of a new node. Park, et al. Expires January 14, 2010 [Page 19] Internet-Draft 6LoWPAN Security Analysis July 2009 11. Security Consideration in Bootstrapping a 6lowpan Node This section aims to discuss how does a node configures itself securely with a IPv6 router in the network. It involves assignment of IPv6 prefix and the default IPv6 router in the 6lowpan. Further details will be collaborated with 6lowpan commissioning/bootstrapping works in near future according to the 6lowpan working group rechartering. Park, et al. Expires January 14, 2010 [Page 20] Internet-Draft 6LoWPAN Security Analysis July 2009 12. Possible Scenarios Using Different Levels of Security This section may suggest example scenarios with example solutions in different cases (IPsec, SSL, other type of solutions) although this document does not recommend or specify any security solutions. Further details will be collaborated with 6lowpan architecture works in near future according to the 6lowpan working group re-chartering. Park, et al. Expires January 14, 2010 [Page 21] Internet-Draft 6LoWPAN Security Analysis July 2009 13. Security Considerations This document addresses only security issues around IPv6 over Low Power WPAN. Park, et al. Expires January 14, 2010 [Page 22] Internet-Draft 6LoWPAN Security Analysis July 2009 14. IANA Considerations There is no IANA considerations. Park, et al. Expires January 14, 2010 [Page 23] Internet-Draft 6LoWPAN Security Analysis July 2009 15. Acknowledgements Thanks to Myungjong Lee at CUNY, USA, Rabia Iqbal, Mustafa Hasan and Ali Hammad Akbar all at Ajou University for their valuable comments to improve the document. Special thanks to Jung-Hyun Oh for his valuable help on this document. Park, et al. Expires January 14, 2010 [Page 24] Internet-Draft 6LoWPAN Security Analysis July 2009 16. 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. [Madden] Madden, S. R., Franklin, M. J., Hellerstein, J. M., and Hong, W., "TAG: a Tiny AGgregation service for ad-hoc sensor networks". In Proceedings of the 5th Annual Symposium on Operating Systems Design and Implementation, 2002. [Stajano] Stajano, F., and Anderson, R., "The Resurrecting Duckling: Security Issues for Ubiquitous Computing". In IEEE Computer Journal, Volume 42, Issue 5, 2002. [WSN] Shi, E., and Perrig, A., "Designing Secure Sensor Networks", In IEEE Wireless Communications, December 2004. [MAC802154] Misic V. B., Fung J., and Misic, J., "MAC Layer Security of 802.15.4-Compliant Networks". In MASS 2005 Workshop, IEEE WSN Conference. [SEC802154] Xiao, Y., Sethi, S., Chen, H. H., and Sun B., "Security Services and Enhancements in the IEEE 802.15.4 Wireless Sensor Networks". In IEEE GlobeCom 2005. [SECWSN] Chen, X., Makki, K., Yen, K., and Pissinou, N., "Sensor Network Security: A Survey". In IEEE Communications Surveys & Tutorials, Volume 11, No. 2, 2nd Quarter 2009. [ZigBee] Specification Version 1.0, December 2004. Park, et al. Expires January 14, 2010 [Page 25] Internet-Draft 6LoWPAN Security Analysis July 2009 17. References 17.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. 17.2. Informative References [I-D.ietf-6lowpan-nd] Shelby, Z., Thubert, P., Hui, J., Chakrabarti, S., and E. Nordmark, "6LoWPAN Neighbor Discovery", draft-ietf-6lowpan-nd-04 (work in progress), July 2009. [I-D.ietf-ipsecme-ikev2bis] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol: IKEv2", draft-ietf-ipsecme-ikev2bis-04 (work in progress), July 2009. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [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)", RFC 3972, March 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007. Park, et al. Expires January 14, 2010 [Page 26] Internet-Draft 6LoWPAN Security Analysis July 2009 Authors' Addresses Soohong Daniel Park System Solution Laboratory, Samsung Electronics 416 Maetan-3dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-742 KOREA Phone: +82 31 200 4635 Email: soohong.park@samsung.com Ki-Hyung Kim Ajou University San 5 Wonchun-dong, Yeongtong-gu Suwon-si, Gyeonggi-do 442-749 KOREA Phone: +82 31 219 2433 Email: kkim86@ajou.ac.kr Wassim Michel Haddad Ericsson 6210 Spine Rd Boulder, Colorado 80301 US Phone: +1 303 473 6963 Email: Wassim.Haddad@ericsson.com Samita Chakrabarti IP infusion Santa Clara, California USA Email: samitac@ipinfusion.com Julien Laganier Qualcomm San Diego, California USA Email: lulien.ietf@laposte.net Park, et al. Expires January 14, 2010 [Page 27]