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