idnits 2.17.1 draft-dvir-roll-security-authentication-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 8, 2012) is 4490 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-06 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT A. Dvir 3 Intended Status: Experimental T. Holczer 4 Expires: July 11, 2012 L. Dora 5 L. Buttyan 6 January 8, 2012 8 Version Number and Rank Authentication 9 draft-dvir-roll-security-authentication-01.txt 11 Abstract 13 Designing a routing protocol for large low-power and lossy networks 14 (LLNs), consisting of thousands of constrained nodes and unreliable 15 links, presents new challenges. The IPv6 Routing Protocol for Low- 16 power and Lossy Networks (RPL), have been developed by the IETF ROLL 17 Working Group as a preferred routing protocol to provide IPv6 routing 18 functionality in LLNs. Unfortunately, the currently available 19 security services in RPL will not protect against a compromised 20 internal node that can construct and disseminate fake messages. 21 Therefore, in RPL special security care must be taken when the 22 Destination Oriented Directed Acyclic Graph (DODAG) root is updating 23 the Version Number by which reconstruction of the routing topology 24 can be initiated. The same care also must be taken to prevent an 25 internal attacker (compromised DODAG node) to publish decreased Rank 26 value, which causes a large part of the DODAG to connect to the DODAG 27 root via the attacker and give it the ability to eavesdrop or 28 manipulate a large part of the network traffic. In this document, a 29 new security service is described that prevents any misbehaving DODAG 30 node from illegitimately increasing the Version Number or publish 31 illegitimately decreased Rank values. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 Copyright and License Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3 VeRA - Version Number and Rank Authentication . . . . . . . . . 6 73 3.1 Version Number Authentication . . . . . . . . . . . . . . . 8 74 3.2 Rank Authentication . . . . . . . . . . . . . . . . . . . 10 75 3.3 Format of the Authentication Option . . . . . . . . . . . 14 76 3.4 The Security Scheme . . . . . . . . . . . . . . . . . . . 17 77 4 Security Considerations . . . . . . . . . . . . . . . . . . . 18 78 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 5.1 RPL Control Message Option . . . . . . . . . . . . . . . 18 80 5.2 New Registry for the Code Value Type . . . . . . . . . . 19 81 5.3 New Registry for the Algorithm Type . . . . . . . . . . . 20 82 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 83 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 7.1 Normative References . . . . . . . . . . . . . . . . . . 21 85 7.2 Informative References . . . . . . . . . . . . . . . . . 21 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 88 1 Terminology 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 This document adopts and conforms to the terminology defined in 94 [I-D.ietf-roll-terminology] and in [RFC4949]. 96 As they form networks, LLN devices often mix the roles of 'host' and 97 'router' when compared to traditional IP networks. In this document, 98 'host' refers to an LLN device that can generate but does not forward 99 RPL [I-D.ietf-roll-rpl] traffic, 'router' refers to an LLN device 100 that can forward as well as generate RPL traffic, and 'node' refers 101 to any RPL device, either a host or a router. This document 102 introduces the following terminology: 104 Compromised: Taking control over a node. 106 h(): Cryptographic one-way hash function [PseuFun]. 108 r: Random number. 110 V: Version Number hash chain. 112 i: Index of the Version Number hash chain. 114 V_0: Root of the Version Number hash chain. 116 V_i: The ith Version Number hash chain element. 118 n+1: Version Number hash chain length. 120 x_i: Random number. 122 R: Rank hash chain. 124 j: Index of the Rank hash chain. 126 l+1: Rank hash chain length. 128 R_(i,j): The jth Rank hash value associated with the ith Version 129 Number hash chain element. 131 R_mrh=R_(i,l): Max Rank hash value associated with the ith Version 132 Number hash chain element. 134 R_sender: Rank element value. 136 Rank_root: Rank value of the DODAG root. 138 Rank_sender: Rank value of the parent. 140 M: Message. 142 Init_VN: Initial value of the Version Number. 144 VN: Current Version Number value. 146 IP: Integrity Protection value. 148 MAC: Message authentication code. 150 MHRI: MinHopRankIncrease [I-D.ietf-roll-rpl]. 152 OF: Objective Function [I-D.ietf-roll-rpl]. 154 2 Introduction 156 Low power and Lossy Networks (LLNs) consist largely of constrained 157 nodes with limited processing power, memory, and sometimes energy, 158 when they are battery operated. These nodes are interconnected by 159 unstable lossy links, typically supporting only low packet and data 160 delivery rates. Another characteristic of such networks is that 161 point-to-point is not the typical traffic pattern, but point-to- 162 multipoint and multipoint-to-point are. Furthermore, such networks 163 may potentially comprise up to thousands of nodes. 165 These characteristics offer unique challenges to a routing solution. 166 The IETF ROLL Working Group has defined application-specific routing 167 requirements for a Low power and Lossy Network (LLN) routing 168 protocol, specified in [RFC5867], [RFC5826], [RFC5673], and 169 [RFC5548]. Moreover, based on those standards, an IPv6 Routing 170 Protocol for Low power and Lossy Networks (RPL) has been proposed 171 [I-D.ietf-roll-rpl] and a security framework for RPL is described in 172 [I-D-roll-security-framework]. 174 Many LLN systems are deployed in unattended or remote locations, such 175 as urban environments [RFC5548]. Hence, security mechanisms that 176 provide confidentiality and authentication are critical for the 177 operation of many applications. The security services that RPL 178 currently provides natively are sufficient to protect the network 179 against such an attack if only an external attacker is assumed. 180 However, native RPL security services will not protect against a 181 compromised internal node. Therefore, this document considers the 182 case where the attacker is a compromised node, where the source of 183 the compromise can be logical [FC_Code] or physical [Tamper] and the 184 attacker can intercept, forge, modify, inject, replay, and create 185 messages (data or control) in order to interfere with the operation 186 of entire network and exhaust nodes' batteries. 188 An internal adversary can attack RPL in many different ways. 189 However, some of these attacks have only a minor influence, while 190 others may have a major influence in the network. A consequence of 191 an attack that will lead to reconstructing the entire DAG and exhaust 192 the nodes' batteries, or eavesdropping a large part of the network 193 traffic can have major or even critical influence. One way for an 194 internal adversary to achieve these goals is to change/modify the 195 Version Number of the DODAG [I-D.ietf-roll-rpl], a sequential counter 196 that is incremented by the DODAG root to form a new Version of a 197 DODAG, or to change/modify the DODAG node Rank value 198 [I-D.ietf-roll-rpl], representation of the location of that node 199 within a DODAG. Therefore, this document presents a security scheme 200 to prevent the following attacks: 202 (i) An internal attacker impersonating a DODAG root and 203 illegitimately increasing the Version Number. 205 (ii) An internal attacker publishing an illegitimately decreased 206 Rank value. 208 Implementation of the security service described in this document is 209 OPTIONAL. It is RECOMMENDED that implementers carefully consider 210 security requirements and the availability of security mechanisms in 211 their network. The hash functions, MAC functions, and digital 212 signature algorithms used in the protocols are based on sections 10.1 213 and 10.9.2 of [I-D.ietf-roll-rpl], e. g., SHA-256 hash function 214 specified in Section 6.2 of [FIPS180], message encoding rules of 215 Section 8.1 of [RFC3447]. The elliptic curve cryptography (ECC) is 216 based on section 2.7 of [SECG2]. The Hashed Message Authentication 217 Mode (HMAC) is described in [RFC4868]. 219 3 VeRA - Version Number and Rank Authentication 221 A grounded DODAG offers connectivity to hosts that are required to 222 satisfy the application-defined goal. An attacker may try to become 223 a grounded DODAG root by sending a well-constructed DIO message. The 224 scope of the current RPL security services is the link; therefore, in 225 RPL the authenticity of the messages sent by the DODAG root relies on 226 the trustworthiness of all intermediate DODAG nodes and the fact that 227 none of the keys are compromised. However, because of to the lack of 228 physical protection, DODAG nodes can be compromised (including their 229 keys). This allows an attacker to send an authentic DIO message that 230 will be accepted by all the DODAG nodes. Therefore, a node that 231 receives a DIO message from the attacker will multicast it to its 232 neighbors using uncompromised keys. The content of the message from 233 the attacker will affect other nodes participating in the DODAG. 235 Version number is an element of each DIO message and related to the 236 network. The Version Number is monotonically incremented by the root 237 each time the DODAG root decides to form a new Version of the DODAG 238 in order to revalidate the integrity and allow global repairs to 239 occur. The Version Number is propagated unchanged Down the DODAG as 240 routers join the new DODAG. The Version Number value is globally 241 significant in a DODAG and indicates the Version of the DODAG that a 242 router is operating in. An older (lesser) value indicates that the 243 originating router has not migrated to the new DODAG and cannot be 244 used as a parent once the receiving node has migrated to the newer 245 DODAG [I-D.ietf-roll-rpl]. RPL allows the Version Number to be 246 increased regularly or occasionally. Moreover, reconstruction of the 247 routing topology can be initiated by sending a DIO message with an 248 increased Version Number. 250 Therefore, preventing any misbehaving DODAG node from impersonating 251 the actual DODAG root and increasing the Version Number is essential. 252 Note that how often the Version Number is increased is out of scope 253 of this draft (application dependent). 255 The Rank is a value that helps the nodes to determine at what level 256 they are in the directed acyclic graph. The lower the Rank is, the 257 closer (in a sense of the hop numbers) the node is to the DODAG root. 258 Each node must set the Rank such that the Rank of all the selected 259 DODAG parents are lower. The siblings of a node are those 260 neighboring nodes whose Rank value is equal to the Rank value of the 261 node. MinHopRankIncrease (MHRI) is the minimum increase in Rank 262 value between a node and any of its DODAG parents. RPL allows the 263 nodes to increase their Rank in order to become distant from the 264 DODAG root. This can be beneficial for the node, because the node 265 has to forward fewer messages, the closer a node is placed to the 266 DODAG root the more messages it has to forward. In that case the 267 DODAG parents and the siblings of the node may change, and also the 268 nodes that set this node as a parent have to change the relation, 269 otherwise a loop may be formed. RPL has some mechanisms to detect 270 loops that may arise because of other reasons than described above. 271 If the network detects a loop that can be difficult to repair, it may 272 reconstruct the whole graph. The reconstruction, global repair, can 273 be initiated by the DODAG root by sending DIO messages with an 274 increased Version Number. 276 By publishing a high Rank value, an attacker can move deeper in the 277 DODAG in order to increase the size of the parent set or improve some 278 other metric. However, the most effective Rank attack is by 279 decreasing the Rank. By publishing a low Rank value, a large part of 280 the DODAG will connect to the DODAG root via the attacker, and give 281 it the ability to eavesdrop and manipulate a large part of the 282 network traffic. 284 3.1 Version Number Authentication 286 By authenticating the Version Number, each DODAG node can securely 287 forward the DIO message in order to bootstrap or update the DODAG 288 Version. 290 Upon initialization, a DODAG root generates a random number r and 291 calculates a hash chain [L1981], named as Version Number hash chain, 292 of size n+1: V_n, V_(n-1)..., V_1, V_0 where V_n=h(r), 293 V_i=h(V_(i+1)), with the random number r, where h() is a 294 cryptographic hash function. 296 Then the DODAG root reveals the root of the Version Number hash chain 297 V_0 and using any supported integrity protection algorithm (e. g., 298 digital signature or MAC) the DODAG root binds the root value to a 299 particular DODAG, {V_0}_sign/mac. Finally, the DODAG root 300 multicasts the DIO message (M#1, in Figure 1) with V_0, the initial 301 value Init_VN of the Version Number and the integrity protection 302 data; the DODAG root can resend the signed DIO message until the 303 first Version Number update occurs. 305 Upon receiving the signed DIO message, each intermediate DODAG node 306 verifies the authentication data and in case of success saves the 307 integrity protection data, the root V_0 of the Version Number hash 308 chain, and the initial value Init_VN of the Version Number. When the 309 trickle timer [RFC6206] expires, it multicasts to all neighbors the 310 DIO message (M#2) according to [I-D.ietf-roll-rpl]. If the message 311 is not authentic, the intermediate DODAG node MUST ignore the 312 message. 314 Upon Version Number update, the DODAG root reveal the next Version 315 Number hash chain element V_i and sends a DIO message (M#3) with a 316 new Version Number VN and V_i. Upon receiving a DIO message with a 317 new Version Number, an intermediate DODAG node can easily verify the 318 message because, if the Version Number is increased by the DODAG 319 root, h^{i}(V_i) must be equal to V_0. Upon success, the intermediate 320 DODAG node saves the current Version Number value. When the trickle 321 timer [RFC6206] expires, it multicasts to all neighbors the DIO 322 message (M#4) after updating according to section 6.3.1. of 323 [I-D.ietf-roll-rpl]. 325 If an attacker wants to increase the Version Number, then it has to 326 compute a pre-image of the last revealed hash chain element of the 327 Version Number hash chain. However, computing the next element 328 V_(i+1) knowing V_i is hard when r is not known and h() is a 329 cryptographic one-way hash function. 331 In the case when a new node wants to join the DODAG, any DODAG node 332 receiving a unicast DIS message (M#5) from the new node (Non DODAG 333 node), MUST reply with a DIO message (M#6) containing the current 334 Version Number value VN, the initial Version Number value Init_VN, 335 the root of the Version Number hash chain V_0, the current Version 336 Number hash chain element V_i, and the integrity protection data IP. 337 Note that all these data is stored by every DODAG node in the network 338 following our scheme. 340 It is RECOMMENDED to use the integrity protection mechanism. When a 341 digital signature is used, each node has to know the public signature 342 verification key. For a normal node it is very costly to digitally 343 sign and verify; therefore it is RECOMMENDED to use the sign 344 procedure only for bootstrapping or in case the DODAG root revealed 345 all the hash chain elements of the current hash chain and need to 346 generate a new hash chain. The first DIO message which contains the 347 new hash chain root, MUST be signed. Moreover, it is OPTIONAL to 348 resend the first DIO message with the hash chain root and the 349 signature till the first Version Number update. In order to minimize 350 the computation time and memory usage of the hash chain, the 351 implementer can use the technique in [OptHash] on the DODAG root 352 side. In case the implementer decides to authenticate the hash chain 353 root using MAC function, the Version Number hash chain root needs to 354 be transported reliably. 356 The sequence diagram of the Version Number Authentication algorithm 357 has three parts: authentication procedure, Version Number update, and 358 admission of a new node in the DODAG. 360 Root Node v Node u New Node 362 | VN=Init_VN, V_0, IP| | | 363 |---------------->M#1| | | 364 | |VN=Init_VN,V_0,IP| | 365 | |----------->M#2 | | 366 | | | | 367 : : : : 368 | | | | 369 | VN=Init_VN+i, V_i | | | 370 |---------------->M#3|VN=Init_VN+i, V_i| | 371 | |----------->M#4 | | 372 | | | | 373 : : : : 374 | | | | 375 | | | Unicast DIS | 376 | | |M#5<-------------------| 377 | | | | 378 | | | VN,Init_VN,V_0,V_i,IP | 379 | | |------------------->M#6| 380 | | | | 382 Figure 1: Sequence Diagram of Version Number Authentication Algorithm 384 3.2 Rank Authentication 386 By authenticating the Rank value, each DODAG node can conclude that 387 its Rank value is greater than its parent Rank value and from the 388 DODAG root towards the current DODAG node, the Rank values are 389 monotonically increasing. 391 Upon initialization, a DODAG root generates a random number r and 392 calculates a hash chain[L1981], named as Version Number hash chain, 393 of size n+1: V_n, V_(n-1)..., V_1, V_0 where V_n=h(r), 394 V_i=h(V_(i+1)), with the random number r. For each element V_i of 395 the Version Number hash chain the DODAG root generates a new random 396 number x_i and calculates a new hash chain, named as Rank hash chain, 397 of size l+1: R_(i,0), R_(i,1)..., R_(i,l-1), R_(i,l) where R_(i,0)= 398 h(x_i), R_(i,j)=h(R_(i,j-1)), with the new random number x_i. In 399 theory, l should be 65535 to have a different value for each possible 400 Rank value (Rank is 16 bits long [I-D.ietf-roll-rpl]). In practice, 401 256 is large enough as for most of the operations DAGRank 402 [I-D.ietf-roll-rpl] is used (the DAG Rank of a node is the upper 8 403 bits of the Rank), which is 8 bits long. If DAGRank is used when 404 defining the hash chain, then all occurrences of Rank must be 405 substituted by DAGRank in the sequel. Figure 2 illustrates the hash 406 chains'. Note that, in order to decrease the size of Rank hash 407 chain, in any case we are using the Rank value as the indicator to 408 the number of times to hash (h^{}()) we divided the Rank value by 409 MinHopRankIncrease (Rank/MinHopRankIncrease). 411 Then the DODAG root reveals the root of the Version Number hash chain 412 V_0, computes MAC_{V_1}(R_(mrh)) a message authentication code (MAC) 413 value computed over the Max Rank hash (mrh) value R_(mrh)=R_(1,l) of 414 the next Rank Hash chain with the next Version Number hash chain 415 element V_1 as the key. Finally, the DODAG root multicast a DIO 416 message with V_0, MAC_{V_1}(R_(mrh)); the DODAG root can resend the 417 DIO message till the DODAG needs to update its Rank value or update 418 the Version Number. 420 Upon receiving the DIO message, each intermediate DODAG node saves 421 the root V_0 of the Version Number hash chain, and the MAC value 422 MAC_{V_1}(R_(mrh)). When the trickle timer [RFC6206] expires, it 423 multicasts to all neighbors the DIO message according to 425 [I-D.ietf-roll-rpl]. Figure 3 illustrates the initialization of the 426 Rank Authentication algorithm. 428 Upon Version Number update, the DODAG root sends a DIO message with 429 the following parameters: next Version Number value VN as described 430 in [I-D.ietf-roll-rpl], next Version Number hash chain element V_i, a 431 message authentication code (MAC) value MAC_{V_(i+1)}(R_(mrh)) 432 computed over the Max Rank hash value R_mrh=R_(i+1,l) with the next 433 Version Number hash chain element V_(i+1) as the key, and a Rank 434 element value R_sender=h^{Rank_root}(x_i), where Rank_root is the new 435 Rank value of the DODAG root. 437 Upon receiving a DIO message with a new Version Number or new Rank 438 value, an intermediate DODAG node use the revealed key V_i, the MAC 439 value from the previous update MAC_{V_(i)}(R_(mrh)) and the Rank 440 element R_sender, to verify whether the Rank value of its parent is 441 monotonically increasing as follows: 443 o It generates R_check= h^{l-Rank_sender}(R_sender), where 444 Rank_sender is the Rank value of the parent. 446 o It checks if MAC_{V_(i)}(R_mrh), from the previous update, 447 is equal to MAC_{V_(i)}(R_check). 449 o If so, intermediate DODAG node v can conclude that the Rank 450 is monotonically increasing and: 452 o It calculates its Rank value regarding its Objective 453 Function, Rank_v. 455 o It calculates delta= Rank_v - Rank_(sender), the 456 difference between the DODAG node Rank value and its parent 457 Rank value. Node v has the parent Rank from the DIO message. 459 o It calculates R_sender= h^{delta}(R_sender). 461 o When the trickle timer [RFC6206] expires, it multicasts 462 to all neighbors the DIO message according to 463 [I-D.ietf-roll-rpl] with the new R_sender value. 465 If an attacker wants to decrease the Rank [I-D.ietf-roll-rpl], then 466 it has to compute a pre-image of the last R_sender. However, 467 computing the previous R_(i-1) knowing R_(i) is hard when x_i is not 468 known and h() is a cryptographic one-way hash function. Figure 4 469 illustrates the Rank update algorithm. 471 In the case when a new node wants to join the DODAG, any node 472 receiving a unicast DIS message from the new node MUST reply with a 473 DIO message containing the last MAC value. 475 Version Number Hash Chain, V_i=h(V_(i+1)) 476 h h h h h 477 r=random V_n=h(r)->V_(n-1)-->...V_i-->....->V_2-->V_1-->V_0 479 | 480 V 482 x_i=random 484 R_(i,0)=h(x_i) 485 | 486 h | 487 v 488 R_(i,1) 489 | 490 h | 491 v 492 R_(i,2) 494 . 495 . 496 h . 497 v 498 R_(i,l-1) 499 | 500 h | 501 v 502 R_(i,l), Max Rank hash value 504 Rank Hash Chain, R_(i,j) = h(R_(i,j-1)) 506 Figure 2: The Hash Chains. 508 DODAG root DODAG node v 510 Generate Random Number r Get 511 | DIO: V_o, MAC_{V_1}(R_mrh) 512 | signature 513 v | 514 Calculate hash chain v 515 h(h(...h(r)))),V_0 Verify ? -- No-> Delete 516 | | 517 | | 518 | Yes 519 | | 520 | v 521 | Save V_o, MAC_{V_1}(R_mrh), signature 522 | | 523 v | 524 For each V_i generate v 525 random number x_i Send 526 | DIO: V_o, MAC_{V_1}(R_mrh), signature 527 | 528 v 529 For each V_i calculate hash chain 530 h(h(...h(x_i)))),R_mrh 531 | 532 | 533 v 534 Rank= OF(root) 535 | 536 | 537 v 538 Signature = Sign (V_0, MAC_{V_1}(R_mrh)) 539 | 540 | 541 v 542 Send 543 DIO: V_o, MAC_{V_1}(R_mrh) 544 signature 546 Figure 3: Rank Authentication Algorithm - Initialization 548 DODAG root DODAG node v 550 Version Number Update Get 551 | DIO:V_i, MAC_{V_(i+1)}(R_mrh), R_sender 552 | | 553 v v 554 Rank= OF(root) R_check=h^{l-Rank_parent}(R_sender) 555 | | 556 | | 557 v v 559 R_sender=h^{Rank}(x_i) Calculate 560 | MAC_check=MAC_{V_i}(R_mrh) 561 | | 562 | | 563 v v 564 R_mrh= h(h(...h(x_(i+1))))) MAC_check == MAC_i 565 | | 566 | | 567 | v 568 v Rank Monotonically increase 569 Send Rank=OF(v) 570 DIO: V_i, MAC_{V_(i+1)}(R_mrh), R_sender | 571 | 572 v 573 delta= Rank_v - Rank_Parent 574 | 575 | 576 v 577 R_sender=h^{delta}(R_sender) 578 | 579 | 580 v 581 Send 582 DIO: V_i, MAC_{V_(i+1)}(R_mrh), R_sender 584 Figure 4: Rank Authentication Algorithm - Update 586 3.3 Format of the Authentication Option 588 In order to authenticate the Version Number or/and the Rank, a DIO 589 MUST carry one "Authentication" option. An Authentication option 590 consists of the following fields: 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type=10 | Option Length |Code | Flags | Algorithm | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | | 598 + + 599 | | 600 : Authentication Data : 601 | | 602 + + 603 | | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Figure 5: Format of the Authentication Option 607 Option Type: 0x0A (to be confirmed by IANA) 609 Option Length: 8-bit unsigned integer, variable length of the option 610 in octets excluding the Type and Length fields. 612 Code: 3-bit unsigned integer, identifies the type of Authentication 613 option. This document defines codes for the following 614 Authentication types (all codes are to be confirmed by IANA 615 Section): 617 +-----+-------------------------------+ 618 |Value| Code Value Type | 619 +-----+-------------------------------+ 620 | 0 |Version Number Hash Chain Value| 621 | | | 622 | 1 |Version Number Hash Chain Root | 623 | | | 624 | 2 |Rank Hash Chain Value | 625 | | | 626 | 3 |MAC of Max Rank Hash Value | 627 | | | 628 | 4 |Integrity Protection Value | 629 | | | 630 | else|Unassigned | 631 | | | 632 +-----+-------------------------------+ 633 Figure 6: Code Type 635 Flags: 5-bit unused field. The field MUST be initialized to zero by 636 the sender and MUST be ignored by the receiver. 638 Algorithm: 8-bit field, indicating which algorithm is being used. 639 The type of the algorithm is set by the Code field: 641 o Code Field = 0: Hash Function. 643 o Code Field = 1: Hash Function. 645 o Code Field = 2: Hash Function. 647 +----------+--------------------------+ 648 |Bit Number| Hash Function | 649 +----------+--------------------------+ 650 | 0 | SHA-256 | 651 | | | 652 | 1 | SHA-512 | 653 | | | 654 | else | Unassigned | 655 +----------+--------------------------+ 657 Figure 7: Hash Function 659 fi 660 o Code Field = 3: MAC Function. 662 +----------+--------------------------+ 663 |Bit Number| MAC Function | 664 +----------+--------------------------+ 665 | 0 | HMAC-SHA-256 | 666 | | | 667 | 1 | HMAC-SHA-512 | 668 | | | 669 | else | Unassigned | 670 +----------+--------------------------+ 672 Figure 8: MAC Function 674 o Code Field = 4: Integrity Protection algorithm (Digital 675 Signature/MAC). 677 +----------+--------------------------+ 678 |Bit Number| Integrity Protection | 679 +----------+--------------------------+ 680 | 0 | HMAC-SHA-256 | 681 | | | 682 | 1 | HMAC-SHA-512 | 683 | | | 684 | 2 | RSA with SHA-256 | 685 | | | 686 | 3 |ECC-SECP256K1 with SHA-256| 687 | | | 688 | else | Unassigned | 689 +----------+--------------------------+ 691 Figure 9: Integrity Protection 693 Authentication Data: Contains the authentication data compatible 694 with the Code and Function Type fields. 696 Unassigned bits of the Authentication option are reserved. They MUST 697 be set to zero on transmission and MUST be ignored on reception. 699 3.4 The Security Scheme 701 Using the two algorithms described above in one Security Scheme 702 prevents an internal attacker from impersonating a DODAG root, 703 illegitimately increasing the Version Number and compromise an 704 illegitimately decreased Rank value. The following tables describe 705 which Authentication option types to use in each step of the 706 algorithms to prevent both Version Number and Rank attacks: 708 VNHA: Version Number Hash Chain Value. 710 VNR: Version Number Hash Chain Root. 712 RHV: Rank Hash Chain Value. 714 MRHM: MAC of Max Rank Hash Value. 716 +------+-------+---------+ 717 | Init | Update| New Node| 718 -----+------+-------+---------+ 719 |VNHV| - | + | + | 720 -----+------+-------+---------+ 721 |VNR | + | - | + | 722 -----+------+-------+---------+ 723 |RHV | - | - | - | 724 -----+------+-------+---------+ 725 |MRHM| - | - | - | 726 -----+------+-------+---------+ 727 |IP | + | - | + | 728 -----+------+-------+---------+ 729 Figure 10: Version Number Authentication 731 +------+-------+---------+ 732 | Init | Update| New Node| 733 -----+------+-------+---------+ 734 |VNHV| - | - | - | 735 -----+------+-------+---------+ 736 |VNR | - | - | - | 737 -----+------+-------+---------+ 738 |RHV | - | + | + | 739 -----+------+-------+---------+ 740 |MRHM| + | + | + | 741 -----+------+-------+---------+ 742 |IP | - | - | - | 743 -----+------+-------+---------+ 744 Figure 11: Rank Authentication 745 +------+-------+---------+ 746 | Init | Update| New Node| 747 -----+------+-------+---------+ 748 |VNHV| - | + | + | 749 -----+------+-------+---------+ 750 |VNR | + | - | + | 751 -----+------+-------+---------+ 752 |RHV | - | + | + | 753 -----+------+-------+---------+ 754 |MRHM| + | + | + | 755 -----+------+-------+---------+ 756 |IP | + | - | + | 757 -----+------+-------+---------+ 758 Figure 12: Version Number and Rank Authentication 760 4 Security Considerations 762 The security mechanism in this draft extend the RPL security 763 mechanisms, sections 6.1 and 10 of [I-D.ietf-roll-rpl]. Therefore, 764 the security consideration described in section 18 of 765 [I-D.ietf-roll-rpl] exists in this document. The scope of the 766 current RPL security services is the link; the authenticity of the 767 messages sent by the DODAG root relies on the trustworthiness of all 768 intermediate nodes and the fact that none of the keys are 769 compromised. The herein proposed Authentication scheme extends the 770 data integrity and data origin authentication [RFC3552] to network 771 level by authenticating Version Number and the Rank. Note that when 772 using the Version Number authentication, only the root can increase 773 the Version Number, so it can control exhaustion of the chain. 775 This draft prevents two powerful attacks: a) An internal attacker 776 impersonating a DODAG root and updating the Version Number; and b) 777 An internal attacker publishing decreased Rank in order to be on the 778 path to the DODAG root for the majority of the nodes and by that to 779 be able to eavesdrop a large part of network traffic. 781 5 IANA Considerations 783 5.1 RPL Control Message Option 785 IANA is requested to create a registry for the RPL Control Message 786 Options. 788 New values may be allocated only by an IETF Review. Each value 789 should be tracked with the following qualities: 791 o Value 792 o Capability description 794 o Defining RFC 796 The following bits are currently defined: 798 +----------+------------------------+---------------+ 799 | Value | Description | Reference | 800 +----------+------------------------+---------------+ 801 | 0x0A | Authentication | This document | 802 +----------+------------------------+---------------+ 803 RPL Control Message Option 805 5.2 New Registry for the Code Value Type 807 IANA is requested to create a registry for the Code Value Type Field, 808 which is contained in the Authentication option. 810 New values may be allocated only by an IETF Review. Each value 811 should be tracked with the following qualities: 813 o Value 815 o Code Value Type 817 o Defining RFC 819 The following bits are currently defined: 821 +-----+-------------------------------+---------------+ 822 |Value| Code Value Type | Reference | 823 +-----+-------------------------------+---------------+ 824 | 0 |Version Number Hash Chain Value| This document | 825 | | | | 826 | 1 |Version Number Hash Chain Root | This document | 827 | | | | 828 | 2 |Rank Hash Chain Value | This document | 829 | | | | 830 | 3 |MAC of Max Rank Hash Value | This document | 831 | | | | 832 | 4 |Integrity Protection Value | This document | 833 | | | | 834 | else|Unassigned | This document | 835 | | | | 836 +-----+-------------------------------+---------------+ 838 Code Field in Authentication Option 840 5.3 New Registry for the Algorithm Type 842 IANA is requested to create one registry for the Algorithm Field per 843 allocated Code value 845 New values may be allocated only by an IETF Review. Each value 846 should be tracked with the following qualities: 848 o Code Value 850 o Algorithm Value 852 o Capability description 854 o Defining RFC 856 The following bits are currently defined: 858 +------+-----+--------------------------+--------------+ 859 | Code |Algo | Description | Reference | 860 +------+-----+--------------------------+--------------+ 861 | 0 | 0 |SHA-256 | This document| 862 | | | | | 863 | 0 | 1 |SHA-512 | This document| 864 | | | | | 865 | 1 | 0 |SHA-256 | This document| 866 | | | | | 867 | 1 | 1 |SHA-512 | This document| 868 | | | | | 869 | 2 | 0 |SHA-256 | This document| 870 | | | | | 871 | 2 | 1 |SHA-512 | This document| 872 | | | | | 873 | 3 | 0 |HMAC-SHA-256 | This document| 874 | | | | | 875 | 3 | 1 |HMAC-SHA-512 | This document| 876 | | | | | 877 | 4 | 0 |HMAC-SHA-256 | This document| 878 | | | | | 879 | 4 | 1 |HMAC-SHA-512 | This document| 880 | | | | | 881 | 4 | 2 |RSA with SHA-256 | This document| 882 | | | | | 883 | 4 | 3 |ECC-SECP256K1 with SHA-256| This document| 884 | | | | | 885 |else |else |Unassigned | This document| 886 +------+-----+--------------------------+--------------+ 887 Security Algorithm Field in Authentication Option 889 6 Acknowledgements 891 The work described in this paper is based on results of the WSAN4CIP 892 project, which receives research funding from the European 893 Community's 7th Framework Programme. Apart from this, the European 894 Commission has no responsibility for the content of this document. 895 Amit Dvir has also been supported by the Marie Curie Mobility Grant, 896 OTKA-HUMAN-MB08-B 81654 and Levente Buttyan has been supported by the 897 Hungarian Academy of Sciences through the Bolyai Janos Research 898 Fellowship. The authors would also like to acknowledge the review 899 and comments from Yoav Ben Yehezkel. 901 7 References 903 7.1 Normative References 905 [I-D.ietf-roll-rpl] 906 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, 907 J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 908 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 909 Lossy Networks", draft-ietf-roll-rpl-19 (work in 910 progress), Sept 2011. 912 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 913 "The Trickle Algorithm", RFC 6206, March 2011. 915 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, March 1997. 918 [RFC3552] Rescorla E., and B. Korver, "Guidelines for Writing RFC 919 Text on Security Considerations", BCP 72, RFC 3552, March 920 2003. 922 [RFC3447] Jonsson, J., and B. Kaliski, "Public-Key Cryptography 923 Standards (PKCS) #1: RSA Cryptography Specifications 924 Version 2.1", RFC 3447, February 2003. 926 7.2 Informative References 928 [I-D.ietf-roll-terminology] 929 Vasseur, J., "Terminology in Low power And Lossy 930 Networks", draft-ietf-roll-terminology-06 (work 931 in progress), March 2012. 933 [I-D-roll-security-framework] 934 Tsao T., Alexander R., Dohler M., Daza V., and A. Lozano, 935 "A Security Framework for Routing over Low Power and 936 Lossy Networks", |%draft-ietf-roll-security-framework-06, 937 (work in progress) December 2011. 939 [draft-ietf-roll-minrank-hysteresis] 940 Gnawali, O., and P. Levis, "The Minimum Rank Objective 941 Function with Hysteresis", draft-ietf-roll-minrank 942 -hysteresis-of-04 (work in progress), Nov 2011. 944 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 945 Routing Requirements in Low-Power and Lossy Networks", RFC 946 5826, April 2010. 948 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 949 "Building Automation Routing Requirements in Low-Power and 950 Lossy Networks", RFC 5867, June 2010. 952 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 953 "Routing Requirements for Urban Low-Power and Lossy 954 Networks", RFC 5548, May 2009. 956 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 957 "Industrial Routing Requirements in Low-Power and Lossy 958 Networks", RFC 5673, October 2009. 960 [RFC4949] R. Shirey, "Internet Security Glossary", RFC 4949, FYI 36, 961 August 2007. 963 [RFC4868] Kelly, S., and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 964 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 966 [FC_Code] Francillon, A., C. Castelluccia, "Code injection attacks 967 on harvard-architecture devices", ACM conference on 968 Computer and communications security, pp. 15-25, 2008, 969 Virginia, USA. 971 [PseuFun] Goldreich, O., Goldwasser, S., and S. Micali, "How to 972 Construct Random Functions", Journal of the ACM, Volume 973 33, Number. 4, 1986, pp 210-217. 975 [Tamper] Anderson, R., and M. Kuhn, "Tamper Resistance - a 976 Cautionary Note", USENIX Workshop on Electronic Commerce 977 Proceedings, pp 1-11, 1996, Oakland, California. 979 [L1981] Lamport L., "Password Authentication with Insecure 980 Communication", ACM Journal of Communications Volume 24 981 Issue 11, pp 770-772, Nov. 1981. 983 [SECG2] D. R. L. Brown, "Standards for Efficient Cryptography 984 Group (SECG), "SEC 2: Recommended Elliptic Curve Domain 985 Parameters version 2.0", Version 2.0, January 2010. 987 [OptHash] Don, C., and M. Jakobsson, "Almost Optimal Hash Sequence 988 Traversal", Fourth Conference on Financial Cryptography, 989 2002. 991 [FIPS180] National Institute of Standards and Technology, "FIPS Pub 992 180-3, Secure Hash Standard (SHS)", US Department of 993 Commerce , February 2008, 994 . 996 Authors' Addresses 998 Amit Dvir 999 Laboratory of Cryptography and Systems Security (CrySyS) 1000 Budapest University of Technology and Economics 1001 BME-HIT, PO Box 91, 1521 Budapest 1002 Hungary 1004 EMail: azdvir@gmail.com 1006 Tamas Holczer 1007 Laboratory of Cryptography and Systems Security (CrySyS) 1008 Budapest University of Technology and Economics 1009 BME-HIT, PO Box 91, 1521 Budapest 1010 Hungary 1012 EMail: tamas.holczer@crysys.hu 1014 Laszlo Dora 1015 Laboratory of Cryptography and Systems Security (CrySyS) 1016 Budapest University of Technology and Economics 1017 BME-HIT, PO Box 91, 1521 Budapest 1018 Hungary 1020 EMail: laszlo.dora@crysys.hu 1022 Levente Buttyan 1023 Laboratory of Cryptography and Systems Security (CrySyS) 1024 Budapest University of Technology and Economics 1025 BME-HIT, PO Box 91, 1521 Budapest 1026 Hungary 1027 EMail: buttyan@crysys.hu