INTERNET-DRAFT A. Dvir Intended Status: Experimental T. Holczer Expires: January 14, 2012 L. Dora L. Buttyan July 13, 2011 Version Number and Rank Authentication for RPL draft-dvir-roll-security-authentication-00.txt Abstract Designing a routing protocol for large low-power and lossy networks (LLNs), consisting of thousands of constrained nodes and unreliable links, presents new challenges. The IPv6 Routing Protocol for Low- power and Lossy Networks (RPL), have been developed by the IETF ROLL Working Group as a preferred routing protocol to provide IPv6 routing functionality in LLNs. Unfortunately, the currently available security services in RPL will not protect against a compromised internal node that can construct and disseminate fake messages. Therefore, in RPL special security care must be taken when the Destination Oriented Directed Acyclic Graph (DODAG) root is updating the Version Number by which reconstruction of the routing topology can be initiated. The same care also must be taken to prevent an internal attacker (compromised DODAG node) to publish decreased Rank value, which causes a large part of the DODAG to connect to the DODAG root via the attacker and give it the ability to eavesdrop or manipulate a large part of the network traffic. In this document, a new security service is described that prevents any misbehaving DODAG node from illegitimately increasing the Version Number or publish illegitimately decreased Rank values. 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." Dvir, et al. January 14, 2011 [Page 1] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright and License Notice Copyright (c) 2011 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. Dvir, et al. January 14, 2011 [Page 2] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 Table of Contents 1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 VeRA - Version Number and Rank Authentication . . . . . . . . . 6 3.1 Version Number Authentication . . . . . . . . . . . . . . . 8 3.2 Rank Authentication . . . . . . . . . . . . . . . . . . . 10 3.3 Format of the Authentication Option . . . . . . . . . . . 14 3.4 The Security Scheme . . . . . . . . . . . . . . . . . . . 16 4 Security Considerations . . . . . . . . . . . . . . . . . . . 18 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5.1 RPL Control Message Option . . . . . . . . . . . . . . . 18 5.2 New Registry for the Code Value Type . . . . . . . . . . 18 5.3 New Registry for the Algorithm Type . . . . . . . . . . . 19 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1 Normative References . . . . . . . . . . . . . . . . . . 21 7.2 Informative References . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Dvir, et al. January 14, 2011 [Page 3] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 1 Terminology 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 RFC 2119 [RFC2119]. This document adopts and conforms to the terminology defined in [I-D.ietf-roll-terminology] and in [RFC4949]. As they form networks, LLN devices often mix the roles of 'host' and 'router' when compared to traditional IP networks. In this document, 'host' refers to an LLN device that can generate but does not forward RPL [I-D.ietf-roll-rpl] traffic, 'router' refers to an LLN device that can forward as well as generate RPL traffic, and 'node' refers to any RPL device, either a host or a router. This document introduces the following terminology: Compromised: Taking control over a node. h(): Cryptographic one-way hash function [PseuFun]. r: Random number. V: Version Number hash chain. i: Index of the Version Number hash chain. V_0: Root of the Version Number hash chain. V_i: The ith Version Number hash chain element. n+1: Version Number hash chain length. x_i: Random number. R: Rank hash chain. j: Index of the Rank hash chain. l+1: Rank hash chain length. R_(i,j): The jth Rank hash value associated with the ith Version Number hash chain. R_mrh=R_(i,l): Max Rank hash value associated with the ith Version Number hash chain. R_sender: Rank element value. Dvir, et al. January 14, 2011 [Page 4] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 Rank_root: Rank value of the DODAG root. Rank_sender: Rank value of the parent. M: Message. Init_VN: Initial value of the Version Number. VN: Current Version Number value. IP: Integrity Protection value. MAC: Message authentication code. MHRI: MinHopRankIncrease [I-D.ietf-roll-rpl]. OF: Objective Function [I-D.ietf-roll-rpl]. 2 Introduction Low power and Lossy Networks (LLNs) consist largely of constrained nodes with limited processing power, memory, and sometimes energy, when they are battery operated. These nodes are interconnected by unstable lossy links, typically supporting only low packet and data delivery rates. Another characteristic of such networks is that point-to-point is not the typical traffic pattern, but point-to- multipoint and multipoint-to-point are. Furthermore, such networks may potentially comprise up to thousands of nodes. These characteristics offer unique challenges to a routing solution. The IETF ROLL Working Group has defined application-specific routing requirements for a Low power and Lossy Network (LLN) routing protocol, specified in [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. Moreover, based on those standards, an IPv6 Routing Protocol for Low power and Lossy Networks (RPL) has been proposed [I-D.ietf-roll-rpl] and a security framework for RPL is described in [I-D-roll-security-framework]. Many LLN systems are deployed in unattended or remote locations, such as urban environments [RFC5548]. Hence, security mechanisms that provide confidentiality and authentication are critical for the operation of many applications. The security services that RPL currently provides natively are sufficient to protect the network against such an attack if only an external attacker is assumed. However, native RPL security services will not protect against a compromised internal node. Therefore, this document considers the case where the attacker is a compromised node, where the source of the compromise can be logical [FC_Code] or physical [Tamper] and the Dvir, et al. January 14, 2011 [Page 5] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 attacker can intercept, forge, modify, inject, replay, and create messages (data or control) in order to interfere with the operation of entire network and exhaust nodes' batteries. An internal adversary can attack RPL in many different ways. However, some of these attacks have only a minor influence, while others may have a major influence in the network. A consequence of an attack that will lead to reconstructing the entire DAG and exhaust the nodes' batteries, or eavesdropping a large part of the network traffic can have major or even critical influence. One way for an internal adversary to achieve these goals is to change/modify the Version Number of the DODAG [I-D.ietf-roll-rpl], a sequential counter that is incremented by the DODAG root to form a new Version of a DODAG, or to change/modify the DODAG node Rank value [I-D.ietf-roll-rpl], representation of the location of that node within a DODAG. Therefore, this document presents a security scheme to prevent the following attacks: (i) An internal attacker impersonating a DODAG root and illegitimately increasing the Version Number. (ii) An internal attacker publishing an illegitimately decreased Rank value. Implementation of the security service described in this document is OPTIONAL. It is RECOMMENDED that implementers carefully consider security requirements and the availability of security mechanisms in their network. The hash functions, MAC functions, and digital signature algorithms used in the protocols are based on sections 10.1 and 10.9.2 of [I-D.ietf-roll-rpl], e. g., SHA-256 hash function specified in Section 6.2 of [FIPS180], message encoding rules of Section 8.1 of [RFC3447]. The elliptic curve cryptography (ECC) is based on section 2.7 of [SECG2]. The Hashed Message Authentication Mode (HMAC) is described in [RFC4868]. 3 VeRA - Version Number and Rank Authentication A grounded DODAG offers connectivity to hosts that are required to satisfy the application-defined goal. An attacker may try to become a grounded DODAG root by sending a well-constructed DIO message. The scope of the current RPL security services is the link; therefore, in RPL the authenticity of the messages sent by the DODAG root relies on the trustworthiness of all intermediate DODAG nodes and the fact that none of the keys are compromised. However, because of to the lack of physical protection, DODAG nodes can be compromised (including their keys). This allows an attacker to send an authentic DIO message that will be accepted by all the DODAG nodes. Therefore, a node that receives a DIO message from the attacker will multicast it to its Dvir, et al. January 14, 2011 [Page 6] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 neighbors using uncompromised keys. The content of the message from the attacker will affect other nodes participating in the DODAG. Version number is an element of each DIO message and related to the network. The Version Number is monotonically incremented by the root each time the DODAG root decides to form a new Version of the DODAG in order to revalidate the integrity and allow global repairs to occur. The Version Number is propagated unchanged Down the DODAG as routers join the new DODAG. The Version Number value is globally significant in a DODAG and indicates the Version of the DODAG that a router is operating in. An older (lesser) value indicates that the originating router has not migrated to the new DODAG and cannot be used as a parent once the receiving node has migrated to the newer DODAG [I-D.ietf-roll-rpl]. RPL allows the Version Number to be increased regularly or occasionally. Moreover, reconstruction of the routing topology can be initiated by sending a DIO message with an increased Version Number. Therefore, preventing any misbehaving DODAG node from impersonating the actual DODAG root and increasing the Version Number is essential. Note that how often the Version Number is increased is out of scope of this draft (application dependent). The Rank is a value that helps the nodes to determine at what level they are in the directed acyclic graph. The lower the Rank is, the closer (in a sense of the hop numbers) the node is to the DODAG root. Each node must set the Rank such that the Rank of all the selected DODAG parents are lower. The siblings of a node are those neighboring nodes whose Rank value is equal to the Rank value of the node. MinHopRankIncrease (MHRI) is the minimum increase in Rank value between a node and any of its DODAG parents. RPL allows the nodes to increase their Rank in order to become distant from the DODAG root. This can be beneficial for the node, because the node has to forward fewer messages, the closer a node is placed to the DODAG root the more messages it has to forward. In that case the DODAG parents and the siblings of the node may change, and also the nodes that set this node as a parent have to change the relation, otherwise a loop may be formed. RPL has some mechanisms to detect loops that may arise because of other reasons than described above. If the network detects a loop that can be difficult to repair, it may reconstruct the whole graph. The reconstruction, global repair, can be initiated by the DODAG root by sending DIO messages with an increased Version Number. By publishing a high Rank value, an attacker can move deeper in the DODAG in order to increase the size of the parent set or improve some other metric. However, the most effective Rank attack is by decreasing the Rank. By publishing a low Rank value, a large part of Dvir, et al. January 14, 2011 [Page 7] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 the DODAG will connect to the DODAG root via the attacker, and give it the ability to eavesdrop and manipulate a large part of the network traffic. 3.1 Version Number Authentication By authenticating the Version Number, each DODAG node can securely forward the DIO message in order to bootstrap or update the DODAG Version. Upon initialization, a DODAG root generates a random number r and calculates a hash chain [L1981], named as Version Number hash chain, of size n+1: V_n, V_(n-1)..., V_1, V_0 where V_n=h(r), V_i=h(V_(i+1)), with the random number r, where h() is a cryptographic hash function. Then the DODAG root reveals the root of the Version Number hash chain V_0 and using any supported integrity protection algorithm (e. g., digital signature or MAC) the DODAG roots binds the root value to a particular DODAG, {V_0}_sign/mac. Finally, the DODAG root multicasts the DIO message (M#1, in Figure 1) with V_0, the initial value Init_VN of the Version Number and the integrity protection data; the DODAG root can resend the signed DIO message until the first Version Number update occurs. Upon receiving the signed DIO message, each intermediate DODAG node verifies the authentication data and in case of success saves the integrity protection data, the root V_0 of the Version Number hash chain, and the initial value Init_VN of the Version Number. When the trickle timer [RFC6206] expires, it multicasts to all neighbors the DIO message (M#2) according to [I-D.ietf-roll-rpl]. If the message is not authentic, the intermediate DODAG node MUST ignore the message. Upon Version Number update, the DODAG root reveal the next Version Number hash chain element V_i and sends a DIO message (M#3) with a new Version Number VN and V_i. Upon receiving a DIO message with a new Version Number, an intermediate DODAG node can easily verify the message because, if the Version Number is increased by the DODAG root, h^{i}(V_i) must be equal to V_0. Upon success, the intermediate DODAG node saves the current Version Number value. When the trickle timer [RFC6206] expires, it multicasts to all neighbors the DIO message (M#4) after updating according to section 6.3.1. of [I-D.ietf-roll-rpl]. If an attacker wants to increase the Version Number, then it has to compute a pre-image of the last revealed hash chain element of the Version Number hash chain. However, computing the next element Dvir, et al. January 14, 2011 [Page 8] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 V_(i+1) knowing V_i is hard when r is not known and h() is a cryptographic one-way hash function. In the case when a new node wants to join the DODAG, any DODAG node receiving a unicast DIS message (M#5) from the new node (Non DODAG node), MUST reply with a DIO message (M#6) containing the current Version Number value VN, the initial Version Number value Init_VN, the root of the Version Number hash chain V_0, the current Version Number hash chain element V_i, and the integrity protection data IP. Note that all these data is stored by every DODAG node in the network following our scheme. It is RECOMMENDED to use the integrity protection mechanism. When a digital signature is used, each node has to know the public signature verification key. For a normal node it is very costly to digitally sign and verify; therefore it is RECOMMENDED to use the sign procedure only for bootstrapping or in case the DODAG root revealed all the hash chain elements of the current hash chain and need to generate a new hash chain. The first DIO message which contains the new hash chain root, MUST be signed. Moreover, it is OPTIONAL to resend the first DIO message with the hash chain root and the signature till the first Version Number update. In order to minimize the computation time and memory usage of the hash chain, the implementer can use the technique in [OptHash] on the DODAG root side. In case the implementer decides to authenticate the hash chain root using MAC function, the Version Number hash chain root needs to be transported reliably. The sequence diagram of the Version Number Authentication algorithm has three parts: authentication procedure, Version Number update, and admission of a new node in the DODAG. Root Node v Node u New Node |Init_VN=n, V_0, IP | | | |---------------->M#1| | | | |Init_VN=n,V_0,IP| | | |----------->M#2 | | | | | | : : : : | | | | | VN=n+i, V_i | | | |---------------->M#3| VN=n+i, V_i | | | |----------->M#4 | | | | | | : : : : | | | | | | | Unicast DIS | Dvir, et al. January 14, 2011 [Page 9] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 | | |M#5<-------------------| | | | | | | | VN,Init_VN,V_0,V_i,IP | | | |------------------->M#6| | | | | Figure 1: Sequence Diagram of Version Number Authentication Algorithm 3.2 Rank Authentication By authenticating the Rank value, each DODAG node can conclude that its Rank value is greater than its parent Rank value and from the DODAG root towards the current DODAG node, the Rank values are monotonically increasing. Upon initialization, a DODAG root generates a random number r and calculates a hash chain[L1981], named as Version Number hash chain, of size n+1: V_n, V_(n-1)..., V_1, V_0 where V_n=h(r), V_i=h(V_(i+1)), with the random number r. For each element V_i of the Version Number hash chain the DODAG root generates a new random number x_i and calculates a new hash chain, named as Rank hash chain, of size l+1: R_(i,0), R_(i,1)..., R_(i,l-1), R_(i,l) where R_(i,0)= h(x_i), R_(i,j)=h(R_(i,j-1)), with the new random number x_i. In theory, l should be 65535 to have a different value for each possible Rank value (Rank is 16 bits long [I-D.ietf-roll-rpl]). In practice, 256 is large enough as for most of the operations DAGRank [I-D.ietf-roll-rpl] is used (the DAG Rank of a node is the upper 8 bits of the Rank), which is 8 bits long. If DAGRank is used when defining the hash chain, then all occurrences of Rank must be substituted by DAGRank in the sequel. Figure 2 illustrates the hash chains'. Note that, in any case we are using the Rank value as the indicator to the number of times to hash a value we divided the Rank value by MinHopRankIncrease in order to decrease the size of Rank hash chain, Rank/MinHopRankIncrease. Then the DODAG root reveals the root of the Version Number hash chain V_0, computes MAC_{V_1}(R_(mrh)) a message authentication code (MAC) value computed over the Max Rank hash (mrh) value R_(mrh)=R_(1,l) of the next Rank Hash chain with the next Version Number hash chain element V_1 as the key. Finally, the DODAG root multicast a DIO message with V_0, MAC_{V_1}(R_(mrh)); the DODAG root can resend the DIO message till the DODAG needs to update its Rank value or update the Version Number. Upon receiving the DIO message, each intermediate DODAG node saves the root V_0 of the Version Number hash chain, and the MAC value MAC_{V_1}(R_(mrh)). When the trickle timer [RFC6206] expires, it multicasts to all neighbors the DIO message according to Dvir, et al. January 14, 2011 [Page 10] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 [I-D.ietf-roll-rpl]. Figure 3 illustrates the initialization of the Rank Authentication algorithm. Upon Version Number update, the DODAG root sends a DIO message with the following parameters: next Version Number value VN as described in [I-D.ietf-roll-rpl], next Version Number hash chain element V_i, a message authentication code (MAC) value MAC_{V_(i+1)}(R_(mrh)) computed over the Max Rank hash value R_mrh=R_(i+1,l) with the next Version Number hash chain element V_(i+1) as the key, and a Rank element value R_sender=h^{Rank_root}(x_i), where Rank_root is the new Rank value of the DODAG root. Upon receiving a DIO message with a new Version Number or new Rank value, an intermediate DODAG node use the revealed key V_i, the MAC value from the previous update MAC_{V_(i)}(R_(mrh)) and the Rank element R_sender, to verify whether the Rank value of its parent is monotonically increasing as follows: o It generates R_check= h^{l-Rank_sender}(R_sender), where Rank_sender is the Rank value of the parent. o It checks if MAC_{V_(i)}(R_mrh), from the previous update, is equal to MAC_{V_(i)}(R_check). o If so, intermediate DODAG node v can conclude that the Rank is monotonically increasing and: o It calculates its Rank value regarding its Objective Function, Rank_v. o It calculates delta= Rank_v - Rank_(sender), the difference between the DODAG node Rank value and its parent Rank value. Node v has the parent Rank from the DIO message. o It calculates R_sender= h^{delta}(R_sender). o When the trickle timer [RFC6206] expires, it multicasts to all neighbors the DIO message according to [I-D.ietf-roll-rpl] with the new R_sender value. If an attacker wants to decrease the Rank [I-D.ietf-roll-rpl], then it has to compute a pre-image of the last R_sender. However, computing the previous R_(i-1) knowing R_(i) is hard when x_i is not known and h() is a cryptographic one-way hash function. Figure 4 illustrates the Rank update algorithm. In the case when a new node wants to join the DODAG, any node receiving a unicast DIS message from the new node MUST reply with a Dvir, et al. January 14, 2011 [Page 11] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 DIO message containing the last MAC value. Version Number Hash Chain, V_n=h(r), V_i=h(V_(i+1)) h h h h h r=random V_n-->V_(n-1)-->...V_i-->....->V_2-->V_1-->V_0 | V x_i=random R_(i,0) | h | v R_(i,1) | h | v R_(i,2) . . h . v R_(i,l-1) | h | v R_(i,l), Max Rank hash value Rank Hash Chain, R_(i,0)=h(x_i), R_(i,j)=h(R_(i,j-1)) Figure 2: The Hash Chains'. DODAG root DODAG node v Generate Random Number r Get | DIO: V_o, MAC_{V_1}(R_mrh) | | v | Calculate hash chain v Dvir, et al. January 14, 2011 [Page 12] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 h(h(...h(r)))),V_0 Save V_o, MAC_{V_1}(R_mrh) | | | | v v For each V_i generate Send random number x_i DIO: V_o, MAC_{V_1}(R_mrh) | | v Rank= OF(root) | | v Send DIO: V_o, MAC_{V_1}(R_mrh) Figure 3: Rank Authentication Algorithm - Initialization DODAG root DODAG node v Version Number Update Get | DIO:V_i, MAC_{V_(i+1)}(R_mrh), R_sender | | v v Rank= OF(root) R_check=h^{l-Rank_parent}(R_sender) | | | | v v R_sender=h^{Rank}(x_i) Calculate MAC_check=MAC_{V_i}(R_mrh) | | | | v v R_mrh= h(h(...h(x_i)))) MAC_check == MAC_i | | | | v v Send Rank=OF(v) DIO: V_i, MAC_{V_(i+1)}(R_mrh), R_sender | | v delta= Rank_v - Rank_Parent | Dvir, et al. January 14, 2011 [Page 13] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 | v R_sender=h^{delta}(R_sender) | | v Send DIO: V_i, MAC_{V_(i+1)}(R_mrh), R_sender Figure 4: Rank Authentication Algorithm - Update 3.3 Format of the Authentication Option In order to authenticate the Version Number or/and the Rank, a DIO MUST carry one "Authentication" option. An Authentication option consists of the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=10 | Option Length |Code | Flags | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | : Authentication Data : | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Format of the Authentication Option Option Type: 0x0A (to be confirmed by IANA) Option Length: 8-bit unsigned integer, variable length of the option in octets excluding the Type and Length fields. Code: 3-bit unsigned integer, identifies the type of Authentication option. This document defines codes for the following Authentication types (all codes are to be confirmed by IANA Section): +-----+-------------------------------+ |Value| Code Value Type | +-----+-------------------------------+ | 0 |Version Number Hash Chain Value| Dvir, et al. January 14, 2011 [Page 14] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 | | | | 1 |Version Number Hash Chain Root | | | | | 2 |Rank Hash Chain Value | | | | | 3 |MAC of Max Rank Hash Value | | | | | 4 |Integrity Protection Value | | | | | else|Unassigned | | | | +-----+-------------------------------+ Figure 6: Code Type Flags: 5-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. Algorithm: 8-bit field, indicating which algorithm is being used. The type of the algorithm is set by the Code field: o Code Field = 0: Hash Function. o Code Field = 1: Hash Function. o Code Field = 2: Hash Function. +----------+--------------------------+ |Bit Number| Hash Function | +----------+--------------------------+ | 0 | SHA-256 | | | | | 1 | SHA-512 | | | | | else | Unassigned | +----------+--------------------------+ Figure 7: Hash Function fi o Code Field = 3: MAC Function. +----------+--------------------------+ |Bit Number| MAC Function | +----------+--------------------------+ | 0 | HMAC-SHA-256 | | | | Dvir, et al. January 14, 2011 [Page 15] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 | 1 | HMAC-SHA-512 | | | | | else | Unassigned | +----------+--------------------------+ Figure 8: MAC Function o Code Field = 4: Integrity Protection algorithm (Digital Signature/MAC). +----------+--------------------------+ |Bit Number| Integrity Protection | +----------+--------------------------+ | 0 | HMAC-SHA-256 | | | | | 1 | HMAC-SHA-512 | | | | | 2 | RSA with SHA-256 | | | | | 3 |ECC-SECP256K1 with SHA-256| | | | | else | Unassigned | +----------+--------------------------+ Figure 9: Integrity Protection Authentication Data: Contains the authentication data compatible with the Code and Function Type fields. Unassigned bits of the Authentication option are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. 3.4 The Security Scheme Using the two algorithms described above in one Security Scheme prevents an internal attacker from impersonating a DODAG root, illegitimately increasing the Version Number and compromise an illegitimately decreased Rank value. The following tables describe which Authentication option types to use in each step of the algorithms to prevent both Version Number and Rank attacks: VNHA: Version Number Hash Chain Value. VNR: Version Number Hash Chain Root. RHV: Rank Hash Chain Value. MRHM: MAC of Max Rank Hash Value. Dvir, et al. January 14, 2011 [Page 16] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 +------+-------+---------+ | Init | Update| New Node| -----+------+-------+---------+ |VNHV| - | + | + | -----+------+-------+---------+ |VNR | + | - | + | -----+------+-------+---------+ |RHV | - | - | - | -----+------+-------+---------+ |MRHM| - | - | - | -----+------+-------+---------+ |IP | + | - | + | -----+------+-------+---------+ Figure 10: Version Number Authentication +------+-------+---------+ | Init | Update| New Node| -----+------+-------+---------+ |VNHV| - | - | - | -----+------+-------+---------+ |VNR | - | - | - | -----+------+-------+---------+ |RHV | - | + | + | -----+------+-------+---------+ |MRHM| + | + | + | -----+------+-------+---------+ |IP | - | - | - | -----+------+-------+---------+ Figure 11: Rank Authentication +------+-------+---------+ | Init | Update| New Node| -----+------+-------+---------+ |VNHV| - | + | + | -----+------+-------+---------+ |VNR | + | - | + | -----+------+-------+---------+ |RHV | - | + | + | -----+------+-------+---------+ |MRHM| + | + | + | -----+------+-------+---------+ |IP | + | - | + | -----+------+-------+---------+ Figure 12: Version Number and Rank Authentication Dvir, et al. January 14, 2011 [Page 17] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 4 Security Considerations The security mechanism in this draft extend the RPL security mechanisms, sections 6.1 and 10 of [I-D.ietf-roll-rpl]. Therefore, the security consideration described in section 18 of [I-D.ietf-roll-rpl] exists in this document. The scope of the current RPL security services is the link; the authenticity of the messages sent by the DODAG root relies on the trustworthiness of all intermediate nodes and the fact that none of the keys are compromised. The herein proposed Authentication scheme extends the data integrity and data origin authentication [RFC3552] to network level by authenticating Version Number and the Rank. Note that when using the Version Number authentication, only the root can increase the Version Number, so it can control exhaustion of the chain. This draft prevents two powerful attacks: a) An internal attacker impersonating a DODAG root and updating the Version Number; and b) An internal attacker publishing decreased Rank in order to be on the path to the DODAG root for the majority of the nodes and by that to be able to eavesdrop a large part of network traffic. 5 IANA Considerations 5.1 RPL Control Message Option IANA is requested to create a registry for the RPL Control Message Options. New values may be allocated only by an IETF Review. Each value should be tracked with the following qualities: o Value o Capability description o Defining RFC The following bits are currently defined: +----------+------------------------+---------------+ | Value | Description | Reference | +----------+------------------------+---------------+ | 0x0A | Authentication | This document | +----------+------------------------+---------------+ RPL Control Message Option 5.2 New Registry for the Code Value Type Dvir, et al. January 14, 2011 [Page 18] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 IANA is requested to create a registry for the Code Value Type Field, which is contained in the Authentication option. New values may be allocated only by an IETF Review. Each value should be tracked with the following qualities: o Value o Code Value Type o Defining RFC The following bits are currently defined: +-----+-------------------------------+---------------+ |Value| Code Value Type | Reference | +-----+-------------------------------+---------------+ | 0 |Version Number Hash Chain Value| This document | | | | | | 1 |Version Number Hash Chain Root | This document | | | | | | 2 |Rank Hash Chain Value | This document | | | | | | 3 |MAC of Max Rank Hash Value | This document | | | | | | 4 |Integrity Protection Value | This document | | | | | | else|Unassigned | This document | | | | | +-----+-------------------------------+---------------+ Code Field in Authentication Option 5.3 New Registry for the Algorithm Type IANA is requested to create one registry for the Algorithm Field per allocated Code value New values may be allocated only by an IETF Review. Each value should be tracked with the following qualities: o Code Value o Algorithm Value o Capability description o Defining RFC Dvir, et al. January 14, 2011 [Page 19] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 The following bits are currently defined: +------+-----+--------------------------+--------------+ | Code |Algo | Description | Reference | +------+-----+--------------------------+--------------+ | 0 | 0 |SHA-256 | This document| | | | | | | 0 | 1 |SHA-512 | This document| | | | | | | 1 | 0 |SHA-256 | This document| | | | | | | 1 | 1 |SHA-512 | This document| | | | | | | 2 | 0 |SHA-256 | This document| | | | | | | 2 | 1 |SHA-512 | This document| | | | | | | 3 | 0 |HMAC-SHA-256 | This document| | | | | | | 3 | 1 |HMAC-SHA-512 | This document| | | | | | | 4 | 0 |HMAC-SHA-256 | This document| | | | | | | 4 | 1 |HMAC-SHA-512 | This document| | | | | | | 4 | 2 |RSA with SHA-256 | This document| | | | | | | 4 | 3 |ECC-SECP256K1 with SHA-256| This document| | | | | | |else |else |Unassigned | This document| +------+-----+--------------------------+--------------+ Security Algorithm Field in Authentication Option 6 Acknowledgements The work described in this paper is based on results of the WSAN4CIP project, which receives research funding from the European Community's 7th Framework Programme. Apart from this, the European Commission has no responsibility for the content of this document. Amit Dvir has also been supported by the Marie Curie Mobility Grant, OTKA-HUMAN-MB08-B 81654 and Levente Buttyan has been supported by the Hungarian Academy of Sciences through the Bolyai Janos Research Fellowship. The authors would also like to acknowledge the review and comments from Yoav Ben Yehezkel. 7 References Dvir, et al. January 14, 2011 [Page 20] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 7.1 Normative References [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-19 (work in progress), March 2010. [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, "The Trickle Algorithm", RFC 6206, March 2011. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3552] Rescorla E., and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, March 2003. [RFC3447] Jonsson, J., and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. 7.2 Informative References [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-05 (work in progress), March 2011. [I-D-roll-security-framework] Tsao T., Alexander R., Dohler M., Daza V., and A. Lozano, "A Security Framework for Routing over Low Power and Lossy Networks", |%draft-ietf-roll-security-framework-03, (work in progress) December 2010. [draft-ietf-roll-minrank-hysteresis] Gnawali, O., and P. Levis, "The Minimum Rank Objective Function with Hysteresis", draft-ietf-roll-minrank -hysteresis-of-02 (work in progress), April 2011. [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010. [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010. Dvir, et al. January 14, 2011 [Page 21] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [RFC4949] R. Shirey, "Internet Security Glossary", RFC 4949, FYI 36, August 2007. [RFC4868] Kelly, S., and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. [FC_Code] Francillon, A., C. Castelluccia, "Code injection attacks on harvard-architecture devices", ACM conference on Computer and communications security, pp. 15-25, 2008, Virginia, USA. [PseuFun] Goldreich, O., Goldwasser, S., and S. Micali, "How to Construct Random Functions", Journal of the ACM, Volume 33, Number. 4, 1986, pp 210-217. [Tamper] Anderson, R., and M. Kuhn, "Tamper Resistance - a Cautionary Note", USENIX Workshop on Electronic Commerce Proceedings, pp 1-11, 1996, Oakland, California. [L1981] Lamport L., "Password Authentication with Insecure Communication", ACM Journal of Communications Volume 24 Issue 11, pp 770-772, Nov. 1981. [SECG2] D. R. L. Brown, "Standards for Efficient Cryptography Group (SECG), "SEC 2: Recommended Elliptic Curve Domain Parameters version 2.0", Version 2.0, January 2010. [OptHash] Don, C., and M. Jakobsson, "Almost Optimal Hash Sequence Traversal", Fourth Conference on Financial Cryptography, 2002. [FIPS180] National Institute of Standards and Technology, "FIPS Pub 180-3, Secure Hash Standard (SHS)", US Department of Commerce , February 2008, . Authors' Addresses Amit Dvir Dvir, et al. January 14, 2011 [Page 22] INTERNET DRAFT Version Number and Rank Authentication July 13, 2011 Laboratory of Cryptography and Systems Security (CrySyS) Budapest University of Technology and Economics BME-HIT, PO Box 91, 1521 Budapest Hungary EMail: azdvir@gmail.com Tamas Holczer Laboratory of Cryptography and Systems Security (CrySyS) Budapest University of Technology and Economics BME-HIT, PO Box 91, 1521 Budapest Hungary EMail: tamas.holczer@crysys.hu Laszlo Dora Laboratory of Cryptography and Systems Security (CrySyS) Budapest University of Technology and Economics BME-HIT, PO Box 91, 1521 Budapest Hungary EMail: laszlo.dora@crysys.hu Levente Buttyan Laboratory of Cryptography and Systems Security (CrySyS) Budapest University of Technology and Economics BME-HIT, PO Box 91, 1521 Budapest Hungary EMail: buttyan@crysys.hu Dvir, et al. January 14, 2011 [Page 23]