idnits 2.17.1 draft-he-iot-security-bootstrapping-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 5, 2015) is 3279 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE802.15.4' is defined on line 402, but no explicit reference was found in the text == Unused Reference: 'I-D.struik-6tisch-security-considerations' is defined on line 438, but no explicit reference was found in the text -- No information found for draft-struik-6tisch-security-considerations - is the name correct? Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. He 3 Internet-Draft Huawei 4 Intended status: Informational B. Sarikaya 5 Expires: November 6, 2015 Huawei USA 6 May 5, 2015 8 Security Bootstrapping of IEEE 802.15.4 based Internet of Things 9 draft-he-iot-security-bootstrapping-01 11 Abstract 13 Network level security bootstrapping and joining device level 14 security bootstrapping mechanisms are described in this document. 15 They are proposed for security bootstrapping of the Internet of 16 Things networks, which implement IETF protocols (e.g. 6LoWPAN, 6lo, 17 RPL, AODV, DSR) over IEEE 802.15.4. The network level security 18 bootstrapping is useful at the very beginning of a newly deployed IoT 19 network. It automatically and hierarchically adds all the devices to 20 security domain and helps establish security communication. The 21 joining device level security bootstrapping provides comprehensive 22 mechanism for different IoT devices joining an existing IoT network. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on November 6, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. new section . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. IEEE 802.15.4 based IoT topologies . . . . . . . . . . . . . 4 61 4. Network level security bootstrapping . . . . . . . . . . . . 4 62 4.1. Security bootstrapping for the first hop FFDs via 6LBR . 5 63 4.2. Security bootstrapping for further FFDs via configured 64 FFDs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4.3. Security bootstrapping for RFDs via configured FFDs . . . 6 66 5. Joining Device Security Bootstrapping . . . . . . . . . . . . 7 67 5.1. Bootstrapping of joining RFD via configured FFD . . . . . 7 68 5.2. Bootstrapping of joining FFD via configured FFD/6LBR . . 8 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 8.2. Informative References . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 An IoT network is composed of various numbers of connected things 79 with communication ability and different functionalities (sensing 80 unit, control logic). They cooperate together to accomplish specific 81 tasks required by users. Things in an IoT network might be supplied 82 by different vendors, and are normally resource-constrained devices 83 that with limited power supply, communication capability, CPU 84 performance and memory volume. 86 [IEEE802.15.4]is a standard which specifies the physical layer and 87 media access control for low-rate wireless personal area networks 88 (LR-WPANs). It is widely used in wireless sensor networks nowadays, 89 6LoWPAN WG (concluded) developed RFC 4944[RFC4944] to describe how to 90 transmit IPv6 packets over 802.15.4, and support mesh routing in LR- 91 WPANs. 6lo WG defines generic IPv6 packet header compression method 92 [RFC7400] for LR-WPANs. 6tisch tries to build adaptation protocol for 93 802.15.4e protocol. Roll develops routing protocol RPL[RFC6550] for 94 IPv6 based low power and lossy networks. IEEE 802.15.4 is foreseen 95 as the most used lower layer protocol for low rate IoT networks with 96 resource constrained devices. 98 Creating security domains from previously unassociated IoT devices is 99 a key operation in the IoT network and in the lifecycle of a thing. 100 Because IEEE 802.15.4 maximum payload size is 128 Bytes, a standard 101 security bootstrapping protocol should be light-weight with low 102 complexity. The protocol must allow for commissioning of devices 103 from different manufacturers and facilitate transitions of control 104 amongst devices during the device's and system's lifecycle. 106 Traditional security bootstrapping approaches include device 107 authentication and key generation/distribution, which tend to impose 108 configuration burdens upon users. For example, users need to follow 109 a series of instruction steps for WPA2-PSK (WiFi Protected Access 2, 110 Pre-shared key) configuration, even though the pre-shared key mode is 111 the simplest option for using WPA. Establishing security among IoT 112 devices becomes more complicated since they don't always provide user 113 interface to input necessary security information. Furthermore, the 114 scale of the IoT network can be large, human intervention in large 115 scale security bootstrapping is expensive and low efficient. 117 [I-D.pritikin-anima-bootstrapping-keyinfra] proposes a zero-touch 118 bootstrapping key infrastructure to allow joining device securely and 119 automatically bootstraps itself based on 802.1AR certificate. It 120 can't be directly used in 802.15.4 devices due to the high security 121 complexity and heavy communication overhead. Its architecture is not 122 built by considering different possible 802.15.4 network topologies 123 and the underlying routing protocols developed by IETF. 125 [I-D.struik-6tisch-security-considerations]defines high level 126 requirements and proposes two types of security mechanisms: single- 127 stage and two-stage. Even though the two types of security AA 128 mechanisms offer flexible solutions. The underlying security 129 architecture can neither be used directly by 802.15.4 IoT networks. 130 IEEE 802.15.4 also defines two-step mechanism for nodes joining 131 network with layer 2 authentication. Without considering use of IPv6 132 infrastructure, the solution is not comprehensive. 134 Another key challenge for security bootstrapping of a device the 135 above mentioned mechanisms is that they are not feasible to 136 commission a device when the adjacent devices have not been 137 commissioned yet. As a result, this document describes and 138 standardizes two types of automatic bootstrapping methods for 139 802.15.4 based IoT networks: network level security bootstrapping and 140 joining device level security bootstrapping. 142 2. new section 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in 147 [RFC2119]. 149 This specification requires readers to be familiar with all the terms 150 and concepts that are discussed in "Neighbor Discovery for IP version 151 6 (IPv6)" [RFC4861], "IPv6 over Low-Power Wireless Personal Area 152 Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and 153 Goals" [RFC4919].This specification makes extensive use of the same 154 terminology defined in [RFC4944]. 156 3. IEEE 802.15.4 based IoT topologies 158 A general architectural overview of the IEEE 802.15.4 based IoT is 159 provided in Figure 1. All the devices communicate to backbone server 160 through 6LBR. FFDs communicate with each other directly or 161 indirectly via hopping or 6LBR. RFDs directly connect to FFDs, and 162 the number of RFDs that attach to a FFD may vary. 164 /////-------------------\\\\\ 165 | Server | 166 \\\\\-------------------///// 167 | 168 +-------------------------------------------------------------------+ 169 | 6LBR | 170 +--------------------------------+----------------------------------+ 171 | +--------+-----------+ | 172 | +-**->| FFD_2 |<--**-+ | 173 | | +--------------------+ | | 174 +-----------------+--+ +---+--------------+ 175 | FFD_1 | <---------*****--------> | FFD_N | 176 +--------------------+ +------------------+ 177 | | | 178 +--------------+ +--------------+ +--------------+ 179 | RFD_11 | | RFD_1M | | FFD_N1 | 180 +--------------+ +--------------+ +--------------+ 182 Figure 1 184 4. Network level security bootstrapping 186 At the very beginning of the networking once nodes are deployed, 187 network level security bootstrapping assist automatically creates 188 security domain and hierarchically adds devices to network. The 189 mechanism is realized by three phases: 191 Phase 1: Security bootstrapping for the first hop FFDs via 6LBR 193 Phase 2: Security bootstrapping for further FFDs via configured 194 FFDs 196 Phase 3: Security bootstrapping for RFDs via configured FFDs 198 4.1. Security bootstrapping for the first hop FFDs via 6LBR 200 When devices are power-on, 6LBR broadcasts beacon frames to 201 neighboring nodes. The FFDs that receive the beacon frames are the 202 first-hop FFDs. As shown in Figure 2, upon receiving the beacon 203 frame, a first-hop FFD associates with 6LBR at link layer according 204 to IEEE 802.15.4. The FFD then presents credential to 6LBR, which 205 are forwarded to trust center to be validated. EAP can be used to 206 realize the authentication procedure. If the validation is 207 successful, the IP address and network key are generated and 208 delivered to the FFD. Further configurations such as cluster head 209 selection, routing protocol, etc., can be realized afterwards. 210 Otherwise if the validation fails, the 6LBR refuses adding the FFD to 211 its domain. 213 First-hop FFD 6LBR TC 214 | | | 215 | Beaconing | | 216 |<--------------------------------| | 217 | | | 218 | IEEE 802.15.4 | | 219 | MAC unsecure association | | 220 |<------------------------------->| | 221 | | | 222 | | | 223 | Authentication | Auth.material check | 224 |<------------------------------->|<---------------------->| 225 | Network key and IP address | IP address | 226 | | | 227 | | | 228 | Further Configuration | | 229 |<------------------------------->| | 230 | | | 231 | | | 233 Figure 2 235 4.2. Security bootstrapping for further FFDs via configured FFDs 237 The configured FFDs broadcast beacon frames to neighboring nodes. 238 The unconfigured FFD that receives the beacon frame associates with 239 the configured FFD at link layer. A FFD may receive multiple beacon 240 frames from more than one configured FFDs, it can select the first 241 one to associate or the one with strongest received power strength. 242 The selection policy is out of the scope of the current document. 243 The unconfigured FFD then presents credential to the associated 244 configured FFD, which are forwarded to 6LBR and TC to be validated. 245 If EAP is used, PANA can be used to relay the authentication message 246 from configured FFDs to 6LBR. If the validation is successful, the 247 IP address and network key are generated and delivered to the FFD. 248 Further configurations such as routing protocol can be realized 249 afterwards. Otherwise if the validation fails, the 6LBR refuses 250 adding the FFD to its domain. 252 Unconfigured FFD Configured FFD 6LBR TC 253 | | | | 254 | Beaconing | | | 255 |<--------------------------------| | | 256 | | | | 257 | IEEE 802.15.4 | | | 258 | MAC unsecure association | | | 259 |<------------------------------->| | | 260 | | | | 261 | | | | 262 | Authentication | Relay | Auth.check | 263 |<------------------------------->|<------------>|<---------------->| 264 | Network key and IP address | | IP address | 265 | | | | 266 | | | | 267 | Further Configuration | | | 268 |<-------------------------------- ------------->| | 269 | | | | 270 | | | | 272 Figure 3 274 4.3. Security bootstrapping for RFDs via configured FFDs 276 The configured FFDs broadcast beacon frames to neighboring nodes. 277 The unconfigured RFD that receives the beacon frame associates with 278 the configured FFD at link layer. A RFD may receive multiple beacon 279 frames from more than one configured FFDs. It can select one device 280 to associate, e.g. the first one that replies or the one with 281 strongest received power strength. The unconfigured RFD then 282 presents credential to the associated configured FFD, which are 283 forwarded to 6LBR and TC to be validated. If the validation is 284 successful, the IP address and network key are generated and 285 delivered to the RFD. Otherwise if the validation fails, the FFD 286 refuses adding the RFD to its domain. 288 RFD Configured FFD 6LBR TC 289 | | | | 290 | Beaconing | | | 291 |<--------------------------------| | | 292 | | | | 293 | IEEE 802.15.4 | | | 294 | MAC unsecure association | | | 295 |<------------------------------->| | | 296 | | | | 297 | | | | 298 | Authentication | Relay | Auth.check | 299 |<------------------------------->|<------------>|<---------------->| 300 | Network key and IP address | | IP address | 301 | | | | 302 | | | | 303 | Further Configuration | | | 304 |<-------------------------------- ------------->| | 305 | | | | 306 | | | | 308 Figure 4 310 5. Joining Device Security Bootstrapping 312 New devices may be added to an existing IoT due to various reasons. 313 As a result the security bootstrapping can be devided into the 314 bootstrapping of joining RFD and bootstrapping of joining FFD. 316 5.1. Bootstrapping of joining RFD via configured FFD 318 A joining RFD broadcasts beacon frames to neighboring nodes. The 319 configured FFDs that receive the beacon frames, decide whether 320 allowing the RFD associating at link layer. A RFD may receive 321 multiple replies from more than one configured FFDs. It can select 322 one device to associate, e.g. the first one that replies or the one 323 with strongest received power strength. The joining RFD then 324 presents credential to the associated configured FFD, which is 325 forwarded to 6LBR and TC to be validated. If the validation is 326 successful, the IP address and network key are generated and 327 delivered to the RFD. Otherwise if the validation fails, the 328 FFDrefuses adding the RFD to its domain. 330 Joining RFD Configured FFD 6LBR TC 331 | | | | 332 | Beaconing | | | 333 |-------------------------------->| | | 334 | | | | 335 | IEEE 802.15.4 | | | 336 | MAC unsecure association | | | 337 |<------------------------------->| | | 338 | | | | 339 | | | | 340 | Authentication | Relay | Auth.check | 341 |<------------------------------->|<------------>|<--------------->| 342 | Network key and IP address | | IP address | 343 | | | | 344 | | | | 345 | Further Configuration | | | 346 |<-------------------------------- ------------->| | 347 | | | | 348 | | | | 350 Figure 5 352 5.2. Bootstrapping of joining FFD via configured FFD/6LBR 354 A joining FFD broadcasts beacon frames to neighboring nodes. The 355 configured FFDs that receive the beacon frames, decide whether 356 allowing the FFD associating at link layer. A FFD may receive 357 multiple replies from more than one configured FFDs or directly from 358 the 6LBR. It can select one device to associate, e.g. the first one 359 that replies or the one with strongest received power strength. The 360 joining FFD then presents credential to the associated configured 361 FFD/6LBR, which is forwarded to TC to be validated. If the 362 validation is successful, the IP address and network key are 363 generated and delivered to the FFD. Further configurations such as 364 routing protocol can be realized afterwards. Otherwise if the 365 validation fails, the 6LBR refuses adding the FFD to its domain. 367 +---------------------------+ 368 Joining FFD | Configured FFD 6LBR | TC 369 | +------+--------------+-----+ | 370 | Beaconing | | | 371 |-------------------------------->| | | 372 | | | | 373 | IEEE 802.15.4 | | | 374 | MAC unsecure association | | | 375 |<------------------------------->| | | 376 | | | | 377 | | | | 378 | Authentication | Relay | Auth.check | 379 |<------------------------------->|<------------>|<---------------->| 380 | Network key and IP address | | IP address | 381 | | | | 382 | | | | 383 | Further Configuration | | | 384 |<-------------------------------- ------------->| | 385 | | | | 386 | | | | 388 Figure 6 390 6. Security Considerations 392 TBD 394 7. Acknowledgement 396 TBD 398 8. References 400 8.1. Normative References 402 [IEEE802.15.4] 403 IEEE Standard, , "IEEE Std. 802.15.4-2011", October 2011, 404 . 407 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 408 Requirement Levels", BCP 14, RFC 2119, March 1997. 410 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 411 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 412 September 2007. 414 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 415 over Low-Power Wireless Personal Area Networks (6LoWPANs): 416 Overview, Assumptions, Problem Statement, and Goals", RFC 417 4919, August 2007. 419 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 420 "Transmission of IPv6 Packets over IEEE 802.15.4 421 Networks", RFC 4944, September 2007. 423 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 424 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 425 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 426 Lossy Networks", RFC 6550, March 2012. 428 [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for 429 IPv6 over Low-Power Wireless Personal Area Networks 430 (6LoWPANs)", RFC 7400, November 2014. 432 8.2. Informative References 434 [I-D.pritikin-anima-bootstrapping-keyinfra] 435 Pritikin, M., Behringer , M., and S. Bjarnason , 436 "Bootstrapping Key Infrastructures", November 2014. 438 [I-D.struik-6tisch-security-considerations] 439 Struik , R., "6TiSCH Security Architectural 440 Considerations", January 2015. 442 Authors' Addresses 444 Danping He 445 Huawei 447 Email: ana.hedanping@huawei.com 449 Behcet Sarikaya 450 Huawei USA 451 5340 Legacy Dr. Building 3 452 Plano, TX 75024 454 Email: sarikaya@ieee.org