idnits 2.17.1 draft-piro-6tisch-security-issues-03.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 == Line 23 has weird spacing: '...esigned for n...' -- The document date (December 10, 2014) is 3424 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '5' on line 421 -- Looks like a reference, but probably isn't: '7' on line 421 -- Looks like a reference, but probably isn't: '1' on line 429 -- Looks like a reference, but probably isn't: '4' on line 429 == Unused Reference: 'I-D.ietf-6tisch-tsch' is defined on line 935, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-struik-6tisch-security-architecture-elements' is defined on line 954, but no explicit reference was found in the text == Unused Reference: 'DH' is defined on line 960, but no explicit reference was found in the text == Unused Reference: 'ZIGBEEIP' is defined on line 969, but no explicit reference was found in the text == Unused Reference: 'Camtepe2005' is defined on line 972, but no explicit reference was found in the text == Unused Reference: 'Wang2006' is defined on line 982, but no explicit reference was found in the text == Unused Reference: 'Cayirci2007' is defined on line 986, but no explicit reference was found in the text == Unused Reference: 'RFC5191' is defined on line 989, but no explicit reference was found in the text == Unused Reference: 'RFC6347' is defined on line 993, but no explicit reference was found in the text == Unused Reference: 'HIPDEX' is defined on line 996, but no explicit reference was found in the text == Unused Reference: 'PalattellaSurvey' is defined on line 999, but no explicit reference was found in the text == Unused Reference: 'StallingsSecurityBooks' is defined on line 1005, but no explicit reference was found in the text == Unused Reference: 'TELOSB' is defined on line 1013, but no explicit reference was found in the text == Unused Reference: 'Watteyne2012' is defined on line 1029, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-03 == Outdated reference: A later version (-04) exists of draft-wang-6tisch-6top-sublayer-01 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-02 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- No information found for draft-moskowitzhip-rg-dex - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 19 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH G. Piro 3 INTERNET-DRAFT (Politecnico di Bari) 4 Intended Status: Informational G. Boggia 5 Expires: June 13, 2015 (Politecnico di Bari) 6 L. A. Grieco 7 (Politecnico di Bari) 8 December 10, 2014 10 Layer-2 security aspects for the IEEE 802.15.4e MAC 11 draft-piro-6tisch-security-issues-03 13 Abstract 15 The aim of this Internet Draft is to define standard compliant 16 procedures for configuring layer-2 security services in IEEE 17 802.15.4e-based Low-power and Lossy Networks. In particular, it 18 provides a review of security aspects presented in both IEEE 19 802.15.4-2011 and IEEE 802.15.4e-2012 specifications, the 20 classification of secure network configurations and layer-2 keys, the 21 description of a set of consecutive steps required to establish a 22 layer-2 secure link, and a lightweight Key Management Protocol 23 designed for negotiating a layer-2 one-hop link key. As the final 24 goal, the document would describe how security MAC attributes can by 25 initialized and updated in order to offer layer-2 security services 26 in real networks. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as 36 Internet-Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Copyright and License Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3 Security in IEEE 802.15.4-2011 (and IEEE 802.15.4e-2012) . . . 4 69 5 Definition of layer-2 keys . . . . . . . . . . . . . . . . . . 7 70 4 Security Configurations . . . . . . . . . . . . . . . . . . . . 8 71 6 Establishing a secured layer-2 link . . . . . . . . . . . . . . 10 72 6.1 Setting-up phase . . . . . . . . . . . . . . . . . . . . . 12 73 6.2 Bootstrap phase . . . . . . . . . . . . . . . . . . . . . . 13 74 6.2.1 Bootstrap phase for the PAN coordinator . . . . . . . . 13 75 6.2.2 Bootstrap phase for a "joining node" . . . . . . . . . 16 76 6.3 Join Phase . . . . . . . . . . . . . . . . . . . . . . . . 19 77 6.4 Key Negotiation Phase . . . . . . . . . . . . . . . . . . . 19 78 6.4.1 New Header Information Elements . . . . . . . . . . . . 20 79 6.4.2 KMP description . . . . . . . . . . . . . . . . . . . . 20 80 6.4.2 Calculation of the "per-peer L2 key" . . . . . . . . . . 22 81 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 24 82 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 24 83 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 9.1 Normative References . . . . . . . . . . . . . . . . . . . 24 85 9.2 Informative References . . . . . . . . . . . . . . . . . . 25 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 88 1 Acronyms 90 In addition to the acronyms defined in [I-D.ietf-6tisch-terminology], 91 the following acronyms are used in this document: 93 ECDH Elliptic Curve Diffie Hellman 95 KMP Key Management Protocol 97 2 Introduction 99 The IEEE 802.15.4 standard [IEEE802154] is widely recognized as one 100 of the most successful enabling technologies for short-range low-rate 101 wireless communications. It covers all the details related to the 102 Medium Access Control (MAC) and physical layers of the protocol stack 103 and supports the possibility to protect MAC packets by means of 104 symmetric-key cryptography techniques with several security options. 105 However, the IEEE 802.15.4 standard does not explain how handling the 106 initialization of a secure IEEE 802.15.4 domain, the generation and 107 the exchange of keys, and the management of joining operations in a 108 secure 802.15.4 network already configured in the past, thus 109 delegating the upper layers to orchestrate, enable, configure, and 110 negotiate security services. The IEEE 802.15.4e [IEEE802154e] 111 standard introduces some amendments to the IEEE 802.15.4 standard. 112 Among its key features there is the Time-slotted Channel Hopping 113 (TSCH), i.e., a novel MAC protocol, which better supports multi-hop 114 communications in emerging industrial applications. In addition, it 115 provides very few upgrades to security-related aspects. 117 Since the IEEE 802.15.4e amendment focuses only on link-layer 118 aspects, the 6TiSCH WG was created to define open standards in 119 support of the adoption of IPv6 over the TSCH mode of the 120 IEEE802.15.4e standard, thus covering all facets related to the 121 management of network communications in complex (and eventually 122 distributed) Low-Power and Lossy Networks (LLNs) [I-D.ietf-6tisch- 123 tsch] [I-D.wang-6tisch-6top]. 125 Security aspects represent an important issue that needs to be 126 considered in a 6TiSCH network. TSCH defines mechanisms to encrypt 127 and authenticate MAC frames but it does not define how this keying 128 material is generated [IEEE802154]. For this reason, the 6TiSCH WG 129 needs to define (i) security requirements and related architecture, 130 (ii) join processes, (iii) the keying material and authentication 131 mechanism needed by a new mote to join an existing network; (iv) a 132 mechanism to allow for the secure transfer of application data 133 between neighbor motes; and (v) define a mechanism to allow for the 134 secure transfer of signaling data between motes and 6TiSCH. 136 The description of the security architecture and related 137 architectural elements are being investigated in [I-D.draft- 138 richardson-6tisch-security-architecture] and [I-D.draft-struik- 139 6tisch-security-architecture-elements], respectively. 141 This Internet Draft focuses on layer-2 security aspects and describes 142 standard compliant procedures for configuring layer-2 security 143 services in IEEE 802.15.4e-based Low-power and Lossy Networks. In 144 particular, main features covered by this document are: 146 - a review of security aspects presented in both IEEE 802.15.4 and 147 IEEE 802.15.4e specifications, with particular attention to the 148 set of parameters that need to be set for enabling security 149 services at the MAC layer; 151 - the definition of types and properties of layer-2 keys; 153 - the classification of possible secure network configurations, 154 which include Fully Secure, Unsecure, Partial Secure, and Hybrid 155 Secure networks; 157 - the description of a set of consecutive steps (i.e., Setting-up, 158 Bootstrap, Join, and Key Negotiation phases) that are required to 159 establish a layer-2 secure link among a couple of nodes; 161 - the design of a lightweight Key Management Protocol useful for 162 negotiating a per-peer layer-2 key. 164 3 Security in IEEE 802.15.4-2011 (and IEEE 802.15.4e-2012) 166 This section summarizes security features defined within IEEE 802.15.4 167 and IEEE 802.15.4e specifications [IEEE802154] [IEEE802154e]. 169 The standard defines eight security levels to protect MAC frames, as 170 summarized in Fig. 1 and imposes the adoption of the CCM* algorithm to 171 perform encryption and description procedures (which requires a key of 172 128 bit). 174 +----------+-------------+-----------+----------------+ 175 | Security | Security | Data | Data | 176 | level | attribute | Integrity | Confidentiality| 177 +----------+-------------+-----------+----------------+ 178 | 0 | None | No | No | 179 +----------+-------------+-----------+----------------+ 180 | 1 | MIC-32 | Yes | No | 181 +----------+-------------+-----------+----------------+ 182 | 2 | MIC-64 | Yes | No | 183 +----------+-------------+-----------+----------------+ 184 | 3 | MIC-128 | Yes | No | 185 +----------+-------------+-----------+----------------+ 186 | 4 | ENC | No | Yes | 187 +----------+-------------+-----------+----------------+ 188 | 5 | ENC-MIC-32 | Yes | Yes | 189 +----------+-------------+-----------+----------------+ 190 | 6 | ENC-MIC-64 | Yes | Yes | 191 +----------+-------------+-----------+----------------+ 192 | 7 | ENC-MIC-128 | Yes | Yes | 193 +----------+-------------+-----------+----------------+ 194 Figure 1. Security levels available for a IEEE 802.15.4 network. 196 At the MAC layer, encryption and decryption operations are implemented 197 within the "outgoing frame security" and the "incoming frame security" 198 procedures, respectively. They use a number of security attributes, 199 summarized in what follows: 201 - macKeyTable: it is composed by a set of KeyDescriptor elements. 202 A specific KeyDescriptor element is created for each key, composed 203 by (see Tab. 61 of the IEEE 802.15.4 standard for more details 204 [IEEE802154]): 206 - The KeyIdLookupList, which is a list of 207 KeyIdLookupDescriptor entries. A KeyIdLookupDescriptor is 208 composed by a set of parameters (see Tab. 65 of the IEEE 209 802.15.4 standard for more details [IEEE802154]), i.e., 210 KeyIdMode, KeySource, KeyIndex, DeviceAddMode, DevicePANId, 211 and DeviceAddress, that are used to identify the key within 212 the macKeyTable. 214 - The DeviceDescriptorHandleList, which contains pointers to 215 DeviceDescriptor elements stored within the macDeviceTable. 216 It is used to identify which devices may use the key. 218 - The KeyUsageList, which is a list of KeyUsageDescriptor 219 elements. A KeyUsageDescriptor is composed by the FrameType 220 and the CommandFrameIdentifies fields that indicate the 221 frame type with which the considered key may be used (see 222 Tab. 62 of the IEEE 802.15.4 standard for more details 223 [IEEE802154]). 225 - The Key. 227 - macDeviceTable: it is composed by a set of DeviceDescriptor 228 elements, providing some information about remote devices which 229 the node can establish secure communication with. A dedicated 230 DeviceDescriptor element is associated to each remote device. It 231 is composed by a number of fields, i.e., PANId, ShortAddress, 232 ExtAddress, FrameCounter, and Extemp, which collect information 233 related to a specific remote device (see Tab. 64 of the IEEE 234 802.15.4 standard for more details [IEEE802154]). 236 - macSecurityLevelTable: it is made by a set of 237 SecurityLevelDescriptor elements, which store details about the 238 security level required for each MAC frame type and subtype. 239 Fields belonging to the SecurityLevelDescriptor data structure 240 are: FrameType, ComamndFrameIdentifier, SecurityMinimum, 241 DeviceOverrideSecurityMinimum, and AllowedSecurityLevels (see Tab. 242 63 of the IEEE 802.15.4 standard for more details [IEEE802154]). 244 - macFrameCounter: it is an integer value storing the outgoing 245 frame counter for the considered device. Its length depends from 246 the configured macFrameCounterMode (in TSCH-enabled networks it 247 represents the ASN [IEEE802154e]). 249 - macAutoRequestSecurityLevel: it is an integer value providing 250 the security level used for automatic data requests. 252 - macAutoRequestKeyIdMode: it is an integer value indicating the 253 key identifier mode used for automatic data requests. It is not 254 valid if the macAutoRequestSecurityLevel attribute is set to 0x00. 256 - macAutoRequestKeySource: it represents a short or extended IEEE 257 802.15.4 MAC address, indicating the originator of the key used 258 for automatic data requests. This attribute is not valid if the 259 macAutoRequestKeyIdMode element is not valid or set to 0x00. 261 - macAutoRequestKeyIndex: it is an integer value storing the index 262 of the key used for automatic data requests. It is not valid if 263 the macAutoRequestKeyIdMode attribute is not valid or set to 264 0x00. 266 - macDefaultKeySource: it is the extended IEEE 802.15.4 MAC 267 address of the originator of the default key used for key 268 identifier mode 0x01. 270 - macPANCoordExtendedAddress: it represents the extended address 271 of the PAN coordinator. 273 - macPANCoordShortAddress: it represents the short address 274 assigned to the PAN coordinator. 276 -macFrameCounterMode: it is an integer value describing the size 277 of the frame counter (i.e., 0x04 corresponds to a frame size of 4 278 octets; 0x04 corresponds to a frame size of 5 octets). 280 During the outgoing security procedure, the high layer uses the 281 KeyIdMode parameter to select a specific key in the macKeyTable to be 282 used for protecting the MAC frame. 284 The KeyIdMode is set to 00, 01, 10, and 11 in the case the key can be 285 implicitly derived by both sender and the receiver and it is not 286 specified in the message, the key is explicitly determined by the 287 KeyIndex parameter stored into the MAC header and the 288 macDefaultKeySource, the key can be derived by considering KeyIndex and 289 KeySource fields stored into the MAC header (with KeySource representing 290 the short address of the device that has generated the key), and the key 291 can be derived by considering KeyIndex and KeySource fields stored into 292 the MAC header (with KeySource representing the IEEE extended address of 293 the device that has generated the key), respectively. 295 Both IEEE 802.15.4 and IEEE 802.15.4e standards do not provide any 296 guideline to create (and or negotiate) keys, as well as to configure the 297 aforementioned security MAC attributes. They just delegate upper layers 298 to orchestrate such aspects. 300 5 Definition of layer-2 keys 302 In line with [I-D.draft-richardson-6tisch-security-architecture], a 303 "production network" may use two different layer-2 keys, that are 304 "production network key" and "per-peer L2 key". 306 The "production network key" is a secret shared by all the authorized 307 nodes. It can be obtained only if the node is able to correctly complete 308 the join procedure, which offers authorization and authentication 309 services. 311 The "per-peer L2 key" is, instead, negotiated only between a couple of 312 nodes through a KMP strategy. 314 In addition, a new layer-2 key, namely "master L2 key", is defined. It 315 represents an initial secret, which is shared among all the motes and 316 configured by the manufacturer or by the network administrator before 317 the network deployment. Note that a mote can be subjected to any kind of 318 tamper attacks. Without any further shrewdness, an attacker that may 319 physically access to the mote could extract the "master L2 key", thus 320 compromising the security of the whole 6TiSCH network. Hence, it is very 321 important to ensure the protection to that tampering attacks by using 322 specific software-based and/or hardware-based mechanisms 323 [Walters07][Becher2006]. 325 Each layer-2 key is used to protect a specific set of messages. In 326 particular, the "master L2 key" is used for protecting enhanced beacon 327 messages and data frames carrying messages exchanged during the join 328 procedure; the "production network key" is used for protecting broadcast 329 messages and MAC frames exchanged during the Key Negotiation Phase; the 330 "per-peer L2 key" is used for encrypting and authenticating messages 331 exchanged between two nodes at the MAC layer. 333 "master L2 key" and "production network key" should be identified within 334 the network by setting KeyIdMode to 0x01 (for both of keys) and the 335 KeyIndex to 1 and 2, respectively. Differently, the "per-peer L2 key" 336 should be explicitly identified within the network. Hence, its KeyIdMode 337 should be set to 0x03 and KeySource and KeyIndex parameters should be 338 set according to the couple of nodes that negotiated the key (more 339 details can be found in Sec. 6). 341 As it will better described in the following sections, the master L2 342 key" is stored within the device during the Setting-Up Phase and 343 configured as one of security MAC attribute at the end of the Bootstrap 344 Phase. The "production network key" is obtained and configured as one of 345 security MAC attribute during the Join Phase. Finally, the "per-peer L2 346 key" is negotiated and configured at the MAC layer during the Key 347 Negotiation Phase. 349 4 Security Configurations 351 Based on the status and the configuration of security services, a 352 "production network" may fall within one of the following security 353 configurations: 355 - Fully Secured network: all the devices forming the network are 356 configured to fully support security services and they have 357 already obtained (or negotiated) all the keys defined in the 358 previous section. It represents the most secured configuration: 359 all packets are encrypted and authenticated by using specific 360 keys, which depend from the message they carry. Nodes that do not 361 support security capabilities (or that are not in posses of all 362 the information to joining the network, such as key materials and 363 encryption and decryption algorithms) are not allowed to join the 364 network. 366 - Unsecured network: security services are not supported. Even if 367 in possession of security capabilities, any pair of nodes is not 368 allowed to establish a secured communication. Differently for the 369 Fully Secured scheme, this is the lowest security level. Since the 370 data encryption, the message integrity, and the peer 371 authentication are not implemented, all the MAC frames are 372 exchanged in clear. Hence, the setup and the maintaining of the 373 network are described by the standard and no further upgrades are 374 required. 376 - Partial Secured network: only the integrity of message is 377 supported. 379 - Hybrid Secured network: a network falls in this configuration 380 when there still are a group of devices that have not yet 381 authenticated by the network (because they have not yet correctly 382 completed the join procedure). 384 The standard imposes to specify, for each kind of MAC packet, minimum 385 security levels that should be guaranteed. These restrictions must be 386 detailed for each remote device. To this end, SecurityMinimum, 387 DeviceOverrideSecurityMinimum, and AllowedSecurityLevels parameters are 388 stored into the DeviceDescriptor element (see Sec. 3) to define the 389 minimum security level (i.e., one of those reported in Fig.1), the 390 possibility to override the minimum security level (i.e., 391 DeviceOverrideSecurityMinimum is just a boolean flag), and the list of 392 allowed security levels in the case the minimum one could be overridden, 393 respectively. 395 Focusing the attention on "production network" that is not in a hybrid 396 (i.e., dynamic) configuration, these parameters must be set as reported 397 in Fig. 2. 399 +----------------------------------------------------+ 400 | Attribute | Secured Network Configurations | 401 | |Unsecured | Fully | Partial | 402 +----------------+-----------+-----------+-----------+ 403 | SecurityMinimum|0 | from 5 | from 1 | 404 | | | to 7 | to 4 | 405 +----------------+-----------+-----------+-----------+ 406 | DeviceOverride-| FALSE | FALSE | FALSE | 407 | SecurityMinimum| | | | 408 +----------------+-----------+-----------+-----------+ 409 | AllowedSecuri- | 0 | from 5 | from 1 | 410 | tyLevelsvels | | to 7 | to 4 | 411 +----------------+-----------+-----------+-----------+ 412 Figure 2. Setting of security attributes of the DeviceDescriptor element 413 in each defined secure network configuration. 415 The Unsecured network configuration does not support any security 416 features. Hence, both minimum and allowable security levels are set to 0 417 for all the MAC frames and the possibility to override such constraints 418 is disabled for all devices. 420 If the Fully Secured configuration is enabled, the minimum security 421 level must be chosen in the range [5,7], thus allowing the possibility 422 to support the encryption and the authentication of messages. The 423 manufacturer must set the default value to 7; it can be updated by the 424 network administrator. The minimum security level must not be overridden 425 by any devices and, as a consequence, the field AllowedSecurityLevels 426 should contain only one value, equal to the minimum security level. 428 If the Partial Secured configuration is enabled, the minimum security 429 level must be chosen in the range [1,4], thus allowing the possibility 430 to support the authentication of messages. The manufacturer must set the 431 default value to 4; it can be updated by the network administrator. The 432 minimum security level must not be overridden by any devices and, as a 433 consequence, the field AllowedSecurityLevels should contain only one 434 value, equal to the minimum security level. 436 6 Establishing a secured layer-2 link 438 A layer-2 secure link can be established through the execution of four 439 consecutive phases: Setting-up, Bootstrapping, Join, and Key Negotiation 440 (see Fig. 3). 442 The Setting-up Phase is used to store into the device all the secrets 443 required to initialize a secured domain. The Bootstrap Phase, whose 444 implementation is different for both PAN coordinator and the "join 445 node", is used for initializing security MAC attributes. The Join Phase 446 is handled by upper layers for offering authorization and authentication 447 services and allows the device to receive at the end the NetworkKey. 448 Finally, the Key Negotiation Phase handles the Key Management Protocol 449 (KMP) and it is used to negotiate a layer-2 key between a couple of 450 nodes that are directly connected at the MAC layer. 452 +-----------------------+ 453 | | Installation of 454 | Setting-up Phase | --> initial secretes 455 | | in each device 456 +-----------------------+ 457 | 458 V 459 +-----------------------+ 460 | | Initialization of 461 | Bootstrap Phase | --> security MAC attributes 462 | | 463 +-----------------------+ 464 | 465 V 466 +-----------------------+ 467 | | Implementation of the 468 | Join Phase | --> join procedure 469 | | 470 +-----------------------+ 471 | 472 V 473 +-----------------------+ 474 | | Negotiation of the 475 | Key Negotiation Phase | --> "per-peer L2 key" 476 | | between a couple of nodes 477 +-----------------------+ 479 Figure 3. Summary of the proposed framework. 481 6.1 Setting-up phase 483 The setting-up phase is used to properly configure the device that will 484 join to a "production network". It consists in storing, within the 485 device, parameters and initial secrets, which will be used by secure 486 algorithms and procedure to setup the secure domain. They include the 487 "master L2 key", (ii) the GlobalSecurityLevelsTable, (iii) the private 488 key of the node, (iv) the public key of the node stored within a 489 certificate, and (iv) the certificate of the certification authority. 490 This operation may be performed by the manufacturer or by the network 491 administrator. 493 Note that the GlobalSecurityLevelsTable, that has been reported in Fig. 494 4, is used to store the minimum security level and the list of allowed 495 security levels that must be adopted for each kind of MAC frame and for 496 each security configuration defined in Sec. 5. Both the minimum security 497 level and the list of allowed security levels must be chosen by the 498 manufacturer or by the network administrator, according to restrictions 499 reported in Fig. 2. 501 +-------------+------------+-----------------------------+ 502 | Attribute | Frame Type |Secured Configurations | 503 | | |Unsecured| Fully | Partial | 504 +-------------+------------+---------+---------+---------+ 505 | Security | Beacon | | | | 506 | Minimum | | | | | 507 +-------------+------------+---------+---------+---------+ 508 | Security | Data | | | | 509 | Minimum | | | | | 510 +-------------+------------+---------+---------+---------+ 511 | Security | Command MAC| | | | 512 | Minimum | | | | | 513 +-------------+------------+---------+---------+---------+ 514 | Security | ACK | | | | 515 | Minimum | | | | | 516 +-------------+------------+---------+---------+---------+ 517 | AllowedSe- | Beacon | | | | 518 | curityLevels| | | | | 519 +-------------+------------+---------+---------+---------+ 520 | AllowedSe- | Data | | | | 521 | curityLevels| | | | | 522 +-------------+------------+---------+---------+---------+ 523 | AllowedSe- | Command MAC| | | | 524 | curityLevels| | | | | 525 +-------------+------------+---------+---------+---------+ 526 | AllowedSe- | ACK | | | | 527 | curityLevels| | | | | 528 +-------------+------------+---------+---------+---------+ 530 Figure 4. Structure of the GlobalSecurityLevelsTable. 532 6.2 Bootstrap phase 534 6.2.1 Bootstrap phase for the PAN coordinator 536 As soon a node becomes the PAN coordinator, it should configure initial 537 security MAC attributes, including those related to the "master L2 key". 538 To this end, specific primitives of the 6top adaptation layer are used 539 [I-D.wang-6tisch-6top]. 541 The following operations are executed: 543 a) A CONFIGURE.security command is generated by the 6top layer and 544 sent to the MAC entity to initialize security attributes. The set 545 of parameters handled by this command are set as in the sequel: 547 a.1) enable = true; 549 a.2) macAutoRequestSecurityLevel = security level expected 550 for the beacon message and stored within the 551 GlobalSecurityLevelsTable; 553 a.3) macAutoRequestKeyIdMode = 0x03; 555 a.4) macAutoRequestKeySource = MAC address of the device; 557 a.5) macAutoRequestKeyIndex = 1; 559 a.6) macDefaultKeySource = MAC address of the device; 561 b) CONFIGURE.security.macSecurityLevelTable command is generated 562 by the 6top layer and sent to the MAC entity to initialize 563 macSecurityLevelTable. Parameters stored into this command are 564 taken from the GlobalSecurityLevelsTable. 566 c) A new KeyIdLookupList data structure is created. A 567 KeyIdLookupDescriptor is generated and stored into the 568 KeyIdLookupList data structure. The KeyIdMode, the KeyIndex, and 569 the key variables of this KeyIdLookupDescriptor are set to 0x01 570 and 1, respectively. Instead, KeySource, DeviceAddrMode, 571 DevicePANId, and DeviceAddress are not set due to the selected 572 KeyIdMode (see Tab. 65 of the IEEE 802.15.4 standard for more 573 details [IEEE802154]). 575 d) A KeyUsageList data structure is created. One 576 KeyUsageDescriptor for each kind of broadcast messages is create 577 and stored into the KeyUsageList data structure. 579 e) An empty DeviceDescriptorHandleList is created. No data are 580 stored within this list because the PAN coordinator does not yet 581 know the list of devices that may use this key. 583 f) Then, the 6top layer deliver the "master L2 key", the 584 KeyIdLookupList, the KeyUsageList, and the 585 DeviceDescriptorHandleList to the MAC layer by using the 586 CONFIGURE.security.macKeyTable primitive. Triggered by the 587 CONFIGURE.security.macKeyTable command, the MAC layer will create 588 a KeyDescriptor associated to the "master L2 key", where storing 589 all the parameters received by the 6top layer, and store it within 590 the macKeyTable. 592 The Bootstrap phase for the PAN coordinator has been summarized in Fig. 593 5. 595 6top MAC 596 | | 597 | CONFIGURE.security | 598 |-----------------------------------------> | 599 | initialize 600 | security MAC 601 | attributes 602 | | 603 | CONFIGURE.security.macSecurityLevelTable | 604 |-----------------------------------------> | 605 | initialize 606 | minimum security 607 | levels 608 | | 609 | CONFIGURE.security.macKeyTable | 610 |-----------------------------------------> | 611 | create the KeyDescriptor 612 | associated to the 613 | "master L2 key" 614 | | 615 V V 616 Figure 5. Bootstrap Phase for the PAN coordinator. 618 6.2.2 Bootstrap phase for a "joining node" 620 Before executing the Join Phase, a "joining node" should initialize 621 security MAC attributes, including information related to the "master L2 622 key", through specific 6top adaptation layer primitives. To this end, 623 after the reception of the enhanced beacon message, the following 624 operations are executed: 626 a) From the received beacon message, the mote extracts the PAN_ID, 627 the MAC address of the node that sent the beacon, and the 628 FrameCounter. 630 b) A CONFIGURE.security primitive is generated by the 6top layer 631 and sent to the MAC entity to initialize security attributes. The 632 set of parameters handled by this primitive are set as in the 633 sequel: 635 b.1) enable = true; 637 b.2) macAutoRequestSecurityLevel = security level expected 638 for the beacon message and stored within the 639 GlobalSecurityLevelsTable; 640 b.3) macAutoRequestKeyIdMode = 0x03; 642 b.4) macAutoRequestKeySource = MAC address of the device; 644 b.5) macAutoRequestKeyIndex = 1; 646 b.6) macDefaultKeySource = MAC address of the device; 648 c) CONFIGURE.security.macSecurityLevelTable primitive is generated 649 by the 6top layer and sent to the MAC entity to initialize 650 macSecurityLevelTable. Parameters stored into this command are 651 taken from the GlobalSecurityLevelsTable. 653 d) A new KeyIdLookupList data structure is created. A 654 KeyIdLookupDescriptor is generated and stored into the 655 KeyIdLookupList data structure. The KeyIdMode and the KeyIndex 656 variables of this KeyIdLookupDescriptor are set to 0x00, the MAC 657 address of the node that sent the beacon message and 1, 658 respectively. Instead, KeySource, DeviceAddrMode, DevicePANId, and 659 DeviceAddress are not set due to the selected KeyIdMode (see Tab. 660 65 of the IEEE 802.15.4 standard for more details [IEEE802154]). 662 e) A KeyUsageList data structure is created. One 663 KeyUsageDescriptor for each kind of messages is create and stored 664 into the KeyUsageList data structure. 666 f) A new DeviceDescriptor element, associated to the node that 667 sent the enhanced beacon message is created and stored into the 668 macDeviceTable. It is built considering these specifications (see 669 Tab. 64 of the IEEE 802.15.4 standard [IEEE802154] for more 670 details): 672 f.1) The PANId variable is associated to the PAN_ID value 673 extracted from the Beacon message. 675 f.2) The ShortAddress is set to the MAC address of node that 676 sent the beacon message whenever the short addressing mode 677 is used. This parameter is set to 0xfffe if only the 678 extended addressing mode is used. If its value is unknown, 679 the ShortAddress parameter is set to 0xfff. 681 f.3) The ExtAddress is set to the IEEE MAC address of node 682 that sent the beacon message. 684 f.4) The FrameCounter parameter is set to the FrameCounter 685 value extracted from the enhanced beacon message (it 686 represents the ASN in the case the network works in TSCH- 687 mode [IEEE802154e]). 689 f.5) The Exempt boolean flag is set to the allowed value of 690 the DeviceOverriddeSecurityMinimum variable described in 691 Fig. 2. 693 g) The DeviceDescriptorHandleList is created and populated with 694 the DeviceDescriptor created at the previous step. 696 h) A KeyUsageList data structure is created and stored within the 697 KeyDescriptor element. One KeyUsageDescriptor for each broadcast 698 message is create and stored into the KeyUsageList data 699 structure. 701 i) The 6top layer deliver the "master L2 key", the 702 KeyIdLookupList, the KeyUsageList, and the 703 DeviceDescriptorHandleList to the MAC layer by using the 704 CONFIGURE.security.macKeyTable primitive. Triggered by the 705 CONFIGURE.security.macKeyTable primitive, the MAC layer will 706 create a KeyDescriptor associated to the "master L2 key", in which 707 storing all the parameters received by the 6top layer, and will 708 store it within the macKeyTable. 710 The Bootstrap Phase for a "joining node" has been summarized in Fig. 6. 712 "joining node" "joining node" device that sends 713 6top MAC the beacon message 714 | | | 715 | | Enhanced Beacon | 716 | | <-----------------| 717 | | | 718 | extract PAN_ID | 719 | and macShortAddress | 720 | | | 721 | CONFIGURE.security | | 722 |----------------------------> | | 723 | initialize | 724 | security MAC | 725 | attributes | 726 | | | 727 | CONFIGURE.security. | | 728 | macSecurityLevelTable | | 729 |----------------------------> | | 730 | initialize | 731 | minimum security | 732 | levels | 733 | | | 734 | CONFIGURE.security. | | 735 | macKeyTable | | 736 |----------------------------> | | 737 | create the KeyDescriptor | 738 | associated to the | 739 | "master L2 key" | 740 | | | 741 V V V 742 Figure 6. Bootstrap Phase for the "joining node". 744 6.3 Join Phase 746 During the Join Phase, the join procedure is implemented by upper layers 747 for offering authorization and authentication features. This aspect is 748 carefully investigated in both [I-D.draft-richardson-6tisch-security- 749 architecture] and [I-D.draft-struik-6tisch-security-architecture- 750 elements], thus being out of scope of this Internet Draft. 752 At the end of the join procedure, the "joining node" obtains the 753 "production network key" and updates security MAC attributes as 754 described for the "master L2 key", with the only difference that the 755 KeyIndex is set to 2. 757 6.4 Key Negotiation Phase 758 Since resource-constrained devices are unable to perform complex 759 algorithms and protocols [Altolini2013][Riaz2009], a simple key 760 agreement protocol, based on both ECDH algorithm and Station-To-Station 761 protocol [StsProtocol], is adopted during the execution of the key 762 negotiation phase. 764 As described in Sec. 6.1, it is supposed that each node stores the 765 certificate of the authority and the couple of its public and private 766 key (generated through the adoption of elliptic curves). Obviously, the 767 public key is stored within a certificate, signed by the authority. 769 In this section is described the KMP implemented between a couple of 770 nodes, i.e., node A and node B, which want to negotiate a on-hop layer-2 771 key. Let PBK_A, PVK_A, PBK_B, and PVK_B be A's public key, A's private 772 key, B's public key, and B's private key, respectively. Moreover, to 773 handle the Key Negotiation phase, a number of high-level commands have 774 been defined. In line with IEEE 802.15.4e specifications, they are 775 mapped into specific Header Information Elements, each one identified by 776 an unique element ID. 778 6.4.1 New Header Information Elements 780 The set of Header Information Elements introduced for handling the KMP 781 are: 783 - Crypto Information Element (element ID set to 0x18). It is used 784 to deliver the certificate storing the ECDH public key. Since the 785 certificate length is generally higher than the IEEE 802.15.4e MAC 786 payload, it is necessary to fragment the certificate, thus sending 787 it through multiple consecutive MAC frames. To this end, the first 788 byte of the introduced Information Element is used to indicate the 789 fragment ID to which the current packet refers to. The second byte 790 of the first fragment stores the RAND parameter, which is a random 791 value adopted to finalize the mutual authentication. 793 - Authentication Information Element (element ID set to 0x19), 794 which stored the AuthField used to execute the mutual 795 authentication. 797 6.4.2 KMP description 798 The KMP consists of six consecutive steps: 800 - Step 1: node A sends to node B its certificate through a number 801 of consecutive MAC frames containing the Crypto Information 802 Element. Let RAND_A be the random number stored within the second 803 byte of the Crypto Information Element belonging to the first MAC 804 frame. All of these packets are protected by using the "production 805 network key" received at the end of the Join Phase. 807 - Step 2: node B verifies the authenticity of the received 808 certificate. In affirmative case, it sends to node A its 809 certificate through a number of consecutive MAC frames containing 810 the Crypto Information Element. Let RAND_B be the random number 811 stored within the second byte of the Crypto Information Element 812 belonging to the first MAC frame. All of these packets are 813 protected by using the NetworkKey received at the end of the Join 814 Phase. 816 - Step 3: node A and node B computes the PreLinkKey, P_k, by using 817 the ECDH algorithm. 819 - Step 4: node A computes the authentication parameter as expected 820 for the Station-To-Station protocol: 821 AuthField_A = E(P_k, sign), 823 where 825 sign = S(PVK_A, H_128 {P_k || RAND_B || RAND_A}) 827 Then, it creates a Authentication Information Element containing 828 the aforecomputed AuthField and sends it to node B. Note that 829 H_128 {.}, E(.), and S(.) operators refer to a 128-bit hash 830 function, the encryption, and the digital sign algorithm, 831 respectively. 833 - Step 5: node B computes the authentication parameter through the 834 128-bit hash function, as in the sequel: 836 AuthField_B = E(P_k, sign), 838 where 840 sign = S(PVK_B, H_128 {P_k || RAND_A || RAND_B}). 842 Then, it creates a Authentication Information Element containing 843 the aforecomputed AuthField and sends it to node A. 845 - Step 6: nodes A and B verifies the authenticity of received 846 AuthField parameters (according to the Station-To-Station) 847 protocol and computes the "per-peer L2 key". 849 6.4.2 Calculation of the "per-peer L2 key" 851 The standard imposes to use the CCM* algorithm and a 128-bit key to 852 protect MAC frames. At the same time, the CCM* algorithm assumes that 853 each key must be used for a specific number of block ciphers 854 [IEEE802154]. 856 For each i-th group of block ciphers, the "per-peer L2 key", L_k, is 857 computed as in the following: 859 L_k = H_128 (i | PAN_ID | P_k). 861 Node A and node B compute the "per-peer L2 key" and updates mac security 862 attributes accordingly. To this end, the following steps are executed: 864 a) If i=1, a new DeviceDescriptor element, associated to the 865 remote mote with which it has negotiated the "per-peer L2 key", is 866 created. It is composed of: 868 a.1) the PANId, which is set to the PAN_ID value. 870 a.2) The ShortAddress, which is set to the MAC address of 871 the remote node whenever the short addressing mode is used. 872 This parameter is set to 0xfffe if only the extended 873 addressing mode is used. In the case its value is unknown, 874 this parameter is set to 0xfff. 876 a.3) The ExtAddress, which is set to the IEEE MAC address of 877 the remote node. 879 a.4) The FrameCounter, which is set to the FrameCounter 880 value extracted from the latest packet received by the 881 remote node. 883 a.5) The Exempt boolean flag, which is set to the allowed 884 value of the DeviceOverriddeSecurityMinimum variable 885 described in Fig. 2. 887 b) A new KeyIdLookupList data structure is created. A 888 KeyIdLookupDescriptor is generated and stored into the 889 KeyIdLookupList data structure. The KeyIdMode, the KeySource, and 890 the KeyIndex variables of this KeyIdLookupDescriptor are set to 891 0x03, the MAC address of the remote mote, and 1, respectively. 892 DeviceAddrMode, DevicePANId, and DeviceAddress are not set because 893 of the selected KeyIdMode (see Tab. 65 of the IEEE 802.15.4 894 standard for more details [IEEE802154]). 896 c) A KeyUsageList data structure is created and stored within the 897 KeyDescriptor element. One KeyUsageDescriptor associated to data 898 MAC frames is created and stored into the KeyUsageList data 899 structure. 901 d) A DeviceDescriptorHandleList is created and populated with the 902 pointer to the DeviceDescriptor created at the point a). 904 e) The 6top layer delivers the "per-peer L2 key", the 905 KeyIdLookupList, the KeyUsageList, and the 906 DeviceDescriptorHandleList to the MAC layer by using the 907 CONFIGURE.security.macKeyTable command. Triggered by the 908 CONFIGURE.security.macKeyTable command, the MAC layer will create 909 a KeyDescriptor associated to the "per-peer L2 key", L_k, in which 910 storing all the parameters received by the 6top layer, and will 911 store it within the macKeyTable. 913 7 Security Considerations 915 There are no security considerations for this document. 917 8 IANA Considerations 919 There is no IANA action required for this document. 921 9 References 923 9.1 Normative References 925 [IEEE802154] IEEE standard for Information Technology, "IEEE std. 926 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 927 and Physical Layer (PHY) Specifications for Low-Rate 928 Wireless Personal Area Networks", June 2011. 930 [IEEE802154e] IEEE standard for Information Technology, "IEEE std. 931 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 932 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 933 2012. 935 [I-D.ietf-6tisch-tsch] Watteyne, T., MR. Palattella, and LA. Grieco, 936 "Using IEEE802.15.4e TSCH in an LLN context: Overview, 937 Problem Statement and Goals", Internet-Draft draft-ietf- 938 6tisch-tsch-03, October 2014. 940 [I-D.wang-6tisch-6top] Wang, Q., Vilajosana, X. and T. Watteyne, 941 "6TiSCH Operation Sublayer (6top)", Internet-Draft draft- 942 wang-6tisch-6top-sublayer-01, July 2014. 944 [I-D.ietf-6tisch-terminology] Palattella, MR., Ed., Thubert, P., 945 Watteyne, T., and Q. Wang, "Terminology in IPv6 over Time 946 Slotted Channel Hopping". Internet Draft draft-ietf- 947 6tisch-terminology-02, July 2014. 949 [I-D.draft-richardson-6tisch-security-architecture] M. Richardson, 950 "security architecture for 6top: requirements and 951 structure". Internet Draft draft-richardson-6tisch- 952 security-architecture-02 April 2014. 954 [I-D.draft-struik-6tisch-security-architecture-elements] R. Struik, 955 Y. Ohba, and S. Das, "6TiSCH Security Architectural 956 Elements, Desired Protocol Properties, and Framework". 957 Internet Draft draft-struik-6tisch-security-architecture- 958 elements-01 October 2014. 960 [DH] W. Diffie and M. Hellman, "New directions in cryptography," IEEE 961 Trans. Inf. Theor. 22, 6 Sep., 2006. 963 [StsProtocol] Whitfield Diffie, Paul C. van Oorschot and Michael J, 964 "Wiener, Authentication and authenticated key exchange", 965 Designs, Codes, and Cryptography, 1987. 967 9.2 Informative References 969 [ZIGBEEIP] ZigBee Public Document 15-002r00, "ZigBee IP 970 Specification", 2013. 972 [Camtepe2005] Seyit A. Camtepe and Bulent Yener, "Key Distribution 973 Mechanisms for Wireless Sensor Networks: a Survey", 974 Technical Report 2005. 976 [Walters07] John Paul Walters, Zhengqiang Liang, Weisong Shi, and 977 Vipin Chaudhary, "Wireless sensor network security: A 978 survey," in book chapter of Security", Proc. of 979 Distributed, Grid, and Pervasive Computing, CRC Press, 980 2007. 982 [Wang2006] Yong Wang, Garhan Attebury, and Byrav Ramamurthy, "A 983 survey of security issues in wireless sensor networks", 984 IEEE Communications Surveys & Tutorials, 2006 986 [Cayirci2007] Security in Wireless Ad Hoc and Sensor Networks. John 987 Wiley & Sons, 2007. 989 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 990 Yegin, "Protocol for Carrying Authentication for Network 991 Access (PANA)", RFC 5191, May 2008. 993 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 994 Security Version 1.2", RFC 6347, January 2012. 996 [HIPDEX] Moskowitz, R., "HIP Diet EXchange (DEX)", draft- 997 moskowitzhip-rg-dex-06 (work in progress), May 2012. 999 [PalattellaSurvey] Maria Rita Palattella, Nicola Accettura, Xavier 1000 Vilajosana, Thomas Watteyne, Luigi Alfredo Grieco, Gennaro 1001 Boggia, and Mischa Dohler," Standardized Protocol Stack 1002 For The Internet Of (Important) Things", IEEE 1003 Communications Surveys & Tutorials, December, 2012 1005 [StallingsSecurityBooks] William Stallings: Cryptography and network 1006 security - principles and practice. Prentice Hall 2010. 1008 [Becher2006] Alexander Becher, Zinaida Benenson, and Maximillian 1009 Dornseif, "Tampering with motes: real-world physical 1010 attacks on wireless sensor networks", In Proc. of conf. 1011 on Security in Pervasive Computing (SPC), Berlin, 2006 1013 [TELOSB] "Crossbow Technology, TelosB Datasheet." [Online]. 1014 Available: http://www.willow.co.uk/TelosB_Datasheet.pdf 1016 [Riaz2009] Riaz, R.; Ki-Hyung Kim; Ahmed, H.F., "Security analysis 1017 survey and framework design for IP connected LoWPANs," 1018 Autonomous Decentralized Systems, 2009. ISADS '09. 1019 International Symposium on , vol., no., pp.1,6, 23-25 1020 March 2009 1022 [Altolini2013] Altolini, D.; Lakkundi, V.; Bui, N.; Tapparello, C.; 1023 Rossi, M., "Low power link layer security for IoT: 1024 Implementation and performance analysis," Wireless 1025 Communications and Mobile Computing Conference (IWCMC), 1026 2013 9th International , vol., no., pp.919,925, 1-5 July 1027 2013 1029 [Watteyne2012] Thomas Watteyne, Xavier Vilajosana, Branko Kerkez, 1030 Fabien Chraim, Kevin Weekly, Qin Wang, Steven D. Glaser, 1031 Kris Pister: OpenWSN: a standards-based low-power wireless 1032 development environment. Trans. Emerging 1033 Telecommunications Technologies 23(5): 480-493 (2012) 1035 Authors' Addresses 1037 Giuseppe Piro 1038 DEI, Dep. of Electrical and Information Engineering 1039 Politecnico di Bari 1040 Via Orabona 4, 70125, Bari, ITALY 1041 Phone: +39 0805963301 1043 Email: giuseppe.piro@poliba.it 1045 Gennaro Boggia 1046 DEI, Dep. of Electrical and Information Engineering 1047 Politecnico di Bari 1048 Via Orabona 4, 70125, Bari, ITALY 1049 Phone: +39 0805963913 1051 Email: gennaro.boggia@poliba.it 1053 Luigi Alfredo Grieco 1054 DEI, Dep. of Electrical and Information Engineering 1055 Politecnico di Bari 1056 Via Orabona 4, 70125, Bari, ITALY 1057 Phone: +39 0805963911 1059 Email: alfredo.grieco@poliba.it