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