Networking Working Group Dong Jin Kwak Internet-Draft KT Advanced Technology Lab Expires: April 16 , 2006 Joon Heo Choong Seon Hong Kyung Hee University October, 2005 Secure Route Discovery in Low-Rate WPAN draft-kwak-srd-wpan-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 April 16, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract A low-rate wireless personal area network (LR-WPAN) is a network designed for low-cost and very low-power short-range wireless communications. It is hard to employ static routes. Route discovery is the procedure whereby network devices cooperate to find and establish routes through the network and is always performed with regard to a particular source and destination device. However, Route discovery in LR-WPAN has lack of authentication mechanism. Also, dynamic network topology makes it arduous to detect malicious nodes. We proposed a secure route discovery authentication mechanism using the レSRD. レSRD uses RREQ ID, destination address and the unique value as input string to generate authentication code (AC). It is used as the authentication between source node and destination node. Kwak, et al. Expires April 16, 2006 [Page 1] Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. Route Discovery in LR-WPAN . . . . . . . . . . . . . . . . 2 3. Security of ZigBee Device . . . . . . . . . . . . . . . . . 3 4. Counter with CBC-MAC (CCM) . . . . . . . . . . . . . . . . 3 5. Mechanism . . . . . . . . . . . . . . . . . . . . . . . 4 5.1 レSRD Algorithm . . . . . . . . . . . . . . . . . . . . . 5 5.2 Authentication Code (AC) in RREQ/RREP message . . . . . . . 5 5.3 Authentication Processes in LR-WPAN . . . . . . . . . . . 7 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction The explosive growth of embedded control and monitoring in almost any electronic device and the need for connectivity of these applications is causing an integration bottleneck. Conventionally, these communication links are wired. Wires allow power and the reliable transmission of signals from a controller to its peripherals. When the peripherals are not physically contained in the controller, the required wiring brings issues such as cost of installation, safety, and operation convenience to the surface. Wireless technology is the obvious solution to overcome these obstacles, although it comes with its own set of challenges propagation, interface, security, regulations, and others. The technology to overcome these issues exists, but normally with added complexity causing an increase in the cost of the system. A low-rate wireless personal area network (LR-WPAN) is a network designed for low-cost and very low-power, short-range wireless communications. Wireless Sensor Networks are a subset of wireless networking applications focused on enabling connectivity without the use of wires to sensors and actuators is general. IEEE 802.15.4 Working Group is chartered to focus on wireless sensor networks [Doc1]. Kwak, et al. Expires April 16, 2006 [Page 2] Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005 The ZigBee Alliance is developing the low-cost, very low power consumption, two-way, wireless communications standard. Solutions adopting the ZigBee standard will be embedded in consumer electronics, home and building automation, industrial controls, Many of these application have security needs [Doc2]. Sometimes LR-WPAN is formed by self-configuring wireless sensor devices, usually mobile, which do not rely on any fixed infrastructure. Route discovery is the procedure whereby network devices cooperate to find and establish routes through the network and is always performed with regard to a particular source and destination device. Some sensor nodes in LR-WPAN act as routers to forward packets for each other and this co-operation helps in routing packets to the destination. Therefore, routing protocols must be dynamic and robust against malicious attacks. However route discovery in LR-WPAN has lack of authentication facilities. Also, dynamic network topology makes it arduous to detect malicious nodes. 2. Route Discovery in LR-WPAN In LR-WPAN, When source node desires to send a message to some destination node and does not already have a valid route to that destination, it initiates a path discovery process to located the other node. Essentially routes are discovered using a request-response protocol as shown in Figure 1 [Doc3]. |------------| |---------------| |------------| | A | | Intermediate | | B | | source | | node | |destionation| |-----|------| |------|--------| |------|-----| | | | | | | | Braodcast RREQ | | |--------------------->| | | | RREQ packets may |Compare path | | arrive by multiple |costs and | | paths |respond with | |---------------------->|with a reply | | |when a new | | Zero or More |minium cost | | Unicast RREP packet |is found. | |<----------------------| compare | | | replies | | | and select| | | the one |<---------------------| | the best | | | route | | | --- --- --- Fig 1. Route Discovery Process in Low-Rate WPAN Kwak, et al. Expires April 16, 2006 [Page 3] Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005 When a device, A, wishes to discover a route to some destination, B, it broadcasts a special route request command (RREQ) frame throughout the network. As the route request command frame transits the network, devices that are not the destination record information about the route taken by the route request command frame. When the route request command frame arrive at B, B responds by unicasting one or more route reply (RREP) command frames. These follow the path set up by the route request and eventually arrive back at A carrying information about possible routes. Routes are compared throughout this process using a routing cost metric that has been defined in such a way that minimizing this metric will minimize latency and improve traffic throughout the network [Doc3]. However, Route discovery in LR-WPAN has lack of authentication mechanism. In LR-WPAN, there are some potential attacks on the integrated routing. To prevent diverse attacks, the authentication process is necessary between source node and destination node. 3. Security of ZigBee Device In IEEE 802.15.4 standard, The AES-CCM-128, AES-CCM-64, AES-CCM-32 modes employ AES to provide access control, encryption, integrity, and, optionally, sequential freshness (by the transmission of a freshness code) [Doc1][IEEE15] In particular, by reusing AES in a clever way, the AES-CCM modes enable a single algorithm to provide all four secure services in a very small implementation. In addition the use of AES-CCM modes retains compatibility with other draft IEEE 802 standards, such as IEEE Draft Std 802.11i and IEEE Std 802.15.3[Doc1]. Security amongst a network of ZigBee devices is based on ｀link¨keys and a ｀network¨ key. Unicast communication between APL (Application Layer) peer entities is secured by means of a 128-bit link key shared by two devices, while broadcast communications are secured by means of a 128-bit network key shared amongst all devices in the network [Doc2]. For the purpose, ZigBee defines the role of trust center. The trust center is the device trusted by devices within a network to distributed keys for the purpose of network and end-to-end application configuration management. All members of the network shall recognize exactly one trust center in each secure network. For purpose of network management, a device shall accept an initial network key only from its trust center. Therefore, only a device that hasjoined the network and successfully received the network key will be able to have its messages communicated more than one hop across the network [Doc2]. 4. Counter with CBC-MAC (CCM) CCM [Jonsson][LEE] is a generic authenticate-and-encrypt block cipher mode. CCM is only defined for using with 128-bit block cipher, such as AES. The CCM ideas can easily be extended to other block sizes, but this will require further definitions. For the generic CCM mode there are two parameter choices. The first choice is M, the size of the authentication Kwak, et al. Expires April 16, 2006 [Page 4] Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005 field. The choice of the value for M involves a trade-off between message expansion and the probability that an attacker can undetectably modify a message. Valid values are 4, 6, 8, 10, 12, 14, and 16octets. The second choice is L, the size of the length field. The value requires a trade-off between the maximum message size and the size of the Nonce. Different applications require different trade-offs,so L is a parameter. Valid values of L range between 2octets and 8octets (the value L=1 is reserved). To send a message, the sender must provide the following information: - An encryption key K suitable for the block cipher. - A nonce N of 15-L octets. Within the scope of any encryption key K, the nonce value should be unique. That is, the set of nonce values used with any given key should not contain any duplicate values. Using the same nonce for two different messages encrypted with the same key destroys the security properties of this mode. - The message m, consisting of a string of l(m) octets where 0 < l(m) < 2^8L. The length restriction ensures that l(m) can be encoded in a field of L octets. - Additional authenticated data a, consisting of a string of l(a) octets where 0 < l(a) < 2^64. This additional data is authenticated but not encrypted, and is not included in the output of this mode. It can be used to authenticate plaintext packet headers, or contextual information that affects the interpretation of the message. Users who do not wish to authenticate additional data can provide a string of length zero. In LR-WPAN, the AES-CCM is used for data encryption/decryption and node authentication. Therefore nodes in LR-WPAN support AES-CCM encryption/decryption mechanism. 5. Mechanism To prevent diverse attacks, the authentication process is necessary between source node and destination node during route discovery process. Moreover, low-cost and low-power characteristic of nodes are important considering fact in LR-WPAN. We proposed a secure route discovery authentication mechanism using the レSRD. レSRD is a new proposal based on the CCM [Jonsson][LEE]. Of course, CCM is a good mechanism to encrypt and authenticate. However, it has some prerequisites and complex transformation process to generate authentication tag. Route discovery process is happened frequently therefore such complexity is overhead to the node. Moreover, CCM uses plaintext data to generate authentication tag. Therefore, if source node has no data, it could not generate authentication value.レSRD uses RREQ ID, destination address and the unique value as input string to generate authentication code (AC). It is used as the authentication value between source node and destination node. Kwak, et al. Expires April 16, 2006 [Page 5] Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005 5.1 レSRD Algorithm レSRD is only the authentication block cipher mode. レSRD is only defined for using with block ciphers with a 128-bit block size, such as AES-128. As with the CCM mode, the レSRD mode requires only one key. Input: The レSRD mode forward transformation takes as inputs A Key size: NWKkey (network key) = 128 bit AddAuthData : 13 octets. It is received from Trust Center in a periodic time. AuthCode = RREQ ID || destination address || AddAuthData (1octet) (2octets) (13octets) Authentication transformation: B0 = AuthCode The CBC-MAC value X1 is defined by X0 := 0128; X1 := E(NWKkey, X0 XOR B0 ) The AC (authentication code) is the result of omitting all but the leftmost 4 octets of the value X1 thus computed. 5.2 Authentication Code (AC) in RREQ/RREP message Authentication code is generated by レSRD. レSRD uses RREQ ID, AddAuthData and destination address as input string to generate authentication code (AC). We have added AC to RREQ/RREP message in Payload. (Figure 2, 3) Kwak, et al. Expires April 16, 2006 [Page 6] Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005 |------------|------------|------------|------------| | Frame |Destination | Source | Payload | NWK frame | Control | | | | |------------|------------|------------|------------| < > < > < > < > < |=====================| > |<-------|------||--------|------------|----------|-----|--------->| |Ox01 |Option|| RREQ ID||Destination| Extended | PCM | RREQ AC | |(octets)| 1 || 1 | 2 | Dest. 8 | 1 | 4 | |--------|------||--------|------------|----------|-----|----------| | | | |==========.==========| ^ | | |______________レSRD_____________| / / / Include AddAuthData Fig 2. RREQ Message included Authentication Code |------------|------------|------------|------------| | Frame |Destination | Source | Payload | NWK frame | Control | | | | |------------|------------|------------|------------| < > < > < > < > < |=========| > |<-------|-------|-|---------|-|----------|--------->| |Ox02 |Option | | RREQ ID | | PCM | RREP AC | |(octets)| 1 | | 1 | | 1 | 4 | |--------|-------|-|---------|-|----------|----------| |====.====| ^ | | |__________レSRD_________| / / / Include AddAuthData & destination address Fig 3. RREP Message included Authentication Code Kwak, et al. Expires April 16, 2006 [Page 7] Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005 5.3 Authentication Processes in LR-WPAN In the previous section, we introduced レSRD and the RREQ/RREP message included authentication code. This section describes the authentication processes in LR-WPAN. a. After successfully associating to a secured network, the joining device shall receive the network key and unique value (AddAuthData) from trust center. b. When a source node (S) desires to send a message to destination node (D) and does not already have a valid route to that destination. It generates the RREQ AC using the レSRD that is included RREQ message payload. Then source node broadcasts a route request (RREQ) message to its neighbor. c. During the process of forwarding the RREQ, intermediate nodes (A, B, E) recode the RREQ AC in their route discovery table. d. Once the RREQ reaches the destination node (D) with a fresh enough route, the destination node generates RREP AC using the レSRD. And then destination node compares RREP AC with RREQ AC. If two values are same, destination node authenticates source node. e. The RREP included AC is routed back along the reverse path. f. If malicious node sends the RREP message to intermediate node. It compares RREP AC with RREQ AC and then ignores the RREP message. g. Once the RREQ reaches the source node (S), the source node compares RREP AC with RREQ AC. If two values are same, source node authenticates destination node. Kwak, et al. Expires April 16, 2006 [Page 8] Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005 A successful authentication procedure is shown in Figure 4. ___________ ____________ _________________ __________ |Source node| |Trust Center| |Intermediate node| |dest. node| |___________| |____________| |_________________| |__________| | | | | | | | | join the network | | join the network | | | | |NWK & AddAuthData | NWK & AddAuthData | |<----------------|||------------------|----------------->| | | | | Generate RREQ | | | AC using the レSRD | | | | | | | | Broadcast RREQ included AC | | |------------------|------------------>| | | | | | | | Save RREQ AC | | | | | | | | RREQ | | | |----------------->| | | | | | | | Generate RREP | | | AC using the レSRD | | | | | | | Compare RREQ AC | | | with RREP AC | | | | | | | Authentication | | | | | | | RREQ included AC | | | |<-----------------| | | | | | | Compare RREQ AC | | | with RREP AC | | | | | | RREP included AC | | |<-----------------|-------------------| | | | | | Compare RREQ AC | | | with RREP AC | | | | | | | Authentication | | | | | | | | | | | | | | | ======== ======= ========= ======== Fig 4. Successful Authentication processes Kwak, et al. Expires April 16, 2006 [Page 9] Internet-Draft Secure Route Discovery in Low-Rate WPAN October 2005 6. Conclusion Route discovery in LR-WPAN has lack of authentication mechanism. In LR-WPAN, there are some potential attacks on the integrated routing. Such problem is caused by non-authentication between source node and destination node. To prevent diverse attacks, the authentication process is necessary between source node and destination node. We decribes a secure route discovery authentication mechanism using the レSRD. レSRD uses RREQ ID, destination address and the unique value as input string instead of plaintext data to generate authentication code (AC). It is included RREQ/RREP message and it is used as the authentication between source node and destination node. This mechanism can reduce the resource of nodes. Also, our mechanism uses lower resource and processing time. It is important fact to the node in LR-WPAN. REFERENCES [Doc1] Jose A. Gutierrez, Edgar H. Callaway Jr, Raymond L. Barrett Jr, ＾Low-Rate Wireless Personal Area Networks￣, IEEE Std 802.15.4. [Doc2] Document 03322r12: ZigBee Security Services Specification, July 2004. [Doc3] Document 02130r5: ZigBee Network Specification, March 2003. [IEEE15] IEEE Standard for Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications for Low Rate Wireless Personal Area Networks (LR-WPANs), 2003. [Zapata] Manel Guerrero Zapata, Secure Ad hoc On-Demand Distance Vector Routing, ACM Mobile Computing and Communications Review (MC2R), Vol. 6, No.3, pp.106-107, 2002. [Jonsson] J. Jonsson, On the Security of CTR+CBC-MAC, in Proceedings of Selected Area in Cryptography-SAC 2002, K. Nyberg, H. Heys, Eds., Lecture Notes in Computer Science, Vol. 2595, pp. 76-93, Berlin: Springer, 2002. [Lee] Man Young LEE, ＾Internet Security Cryptographic principles, algorithms and protocols", WILEY, 2002. AUTHOR'S ADDRESS Questions about this document can also be directed to the author: Dongjin Kwak KT Advanced Technology Lab Woomyun, Seocho, Seoul, Korea djk@kt.co.kr Joon Heo Department of Computer Engineering Kyung Hee University 1 Seocheon, Giheung, Yongin, Gyeongi-Do, 449-701, Korea Email: joon@networking.khu.ac.kr Choong Seon Hong Department of Computer Engineering Kyung Hee University 1 Seocheon, Giheung, Yongin, Gyeongi-Do, 449-701, Korea E-mail : cshong@khu.ac.kr Kwak, et al. Expires April 16, 2006 [Page 10] Internet-Draft Secure Route Discovery in Low-Rate WPAN October 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. Kwak, et al. Expires April 16, 2006 [Page 11]