idnits 2.17.1 draft-qiu-roll-kemp-02.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 104: '...network dynamics SHOULD NOT impact the...' RFC 2119 keyword, line 106: '...ecurity approach SHOULD be sufficientl...' RFC 2119 keyword, line 107: '... a U-LLN; the U-LLN MUST deny any node...' RFC 2119 keyword, line 116: '...26 needed a node MUST authenticate its...' RFC 2119 keyword, line 119: '...ociated with the LLN MUST deny, to the...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2012) is 4166 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 660, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 665, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 4919 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 5548 (ref. '6') ** Downref: Normative reference to an Informational RFC: RFC 5673 (ref. '7') ** Downref: Normative reference to an Informational RFC: RFC 5826 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 5867 (ref. '9') -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL Working Group Y. Qiu 3 Internet-Draft J. Zhou 4 Expires: April 25, 2013 F. Bao 5 Institute for Infocomm Research 6 October 22, 2012 8 Lightweight Key Establishment and Management Protocol in Dynamic Sensor 9 Networks (KEMP) 10 draft-qiu-roll-kemp-02 12 Abstract 14 When a sensor node roams within a very large and distributed wireless 15 sensor network, which consists of numerous sensor nodes, its routing 16 path and neighborhood keep changing. In order to provide a high 17 level of security in this environment, the moving sensor node needs 18 to be authenticated to new neighboring nodes as well as to establish 19 a key for secure communication. The document proposes an efficient 20 and scalable protocol to establish and update the secure key in a 21 dynamic wireless sensor network environment. The protocol guarantees 22 that two sensor nodes share at least one key with probability 1 23 (100%) with less memory and energy cost, while not causing 24 considerable communication overhead. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 25, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Network Assumptions . . . . . . . . . . . . . . . . . . . . . 5 62 3. Shared-Key Discovery . . . . . . . . . . . . . . . . . . . . . 6 63 4. Dynamic Authentication and Key Establishment Protocol . . . . 7 64 4.1. Basic Protocol . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2. Key Management . . . . . . . . . . . . . . . . . . . . . . 8 66 4.3. Distribution Mode . . . . . . . . . . . . . . . . . . . . 10 67 4.4. Node Bootstraps . . . . . . . . . . . . . . . . . . . . . 11 68 4.5. Working with Multiple Trust Domains . . . . . . . . . . . 11 69 4.6. Packet Format in Link Layer . . . . . . . . . . . . . . . 12 70 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 71 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16 72 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 8. Normative References . . . . . . . . . . . . . . . . . . . . . 18 74 Appendix A. Version History . . . . . . . . . . . . . . . . . . . 19 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 77 1. Introduction 79 The demand of wireless sensor networks (WSNs) is growing 80 exponentially. It has turned out that the sensor networks can be 81 widely applied in the areas of healthcare, environment monitoring, 82 and the military. One of the surveys on WSNs points out that, in the 83 near future, wireless sensor networks will be an integral part of our 84 lives, more so than the present-day personal computer [1]. 86 A sensor node has low capability in terms of power, computation, 87 storage and communication. A wireless sensor network is composed of 88 a large number of wireless sensor nodes and multi-hop communication 89 is desired in WSNs. As a result, security in wireless sensor 90 networks has six challenges to overcome: (a) the wireless nature of 91 communication, (b) resource limitations of sensor nodes, (c) very 92 large and dense WSNs, (d) lack of fixed infrastructure, (e) unknown 93 network topology prior to deployment, (f) high risk of physical 94 attacks on unattended sensors [2][3]. 96 The capabilities in term of Scalability, Mobility/Dynamicity Network, 97 Latency, etc. are also listed in the RFC documents, i.e. Routing 98 Requirements for Urban Low-Power and Lossy Networks (RFC 5548)[6], 99 Routing Requirements for Urban Low-Power and Lossy Networks (RFC 100 5673)[7], Home Automation Routing Requirements in Low-Power and Lossy 101 Networks (RFC 5826)[8], and Building Automation Routing Requirements 102 in Low-Power and Lossy Networks (RFC 5867)[9]. 104 RFC 5548 required local network dynamics SHOULD NOT impact the entire 105 network to be reorganized or re-reconfigured; a viable routing 106 security approach SHOULD be sufficiently lightweight that it may be 107 implemented across all nodes in a U-LLN; the U-LLN MUST deny any node 108 that has not been authenticated to the U-LLN and authorized to 109 participate to the routing decision process. 111 RFC 5673 addressed the handover speed; a compromised field device 112 does not destroy the security of the whole network; because nodes are 113 usually expected to be capable of routing, the end-node security 114 requirements are usually a superset of the router requirements. 116 RFC 5826 needed a node MUST authenticate itself to a trusted node 117 that is already associated with the LLN before the former can take 118 part in self-configuration or self-organization. A node that has 119 already authenticated and associated with the LLN MUST deny, to the 120 maximum extent possible, the allocation of resources to any 121 unauthenticated peer. The routing protocol(s) MUST deny service to 122 any node that has not clearly established trust with the HC-LLN. 124 RFC 5867 listed the possible security keys below: a) a key obtained 125 from a trust center already operable on the LLN; b) a pre-shared 126 static key as defined by the general contractor or its designee; or 127 c) a well-known default static key. 129 With the aforementioned limitations of the existing solutions in 130 mind, we now propose a secure protocol in dynamic WSN, addressing all 131 of the following issues: 133 o A moving sensor node needs to change its attached routers (or 134 cluster heads) frequently. 136 o A router (or cluster head) needs to ensure a joining node is not a 137 malicious sensor. 139 o A moving node needs to establish a secure tunnel with the new 140 router (or cluster head). 142 o The energy consumption for establishing the secure tunnel must be 143 minimal. 145 One of the important novel features of the proposed protocol is that 146 the router or cluster head is employed as sub-base-stations to 147 execute key establishment. This way, the total dependency on the 148 base station for key establishment can be avoided. Also, this 149 approach reduces the hops between two communicating ends and hence 150 results in reduction of the communication cost. 152 2. Network Assumptions 154 In this document, we consider a scenario in which a sensor node roams 155 within a very large and distributed wireless sensor networks (WSN), 156 consisting of a large number of sensor nodes and base stations. It 157 is a typical scenario that is widely adopted in hospital environments 158 as the patients or doctors equipped with sensors roam across each 159 department in the hospital. A patient who carries the sensor nodes 160 can move freely within the range of a hospital. When a wireless 161 sensor node is moving, its routing path and neighborhood keep 162 changing. The moving node needs to be authenticated to the new 163 neighbors and to establish a key for secure communication. 165 This scenario reflects the problems described in Section 1: (a) 166 composition by a large number of sensor nodes; (b) communication 167 based on wireless multi-hop mechanism; (c) no fixed infrastructure; 168 (d) the possible location change of sensor node (patient). 169 Therefore, the challenges of this network assumption are how to 170 establish a secure channel with these routers. 172 3. Shared-Key Discovery 174 In the WSN environment, as data transmission consumes much more 175 energy than computation, the probabilistic solution is widely 176 accepted in order to reduce the storage and communication overhead 177 during key establishment. 179 So far in the literature, numerous random key pre-distribution 180 schemes have been proposed. For example, in Chan et al.'s scheme[4], 181 each sensor node stores a random set of Np dedicated pair-wise keys 182 to achieve the probability p that two nodes share a key. At the key 183 setup phase, each node ID is matched with Np other randomly selected 184 node IDs with probability p. A distinct pair-wise key is generated 185 for each ID pair, and is stored in both nodes' key-chain along with 186 the ID of the other party. During the shared-key discovery phase, 187 each node broadcasts its ID so that neighboring nodes can tell if 188 they share a common pair-wise key. Note that Chan et al.'s scheme 189 reduces the storage overhead by sacrificing key connectivity, but it 190 still provides perfect key resilience. 192 In this protocol, it is assumed that a sensor node (carried by a 193 patient) can move within a special range (e.g. hospital). As each 194 sensor's memory is severely constrained, each sensor may only store a 195 small set of keys randomly selected from a key pool at the 196 deployment. Two nodes may use any existing key discovery protocol 197 (e.g., the solution proposed in [4]) to find a common key from their 198 own sets. If the common key is not found, the key establishment 199 scheme will be initiated. The reason why binding a general pre- 200 shared key discovery phase to the protocol is to reduce the energy 201 cost as much as possible. 203 4. Dynamic Authentication and Key Establishment Protocol 205 4.1. Basic Protocol 207 Due to the limited storage of sensor nodes, the pre-shared key-pair 208 is not always available between the roaming node and its new 209 neighbors in the circumstance of a dynamic node roaming within large 210 WSNs (e.g., in hospitals and nuclear power plants). Therefore it 211 requires an efficient and scalable protocol to establish and update 212 the keys among nodes for secure communications. 214 Figure 1 shows the basic architecture and message flow of our 215 protocol for authentication and key establishment in dynamic WSNs. 216 When a dynamic sensor node moves to a new area and wants to attach to 217 a router or a cluster head in this area, it first sends a request 218 message to the base station (refer to Figure 1). 220 +--------+ 221 | Router | 222 +--------+ 223 / |\ 224 notice / \ appv 225 / \ 226 |/ \ 227 +--------+ +---------+ 228 | Sensor | req | Base | 229 | Node |---------->| Station | 230 +--------+ +---------+ 232 Figure 1. The basic architecture and message flow of KEMP protocol 234 req={Src=SN, Dst= BS, RT||R0||MAC(K_BN, SN||RT||R0)} (1) 236 where Src and Dst denote the source and destination address of a 237 message respectively. SN, BS and RT are identifiers for sensor node, 238 base station and router, respectively. R0 denotes a random number 239 generated by the sensor node. MAC indicates the message 240 authentication code algorithm with a key and K_BN is the shared 241 secret key between the base station and the sensor node. 243 After receiving the req message, the base station will check its 244 revocation list whether the sensor node has been revoked. If the 245 sensor node is acceptable, then the base station verifies the MAC 246 message. If the result is positive, the base station will generate a 247 session key K_NR for the roaming sensor node and the router (or 248 cluster head). 250 K_NR = H(K_BN, SN||R0||R1) (2) 252 where H is a keyed one-way hash function, and R1 is the random number 253 selected by the base station. The base station then sends an 254 approval message appv with the session key to the router: 256 appv = {Src=BS, Dst=RT, E(K_BR, SN||R0||R1||K_NR)} (3) 258 where E is an encryption algorithm, and K_BR is the shared secret key 259 between the base station and the router. 261 After receiving the appv message, the router decrypts the payload and 262 extracts the session key KNR, and then sends a notice to the sensor 263 node. 265 notice = {Src=RT, Dst=SN, R0||R1|| MAC(K_NR, RT||SN|| R0||R1)} (4) 267 Upon getting the notice message, the sensor node extracts the random 268 numbers R0 and R1. After checking if the received random number R0 269 is equal to the original R0, the sensor node recalculates the session 270 key K_NR = H(K_BN, SN||R0||R1) and then verifies the MAC value. If 271 the result is positive, the sensor node will use the session key for 272 the communication with this router afterwards. The R0 cannot be 273 ignored because the sensor node might send out many request messages 274 with various R0 if it cannot receive the notice message in time. 275 Hence, the sensor node must know which R0 is used in the notice 276 message. 278 In practice, the router could be any sensor node that the dynamic 279 sensor node wants to connect to. 281 4.2. Key Management 283 In order to manage the keys, every sensor node maintains a table, 284 called "Key Cache". Table 1 shows the structure of the Key Cache. 286 Table 1. The structure of Key Cache 287 +----------------------------------------------+ 288 | Key Cache in Sensor Node N | 289 +----------------------------------------------+ 290 | Correspondence Node ID | Key | Key Lifetime | 291 +----------------------------------------------+ 292 | BS | K_BN | T_BN | 293 | Node_i | K_Ni | T_Ni | 294 | ... ... | ... | ... ... | 295 | Node_j | K_Nj | T_Nj | 296 | PreSharedKey_x | K_x | T_x | 297 | ... ... | ... | ... ... | 298 | PreSharedKey_y | K_y | T_y | 299 +----------------------------------------------+ 301 When a sensor node, say node N, wants to connect to other sensor 302 node, say node R, it executes the following procedure: 304 (1) Checks first if there is an existing key pair between them. 306 (2) Otherwise, processes the subroutine of shared-key discovery to 307 find a common key between node N and node R based on those 308 "PreSharedKeys" in their key caches. 310 (3) If there is still no common key between them, the sensor node 311 allocates an entry in the key cache, and assigns Node ID as 312 nodeR, Key Stuff as the random number R0 and Key Lifetime as 0, 313 as shown in Table 2. 315 Table 2. The initial key entry. 316 +---------------------------------------------+ 317 | Correspondence Node ID | Key | Key Lifetime | 318 +---------------------------------------------+ 319 | Node_R | R0 | 0 | 320 +---------------------------------------------+ 322 (4) Then the sensor node initiates the procedure of key 323 establishment described in the above section. After receiving 324 the notice message, and recalculating the session key KNR, the 325 sensor node updates the entry's key stuff and key lifetime 326 accordingly. 328 (5) When the key lifetime is expired, the dynamic sensor node should 329 re-initiate the procedure of key establishment described in the 330 above section. 332 (6) When the sensor node leaves the range of the connected router, 333 the sensor node deletes the related entry from its cache table 334 in order to save the storage. In case there is no space for 335 adding a new entry, it may first delete the oldest key which has 336 expired or will expire soon. 338 The base station also maintains a key table (Table 3) that includes 339 the secret keys shared with all of the sensor nodes in the network. 341 Table 3. The structure of Key Table in basestation 342 +--------------------------------+ 343 | Key Table in Base Station | 344 +--------------------------------+ 345 | Node ID | Key | Key Lifetime | 346 +--------------------------------+ 347 | Node_i | K_Bi | T_Bi | 348 | ... ... | ... | ... ... | 349 | Node_j | K_Bj | T_Bj | 350 +--------------------------------+ 352 If a node is compromised and revoked, its field of key lifetime would 353 be marked as negative. 355 4.3. Distribution Mode 357 In WSNs, the more hops between two communicating ends exist, the 358 poorer the traffic performance becomes and the more energy 359 consumption is required. To overcome these problems, we introduce 360 the distribution mode. 362 The major idea of distribution mode is to deploy the cluster heads as 363 the sub-base-stations because a cluster head is more powerful than 364 normal sensor nodes. The distribution mode includes the following 365 steps: 367 (1) Each cluster head manages to establish the shared key with its 368 neighboring cluster heads after deployment. There are several 369 ways to do this. One could embed those keys in advance if the 370 topology is known at deployment, or use the basic protocol 371 described in the above sections, via the base station. (As this 372 is a one-time operation, the overheads may be acceptable.) 374 (2) Each sensor node keeps two base station identifiers (IDs): one 375 is a real base station ID; the other is a sub-base-station (the 376 cluster head) ID. Initially, the ID of sub-base-station is a 377 real base station. 379 (3) After deployment, the first round for a mobile node to establish 380 the shared key with the nearest cluster head uses the basic 381 protocol, too. 383 (4) When the mobile node moves, use the basic protocol to establish 384 the shared key with the new cluster head, via the sub-base- 385 station (old cluster head) rather than the real base station. 387 (5) After successfully establishing the keys, the sensor node 388 updates the ID of sub-base-station with the current cluster 389 head. 391 (6) For security reasons, each sensor node must reset its sub-base- 392 station ID to the real base station at a specified interval (say 393 a few hours or days, depending on the various applications) and 394 re-establish keys with its near cluster heads via the real base 395 station. If the base station does not receive any request from 396 a sensor node, it considers the sensor node has been 397 compromised. 399 The distribution mode could provide an efficient and low energy-cost 400 solution for the shared-key establishment. The basic protocol can 401 provide the stronger protection since it can immediately block and 402 revoke compromised nodes. 404 4.4. Node Bootstraps 406 The description in this paragraph is how to establish the secure 407 session between sensor node SN and its first router RT_first when the 408 node wake up in a new sensor networks. 410 (1) After bootstrapping, the sensor node SN sends its first request 411 to Base Station BS via RT_first itself (in generic, via the 412 reviopuse router RT_previous) as below: 414 req={Src=SN, Dst= BS, RT_first||R0||MAC(K_BN, SN||RT_first||R0)} (5) 416 (2) Hence, the BS will return appv message to RT_first. Upon 417 receiving the notice from RT_first, the sensor node SN could 418 establish the secure session with RT_first by normal processing 419 descibed in previous sections 4.1 and 4.2 421 4.5. Working with Multiple Trust Domains 423 This paragraph describes the operation in scenarios of Multiple Trust 424 Domains. 426 (1) If these multiple domains are managed by one base station (key 427 centre), each node address should include the prefix of the 428 domain. With the prefix, a base station / key centre could 429 distinguish each node and avoid any confliction. 431 (2) If these multiple domains have their own base station, extend 432 the node's cache table to store the pre-shared secrets between 433 the node and these base stations. 435 (3) If the sensor node cannot decide which base station is its 436 destination, let the req message carry a set of all of MACs with 437 generated by the secret between the node and the basestation, 438 respectively. 440 4.6. Packet Format in Link Layer 442 The following attributes could be found from the KEMP protocol that 443 fits the features of Link Layer : 445 (1) No handshaking between sending and receiving nodes. 447 (2) Receiving node doesn't send an acknowledgement to sending node 448 directly. The acknowledgement will be sent to the sending node 449 via the third party. 451 Therefore the protocol is suggested to deploy on the Link Layer in 452 order to reduce the communication cost and increase communication 453 speed. 455 The messages in the KEMP protocols are carried in the MAC Command 456 Frame / Key Management Protocols (KMP) described in IEEE 802.15.4 and 457 IEEE 802.15.9. 459 Table 4. 15.4 MAC and IE formats 460 +------------------------------------------------------------------+- 461 | Octets:2 | 1 | 0/2 | 0/2/8 | 0/2 | 0/2/8 | 462 +--------------+-----+------------+----------+-----------+---------+- 463 |Frame control |Seq# |Dest PAN ID |Dest addr |Src PAN ID |Src addr | 464 +------------------------------------------------------------------+- 466 --------------------------------------------------------------+ 467 1 | Variable | 2 | 468 --------------------------------------------+-----------------+ 469 Auxiliary | Information Elements | Frame check seq#| 470 Security +---------------------------------+ | 471 Header | KMP type | KMP payload fragment | | 472 --------------------------------------------------------------+ 474 A new KMP type ID for KEMP protocol is required. Currently, the KMP 475 type includes: 477 (1) 802.1X 479 (2) HIP 481 (3) IKEv2 483 (4) PANA 485 (5) SAE 487 5. Security Consideration 489 In this proposed protocol, the session key K_NR between the sensor 490 node and the router is generated by the base station and sensor node 491 respectively, and the session key is directly sent to the router from 492 the base station by an encrypted packet. Hence, the session key K_NR 493 is never disclosed during transmission. The session key K_NR is only 494 known by the related peers, i.e., the sensor node, the base station 495 and the router. 497 Referring to equation (2), the session key K_NR is generated by a 498 keyed hash function with the shared key K_BN between sensor node and 499 base station as well as two random numbers, R0 and R1, which are 500 generated by the sensor node and base station respectively. As both 501 R0 and R1 are used only one time, there are not the same session keys 502 K_NR. This property is useful to against the replication attacks. 504 Since the session key K_NR is generated by a keyed hash function with 505 the secret key K_BN between the sensor node and the base station, the 506 different sensor nodes will have different session keys. This 507 feature is useful to protect sensor node privacy. 509 Even though an eavesdropper at the edge of the sensor node can 510 monitor and capture the random numbers R0 and R1 as well as the 511 identity of the sensor node, it is still not able to regenerate the 512 session key K_NR due to lack of the secret key K_BN. Without a 513 proper session key, the routers will not forward the packets to next 514 nodes. This attribute could prevent camouflage and traffic attacks. 516 Due to the fact that no trusted connection is established between 517 sensor node and new router before the connection between them, the 518 proposed protocol employs a random number R1 issued by the base 519 station. The sensor node needs to recalculate the K_NR first based 520 on the R1 together with K_BN and R0. Then using the calculated 521 session key K_NR to verify the received session key K_NR and the 522 random number R1. If the result is positive, then the sensor node 523 will trust that the router is authorized by the base station. 525 Besides the function of informing the sensor node that the new 526 session key K_NR is ready to use in the router, the notice message 527 also plays an important role to check if the sensor node!_s address 528 is reachable. Without this reachability check, the sensor node may 529 claim that it is at any location rather than its real location. It 530 could launch redirecting attacks. 532 The path between the base station and the router is secure because 533 the packet between them is encrypted with a pre-shared key K_BR. 535 The messages from the sensor node to the base station and from the 536 router to the sensor node are authenticated by a keyed hash function. 537 Before accepting the inward message and making further processing, 538 the receivers must verify the authentication. Since the cost of a 539 hash algorithm is very small, the base station and sensor node could 540 avoid the attacks of denial of service. 542 In order to achieve high efficiency and low energy cost, the protocol 543 deploys a distribution mode which uses the cluster headers as the 544 sub-base-stations. Due to the capability of cluster header, it is 545 not able to recognize any compromised sensor nodes in time; the 546 protocol requires each sensor node to reset its sub-base-station ID 547 to the real base station regularly, and to re-establish keys with its 548 near cluster heads via the real base station. This step is also 549 useful to avoid a sensor node binding a compromised cluster head for 550 long time. 552 According to the above analysis, this proposed protocol, which is 553 simple and easy to implement, can provide relatively strong 554 protection for sensor node networks. 556 The solutions based on public keys are not suitable in sensor 557 networks. As sensor nodes are very easy to be compromised and lost, 558 the public-key revocation is a very hard work in low power and lossy 559 networks due to the 2 reasons below: 561 (1) How and how often to update the revocation list? 563 (2) How to store the revocation list in sensor node? 565 Moreover, before deploy the negoation of public keys, the new 566 attached node must be ensured it is reachable in the sensor networks. 567 Our proposal lets the previous router and basestation to endorse the 568 new attaching node. 570 6. IANA Consideration 572 Apply an new IANA number for the KEMP protocol under KMP type. 574 7. Conclusions 576 In this document, we have proposed an efficient and scalable protocol 577 to establish and update the authentication key between any pair of 578 sensor nodes in a dynamic wireless sensor network. Our protocol has 579 the following features: 581 o It is suitable for both static and dynamic WSNs. Any pair of 582 nodes can establish a key for secure communication. 584 o A roaming node only deals with its closest router for security. 585 There is no need to change the rest of routing path to the base 586 station. 588 o The base station can manage a revocation list for lost or 589 compromised roaming nodes. 591 o The system is scalable and resilient against node compromise. 593 o The protocol is efficient due to the small number and size of 594 signalling messages. 596 o The size of each signalling message is smaller than the IEEE 597 802.15.4 frame size so that it can to avoid packet fragmentation 598 and the overhead for reassembly. 600 o The distribution mode can considerably reduce the latency. 602 o Any pair of nodes can establish a key. The protocol guarantees 603 that two sensor nodes share at least one key with probability 1 604 (100%). 606 Thanks to above features, the protocol can satisfy the requirements 607 for IPv6 over Low power WPAN Routing [5] and could be the security 608 solution deployed in Routing Requirements for Urban Low-Power and 609 Lossy Networks (RFC 5548)[6], Routing Requirements for Urban Low- 610 Power and Lossy Networks (RFC 5673)[7], Home Automation Routing 611 Requirements in Low-Power and Lossy Networks (RFC 5826)[8], and 612 Building Automation Routing Requirements in Low-Power and Lossy 613 Networks (RFC 5867)[9]. 615 After comparing with some of the popular and latest protocols used in 616 WSNs, our protocol could save about 30% in communication energy, and 617 has the higher probability (100%) of sharing a key between two sensor 618 nodes with less memory cost than those pre-distribution schemes, 619 without incurring in a considerable amount of communication. 621 8. Normative References 623 [1] Akyildiz, I., Sankarasubramaniam, Y., and E. Cayirci, "Wireless 624 sensor networks: a survey", Comput. Netw 38, 393-422, 2002. 626 [2] Camtepe, S. and B. Yener,, "Key Distribution Mechanisms for 627 Wireless Sensor Networks: a Survey", Technical Report TR-05-07; 628 Department of Computer Science, Rensselaer Polytechnic 629 Institute: Troy, NY, USA , Mar. 2005. 631 [3] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over 632 Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, 633 Assumptions, Problem Statement, and Goals", RFC 4919, 634 August 2007. 636 [4] Chan, H., Perrig, A., and D. Song, "Random key predistribution 637 schemes for sensor networks", IEEE Symposium on Research in 638 Security and Privacy Oakland, California, USA, May 2003. 640 [5] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 641 Statement and Requirements for 6LoWPAN Routing", Work 642 in Progress, Aug. 2010. 644 [6] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing 645 Requirements for Urban Low-Power and Lossy Networks", RFC 5548, 646 May 2009. 648 [7] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial 649 Routing Requirements in Low-Power and Lossy Networks", 650 RFC 5673, October 2009. 652 [8] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing 653 Requirements in Low-Power and Lossy Networks", RFC 5826, 654 April 2010. 656 [9] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building 657 Automation Routing Requirements in Low-Power and Lossy 658 Networks", RFC 5867, June 2010. 660 [10] "IEEE Standard for Part 15.4: Wireless Medium Access Control 661 Layer (MAC) and Physical Layer (PHY) specifications for Low 662 Rate Wireless Personal Area Networks (LR-WPANs), IEEE Std 663 802.15.4-2006". 665 [11] Moskowitz, J., "Key Management Support for 15.4 and 15.7", IEEE 666 P802.15 Working Group for Wireless Personal Area Networks 667 (WPANs) KMP Transport Proposal, March 2012. 669 Appendix A. Version History 671 o v00 to v01 673 * Add a new section about the processing of node bootstraps. 675 * Add a new section about the multiple trust domains. 677 * The modification is based on the feedback from Rene Struik, 678 Steve Childress, Shoichi Sakane, Greg Zaverucha, Matthew 679 Campagna. 681 o v01 to v02 683 * Add a new section about Frame Format. 685 * Apply an IANA number for KEMP protocol under KMP type. 687 Authors' Addresses 689 Ying Qiu 690 Institute for Infocomm Research, Singapore 691 1 Fusionopolis Way 692 #21-01 Connexis (South Tower) 693 Singapore 138632 695 Phone: +65-6408 2053 696 Email: qiuying@i2r.a-star.edu.sg 698 Jianying Zhou 699 Institute for Infocomm Research, Singapore 700 1 Fusionopolis Way 701 #21-01 Connexis (South Tower) 702 Singapore 138632 704 Phone: +65-6408 2075 705 Email: jyzhou@i2r.a-star.edu.sg 707 Feng Bao 708 Institute for Infocomm Research, Singapore 709 1 Fusionopolis Way 710 #21-01 Connexis (South Tower) 711 Singapore 138632 713 Phone: +65-6408 2073 714 Email: baofeng@i2r.a-star.edu.sg