idnits 2.17.1 draft-richardson-6tisch--security-6top-05.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 -- The document date (November 20, 2015) is 3079 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6550' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-nmrg-autonomic-network-definitions' is defined on line 913, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 956, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-zerotouch' is defined on line 960, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-08 == Outdated reference: A later version (-07) exists of draft-thubert-6lo-rfc6775-update-reqs-06 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-03) exists of draft-thubert-6lowpan-backbone-router-00 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-04 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Richardson 3 Internet-Draft SSW 4 Intended status: Informational November 20, 2015 5 Expires: May 23, 2016 7 6tisch secure join using 6top 8 draft-richardson-6tisch--security-6top-05 10 Abstract 12 This document details a security architecture that permits a new 13 6tisch compliant node to join an 802.15.4e network. The process 14 bootstraps the new node authenticating the node to the network, and 15 the network to the node, and configuring the new node with the 16 required 6tisch schedule. Any resemblance to WirelessHART/IEC62591 17 is entirely intentional. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 23 "OPTIONAL" in this document are to be interpreted as described in RFC 24 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 23, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology and Roles . . . . . . . . . . . . . . . . . . . . 4 63 3. Architectural requirements of join protocol . . . . . . . . . 6 64 3.1. Entities involves in the join processions . . . . . . . . 6 65 3.2. Join Protocol deliverables . . . . . . . . . . . . . . . 6 66 3.3. Join Protocol connection setup . . . . . . . . . . . . . 7 67 3.4. End to End considerations for Join Protocol . . . . . . . 8 68 3.4.1. Security Considerations: alternatives to source 69 routes . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.5. Join node discovery mechanism . . . . . . . . . . . . . . 10 71 3.5.1. prefixes to use for join traffic . . . . . . . . . . 11 72 4. security requirements . . . . . . . . . . . . . . . . . . . . 12 73 4.1. threat model . . . . . . . . . . . . . . . . . . . . . . 12 74 4.1.1. threats to the joining node . . . . . . . . . . . . . 12 75 4.1.2. threats to the resources of the network . . . . . . . 13 76 4.1.3. threats to other joining nodes . . . . . . . . . . . 13 77 4.2. implementation cost . . . . . . . . . . . . . . . . . . . 14 78 4.3. denial of service . . . . . . . . . . . . . . . . . . . . 14 79 5. protocol requirements/constraints/assumptions . . . . . . . . 14 80 5.1. inline/offline . . . . . . . . . . . . . . . . . . . . . 14 81 6. time sequence diagram . . . . . . . . . . . . . . . . . . . . 14 82 6.1. explanation of each step . . . . . . . . . . . . . . . . 15 83 6.1.1. step (1): enhanced beacon . . . . . . . . . . . . . . 16 84 6.1.2. step (1B): send router solicitation . . . . . . . . . 16 85 6.1.3. step (1C): receive router advertisement . . . . . . . 16 86 6.1.4. step (2): certificate cache load . . . . . . . . . . 16 87 6.1.5. step (3): receive certificate cache . . . . . . . . . 16 88 6.1.6. step (4): join request . . . . . . . . . . . . . . . 17 89 6.1.7. step (5): NS duplicate address request (DAR) . . . . 17 90 6.1.8. step (7): 6LBR informs JCE of new node . . . . . . . 17 91 6.1.9. step (8): JCE informs/acks to 6LBR of new node . . . 17 92 6.1.10. step (9): NS duplicate address confirmation (DAC) . . 17 93 6.1.11. step (10): JCE initiates connection to joining node . 17 94 6.1.12. step (11): Join Assistant forwards packet to joining 95 node . . . . . . . . . . . . . . . . . . . . . . . . 17 97 6.1.13. step (12): Joining node replies . . . . . . . . . . . 17 98 6.1.14. step (13): Join Assistant forwards reply to JCE . . . 17 99 6.2. size of each packet . . . . . . . . . . . . . . . . . . . 18 100 7. resulting security properties obtained from this process . . 18 101 8. deployment scenarios underlying protocol requirements . . . . 18 102 9. device identification . . . . . . . . . . . . . . . . . . . . 18 103 9.1. PCE/Proxy vs Node identification . . . . . . . . . . . . 18 104 9.2. Time source authentication / time validation . . . . . . 18 105 9.3. description of certificate contents . . . . . . . . . . . 18 106 9.4. privacy aspects . . . . . . . . . . . . . . . . . . . . . 18 107 10. slotframes to be used during join . . . . . . . . . . . . . . 19 108 11. configuration aspects . . . . . . . . . . . . . . . . . . . . 19 109 12. authorization aspects . . . . . . . . . . . . . . . . . . . . 19 110 12.1. how to determine a proxy/PCE from a end node . . . . . . 19 111 12.2. security considerations . . . . . . . . . . . . . . . . 19 112 13. security architecture . . . . . . . . . . . . . . . . . . . . 19 113 14. Posture Maintenance . . . . . . . . . . . . . . . . . . . . . 19 114 15. Security Considerations . . . . . . . . . . . . . . . . . . . 19 115 16. Other Related Protocols . . . . . . . . . . . . . . . . . . . 19 116 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 117 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 118 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 119 19.1. Normative references . . . . . . . . . . . . . . . . . . 19 120 19.2. Informative references . . . . . . . . . . . . . . . . . 21 121 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 123 1. Introduction 125 A challenging part with constructing an LLN with nodes from multiple 126 vendors is providing enough security context to each node such that 127 the network communication can form and remain secure. Most LLNs are 128 small and have no operator interfaces at all, and even if they have 129 debug interfaces (such as JTAG) with personnel trained to use that, 130 doing any kind of interaction involving electrical connections in a 131 dirty environment such as a factory or refinery is hopeless. 133 It is necessary to have a way to introduce new nodes into a 6tisch 134 network that does not involve any direct manipulation of the nodes 135 themselves. This act has been called "zero-touch" provisioning, and 136 it does not occur by chance, but requires coordination between the 137 manufacturer of the node, the service operator running the LLN, and 138 the installers actually taking the devices out of the shipping boxes. 140 1.1. Assumptions 142 For the process described in this document to work, some assumptions 143 about available infrastructure are made. These are perhaps more than 144 assumptions, but rather architectural requirements; the exact 145 operation of said infrastructure to be defined in a subsequent 146 document. 148 In the diagrams and text that follows entities are named (and defined 149 in the terminology section). Unless otherwise stated these are 150 roles, not actual machines/systems. The roles are seperated by 151 network protocols in order that they roles can be performed by 152 different systems, not because they have to be. Different 153 deployments will have different scaling requirements for those 154 entities. Smaller deployments might co-located many roles together 155 into a single ruggedized platform, while other deployments might 156 operate all of the roles on distinct, multiply-redundant server 157 classes located in a fully equipped datacentre. 159 2. Terminology and Roles 161 Most terminology should be taken from [I-D.ietf-6tisch-architecture] 162 and from [I-D.ietf-6tisch-6top-interface] and 163 [I-D.wang-6tisch-6top-sublayer]. As well, many terms are taken from 164 [RFC6775]. 166 The following roles/things are defined: 168 PCE the Path Computation Engine. This entity reaches 169 out to each of the nodes in the LLN, and 170 configures an appropriate schedule using 6top. 172 Authz Server/ACE the Authorization Server. This offloads 173 calculation of access control lists and other 174 access control decisions for constrainted nodes. 175 See [I-D.seitz-ace-problem-description] 177 6top the 6top protocol is defined abstractly in 178 [I-D.ietf-6tisch-6top-interface] and mapped to 179 run over CoAP in [I-D.ietf-6tisch-coap]. The 180 6top protocol is defined primarily to provision 181 the 6TiSCH schedule; this document proposes to 182 extend it for also provisioning of layer-2 183 security parameters. 185 JCE the Join Coordination Entity. This acronym is 186 chosen to parallel the PCE. 188 joining node The newly unboxed constrained node that needs to 189 join a network. 191 join protocol the protocol which secures initial communication 192 between the joining node and the JCE 194 join assistant A constrained node near the joining node that 195 will act as it's first 6LR, and will relay 196 traffic to/from the joining node. 198 unique join key a key shared between a newly joining node, and 199 the JCE. This key supports smaller installations 200 for which asymmetric methods are considered too 201 large 203 production network A 802.15.4e network whose encryption/ 204 authentication keys are determined by some 205 algorithm/protocol. There may have network-wide 206 group keys, or per-link keys. 208 production network key A L2-key known by all authorized nodes, used 209 for multicast messages 211 per-peer L2 key a key that results from an exchange (such as MLE) 212 that creates a pair-wise L2 key which is known 213 only to the two nodes involved, 214 [I-D.piro-6tisch-security-issues] calls this a 215 LinkKey 217 The following terms are used in this document and come from other 218 documents: 220 DevID [IEEE.802.1AR] defines the secure DEVice 221 IDentifier as a device identifier that is 222 cryptographically bound to the device and is 223 composed of the Secure Device Identifier Secret 224 and the Secure Device Identifier Credential. 226 IDevID The Initial secure DEVice IDentifier (IDevID) is 227 the Device Identifier which was installed on the 228 device by the manufacturer. 230 LDevID A Locally significant secure DEVice IDentifiers 231 (LDevIDs) is a Secure Device Identifier 232 credential that is unique in the local 233 administrative domain in which the device is 234 used. The LDevID is usually a new certificate 235 provisioned by some local means, such as the 6top 236 mechanism defined in this document. 238 CoAP The CoAP protocol, defined in [RFC7252] is an 239 HTTP-like resource access protocol. CoAP runs 240 over UDP. 242 DTLS The datagram version of TLS, defined in 243 [RFC6347], and which can be used to secure CoAP 244 in the same way that TLS secures HTTP. 246 ARO [RFC6775]defines a number of new Neighbor 247 Discovery options including the Address 248 Registration Option 250 DAR/DAC [RFC6775]defines the Duplicate Address Request 251 and Duplicate Address Confirmation options to 252 turn the multicasted Duplicate Address Detection 253 protocol into a client/server process 255 EARO [I-D.thubert-6lo-rfc6775-update-reqs]extends the 256 ARO option to include some additional fields 257 necessary to distinguish duplicate addresses from 258 nodes that have moved networks when there are 259 mulitple LLNs linked over a backbone. 261 3. Architectural requirements of join protocol 263 3.1. Entities involves in the join processions 265 The following actors are involved: there is a new joining node. It 266 is (radio) adjacent to the join assistant. The join assistant is 267 part of the production network, and participates in one or more 268 DODAGs, such that it is reachable from the 6LBR, and the JCE. 270 3.2. Join Protocol deliverables 272 This section works from the ultimate goal, and goes backwards to 273 prerequisite actions. (Section 6 presents the protocol from 274 beginning to end order) 276 The ultimate goal of the join protocol is to provide a new node with 277 a locally significant security credentials so that it is able to take 278 part in the network directly. The credentials may vary by 279 deployment. They can be one of: 281 1) a network-wide shared symmetric key (this is the production 282 network key, or MasterKey) 284 2) a locally significant (one-level only) 802.11AR type LDevID 285 certificate (which allows it to negotiate a pair-wise keys) 287 One of these two items is delivered by JCE to the joining node using 288 the 6top protocol. That is, the JCE provisions using a secure 289 "northbound" interface. The authentication of this interface the 290 subject of the Join Protocol as explained below. 292 The above credential are used for authentication to generate per-peer 293 L2, using a key exchange protocol. The choice of key exchange 294 protocol, and what kind of link and multicast keying needs to be done 295 is also provisioned by the JCE. There are a number of options for 296 doing this, such as: 298 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] 299 (IMPORTANT, a good option. Uses certificates from common CA) 301 2) work in 802.15.9 (uses certificates from common CA) 303 3) Security Framework and Key Management Protocol Requirements for 304 6TiSCH [I-D.ohba-6tisch-security] (this document provides the 305 phase 0 required, using the network-wide shared key) 307 4) Layer-2 security aspects for the IEEE 802.15.4e MAC 308 [I-D.piro-6tisch-security-issues]: the MasterKey is used to 309 derive per-peer L2 keys 311 Per-peer L2 keying is critical when doing peer-2-peer schedule 312 negotiation over 15.4 Information Elements. Therefore a network-wide 313 layer-2 key is inappropriate for the self-organizing networks, and a 314 protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys. 316 For networks where there is a PCE present, it will do all schedule 317 computation. As a result the only trust relationship necessary is 318 between the individual node and the PCE, and it MAY be acceptable to 319 have a network-wide L2 key derived in ways such as 320 [I-D.piro-6tisch-security-issues] describes in section ?. The trust 321 relationship between the PCE and the joining node flows from the 322 LDevID certificate loaded by the JCE. When the PCE and JCE are co- 323 located, the existing 6top/DTLS security association could be reused. 325 3.3. Join Protocol connection setup 327 The intermediate level goal of the join protocol is to enable a Join 328 Coordination Entity (JCE) to reach out to the new node, and install 329 the credentials detailed above. The JCE must authenticate itself to 330 the joining node so that the joining node will know that it has 331 joined the correct network, and the joining node must authenticate 332 itself to the JCE so that the JCE will know that this node belongs in 333 the network. This two way authentication occurs in the 6top/CoAP/ 334 DTLS session that is established between the JCE and the joining 335 node. 337 [I-D.ietf-6tisch-6top-interface] presents a way to interface to a 338 6top information model (defined in YANG). [I-D.ietf-6tisch-coap] 339 explains how to access that information model using CoAP. This 340 information model will include security attributes for the network. 341 The JCE would therefore reach out to the joining node and simply 342 provision appropriate security properties into the joining node, much 343 like the PCE will provision schedules. 345 This 6top-based secure join protocol has defined a push model for 346 security provisioning by the JCE. This has been done for three 347 reasons: 349 1) 6tisch nodes already have to have a 6top CoAP server for schedule 350 provising 352 2) this permits the JCE to manage how many nodes are trying to join 353 at the same time, and limit how much bandwidth/energy is used for 354 the join operation, and also for the JCE to prioritize the join 355 order for nodes. 357 3) making the JCE initiate the DTLS connection significantly 358 simplies the certificate chains that must be exchanged as the 359 most constrained side (the joining node) provides it's 360 credentials first, and lets the less constrained JCE figure out 361 what kind of certificate chain will be required to authenticate 362 the JCE to the joining node. In EAP-TLS/802.1x situations, the 363 TLS channel is created in the opposite direction, and it would 364 have to complete in a tentative way, and then further 365 authorization occur in-band. 367 3.4. End to End considerations for Join Protocol 369 In order for a 6top/DTLS/CoAP connection to occur between the JCE and 370 the joining node, there needs to be end-to-end IPv6 connectivity 371 between those two entities. The joining node will not participate in 372 the route-over RPL mesh, but rather will be seen by the network as 373 being a 6lowpan only leaf-node. 375 The joining node sends traffic to the join assistant, which forwards 376 it using the normal RPL DODAG upwards routes, and which will reach 377 the JCE using regular routing. 379 The challenge is getting connectivity from the JCE to the joining 380 node, as the DODAG and 6LBR root will have no information about this 381 node. Instead, the JCE will use loose-source routes (in the RH2) to 382 address packets first to the Join Assistant, which will then forward 383 to the joining node. This has an interaction with the (strict) 384 source routes used by non-storing DODAGs which would be used by the 385 6LBR to reach the Join Assistant. 387 There are some alternatives to having full end to end connectivity 388 which are discussed in the security considerations section. 390 3.4.1. Security Considerations: alternatives to source routes 392 This goes into security-considerations section 394 A number of alternatives were considered for creating end to end 395 connectivity between the joining node and the JCE, but were rejected. 397 (1) IPIP tunnel between Join Assistant and JCE 399 (2) using straight RPL routing: the Join Assistant sends a DAO 401 (3) using a separate RPL DODAG for join traffic 403 (4) establishing a specific multi-hop 6tisch track for join traffic 404 for each Join Assistant 406 3.4.1.1. IPIP tunnel 408 This mechanism requires 40 bytes overhead per packet, and may require 409 specific state to be created on the Join Assistant, or may open the 410 network up to a resource exhaustion by malicious join nodes. 412 This mechanism was rejected on due to byte count, because it would 413 require code only needed for join, and because doing it securely may 414 require a per-tunnel state to be maintained on the join assistant. 416 3.4.1.2. join existing DODAG 418 This mechanism is to just have the new node join the DODAG as a leaf 419 node. The join assistant would issue a DAO for the new node. If a 420 storing DODAG was used, this would directly cost state in all parent 421 nodes of the Join Assistant, subjecting the lower-rank parts of the 422 network to significant denial of service attacks. 424 On a non-storing DODAG the situation is significantly better: no 425 state is created by the presence of the leaf node except in the 6LBR, 426 where available resources may be higher. 428 This mechanism was rejected in favour of the loose source routed 429 option as this the loose source routed option always works even for 430 storing DODAGs, and is otherwise exactly equivalent in terms of 431 network bandwidth cost. 433 3.4.1.3. join a DODOAG for joining 435 One option to deal with the problem of resource consumption in the 436 storing DODAG case is to use a second DODAG. 438 This mechanism was rejected as it consumes resources in all nodes for 439 the second DODAG, and many implementations support on a single DODAG. 440 While storing DODAGs have a lighter network impact than non-storing 441 ones (due to the lack of source routes), the PCE can control how much 442 network bandwidth can be wasted by malicious join nodes using the 443 regular 6tisch mechanisms, and this can be tuned. A second DODAG 444 would be a sunk cost with no tuning possible. 446 3.4.1.4. create 6tisch track to form mesh-under 448 This mechanism would use 6tisch tracks so that traffic from the JCE 449 would be switched from 6LBR to join node. A track would be required 450 to each join assistant. This is an optimized form of source routing. 452 This mechanism was not rejected, rather it was observed that it may 453 be applied to any mechanism that uses source routing, and is an 454 optimization; it has a certain cost in the form of intermediary node 455 state, but that this state is not created by a malicious join node, 456 rather it is created by the PCE. 458 3.5. Join node discovery mechanism 460 Continuing to work backwards, in order the JCE reach out to provision 461 the Joining Node, it needs to know that the new node is present. 462 This is done by taking advantage of the 6lowPAN Address Resolution 463 Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address 464 to also be sent up to the 6LBR for duplicate detection using the DAR/ 465 DAC mechanism. The 6LBR simply needs to tell the JCE about this. A 466 new protocol may be required for the situation where the JCE, PCE and 467 6LBR are not co-located; it may be that this protocol could be simply 468 a DAR in some encapsulation. The details of this are currently out 469 of scope for the architecture, as they affect interoperability 470 between different vendors of JCE/6LBR/PCE rather than 471 interoperability between the assistance/offload infrastructure, and 472 the contrained nodes. Future work may specify this part. 474 In addition to needing to know the joining devices address from the 475 DAR/NS, the JCE also needs to know the joining node's IDevID. This 476 is to determine if the node should even get any attention. At this 477 point, the IDevID can be forged, it will be authenticated during the 478 setup of the 6top control protocol in the DTLS certificate exchange. 479 If the serialNumber attribute of the IDevID is less than 64 bits, 480 then it is possible that it could be placed into the EUI-64 option of 481 the ARO, or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs] 482 EARO. The JCE needs to know the joining node's serialNumber to know 483 if this is device that it should even attempt to provision; and if 484 so, it may need to retrieve an appropriate certificate chain (see 485 [I-D.richardson-6tisch-idevid-cert]) from the Factory in order for 486 the JCE to prove it is the legitimate owner of the joining node. 488 Neither 802.1AR nor [RFC5280] provide any structure for the 489 serialNumber, except that they are positive integers of up-to 20 490 octets in size (numbers up to 2^160). This specification would 491 require that the serialNumber encoded in the IDevID be the same as 492 the EUI-64 used by the device. Some consideration needs to be given 493 as to whether there are privacy considerations to doing this: any 494 observer that can see the join traffic, can also see the source MAC 495 address of the node as well. 497 Prior to being able to announce itself in a NS, the joining node 498 needs to find the Join Network. This is done by listening to the 499 extended beacon which are broadcast in designated slotframes by the 500 network. These are the same extended beacons which are used by the 501 production network. The extended beacons are transmitted in "MIC- 502 only" (authentication only) mode. Nodes with the production network 503 key can authenticate the beacons. The newly joining node can not 504 authenticate the beacons, but it can read and process them, and can 505 use this as a way to synchronize to the network. During the Alpha 506 period, the joining node can send a Router Soliticiation, and receive 507 an appropriate Router Advertisement giving the Joining Node a prefix 508 and default route to which to send the join traffic (the ND DAD 509 mentioned above). 511 It may be possible to eliminate a message exchange if space for a 512 Router Advertisement can be found as part of the Join Network 513 Extended Beacon. This Enhanced Beacon would be distinct to the Join 514 Network, and would be encrypted with the well-known Join Network key. 516 3.5.1. prefixes to use for join traffic 518 What prefix would the joining node for communication? There are 519 three options: 521 (1) just use link-local addresses (this may require that some 522 traffic between 6LBR and JCE be IPIP tunneled) 524 (2) use a prefix specifically for join traffic (may be easier with a 525 join-only DODAG) 527 (3) use the same prefix as the rest of the traffic (may require more 528 complex ACLs, and leaks information to attackers) 530 It would be ideal to use link-local addresses, but they need to be 531 scoped to the radio interface of the join assistant which can 532 actually reach the joining node. It may be that this can be made to 533 work, but otherwise, the join assistant will have a ULA for each 534 radio on which it expects join traffic. 536 4. security requirements 538 4.1. threat model 540 There are three kinds of threats that a join process must deal with: 541 threats to the joining node, threats to the resources of the network, 542 and threats to other joining nodes. 544 4.1.1. threats to the joining node 546 A node may be taken out of it's box by a malicious entity and powered 547 on. This could happen during shipping, while being stored in a 548 warehouse. The device may be subject to physical theft, or the goal 549 of the attacker may be to turn the device into a trojan horse of some 550 kind. Physical protection of the device is out of scope for this 551 document; this document will henceforth assume that the device is 552 sealed in some tamper-evident way and this document deals with 553 attacks over the network. 555 An attacker may attempt to convince the joining node that it is the 556 legitimate Production Network; this is done by putting up a 557 legitimate looking Join Network, and following the protocol as 558 described in this document. The Joining Node can not know if it has 559 the corrrect Production Network until steps 11-13, when it attempts 560 to validate the ClientCertificate provided by the JCE. 562 When the joining node determines that this is the incorrect network, 563 it must remember the PANID of the network that it has attempted to 564 join, and then look for another network to try. It SHOULD have some 565 limit as the number of times it will try before going back to sleep, 566 or shutting down, and it SHOULD take care not to consume more than 567 some specified percentage of any battery it might have. 569 Should a malicious production network be present at the same time/ 570 place as the legitimate production network, a the malicious agent 571 could intercept and replay various packets from the proper join 572 network, but ultimately this either results in a jamming-like denial 573 of service, and/or the the ClientCertificate will not validate. 575 It is a legitimate situation for there to be multiple possible join 576 networks, and the joining node may have to try each one before it 577 finds the network that it the right one for it. The incorrect, but 578 non-malicious networks will not attempt the 6top provisioning step, 579 and SHOULD return a negative result in steps 8/9, refusing the node's 580 NS. Those incorrect networks will be recognize that the node does 581 not belong to them, because they will be able to see the Joining 582 Node's IDevID in the ARO of step 4. 584 4.1.2. threats to the resources of the network 586 The production network has two important resources that may be 587 attacked by malicious Joining nodes: 1) energy/bandwidth, 2) memory 588 for routing entries. 590 A malicious joining node could send many NS messages to the Join 591 Assistant (from many made up addresses), which would send many NS/DAR 592 messages to the 6LBR, and this would consume bandwidth, and therefore 593 energy from the members of the mesh along the path to the 6LBR. This 594 can be mitigated by limited the total bandwidth available for 595 joining. 597 A malicious joining node could send many NS messages, and if the 6LBR 598 agreed to accept the new node (by IDevID), then the Join Assistant 599 would MAY inject routing information into mesh for the Joining node. 600 Non-storing DODAGs store are routing information in the DODAG Root 601 (probably the 6LBR), which is generally not a constrained node. 602 Storing DODAGs store routing entries at all nodes up to the DODAG, 603 and those are constrained nodes. Using a separate Join DODAG, and 604 having that DODAG be non-storing will reduce any impact on 605 intermediate nodes, but it does cause resources to be used for the 606 second DODAG, and it may have a code impact if the nodes otherwise 607 would not implement non-storing RPL. 609 4.1.3. threats to other joining nodes 611 A joining node (or the nodes of a malicious network, co-located near 612 the legitimate production network) may mount attacks on legitimate 613 nodes which have not yet joined. 615 The malicious nodes may attempt to perform 6top operations against 616 the joining node to keep it from being able to respond to the 617 legitimate 6top session from the legitimate JCE. During the Join 618 phase, the Joining node MUST have all other resources and protocols 619 turned off, even if they would normally be accessible as read-only 620 unauthenticated CoAP resources. 622 Malicious nodes could use the Join Network to mount various DTLS 623 based attacks against the joining node, such as sending very long 624 certificate chains to validate. One might think to limit the length 625 of such chains, but as shown in [I-D.richardson-6tisch-idevid-cert] 626 the chain may as a long as the supplier chain, plus may include 627 additional certificates due to resales of plants/equipment/etc. 628 Validating from a trusted certificate down to the specific 629 certificate which proves ownership would eliminate random certificate 630 chains, but the attacker could just feed the joining node legitimate 631 chains that it observed (and replayed) from the legitimate JCE. This 632 does no good; the Joining node finds that the DTLS connection is 633 invalid, but it may significantly run batteries down. 635 4.2. implementation cost 637 (storage of security material, computational cost) 639 4.3. denial of service 641 other communication impacts of security protocol mechanics 643 5. protocol requirements/constraints/assumptions 645 5.1. inline/offline 647 dependencies on centralized or external functionality, inline and 648 offline 650 6. time sequence diagram 651 +-----+ +------+ +----------+ +-----------+ 652 | | | | | JOIN | | Joining | 653 | JCE | | 6LBR | | Assistant| | Node | 654 +-----+ +------+ | (proxy) | | | 655 | | +----------+ +-----------+ 656 | | | | 657 | | |-------BEACON (1)---------->| 658 | | | | 659 | | |<----Router Solicitation----| 660 | | |---Router Advertisement---->| 661 | | | | 662 | | |<------CERT CACHE-----------| 663 | | | LOAD (2) | 664 | | | | 665 | | | | 666 | | |-------CERT CACHE---------->| 667 | | | RESPONSE (multiple) | 668 | | | (packets) | 669 | | | | 670 | | |<-----JOIN REQUEST (4) -----| 671 | | | (NS w/ARO ) | 672 | | | | 673 | |<---NS (DAR) (5)-----| | 674 |<--??(6)-| | | 675 | | | | 676 |--??(7)->| | | 677 | | | | 678 | |----NS (DAC)-(8)---->| | 679 | | +------+ | | 680 | || | 682 | | ACK +------+ | | 683 | | |-------JOIN ACK (9)-------->| 684 | | | | 685 | | | | 686 |================(10)==========>|----------6top----(11)----->| 687 | | | DTLS | 688 |<===============(13)===========|<---------CoAP----(12)------| 689 | | | (many packets) | 691 Figure 1: Message sequence for JOIN message 693 6.1. explanation of each step 694 6.1.1. step (1): enhanced beacon 696 A 6tisch join/synchronization beacon is broadcast periodically, and 697 is authenticated with a symmetric "beacon key": 699 well known JOIN key, such "JOIN6TISCH" 701 another key, provisioned in advance (OOB) 703 a shared symmetric key derived from public part of top level 704 certificate (a closely held "secret") 706 The purpose of this key is not to provide a high level of assurance, 707 but rather to filter out 6tisch traffic from another random traffic 708 that may be sharing the same radio frequencies. 710 These beacons are used for JOIN purpose only, and are not related to 711 the Enhanced Beacons used in the rest of 6tisch. 713 6.1.2. step (1B): send router solicitation 715 The joining node sends a router solicitation during the Aloha period 716 of the beacon. 718 6.1.3. step (1C): receive router advertisement 720 The joining node receives a router advertisement from the Join 721 Assistant. It could include 6CO options to help compress packets, 722 and should contain a prefix appropriate for join traffic. 724 6.1.4. step (2): certificate cache load 726 At step 10, the JCE will need to present a certificate chain anchored 727 at a trusted CA built into the joining node. It has been speculated 728 that a significant amount of traffic could be avoided at step (10) if 729 the common parts of the certificate chains could be cached in the 730 join assistant. 732 This optional step involves the joining node asking for certificates 733 from the join assistant. 735 6.1.5. step (3): receive certificate cache 737 the proxy neighbour sends requested cached certificates to the 738 joining node 740 6.1.6. step (4): join request 742 A regular Neighbour Solicitation is sent. This should contain an ARO 743 (or EARO) option containing the Joining Nodes' IDevID. The ARO/EARO 744 will be proxied by the Join Assistant as part of normal 6LowPAN 745 processing for leaf nodes (non-RPL nodes) upwards to the 6LBR 747 6.1.7. step (5): NS duplicate address request (DAR) 749 6.1.8. step (7): 6LBR informs JCE of new node 751 6.1.9. step (8): JCE informs/acks to 6LBR of new node 753 The JCE could reply in the negative, and this would cause a DAC 754 failure, TBD 756 6.1.10. step (9): NS duplicate address confirmation (DAC) 758 6.1.11. step (10): JCE initiates connection to joining node 760 The double lines indicate that an IPIP tunnel operation may be 761 required. If a straight DAO or seperate Join DODAG is used, then 762 this is just a straight forwarding root to leaf node forwarding 763 operation, and involves either using source routes (non-storing), or 764 just forwarding for storing DODAGs. 766 A specific bandwidth allocation would be used for this join traffic 768 The production network encryption keys would be used for the join 769 traffic 771 6.1.12. step (11): Join Assistant forwards packet to joining node 773 The JOIN Assistant would forward traffic to the Joining Node. 774 Recognizing that this traffic the JOIN Network, the JOIN Assistant 775 would use the JOIN Network key. 777 6.1.13. step (12): Joining node replies 779 The joining node replies, using JOIN Network key. 781 6.1.14. step (13): Join Assistant forwards reply to JCE 783 The JOIN Assistant, recognizing that the traffic came from the JOIN 784 Network, restricts the destination that can be reached to the the JCE 785 only. It can do this in a stateless way, and it does NOT need to 786 track the traffic at (10) to open pinhole, etc. 788 Recognizing that the traffic came from the JOIN Network, the traffic 789 would be placed into a bandwidth allocation (track?) that allows such 790 traffic. 792 6.2. size of each packet 794 and number of frames needed to contain it. 796 7. resulting security properties obtained from this process 798 An end to end IPv6 CoAP/DTLS connection is created between the JCE 799 and the Joining Node. This connection carries 6top commands to 800 update security parameters. This results in either deployment of a 801 single-level, locally relevant certificate (LDevID), or deployment of 802 a network-wide symmetric "Master Key" 804 8. deployment scenarios underlying protocol requirements 806 9. device identification 808 The JCE authenticates the joining node using a certificate chain 809 provided inline during the DTLS negotiation. The certificate chain 810 is rooted in a vendor certificate that the JCE must have preloaded, 811 and is a statement as to the node's 802.1AR IDevID. The joining node 812 authenticates the 814 9.1. PCE/Proxy vs Node identification 816 9.2. Time source authentication / time validation 818 Note: RPL Root authentication is a chartered item 820 9.3. description of certificate contents 822 9.4. privacy aspects 824 The EUI-64 of the Joining node is transmitted using a Well Known 825 layer-2 encryption key. Within the ARO/EARO of the Neighbour 826 Solicitation is an OUI, which may be identical to the EUI-64 of the 827 Joining node, or it might be an unrelated IDevID. 829 An eavesdropper can therefore learn something about the manufacturer 830 of every device as it joins. 832 10. slotframes to be used during join 834 how is this communicated in the (extended) beacon. 836 11. configuration aspects 838 (allocation of slotframes after join, network statistics, 839 neighboetc.) 841 12. authorization aspects 843 lifecycle (key management, trust management) 845 12.1. how to determine a proxy/PCE from a end node 847 12.2. security considerations 849 what prevents a node from transmitting when it is not their turn 850 (part one: jamming) 852 can a node successfully communicate with a peer at a time when not 853 supposed to, may be tied to link layer security, or will it be 854 policed by receiver? 856 13. security architecture 858 security architecture and fit of e.g. join protocol and provisioning 859 into this 861 14. Posture Maintenance 863 (SACM related work) 865 15. Security Considerations 867 16. Other Related Protocols 869 17. IANA Considerations 871 18. Acknowledgements 873 19. References 875 19.1. Normative references 877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", BCP 14, RFC 2119, March 1997. 880 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 881 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 882 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 883 Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/ 884 RFC6550, March 2012, 885 . 887 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 888 Bormann, "Neighbor Discovery Optimization for IPv6 over 889 Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 890 6775, DOI 10.17487/RFC6775, November 2012, 891 . 893 [IEEE.802.1AR] 894 Institute of Electrical and Electronics Engineers, "Secure 895 Device Identity", IEEE 802.1AR, 2009, 896 . 898 [I-D.ietf-6tisch-coap] 899 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 900 Interaction using CoAP", draft-ietf-6tisch-coap-03 (work 901 in progress), March 2015. 903 [I-D.ietf-6tisch-6top-interface] 904 Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer 905 (6top) Interface", draft-ietf-6tisch-6top-interface-04 906 (work in progress), July 2015. 908 [I-D.ietf-6tisch-architecture] 909 Thubert, P., "An Architecture for IPv6 over the TSCH mode 910 of IEEE 802.15.4", draft-ietf-6tisch-architecture-08 (work 911 in progress), May 2015. 913 [I-D.irtf-nmrg-autonomic-network-definitions] 914 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 915 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 916 Networking - Definitions and Design Goals", draft-irtf- 917 nmrg-autonomic-network-definitions-07 (work in progress), 918 March 2015. 920 [I-D.seitz-ace-problem-description] 921 Seitz, L. and G. Selander, "Problem Description for 922 Authorization in Constrained Environments", draft-seitz- 923 ace-problem-description-03 (work in progress), March 2015. 925 [I-D.richardson-6tisch-idevid-cert] 926 Richardson, M., "X509.v3 certificate extension for 927 authorization of device ownership", draft-richardson- 928 6tisch-idevid-cert-01 (work in progress), March 2015. 930 [I-D.wang-6tisch-6top-sublayer] 931 Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer 932 (6top)", draft-wang-6tisch-6top-sublayer-04 (work in 933 progress), November 2015. 935 [I-D.thubert-6lo-rfc6775-update-reqs] 936 Thubert, P. and P. Stok, "Requirements for an update to 937 6LoWPAN ND", draft-thubert-6lo-rfc6775-update-reqs-06 938 (work in progress), January 2015. 940 19.2. Informative references 942 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 943 Housley, R., and W. Polk, "Internet X.509 Public Key 944 Infrastructure Certificate and Certificate Revocation List 945 (CRL) Profile", RFC 5280, May 2008. 947 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 948 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 949 RFC7252, June 2014, 950 . 952 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 953 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 954 January 2012, . 956 [I-D.thubert-6lowpan-backbone-router] 957 Thubert, P., "LoWPAN Backbone Router", draft-thubert- 958 6lowpan-backbone-router-00 (work in progress), March 2008. 960 [I-D.ietf-netconf-zerotouch] 961 Watsen, K., Clarke, J., and M. Abrahamsson, "Zero Touch 962 Provisioning for NETCONF Call Home", draft-ietf-netconf- 963 zerotouch-04 (work in progress), October 2015. 965 [I-D.kelsey-intarea-mesh-link-establishment] 966 Kelsey, R., "Mesh Link Establishment", draft-kelsey- 967 intarea-mesh-link-establishment-06 (work in progress), May 968 2014. 970 [I-D.ohba-6tisch-security] 971 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and 972 A. Yegin, "Security Framework and Key Management Protocol 973 Requirements for 6TiSCH", draft-ohba-6tisch-security-01 974 (work in progress), March 2014. 976 [I-D.piro-6tisch-security-issues] 977 Piro, G., Boggia, G., and L. Grieco, "Layer-2 security 978 aspects for the IEEE 802.15.4e MAC", draft-piro-6tisch- 979 security-issues-03 (work in progress), December 2014. 981 Author's Address 983 Michael C. Richardson 984 Sandelman Software Works 985 470 Dawson Avenue 986 Ottawa, ON K1Z 5V7 987 CA 989 Email: mcr+ietf@sandelman.ca 990 URI: http://www.sandelman.ca/