idnits 2.17.1 draft-struik-6tisch-security-considerations-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 9, 2015) is 3396 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6tisch-terminology' is defined on line 691, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-02 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6tisch R. Struik 3 Internet-Draft Struik Security Consultancy 4 Intended status: Informational January 9, 2015 5 Expires: July 13, 2015 7 6TiSCH Security Architectural Considerations 8 draft-struik-6tisch-security-considerations-01 10 Abstract 12 This document describes 6TiSCH security architectural elements with 13 high level requirements and the security framework that are relevant 14 for the design of the 6TiSCH security solution. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on July 13, 2015. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Join Protocol Behavior . . . . . . . . . . . . . . . . . . . 2 51 1.1. MAC Behavior . . . . . . . . . . . . . . . . . . . . . . 2 52 1.2. MAC Security Considerations . . . . . . . . . . . . . . . 4 53 1.3. Join Protocol Behavior . . . . . . . . . . . . . . . . . 7 54 1.3.1. Device Enrollment Phases . . . . . . . . . . . . . . 7 55 1.3.2. Join protocol description . . . . . . . . . . . . . . 9 56 1.3.3. Remarks . . . . . . . . . . . . . . . . . . . . . . . 12 57 1.4. Routing Behavior . . . . . . . . . . . . . . . . . . . . 15 58 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 59 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 60 4. Normative References . . . . . . . . . . . . . . . . . . . . 15 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 63 1. Join Protocol Behavior 65 1.1. MAC Behavior 67 1. The joining node has to transgress from the so-called "embryonic 68 stage", where it does not have shared keying material with any 69 network nodes yet, to the stage where it has shared keying 70 material with the security manager of the network (who hands out 71 a network wide key, amongst other things). In many cases, the 72 security manager will be the PAN coordinator. 74 2. Initially, the joining node listens to an enhanced beacon sent by 75 its neighbor node. If this beacon is secured, it can still 76 extract the visible portion of the enhanced beacon frame (which 77 includes all frame fields before these were secured by the 78 neighbor node if the frame was authenticated and which includes 79 only the header fields, including potential header information 80 elements, otherwise). With 802.15.4-2011, the passive scan 81 procedure supports this (see 5.1.2.1.2). In either case, the 82 joining node stores the PAN Descriptor. Note that it cannot rely 83 on the authenticity of the PAN Descriptor, since the beacon frame 84 is either not secured, or it was secured and the joining node did 85 not have a shared key. Either way, it has to accept the PAN 86 Descriptor "on face value". 88 3. The neighbor node, if it operates securely, normally does not 89 accept incoming frames from the joining node, since these would 90 not be properly secured with the correct keying material. 91 However, the 802.15.4 specification allows one exception to this: 92 it also accepts incoming messages from specifically identified 93 devices that have diplomatic immunity (have so-called "exempt 94 status"). This mechanism can be used to facilitate communication 95 between a joining node and a neighbor node till they have 96 established shared keying material (whereby the joining node can 97 emerge out of its initial embryonic stage). This can be done as 98 follows: 100 * The neighbor node can temporarily give the joining node 101 "exempt status", e.g., after failed incoming security 102 processing (thereby, allowing subsequent unsecured data frames 103 from this joining node to be accepted *from this specific 104 device*). It can also populate the table with exempt devices 105 via other means. 107 * The higher layer can switch on/off this "exempt status" 108 facility for specific joining nodes based on local criteria 109 (one joining node at the time; device open for enrollment of 110 devices or not, pre-populated table, etc.) 112 * The higher layer of the neighbor node should ensure that this 113 facility is only used for MAC data frames that correspond to 114 initial join messages. 116 * The higher layer can use this "exempt status" flag for 117 outgoing messages back to the joining node (where this 118 indicates "please send message unsecured" (since message to 119 newbee joining node with diplomatic immunity status). 121 4. Once the joining node and the neighbor node have established a 122 shared key, the neighbor node can lift the diplomatic immunity 123 status of the joining node (by removing the "exempt status" flag 124 corresponding to this device), after which it may only accept 125 incoming messages from the joining node if these are properly 126 secured. Conversely, the joining node can now update its 127 security policy settings, after which it may only accept properly 128 secured messages received from the neighbor node. Note that from 129 that moment on, the communications between the joining node and 130 the neighbor node can all be authenticated, including time 131 corrections that are very important for proper operation of TSCH 132 (where, e.g., neighbor node is time "clock tower" for joining 133 node). 135 5. Conceptually, the use of the "exempt flag" could be considered as 136 a mechanism for forming a temporary two-node "join network" 137 (consisting of the joining node and its neighbor node), in which 138 join-related messages are allowed to flow unsecurely. This does 139 not mean, however, that these nodes operate in a separate PAN, 140 though, since incoming frame processing relies on filtering on a 141 single destination PAN Identifier (see 802.15.4-2011, 5.1.6.2), 142 which implies that the neighbor node can only be part of a single 143 PAN (802.15.4-2011 does not know the concept of "multiple PAN 144 instances"). This also implies that there is no mechanism within 145 802.15.4 to designate frames for "join" purposes or other special 146 uses (as Wireless HART seems to do with enhanced beacon frames). 147 Of course, there are ways to still artificially realize this, 148 e.g., based on context information (overloading semantics of 149 schedules) or based on yet-to-be-defined information elements (so 150 as to make these act as frame "sub-types"), should one wish to 151 emulate this behavior. Emulating any of this would require 152 changes to 802.15.4 security processing. Currently, there does 153 not seem to be a need for this additional complexity.) 155 1.2. MAC Security Considerations 157 1. With 802.15.4-2011, incoming security processing requires access 158 to device-specific information of the originating device (stored 159 on the recipient device in the so-called device descriptor 160 table). This includes the extended address of the originating 161 device, the "lowest" unseen frame counter for that device, and 162 its "exempt status". Successful incoming security processing of 163 a secured frame results in a state change of this device-specific 164 information (since this updates, e.g., the frame counter). 166 2. Successful incoming security processing of a secured or unsecured 167 frame may result in other state changes as well if only because 168 the device simply "acts" on the received frame or, e.g., due to 169 side effects of the successful receipt hereof. Examples of such 170 side effects include actions triggered by information elements 171 contained in the received frame, such as time corrections to the 172 local clock (which are very important for proper operation of 173 TSCH). 175 3. 802.15.4-2011 uses the AEAD scheme CCM for frame security, where 176 the nonce is derived from the frame counter and other 177 information. The security of this scheme (or other nonce-based 178 authenticated encryption scheme) is void if nonces are ever 179 reused with the same key. We give an example illustrating how 180 nonce reuse breaks confidentiality: one can derive from two 181 ciphertexts the xor of the corresponding plaintext (or the 182 segment with the size of the shorter ciphertext). From this 183 information and side information on the plaintext (e.g., 184 redundancy), one can often recover both plaintexts (with 185 virtually no remaining ambiguity). 187 4. Since successful incoming security processing induces a state 188 change, it is imperative that all cryptographic keys used are, 189 indeed, real keys. In particular, this implies that one shall 190 never use 802.15.4 with "default" keys (fake keys with an easy to 191 guess, low-entropy value). 193 5. If a device wants to communicate with a corresponding party with 194 which it does not share cryptographic keying material yet (e.g., 195 because it is a joining node in embryonic stage), it should send 196 unsecured frames and *not* frames *obscured* (via security 197 through obscurity techniques) using "fake" keys, if only because 198 of avoidance of undesirable side effects: if a recipient accepts 199 an unsecured frame (e.g, because the originator has "exempt 200 status"), this does *not* trigger a state change of security- 201 relevant parameters, whereas if a recipient accepts an obscured 202 frame (secured using a "fake" key), this *does* trigger a state 203 change of security-relevant parameters. 205 6. TSCH security with 802.15.4e-2012 relies on nonces that are 206 derived from the absolute slot number (ASN), rather than from the 207 frame counter in the device descriptor. Successul processing of 208 a secured incoming frame depends on both originator and recipient 209 of the frame having synchronized "world views" of the ASN entry. 210 The ASN is also used for communication purposes, since indicates 211 scheduling information. This "mixed" use (both for communication 212 and security) is somewhat problematic, since changes to this 213 parameter for either use has spill-over effects on the other use: 214 any changes to the ASN as a communication parameter now might 215 have side effects on security-critical parameters that could, 216 worst case, entirely break security; conversely, any changes to 217 the ASN as a security parameter, e.g., resulting from its 218 inadverent use with a compromised key (or, equivalently, a "fake" 219 key), could result in unreliability of this parameter for 220 indicating scheduling information. Impact of ASN manipulation on 221 security may include reuse of nonces (resulting in compromise of 222 the AEAD cipher's properties), denial-of-service attacks on 223 sender or recipient (e.g., due to putting the ASN entry "out-of- 224 sync" on either end), or frame counter reuse (since 225 802.15.4e-2012 does not inspect the frame counter in the device 226 descriptor, but solely relies on the ASN entry). Thus, ASN 227 entries are very fragile and their use should happen with extreme 228 care. 230 7. As already mentioned, ASN anomalies may seriously impact 231 security. If any device's ASN state is out-of-synch with other 232 devices, this may result in that device not being able to 233 communicate in the network any more. With network-wide keys, the 234 remedy may include a combination of rekeying all devices (a 235 costly proposition) and resetting ASN entries of the impacted 236 device. 238 8. The security provisions in 802.15.4-2011 and 802.15.4e-2012 leave 239 some room for potential Denial of Service (DoS) attacks. We only 240 discuss "accidental" DoS attacks for now, which we define as 241 those triggered without active involvement of an adversarial 242 network element (active DoS attacks are considered separately). 244 * If a device acts on an incoming frame that is 245 cryptographically secured, it has assurances that this frame 246 originated from a device with access to the key. Here, 247 processing a frame with a key provides a mechanism for network 248 segregation, since proper incoming security processing (and 249 assuming non-compromised locally stored security-relevant 250 material and processes) allows one to draw conclusions as to 251 whether originator and recipient belong to the same "group" 252 (the key-sharing group). This propery holds if the incoming 253 frame has an authenticity tag; in some cases, this may also 254 hold if the frame was only encrypted, but not authenticated. 255 This "network segregation" property holds independent of 256 whether the key was actually a real key (cryptographic key); 257 the number of groups created depends on the number of these 258 group keys (perhaps, more properly termed "group identifiers" 259 if of no cryptographic use) used. 261 * A joining node must make its decision to join the network 262 based on information derived from processing an enhanced 263 beacon. Since it is in embryonic stage, it has to take this 264 information at face value (no matter whether this beacon was 265 cryptographically secured or not). In theory, this may give 266 rise to dilemmas of choice, i.e., how is a joining node to 267 pick which beacon to act upon? As already said, one could 268 realize network segregation using a "default" key, whereby the 269 joining node and the beaconing device would be able to check 270 membership of the same loosely defined group (this is the 271 mechanism Wireless HART uses). However, as mentioned before, 272 this could potentially adversely impact 802.15.4-2011 and 273 802.15.4e-2012 security. Even if one discards security 274 concerns, this only establishes membership of a very crudely 275 defined group (e.g., if one uses as "default" key the fixed 276 value "6tisch-default-join", this would have any joining node 277 accept any 6tisch-beacon). The same filtering mechanism could 278 also, without any possible security side effects, be realized 279 by partitioning the "language of well-formed frames" and, 280 e.g., filtering enhanced beacons on the data object "6tisch- 281 default-join" (e.g., when including this tag as a Header 282 Information Element with the beacon). If one does not use 283 such explicit "tags", one could conceivable also accept beacon 284 frames that implement an alien protocol, rather than 285 802.15.4e-2012. It is, however, quite unlikely that a random 286 alien frame will pass incoming frame filtering, since 802.15.4 287 incoming frame processing checks for well-formedness. 288 Checking some built-in redundancy of well-formed frames 289 thereby most likely filters out virtually all unwanted alien 290 frame types. Such filtering could, e.g., include a "language 291 check" as to fixed fields in information elements. For 292 enhanced beacon frames for TSCH, e.g., the header fields of 293 the synchronization IE, timeslot IE, and header IE contained 294 herein have fixed 2-octet values 0x1a06, 0x1c01, and 0x1d01, 295 respectively, thereby providing up to 48 bits of redundancy. 296 This provides similar filtering functionality as the explicit 297 "6tisch-default-join" tag mentioned before, but without the 298 need to introduce an explicit tag or to communicate this 299 separately over the air. 301 It should be emphasized (again) that none of the mechanisms above 302 protects against active attacks. 304 1.3. Join Protocol Behavior 306 1.3.1. Device Enrollment Phases 308 The join protocol consists of three phases, viz. 310 1. Device Authentication: The joining node and proxy network node 311 authenticate each other and establish a shared key, so as to 312 ensure on-going authenticated communications. This may involve a 313 server as a third party. 315 2. Authorization: The proxy network node decides on whether/how to 316 authorize a joining node (if denied, this may result in loss of 317 bandwidth). Authorization decisions may involve other nodes in 318 the network. 320 3. Configuration/Parameterization: The proxy network node 321 distributes configuration information to the joined node, such as 322 scheduling information, IP address assignment information, and 323 network policies. This may originate from other network devices, 324 for which it acts as proxy. This step may also include 325 distribution of information from the joining node to the network 326 node and other nodes in the network and, more generally, 327 synchronization of information between these entities. 329 The device enrollment process is depicted in Figure Figure 1, where 330 it is assumed that devices have access to certificates and where 331 entities have access to the root CA keys of their communicating 332 parties (initial set-up requirement). Under these assumptions, the 333 authentication step of the device enrollment process does not require 334 online involvement of a third party. Mutual authentication is 335 performed between the joining node and the proxy using their 336 certificates, which also results in a shared key between these two 337 entities. The proxy assists the joining node in mutual 338 authentication with the server, which also results in a shared (end- 339 to-end) key between those two entities. The server may arbitrage 340 network authorization of the joining node (where the proxy will deny 341 bandwidth if authorization is not successful) and may distribute 342 network-specific configuration parameters (including network-wide 343 keys) to the joining node. In its turn, the joining node may provide 344 distribute/synchronize information (including, e.g., network 345 statistics) to the server node. 347 The server functionality is a role and may be implemented with one 348 device (centralized) or with multiple entities (distributed). In 349 either case, mutual authentication is established with each physical 350 server entity with which a role is implemented. Note that in the 351 above description, the proxy does not solely act as a relay node. 352 For more detailed rationale, see the relevant detailed descriptions 353 further in this document. This also provides some insight into what 354 happens in case the initial set-up requirements are not met or some 355 other out-of-sync behavior occurs and suggest some optimization in 356 case server-related information is already available with the proxy 357 node (caching). 359 When a device rejoins the network in the same authorization domain, 360 the authorization step could be omitted if the server distributes the 361 authorization state for the device to the proxys when the device 362 initially joined the network. However, this generally still requires 363 the exchange of updated configuration information, e.g., related to 364 time schedules and bandwidth allocation. 366 {joining node} {neighbor} {server, etc.} 367 +---------+ +---------+ +---------+ 368 | Node | | Proxy | +--| CA |e.g., certificate 369 | A | | B | | +---------+ issuance 370 +---------+ +---------+ | +---------+ 371 | | +--|Authoriz.|e.g., membership 372 |<----Beaconing------| | +---------+ test 373 | | | +---------+ 374 |<--Authentication-->| +--| Routing |e.g., IP address 375 | |<--Authorization-->| +---------+ assignment 376 |<-------------------| | +---------+ 377 | | +--| Gateway |e.g., backbone, 378 |------------------->| | +---------+ cloud 379 | |<--Configuration-->| +---------+ 380 |<-------------------| +--|Bandwidth|e.g., PCE 381 +---------+ schedule 382 . . . 383 . . . 385 Figure 1: Network joining, with only authorization by third party 387 1.3.2. Join protocol description 389 NOTE: the description below considers the scenario where devices have 390 credentials on board and where the neighbor does not simply act as a 391 relay node only. Other scenarios will be considered in future 392 versions of this draft. 394 1. Upon hearing the enhanced beacon, the joining node stores the 395 PAN descriptor. 397 2. The joining node uses local criteria, including information 398 contained in the PAN desciptor, to determine whether it wishes 399 to join the network. 401 3. The joining node sends the first join protocol message to the 402 neighbor node. This message corresponds to one or more 403 unsecured MAC data frames. This message includes the joining 404 node's key contribution and credentials. 406 4. The neighbor node processes the incoming join message from the 407 joining node and, depending on local criteria (including a check 408 that this is a join message), grants the joining node temporary 409 diplomatic immunity status ("exempt stauts") from a MAC 410 perspective (if not granted, this simply results in a rejected 411 incoming frame at the MAC layer). 413 5. The neighbor node performs some checks on the incoming message. 414 If successful, it sends a first return join protocol message to 415 the joining node. This message corresponds to one or more 416 unsecured MAC data frames. This message includes the neighbor 417 node's key contribution and credentials. It may also include 418 the server's cached first return join protocol message info. At 419 this point, the neighbor node is capable of deriving the shared 420 key with the joining node based on inputs received and locally 421 maintained status information. 423 6. The joining node performs some checks on the incoming message 424 (including that it received this message from the neighbor node 425 and that this is a join message). If succesful, it derives a 426 shared key with the neighbor node and may derive a shared key 427 with the server (it may also postpone the latter till required 428 ["lazy evaluation"]). 430 7. The joining node sends a second join protocol message (a key 431 confirmation message) to the neighbor node and may include some 432 other information (so-called piggy-backed info). The piggy- 433 backed information includes configuration information to be 434 passed from the joining node to the neighbor node. This message 435 corresponds to one or more unsecured MAC data frames. 437 8. The joining node sends a similar second join protocol message 438 (another key confirmation message, including piggy-backed 439 information) to the server. The piggy-backed information 440 includes configuration information to be passed from the joining 441 node to the server that allows the server to check the joining 442 node's true credentials and some network-relevant parameters 443 (including the ASN number and the joining node's local schedule 444 maintained with the neighbor node). This message corresponds to 445 one or more unsecured MAC data frames. This message may be 446 combined with the message sent to the neighor node, since it 447 travels along the same initial communication path. 449 9. The neighbor node checks the received second join protocol 450 message (the key confirmation message and received piggy-backed 451 info), including that this message originated from the same 452 device as the previous join protocol message and that this 453 message is a join message. If successful, it clears the "exempt 454 status" attribute of the joining node in the DeviceDescriptor 455 (thereby, lifting diplomatic immunity status for the joining 456 device) and adds the {data key, joining node} pair to its 457 KeyDescriptor list. It also stores policy-related attributes 458 for this key. It may update some additional state, based on the 459 piggy-backed info received from the joining device. The 460 clearing of the "exempt status" flag means that it will only 461 accept incoming secured frames from the joining node from that 462 moment onwards. 464 10. The server checks the received second join protocol message (key 465 confirmation message and received piggy-backed info). If 466 successful, it adds the {data key, joining node} pair to its 467 locally maintained list of end-to-end keying material and 468 includes policy-related attributes for this key. It sends its 469 own second return join protocol message (another key 470 confirmation message, including piggy-backed configuration 471 information) to the joining node. This is actually sent to the 472 neighbor node it received the first join protocol message from, 473 who in turn forwards this to the joining node (here, the 474 neighbor node acts in storing mode and knows the local network 475 topology the server may not know (yet)). NOTE: this requires 476 the neighbor node to remember some information pertaining to the 477 joining node (mainly, the {data key, joining node} pair of the 478 KeyDescriptor and the local communication schedule with the 479 joining node). This may include an explicit notification to the 480 neighbor node that the joining node is authorized to join the 481 network. If so, this authorization part of this message is 482 secured, using end-to-end security between the server and the 483 neighbor node. 485 11. The neighbor node checks the authorization-related info, if 486 indeed contained in this message (if denied, it may clear the 487 joining node related info from its tables). If successful, it 488 forwards this information along with its own second return join 489 protocol message (key confirmation message and piggy-backed 490 info) to the joining node. Obviously, this can be done 491 separately as well, but travels over the same (single hop) 492 communication path. 494 12. The joining node checks the received second join protocol 495 message (the key confirmation and piggy-backed info) from its 496 neighbor node. If successful, it adds the {data key, neighbor 497 node} pair to its KeyDescriptor list. It also stores policy- 498 related attributes for this key. If not successful, it clears 499 its local table with info pertaining to the neighbor node. 501 13. The joining node checks the received second join protocol 502 message (the key confirmation and piggy-backed info) from the 503 server. If successful, it adds the {data key, server node} pair 504 to its locally maintained list of end-to-end keying material and 505 includes policy-related attributes for this. It may also update 506 its local state, based on information contained in the piggy- 507 backed info received from the server. Updates of local state 508 may be subject to additional local criteria, such as consistency 509 of status information obtained from neighbor node and server 510 node (e.g., pertaining to the ASN field, PAN identifier, or 511 scheduling information). This may give rise to triggered 512 alerts. If not successful, it clears its local table with info 513 pertaining to the server node. Depending on local criteria, it 514 may clear the table with info pertaining to the neighbor node. 516 1.3.3. Remarks 518 1. The join protocol above can be optimized in various ways, 519 including first handling mutual authentication of local 520 communication channels, prior to engaging in non-local 521 communications so as to reduce time latencies in case of failure 522 conditions. This is realized by having the neighbor node 523 authenticate itself to the joining node before initiating non- 524 local communications from the joining node to the server node 525 along the communication path via the neighbor node (rather than 526 at the end of this non-local communications). Since 10-hop 527 communications may take roughly 2.5 minutes on a TSCH network 528 and local communication time latencies take roughly 15 seconds, 529 this could present a significant time saving (and reduced 530 requirement on keeping state and energy consumption on the 531 joining device). 533 2. The join protocol above takes only one non-local communication 534 between the neighbor node and the server node. This assumes 535 that the neighbor node is able to cache security-related 536 information from the server. Since this includes certificate- 537 related information of the server node (which may require more 538 than one classical 802.15.4 MAC frame to carry), this may 539 present significant communication time latency savings. 540 Obviously, an additional long-haul round trip may be required 541 should this cached information be stale (keeping this 542 information in sync is a responsibility of the neighbor node). 543 With caching, this turns the join protocol described above into 544 the most efficient possible, in terms of communication time 545 latencies involved. At the same time, this protocol has very 546 strong security properties, unmatched by legacy protocols [...]. 548 3. The join protocol above assumes authentication of the joining 549 node to the neighbor node, before non-local traffic takes place. 550 This assists in thwarting denial-of-service attacks on "das 551 Hinterland" of the neighbor node triggered by joining nodes with 552 improper credentials (unparsable certs). While this check is an 553 authentication check only and *not* a fine-grained authorization 554 check, this could be complemented by additional local "sanity 555 checks" on the neighbor node (device white listing, etc.), thus 556 allowing extensibility to more fine-grained authorization 557 filtering mechanisms. (Further details are outside scope of 558 this document, but may be described later.) 560 4. The join protocol above assumes authentication of the neighbor 561 node to the joining node (i.e., the neighbor node is not simply 562 a relay node). This potentially assists in thwarting denial of 563 service attacks on the joining node itself, primarily since it 564 may allow the joining node to conclude it joined an improper 565 network based on local communications only (if the neighbor node 566 presented an unparsable cert or did not properly authenticate), 567 rather than having to await a nonlocal verdict via the server 568 that may take a long time to materialize. Here, again, more 569 fine-grained authorization checks may be realized in scenarios 570 where the joining node has more local intelligence to draw from. 571 (Again, further details are outside scope of this document for 572 now.) 574 5. The join protocol above includes mutual authentication between 575 the joining node and the neighbor node and establishment of a 576 shared "link key" (to use 802.15.4 parlance) between these two 577 devices. This may be useful in case one wishes to trigger time 578 synchronization between the joining node and the neighbor node 579 contingent on frames secured using this pair-wise key only. 580 This would strengthen TSCH security compared to that provided by 581 the current 802.15.4e-2012 specification (which allows time 582 synchronization to be also triggered by frames secured using a 583 network-wide key, thereby opening the network to attacks by a 584 single random compromised node, rather than a specific 585 compromised node [the "clock tower" node] only.) 587 6. The join protocol above can also be "weakened", e.g., by 588 removing authentication of the neighbor node to the joining node 589 or vice-versa. As already said, this might open the protocol to 590 wide-spread denial of service attacks on the network (in case 591 the neighbor node simply forwards any joining node traffic, 592 without inspection) or denial of service attacks on the joining 593 node (in case the neighbor node is a bogus node or a node of an 594 alien network). In some settings, though, practical trade-offs 595 may favor such a "weakened" approach, e.g., if one wishes to 596 "sprinkle" in sufficiently many neighbor nodes to guarantee 597 connectivity to the server during initial deployment. If so, 598 one should still have a fall-back strategy in place should 599 denial of service attacks become a reality. (NOTE: These 600 "weakened" versions will be analyzed in more detail in a later 601 version of this draft.) 603 7. The join protocol above does not impose requirements on the 604 security of the communication path between the neighbor node and 605 the server, except that "it should be there" (i.e., there is 606 connectivity) although there may be additional requirements to 607 counter, e.g., denial of service attacks on communications 608 between neighbor node and server. (An exception here is if the 609 server returns authorization-related information to the neighbor 610 node [which we required to be secured], but which we will ignore 611 for now.) Such minimization of dependencies between the join 612 protocol and the routing protocol may be beneficial for use 613 cases where one wishes to facilitate "random" installation 614 process flows. Obviously, once a node is part of the network, 615 it should be able to route packets (but that is not part of the 616 join protocol itself, but next-stage phase). 618 8. The join protocol above tries to embrace a design where the 619 order of joining would be mostly orthogonal to routing protocol 620 topology considerations, if it all possible. In particular, it 621 is aimed to take into account that not all installations follow 622 the pattern where one has an operational network and where all 623 non-local communications during the join protocol not of the 624 type {joining node - neighbor router} are within the operational 625 network (i.e., one would like to facilitate scenarios other than 626 a tree-like structure, where network is built from tree root up 627 onwards [this is highly relevant in building control settings]). 629 9. The join protocol above exchanges piggy-backed information 630 between joining node, neighbor node, and server. This 631 conceptually would allow very agressive implementations of the 632 routing protocol, where one intertwines routing and join 633 processes, by including some of the routing-related attributes 634 as opaque strings in the piggy-backed fields. It should be 635 noted that the join protocol already supports the routing tree 636 of the existing network and the "new tree branch" {joining node 637 - neighbor node}, so all "upwards routes" to the pre-existing 638 tree roots are inherited right away. The only routes that may 639 need defining are those towards the newbee joining node. For 640 reliability reasons, this does require the joining node to have 641 successfully concluded the join protocol first. As such, there 642 seems to be no technical reason to intertwine these protocols: 643 one should simply perform routing-related operations only 644 *after* the join protocol ran its full course. 646 10. The join protocol above allows the neighbor node to influence 647 with which server the joining node communicates, thus allowing a 648 distributed implementation of the server. 650 11. The join protocol above assumes that the server arbitrages the 651 correct value of supposedly common network parameters, such as 652 the PAN identifier and ASN field. Here, one should note that 653 the neighbor node can indicate, e.g., any PAN identifier and any 654 ASN entry to its liking in its beacon, which does not 655 necessarily correspond to the "common world view" hereof by the 656 server. 658 12. The join protocol above could in theory result in a node joining 659 the network only locally (i.e., forming a two-node network with 660 the neighbor node only), without the server or any other nodes 661 becoming aware of this. This scenario could arrise if the 662 joining node is unaware of some server-related context 663 information and if the neighbor node simply usurps the server 664 role itself. The impact of this "hidden node" type scenario 665 depends on higher-layer, end-to-end design details. From a MAC 666 perspective, this could simply mean that the two-node {joining 667 node, neighbor node} network is conceptually represented by this 668 neighbor node, where the internal structure of this two-node 669 network remains hidden for other nodes. 671 1.4. Routing Behavior 673 TBD. 675 2. IANA Considerations 677 There is no IANA action required for this document. 679 3. Acknowledgments 681 TBD. Kris Pister provided the filtering example details for enhanced 682 beacon frames. Yoshi Ohba, Subir Das, Giuseppe Piro, Pascal Thubert, 683 and Kris Pister kindly provided feeback on previous versions of this 684 document. 686 4. Normative References 688 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 689 Requirement Levels", BCP 14, RFC 2119, March 1997. 691 [I-D.ietf-6tisch-terminology] 692 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 693 "Terminology in IPv6 over the TSCH mode of IEEE 694 802.15.4e", draft-ietf-6tisch-terminology-02 (work in 695 progress), July 2014. 697 Author's Address 699 Rene Struik 700 Struik Security Consultancy 702 Email: rstruik.ext@gmail.com