Networking Working Group R.Struik Internet Draft Certicom Corp. Intended status: Informational March 1, 2010 Expires: September 1, 2010 Security Design for the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL) draft-struik-roll-rpl-security-design-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 September 1, 2010. Struik Expires September 1, 2010 [Page 1] Internet-Draft Security Design for RPL March 2010 Copyright Notice Copyright (c) 2010 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract We discuss a security design for the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). While the design focuses on communication security, we also discuss cross-layering aspects and security policy considerations. Table of Contents 1. Introduction...................................................2 2. Functional description of packet protection....................5 2.1. Transmission of outgoing packets..........................5 2.1.1. Outgoing packet security procedure...................5 2.2. Reception of incoming packets.............................6 2.2.1. Incoming packet security procedure...................6 3. Packet Formatting..............................................8 4. Information elements...........................................8 5. Security Considerations........................................9 6. IANA Considerations............................................9 7. Conclusions....................................................9 8. Future Work....................................................9 9. References....................................................10 9.1. Normative references.....................................10 9.2. Informative references...................................12 10. Acknowledgments..............................................13 1. Introduction From a security perspective, wireless adhoc networks are no different from any other wireless network. They are vulnerable to passive Struik Expires September 1, 2010 [Page 2] Internet-Draft Security Design for RPL March 2010 eavesdropping attacks and potentially even active tampering because physical access to the wire is not required to participate in communications. The very nature of ad hoc networks and their cost objectives impose additional security constraints, which perhaps make these networks the most difficult environments to secure. Devices are low-cost and have limited capabilities in terms of computing power, available storage, and power drain; and it cannot always be assumed they have neither a trusted computing base nor a high-quality random number generator aboard. Communications cannot rely on the online availability of a fixed infrastructure and might involve short-term relationships between devices that may never have communicated before. These constraints might severely limit the choice of cryptographic algorithms and protocols and would influence the design of the security architecture because the establishment and maintenance of trust relationships between devices need to be addressed with care. In addition, battery lifetime and cost constraints put severe limits on the security overhead these networks can tolerate, something that is of far less concern with higher bandwidth networks. Most of these security architectural elements can be implemented at higher layers and may, therefore, be considered to be outside the scope of this standard. Special care, however, needs to be exercised with respect to interfaces to these higher layers. The security mechanisms in this standard are based on symmetric-key and public-key cryptography and use keys that are provided by higher layer processes. The establishment and maintenance of these keys are outside the scope of this standard. The mechanisms assume a secure implementation of cryptographic operations and secure and authentic storage of keying material. The security mechanisms specified provide particular combinations of the following security services: o Data confidentiality: Assurance that transmitted information is only disclosed to parties for which it is intended. o Data authenticity: Assurance of the source of transmitted information (and, hereby, that information was not modified in transit). o Replay protection: Assurance that a duplicate of transmitted information is detected. Struik Expires September 1, 2010 [Page 3] Internet-Draft Security Design for RPL March 2010 o Timeliness (delay protection): Assurance that transmitted information was received in a timely manner. The actual protection provided can be adapted on a per-packet basis and allows for varying levels of data authenticity (to minimize security overhead in transmitted packets where required) and for optional data confidentiality. When nontrivial protection is required, replay protection is always provided. Replay protection is provided via the use of a non-repeating value (nonce) in the packet protection process and storage of some status information for each originating device on the receiving device, which allows detection of whether this particular nonce value was used previously by the originating device. In addition, so-called delay protection is provided amongst those devices that have a loosely synchronized clock on board. The acceptable time delay can be adapted on a per-packet basis and allows for varying latencies (to facilitate longer latencies in packets transmitted over a multi-hop communication path). Cryptographic protection may use a key shared between two peer devices (link key) or a key shared among a group of devices (group key), thus allowing some flexibility and application-specific tradeoffs between key storage and key maintenance costs versus the cryptographic protection provided. If a group key is used for peer-to-peer communication, protection is provided only against outsider devices and not against potential malicious devices in the key-sharing group. Data authenticity may be provided using symmetric-key based or public- key based techniques. With public-key based techniques (via signatures), one corroborates evidence as to the unique originator of transmitted information, whereas with symmetric-key based techniques data authenticity is only provided relative to devices in a key-sharing group. Thus, public-key based authentication may be useful in scenarios that require a more fine-grained authentication than can be provided with symmetric-key based authentication techniques alone, such as with group communications (broadcast, multicast), or in scenarios that require non-repudiation. Struik Expires September 1, 2010 [Page 4] Internet-Draft Security Design for RPL March 2010 2. Functional description of packet protection 2.1. Transmission of outgoing packets For each transmitted packet, the current time, if any, shall be recorded and used in the outgoing packet security procedure described in Section 2.1.1. If that procedure is not successful, the packet shall not be processed further and a status code indicating the purported source of the error shall be generated with sufficient granularity so as to allow a subsequent process to act upon this error and perform a failure recovery and/or error logging and reporting operation; otherwise, the packet may be communicated. 2.1.1. Outgoing packet security procedure Input: outgoing packet, required security protection; time of handling. Output: secured packet, status information. The outgoing packet security procedure shall include the following steps: 1. If no cryptographic security protection is required, the procedure shall return with the secured packet set to the packet to be secured. 2. The procedure shall derive the nonce to be used to protect the outgoing packet from locally maintained counter information and the time of handling and shall report an error code if this derivation process fails. 3. The procedure shall construct the security-related header fields of the protected packet and insert these into the packet according to the procedure described in Section 3. The security-related header fields shall encode information regarding the security protection to be applied to the packet and the key and nonce to be used to protect the packet with sufficient granularity so as to allow a recipient to recover that information uniquely. 4. The procedure shall execute the cryptographic mode of operation with as inputs the packet header and packet payload resulting from the previous step, the security protection to be applied to the packet, the indicated key to be used, and the nonce value obtained before. Struik Expires September 1, 2010 [Page 5] Internet-Draft Security Design for RPL March 2010 5. The procedure shall suitably combine the payload field with the output of the cryptographic transformation and substitute the payload field by the thus obtained field, thus yielding the secured packet. 6. The procedure shall check whether the thus obtained secured packet satisfies syntax checks (e.g., on resulting packet length) and shall perform security policy checks (e.g., as to whether the security protection applied and the key and nonce value used satisfy locally maintained security policies for that packet in question) and shall report an error code if any of these checks fail. 7. The procedure shall update the locally maintained nonce information, so as to preclude reconstruction of the same nonce value twice. 8. The procedure shall return with the thus secured packet. 2.2. Reception of incoming packets For each received packet, the time of receipt, if any, shall be recorded and used in the incoming packet security procedure specified in 2.2.1. If that procedure is not successful, the packet shall not be processed further and a status code indicating the purported source of the error shall be generated with sufficient granularity so as to allow a subsequent process to act upon this error and perform a failure recovery and/or error logging and reporting operation; otherwise, the packet may be processed further. 2.2.1. Incoming packet security procedure Input: received packet; time of receipt. Output: unsecured packet, status information The incoming packet security procedure shall include the following steps: 1. The procedure shall derive the purported security protection applied to the packet from the packet's security-related header fields according to the procedure described in Section 3. 2. The procedure shall perform security policy checks (e.g., whether the security protection applied satisfies locally maintained security policies for that packet in question) and shall report an error code if this check fails. Struik Expires September 1, 2010 [Page 6] Internet-Draft Security Design for RPL March 2010 3. If those security policy checks succeeded and the purported security protection indicates that no cryptographic security protection has been applied, the procedure shall return with the unsecured packet set to the packet to be unsecured. 4. The procedure shall derive the purported originator of the packet from the packet header according and convert this to the logical identifier for that device according the device table described in Section 3. 5. The procedure shall perform security policy checks (e.g., whether the security protection applied satisfies locally maintained security policies for that packet and that originating device in question) and shall report an error code if this check fails. 6. The procedure shall derive the purported nonce used to protect the packet from the packet's security-related header fields and the time of receipt. 7. The procedure shall perform security policy checks on the nonce value derived in the previous step and locally maintained status information, including that for the device logically identified in Step 4 above. This shall include checking whether the nonce value obtained in the previous step cannot possibly have been used by the originating device before (thus, providing replay detection) and, checking whether that counter value corresponds to a recently communicated packet (thus, providing timeliness). The procedure shall report an error code if any of these checks fail. 8. The procedure shall derive the purported key used to protect the packet from information contained in the packet's security-related header fields and obtain the actual key thus identified from locally maintained status information according to the key table described in Section 4. The procedure shall report an error code if this procedure fails. 9. The procedure shall perform key-related security policy checks (e.g., whether the key applied satisfies locally maintained security policies for that packet and for that originating device in question) and shall report an error code if this check fails. 10.The procedure shall execute the inverse cryptographic mode of operation with as inputs the packet header and packet payload, the security protection purportedly applied to the packet and the key and the nonce value purportedly used to secure the packet. Struik Expires September 1, 2010 [Page 7] Internet-Draft Security Design for RPL March 2010 11.If this procedure fails, the procedure shall report an error code; otherwise, it shall suitably combine the payload field with the output of the cryptographic transformation and substitute the payload field by the thus obtained field, thus yielding the unsecured packet. 12.The procedure shall update the locally maintained nonce information for the originating device, so as to preclude successful reception of packets from the same originating device with the same nonce value twice. 13.The procedure shall return with the thus unsecured packet. 3. Packet Formatting The security design described here can be implemented with the general packet format defined in [11], as follows: o Security subfield. Specify bit b4 of the so-called DIO base ([11], Fig. 4) as Security subfield. This field shall indicate whether security is applied to the packet. o Security-related header. Specify the security-related header field as the leftmost DIO sub- option field ([11], Fig. 5). This sub-option field shall be present only if the security subfield is set to one. o Packet payload (from security processing perspective). All sub-option fields except the leftmost DIO sub option field shall be considered as packet payload from a security processing perspective. 4. Information elements These should be further detailed with a next version of this document. Struik Expires September 1, 2010 [Page 8] Internet-Draft Security Design for RPL March 2010 5. Security Considerations This document describes a security design for the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL). 6. IANA Considerations This document contains no request to IANA. 7. Conclusions We presented a security design for communication security for the IPv6 Routing Protocol for Low Power and Lossy Networks (RPL) and discussed cross-layer aspects and security policy considerations. The design is tailored towards low overall implementation cost, by providing an orthogonal design that separates general security constructs and specific security policy settings and that takes cross- layer aspects and trust lifecycle management consideration of security design into account. An application-specific instantiation of this security design (e.g., to serve specific needs identified in [4], [5], [6], [7]) can be realized via proper security policy settings. The design allows for different levels of granularity of security services, via the use of group keys, ranging from coarse-grained protection against outsider devices only (via a network-wide key) to more fine-grained protection relative to a particular multicast group (via a group key) or relative to an peer-to-peer connection (via a link key). The use of group keys also supports semi-automatic lifecycle management, by facilitating key management due to, e.g., network topology changes and due to changes in trust models underlying network operations. For more details, we refer to, e.g., [8]. 8. Future Work As for now, the security design focuses on communication security aspects and does not pay great attention to communication stack layering and trust lifecycle management aspects. Moreover, scant attention is being paid to the impact of insider attacks and of compromised devices on network operations. This should be addressed in a future version of this document. Struik Expires September 1, 2010 [Page 9] Internet-Draft Security Design for RPL March 2010 With the current RPL design [11], there seems to be room for significantly reducing the over-the-air per-packet communication overhead. While not strictly a security concern, the use of proper cryptographic techniques can assist in enhancing robustness of overhead reduction techniques at relatively low cost (cf., e.g., [9]). Similarly, there seems to be room for significantly reducing the amount of security state maintained on communicating devices. This should also be addressed in a future version of this document. This being said, some of this work is being undertaken with other IETF groups, such as, e.g., 6lowapp ([8], [10]). Assumptions and design considerations need to be validated with 6lowapp charter and may result in emanating work that may find a home in different IETF groups. 9. References 9.1. Normative references [1] J.P. Vasseur, ''Terminology in Low power And Lossy Networks,'' draft-ietf-roll-terminology-02, October 8, 2009. [2] P. Thubert, Ed., ''RPL Objective Function 0,'' draft-ietf-roll-of0- 01, February 18, 2010. [3] J.P. Vasseur, M. Kim, Eds., K. Pister, H. Chong, ''Routing Metrics used for Path Calculation in Low Power and Lossy Networks,'' draft- ietf-roll-routing-metrics-04, December 3, 2009. [4] A. Brandt, J. Buron, G. Porcu, ''Home Automation Routing Requirements in Low Power and Lossy Networks,'' draft-ietf-roll-home- routing-reqs-11, January 3, 2010. [5] J. Martocci, P. de Mil, W. Vermeylen, N. Riou, ''Building Automation Routing Requirements in Low Power and Lossy Networks,'' draft-ietf- roll-building-routing-reqs-09, January 28, 2010. [6] RFC 5548, Routing Requirements for Urban Low-Power and Lossy Networks, M. Dohler, T. Watteyne, T. Winger, D. Barthel, May 2009. [7] RFC 5673, Industrial Routing Requirements in Low-Power and Lossy Networks, Internet Request for Comments, K. Pister, P. Thubert, S. Dwars, T. Phinney, October 2009. Struik Expires September 1, 2010 [Page 10] Internet-Draft Security Design for RPL March 2010 [8] R. Struik, ''Security Architectural Design Considerations for Low- Power Wireless Sensor Networks,'' draft-struik-6lowapp-security- considerations-00, Oct 19, 2009. [9] R. Struik, ''Security and Efficiency Enhancements,'' IEEE 802.15/08/828r9, June 17, 2009. Available from https://mentor.ieee.org/802.15/. [10] C. O'Flynn, ''Initial Configuration of Resource-Constrained Devices,'' draft-oflynn-6lowapp-bootstrapping-00, January 27, 2010. [11] T. Winter, T. Winter, P. Thubert, Eds., ''RPL: IPv6 Routing Protocol for Low power and Lossy Networks,'' draft-ietf-roll-rpl-06, February 3, 2010. [12] T. Tsao, R. Alexander, M. Dohler, V. Daza, A. Lozano, Eds., ''A Security Framework for Routing over Low Power and Lossy Networks,'' draft-tsao-roll-security-framework-01, September 20, 2009. [13] ANSI X9.92, Public Key Cryptography for the Financial Services Industry - Digital Signature Algorithms Giving Partial Message Recovery - Part 1: Elliptic Curve Pintsov-Vanstone Signatures (ECPVS), American Bankers Association, 2009. Available from http://www.ansi.org. [14] ANSI X9.63-2001, Public Key Cryptography for the Financial Services Industry - Key Agreement and Key Transport Using Elliptic Curve Cryptography, American Bankers Association, November 20, 2001. Available from http://www.ansi.org. [15] FIPS Pub 186-2, Digital Signature Standard (DSS), Federal Information Processing Standards Publication 186-2, US Department of Commerce/National Institute of Standards and Technology, Gaithersburg, Maryland, USA, January 27, 2000. (Includes change notice, October 5, 2001.) [16] FIPS Pub 197, Advanced Encryption Standard (AES), Federal Information Processing Standards Publication 197, US Department of Commerce/N.I.S.T., Springfield, Virginia, November 26, 2001. Available from: http://csrc.nist.gov/. [17] Institute of Electrical and Electronics Engineers, Inc., IEEE Std. 802.15.4-2006, IEEE Standard for Information Technology - Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks Specific Requirements - Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Struik Expires September 1, 2010 [Page 11] Internet-Draft Security Design for RPL March 2010 Specifications for Low Rate Wireless Personal Area Networks (WPANs), New York: IEEE Press, 2006. (Revision of IEEE Std 802.15.4-2006.) [18] NIST Pub 800-38C, Recommendation for Block Cipher Modes of Operation - The CCM Mode for Authentication and Confidentiality, NIST Special Publication 800-38C, US Department of Commerce/N.I.S.T., Springfield, Virginia, May 2004. Available from http://csrc.nist.gov/. 9.2. Informative references [19] E. Callaway, T.S. Messerges, J. Cukier, T.A.M. Kevenaar, L. Puhl, R. Struik, ''A Security Design for a General Purpose, Self- Organizing, Multihop Ad Hoc Wireless Network, in Proceedings of the 2003 ACM Workshop on Security of Adhoc and Sensor Networks (SASN), George Mason University, Fairfax, VA, October 31, 2003. [20] L.F. Cranor, S. Garfinkel, Eds., Security and Usability: Designing Secure Systems That People Can Use, Cambridge: O'Reilly, 2005. [21] C. Karlof, D. Wagner, ''Secure Routing in Wireless Sensor Networks: Attacks and Countermeasures,'' in Proceedings of the First IEEE International Workshop on Sensor Network Protocols and Applications (SNPA), May 11, 2003. [22] C. Karlof, N. Sastry, D. Wagner, ''TinySec: A Link Layer Security Architecture for Wireless Sensor Networks,'' in Proceedings of the Second ACM Conference on Embedded Networked Sensor Systems - SenSys 2004, November 2004. [23] A.J. Menezes, P.C. van Oorschot, S.A. Vanstone, Handbook of Applied Cryptography, Boca Raton: CRC Press, 1997. [24] U.S. Department of Energy, Industrial Wireless Technology for the 21st Century, December 2002. Available from http://www.oit.doe.gov/sens_cont/pdfs/wireless_technology.pdf [25] D. Wagner, ''Security for Sensor Networks: Cryptography and Beyond,'' in Proceedings of the 2003 ACM Workshop on Security of Adhoc and Sensor Networks (SASN), George Mason University, Fairfax, VA, October 31, 2003. [26] A.S. Wander, N. Gura, H. Eberle, V. Gupta, S.C. Shantz, ''Energy Analysis of Public-Key Cryptography for Wireless Sensor Networks,'' Struik Expires September 1, 2010 [Page 12] Internet-Draft Security Design for RPL March 2010 in Proceedings of the Third IEEE International Conference on Pervasive Computing - PerCom 2005, 2005. [27] ZigBee Alliance, 'ZigBee General MRD,' ZigBee document 03/143r0ZB, June 24, 2003. 10. Acknowledgments This submission is influenced by discussions with IETF members and members of the IEEE 802 and ZigBee communities. (Individual members to be acknowledged in person in later version of this document.) Struik Expires September 1, 2010 [Page 13] Internet-Draft Security Design for RPL March 2010 Authors' address: R. Struik Certicom Corp. 5520 Explorer Drive, 4th Floor Mississauga, ON Canada L4W 5L1 Phone: +1 (905) 501-6083 Email: rstruik@certicom.com Struik Expires September 1, 2010 [Page 14]