idnits 2.17.1 draft-richardson-6tisch--security-6top-04.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 11, 2014) is 3453 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6550' is defined on line 875, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-nmrg-autonomic-network-definitions' is defined on line 906, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 946, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-zerotouch' is defined on line 951, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-6tisch-coap-01 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-6top-interface-01 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-01 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-00 == Outdated reference: A later version (-03) exists of draft-seitz-ace-problem-description-01 == Outdated reference: A later version (-01) exists of draft-richardson-6tisch-idevid-cert-00 == Outdated reference: A later version (-04) exists of draft-wang-6tisch-6top-sublayer-00 == Outdated reference: A later version (-07) exists of draft-thubert-6lo-rfc6775-update-reqs-01 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-00 == Outdated reference: A later version (-06) exists of draft-kelsey-intarea-mesh-link-establishment-05 == Outdated reference: A later version (-03) exists of draft-piro-6tisch-security-issues-02 Summary: 0 errors (**), 0 flaws (~~), 16 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 11, 2014 5 Expires: May 15, 2015 7 6tisch secure join using 6top 8 draft-richardson-6tisch--security-6top-04 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 15, 2015. 43 Copyright Notice 45 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . 12 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 . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . 16 89 6.1.7. step (5): NS duplicate address request (DAR) . . . . 16 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 . . . . . . . . . . . . . . 18 108 11. configuration aspects . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . . . . 21 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 join network A 802.15.4e network whose encryption and 199 authentication key is "JOIN6TISCH". 201 unique join key a key shared between a newly joining node, and 202 the JCE 204 production network A 802.15.4e network whose encryption/ 205 authentication keys are determined by some 206 algorithm. There may have network-wide group 207 keys, or per-link keys. 209 production network key A shared L2-key known by all authorized 210 nodes. This key can be used to derive other 211 keys. 213 per-peer L2 key a key that results from an exchange (such as MLE) 214 that creates a pair-wise L2 key which is known 215 only to the two nodes involved, 216 [I-D.piro-6tisch-security-issues] calls this a 217 LinkKey 219 The following terms are used in this document and come from other 220 documents: 222 DevID [IEEE.802.1AR] defines the secure DEVice 223 IDentifier as a device identifier that is 224 cryptographically bound to the device and is 225 composed of the Secure Device Identifier Secret 226 and the Secure Device Identifier Credential. 228 IDevID The Initial secure DEVice IDentifier (IDevID) is 229 the Device Identifier which was installed on the 230 device by the manufacturer. 232 LDevID A Locally significant secure DEVice IDentifiers 233 (LDevIDs) is a Secure Device Identifier 234 credential that is unique in the local 235 administrative domain in which the device is 236 used. The LDevID is usually a new certificate 237 provisioned by some local means, such as the 6top 238 mechanism defined in this document. 240 CoAP The CoAP protocol, defined in [RFC7252] is an 241 HTTP-like resource access protocol. CoAP runs 242 over UDP. 244 DTLS The datagram version of TLS, defined in 245 [RFC6347], and which can be used to secure CoAP 246 in the same way that TLS secures HTTP. 248 ARO [RFC6775]defines a number of new Neighbor 249 Discovery options including the Address 250 Registration Option 252 DAR/DAC [RFC6775]defines the Duplicate Address Request 253 and Duplicate Address Confirmation options to 254 turn the multicasted Duplicate Address Detection 255 protocol into a client/server process 257 EARO [I-D.thubert-6lo-rfc6775-update-reqs]extends the 258 ARO option to include some additional fields 259 necessary to distinguish duplicate addresses from 260 nodes that have moved networks when there are 261 mulitple LLNs linked over a backbone. 263 3. Architectural requirements of join protocol 265 3.1. Entities involves in the join processions 267 The following actors are involved: there is a new joining node. It 268 is (radio) adjacent to the join assistant. The join assistant is 269 part of the production network, and participates in one or more 270 DODAGs, such that it is reachable from the 6LBR, and the JCE. 272 3.2. Join Protocol deliverables 274 This section works from the ultimate goal, and goes backwards to 275 prerequisite actions. (Section 6 presents the protocol from 276 beginning to end order) 278 The ultimate goal of the join protocol is to provide a new node with 279 a locally significant security credentials that it is able to take 280 part in the network directly. The credentials may vary by 281 deployment. They can be one of: 283 1) a network-wide shared symmetric key (this is the production 284 network key, or MasterKey) 286 2) a locally significant (one-level only) 802.11AR type LDevID 287 certificate (which allows it to negotiate a pair-wise keys) 289 One of these two items is delivered by JCE to the joining node using 290 the 6top protocol. That is, the JCE provisions using a secure 291 "northbound" interface. The authentication of this interface the 292 subject of the Join Protocol as explained below. 294 The above credential are used for authentication to generate per-peer 295 L2, using a key exchange protocol. The choice of key exchange 296 protocol, and what kind of link and multicast keying needs to be done 297 is also provisioned by the JCE. There are a number of options for 298 doing this, such as: 300 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] 301 (IMPORTANT, a good option. Uses certificates from common CA) 303 2) work in 802.15.9 (uses certificates from common CA) 305 3) Security Framework and Key Management Protocol Requirements for 306 6TiSCH [I-D.ohba-6tisch-security] (this document provides the 307 phase 0 required, using the network-wide shared key) 309 4) Layer-2 security aspects for the IEEE 802.15.4e MAC 310 [I-D.piro-6tisch-security-issues]: the MasterKey is used to 311 derive per-peer L2 keys 313 Per-peer L2 keying is critical when doing peer-2-peer schedule 314 negotiation over 15.4 Information Elements. Therefore a network-wide 315 layer-2 key is inappropriate for the self-organizing networks, and a 316 protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys. 318 For networks where there is a PCE present and it will do all schedule 319 computation, then the only trust relationship necessary is between 320 the individual node and the PCE, and it MAY be acceptable to have a 321 network-wide L2 key derived in ways such as 322 [I-D.piro-6tisch-security-issues] describes in section ?. The trust 323 relationship between the PCE and the joining node flows from the 324 LDevID certificate loaded by the JCE. When the PCE and JCE are co- 325 located, the existing 6top/DTLS security association could be reused. 327 3.3. Join Protocol connection setup 329 The intermediate level goal of the join protocol is to enable a Join 330 Coordination Entity (JCE) to reach out to the new node, and install 331 the credentials detailed above. The JCE must authenticate itself to 332 the joining node so that the joining node will know that it has 333 joined the correct network, and the joining node must authenticate 334 itself to the JCE so that the JCE will know that this node belongs in 335 the network. This two way authentication occurs in the 6top/CoAP/ 336 DTLS session that is established between the JCE and the joining 337 node. 339 [I-D.ietf-6tisch-6top-interface] presents a way to interface to a 340 6top information model (defined in YANG). [I-D.ietf-6tisch-coap] 341 explains how to access that information model using CoAP. This 342 information model will include security attributes for the network. 343 The JCE would therefore reach out to the joining node and simply 344 provision appropriate security properties into the joining node, much 345 like the PCE will provision schedules. 347 This 6top-based secure join protocol has defined a push model for 348 security provisioning by the JCE. This has been done for three 349 reasons: 351 1) 6tisch nodes already have to have a 6top CoAP server for schedule 352 provising 354 2) this permits the JCE to manage how many nodes are trying to join 355 at the same time, and limit how much bandwidth/energy is used for 356 the join operation, and also for the JCE to prioritize the join 357 order for nodes. 359 3) making the JCE initiate the DTLS connection significantly 360 simplies the certificate chains that must be exchanged as the 361 most constrained side (the joining node) provides it's 362 credentials first, and lets the less constrained JCE figure out 363 what kind of certificate chain will be required to authenticate 364 the JCE to the joining node. In EAP-TLS/802.1x situations, the 365 TLS channel is created in the opposite direction, and it would 366 have to complete in a tentative way, and then further 367 authorization occur in-band. 369 3.4. End to End considerations for Join Protocol 371 In order for a 6top/DTLS/CoAP connection to occur between the JCE and 372 the joining node, there needs to be end-to-end IPv6 connectivity 373 between those two entities. The joining node will not participate in 374 the route-over RPL mesh, but rather will be seen by the network as 375 being a 6lowpan only leaf-node. 377 The joining node sends traffic to the join assistant, which forwards 378 it using the normal RPL DODAG upwards routes, and which will reach 379 the JCE using regular routing. 381 The challenge is getting connectivity from the JCE to the joining 382 node, as the DODAG will have no information about this node. 383 Instead, the JCE will use loose-source routes to address packets 384 first to the Join Assistant, which will then forward to the joining 385 node. This has an interaction with the (strict) source routes used 386 by non-storing DODAGs which would be used by the 6LBR to reach the 387 Join Assistant. 389 There are some alternatives to having full end to end connectivity 390 which are discussed in the security considerations section. 392 3.4.1. Security Considerations: alternatives to source routes 394 This goes into security-considerations section 396 A number of alternatives were considered for creating end to end 397 connectivity between the joining node and the JCE, but were rejected. 399 (1) IPIP tunnel between Join Assistant and JCE 401 (2) using straight RPL routing: the Join Assistant sends a DAO 403 (3) using a separate RPL DODAG for join traffic 405 (4) establishing a specific multi-hop 6tisch track for join traffic 406 for each Join Assistant 408 3.4.1.1. IPIP tunnel 410 This mechanism requires 40 bytes overhead per packet, and may require 411 specific state to be created on the Join Assistant, or may open the 412 network up to a resource exhaustion by malicious join nodes. 414 This mechanism was rejected on due to byte count, because it would 415 require code only needed for join, and because doing it securely may 416 require a per-tunnel state to be maintained on the join assistant. 418 3.4.1.2. join existing DODAG 420 This mechanism is to just have the new node join the DODAG as a leaf 421 node. The join assistant would issue a DAO for the new node. If a 422 storing DODAG was used, this would directly cost state in all parent 423 nodes of the Join Assistant, subjecting the lower-rank parts of the 424 network to significant denial of service attacks. 426 On a non-storing DODAG the situation is significantly better: no 427 state is created by the presence of the leaf node except in the 6LBR, 428 where available resources may be higher. 430 This mechanism was rejected in favour of the loose source routed 431 option as this the loose source routed option always works even for 432 storing DODAGs, and is otherwise exactly equivalent in terms of 433 network bandwidth cost. 435 3.4.1.3. join a DODOAG for joining 437 One option to deal with the problem of resource consumption in the 438 storing DODAG case is to use a second DODAG. 440 This mechanism was rejected as it consumes resources in all nodes for 441 the second DODAG, and many implementations support on a single DODAG. 442 While storing DODAGs have a lighter network impact than non-storing 443 ones (due to the lack of source routes), the PCE can control how much 444 network bandwidth can be wasted by malicious join nodes using the 445 regular 6tisch mechanisms, and this can be tuned. A second DODAG 446 would be a sunk cost with no tuning possible. 448 3.4.1.4. create 6tisch track to form mesh-under 450 This mechanism would use 6tisch tracks so that traffic from the JCE 451 would be switched from 6LBR to join node. A track would be required 452 to each join assistant. This is an optimized form of source routing. 454 This mechanism was not rejected, rather it was observed that it may 455 be applied to any mechanism that uses source routing, and is an 456 optimization; it has a certain cost in the form of intermediary node 457 state, but that this state is not created by a malicious join node, 458 rather it is created by the PCE. 460 3.5. Join node discovery mechanism 461 Continuing to work backwards, in order the JCE reach out to provision 462 the Joining Node, it needs to know that the new node is present. 463 This is done by taking advantage of the 6lowPAN Address Resolution 464 Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address 465 to also be sent up to the 6LBR for duplicate detection using the DAR/ 466 DAC mechanism. The 6LBR simply needs to tell the JCE about this. A 467 new protocol may be required for the situation where the JCE, PCE and 468 6LBR are not co-located; it may be that this protocol could be simply 469 a DAR in some encapsulation. The details of this are currently out 470 of scope for the architecture, as they affect interoperability 471 between different vendors of JCE/6LBR/PCE rather than 472 interoperability between the assistance/offload infrastructure, and 473 the contrained nodes. Future work may specify this part. 475 In addition to needing to know the joining devices address from the 476 DAR/NS, the JCE also needs to know the joining node's IDevID. This 477 is to determine if the node should even get any attention. At this 478 point, the IDevID can be forged, it will be authenticated during the 479 setup of the 6top control protocol in the DTLS certificate exchange. 480 If the serialNumber attribute of the IDevID is less than 64 bits, 481 then it is possible that it could be placed into the EUI-64 option of 482 the ARO, or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs] 483 EARO. The JCE needs to know the joining node's serialNumber to know 484 if this is device that it should even attempt to provision; and if 485 so, it may need to retrieve an appropriate certificate chain (see 486 [I-D.richardson-6tisch-idevid-cert]) from the Factory in order for 487 the JCE to prove it is the legitimate owner of the joining node. 489 Neither 802.1AR nor [RFC5280] provide any structure for the 490 serialNumber, except that they are positive integers of up-to 20 491 octets in size (numbers up to 2^160). This specification would 492 require that the serialNumber encoded in the IDevID be the same as 493 the EUI-64 used by the device. Some consideration needs to be given 494 as to whether there are privacy considerations to doing this: any 495 observer that can see the join traffic, can also see the source MAC 496 address of the node as well. 498 Prior to being able to announce itself in a NS, the joining node 499 needs to find the Join Network. This is done by listening to an 500 extended beacon which are broadcast in designated slotframes by Join 501 Assistants. The Extended Beacon provides a way for the Joining Node 502 to synchronize itself to the overall timeslot schedule and provides 503 an Aloha period in which the Joining Node can send a Router 504 Soliticiation, and receive an appropriate Router Advertisement giving 505 the Joining Node a prefix and default route to which to send join 506 traffic. 508 It may be possible to eliminate a message exchange if space for a 509 Router Advertisement can be found as part of the Join Network 510 Extended Beacon. This Enhanced Beacon would be distinct to the Join 511 Network, and would be encrypted with the well-known Join Network key. 513 3.5.1. prefixes to use for join traffic 515 What prefix would the joining node for communication? There are 516 three options: 518 (1) just use link-local addresses (this may require that some 519 traffic between 6LBR and JCE be IPIP tunneled) 521 (2) use a prefix specifically for join traffic (may be easier with a 522 join-only DODAG) 524 (3) use the same prefix as the rest of the traffic (may require more 525 complex ACLs, and leaks information to attackers) 527 The simplest method is to use the link-local addresses for the 6top 528 connection, and the cost of an IPIP tunnel between the unconstrained 529 6LBR and the JCE is not considered significant. 531 4. security requirements 533 4.1. threat model 535 There are three kinds of threats that a join process must deal with: 536 threats to the joining node, threats to the resources of the network, 537 and threats to other joining nodes. 539 4.1.1. threats to the joining node 541 A node may be taken out of it's box by a malicious entity and powered 542 on. This could happen during shipping, while being stored in a 543 warehouse. The device may be subject to physical theft, or the goal 544 of the attacker may be to turn the device into a trojan horse of some 545 kind. Physical protection of the device is out of scope for this 546 document; this document will henceforth assume that the device is 547 sealed in some tamper-evident way and this document deals with 548 attacks over the network. 550 An attacker may attempt to convince the joining node that it is the 551 legitimate Production Network; this is done by putting up a 552 legitimate looking Join Network, and following the protocol as 553 described in this document. The Joining Node can not know if it has 554 the corrrect Production Network until steps 11-13, when it attempts 555 to validate the ClientCertificate provided by the JCE. 557 When the joining node determines that this is the incorrect network, 558 it must remember the PANID of the network that it has attempted to 559 join, and then look for another network to try. It SHOULD have some 560 limit as the number of times it will try before going back to sleep, 561 or shutting down, and it SHOULD take care not to consume more than 562 some specified percentage of any battery it might have. 564 Should a malicious production network be present at the same time/ 565 place as the legitimate production network, a the malicious agent 566 could intercept and replay various packets from the proper join 567 network, but ultimately this either results in a jamming-like denial 568 of service, and/or the the ClientCertificate will not validate. 570 It is a legitimate situation for there to be multiple possible join 571 networks, and the joining node may have to try each one before it 572 finds the network that it the right one for it. The incorrect, but 573 non-malicious networks will not attempt the 6top provisioning step, 574 and SHOULD return a negative result in steps 8/9, refusing the node's 575 NS. Those incorrect networks will be recognize that the node does 576 not belong to them, because they will be able to see the Joining 577 Node's IDevID in the ARO of step 4. 579 4.1.2. threats to the resources of the network 581 The production network has two important resources that may be 582 attacked by malicious Joining nodes: 1) energy/bandwidth, 2) memory 583 for routing entries. 585 A malicious joining node could send many NS messages to the Join 586 Assistant (from many made up addresses), which would send many NS/DAR 587 messages to the 6LBR, and this would consume bandwidth, and therefore 588 energy from the members of the mesh along the path to the 6LBR. This 589 can be mitigated by limited the total bandwidth available for 590 joining. 592 A malicious joining node could send many NS messages, and if the 6LBR 593 agreed to accept the new node (by IDevID), then the Join Assistant 594 would MAY inject routing information into mesh for the Joining node. 595 Non-storing DODAGs store are routing information in the DODAG Root 596 (probably the 6LBR), which is generally not a constrained node. 597 Storing DODAGs store routing entries at all nodes up to the DODAG, 598 and those are constrained nodes. Using a separate Join DODAG, and 599 having that DODAG be non-storing will reduce any impact on 600 intermediate nodes, but it does cause resources to be used for the 601 second DODAG, and it may have a code impact if the nodes otherwise 602 would not implement non-storing RPL. 604 4.1.3. threats to other joining nodes 606 A joining node (or the nodes of a malicious network, co-located near 607 the legitimate production network) may mount attacks on legitimate 608 nodes which have not yet joined. 610 The malicious nodes may attempt to perform 6top operations against 611 the joining node to keep it from being able to respond to the 612 legitimate 6top session from the legitimate JCE. During the Join 613 phase, the Joining node MUST have all other resources and protocols 614 turned off, even if they would normally be accessible as read-only 615 unauthenticated CoAP resources. 617 Malicious nodes could use the Join Network to mount various DTLS 618 based attacks against the joining node, such as sending very long 619 certificate chains to validate. One might think to limit the length 620 of such chains, but as shown in [I-D.richardson-6tisch-idevid-cert] 621 the chain may as a long as the supplier chain, plus may include 622 additional certificates due to resales of plants/equipment/etc. 623 Validating from a trusted certificate down to the specific 624 certificate which proves ownership would eliminate random certificate 625 chains, but the attacker could just feed the joining node legitimate 626 chains that it observed (and replayed) from the legitimate JCE. This 627 does no good; the Joining node finds that the DTLS connection is 628 invalid, but it may significantly run batteries down. 630 4.2. implementation cost 632 (storage of security material, computational cost) 634 4.3. denial of service 636 other communication impacts of security protocol mechanics 638 5. protocol requirements/constraints/assumptions 640 5.1. inline/offline 642 dependencies on centralized or external functionality, inline and 643 offline 645 6. time sequence diagram 647 +-----+ +------+ +----------+ +-----------+ 648 | | | | | JOIN | | Joining | 649 | JCE | | 6LBR | | Assistant| | Node | 650 +-----+ +------+ | (proxy) | | | 651 | | +----------+ +-----------+ 652 | | | | 653 | | |-------BEACON (1)---------->| 654 | | | | 655 | | |<----Router Solicitation----| 656 | | |---Router Advertisement---->| 657 | | | | 658 | | |<------CERT CACHE-----------| 659 | | | LOAD (2) | 660 | | | | 661 | | | | 662 | | |-------CERT CACHE---------->| 663 | | | RESPONSE (multiple) | 664 | | | (packets) | 665 | | | | 666 | | |<-----JOIN REQUEST (4) -----| 667 | | | (NS w/ARO ) | 668 | | | | 669 | |<---NS (DAR) (5)-----| | 670 |<--??(6)-| | | 671 | | | | 672 |--??(7)->| | | 673 | | | | 674 | |----NS (DAC)-(8)---->| | 675 | | +------+ | | 676 | || | 678 | | ACK +------+ | | 679 | | |-------JOIN ACK (9)-------->| 680 | | | | 681 | | | | 682 |================(10)==========>|----------6top----(11)----->| 683 | | | DTLS | 684 |<===============(13)===========|<---------CoAP----(12)------| 685 | | | (many packets) | 687 Figure 1: Message sequence for JOIN message 689 6.1. explanation of each step 691 6.1.1. step (1): enhanced beacon 693 A 6tisch join/synchronization beacon is broadcast periodically, and 694 is authenticated with a symmetric "beacon key": 696 well known JOIN key, such "JOIN6TISCH" 697 another key, provisioned in advance (OOB) 699 a shared symmetric key derived from public part of top level 700 certificate (a closely held "secret") 702 The purpose of this key is not to provide a high level of assurance, 703 but rather to filter out 6tisch traffic from another random traffic 704 that may be sharing the same radio frequencies. 706 These beacons are used for JOIN purpose only, and are not related to 707 the Enhanced Beacons used in the rest of 6tisch. 709 6.1.2. step (1B): send router solicitation 711 The joining node sends a router solicitation during the Aloha period 712 of the beacon. 714 6.1.3. step (1C): receive router advertisement 716 The joining node receives a router advertisement from the Join 717 Assistant. It could include 6CO options to help compress packets, 718 and should contain a prefix appropriate for join traffic. 720 6.1.4. step (2): certificate cache load 722 At step 10, the JCE will need to present a certificate chain anchored 723 at a trusted CA built into the joining node. It has been speculated 724 that a significant amount of traffic could be avoided at step (10) if 725 the common parts of the certificate chains could be cached in the 726 join assistant. 728 This optional step involves the joining node asking for certificates 729 from the join assistant. 731 6.1.5. step (3): receive certificate cache 733 the proxy neighbour sends requested cached certificates to the 734 joining node 736 6.1.6. step (4): join request 738 A regular Neighbour Solicitation is sent. This should contain an ARO 739 (or EARO) option containing the Joining Nodes' IDevID. The ARO/EARO 740 will be proxied by the Join Assistant as part of normal 6LowPAN 741 processing for leaf nodes (non-RPL nodes) upwards to the 6LBR 743 6.1.7. step (5): NS duplicate address request (DAR) 744 6.1.8. step (7): 6LBR informs JCE of new node 746 6.1.9. step (8): JCE informs/acks to 6LBR of new node 748 The JCE could reply in the negative, and this would cause a DAC 749 failure, TBD 751 6.1.10. step (9): NS duplicate address confirmation (DAC) 753 6.1.11. step (10): JCE initiates connection to joining node 755 The double lines indicate that an IPIP tunnel operation may be 756 required. If a straight DAO or seperate Join DODAG is used, then 757 this is just a straight forwarding root to leaf node forwarding 758 operation, and involves either using source routes (non-storing), or 759 just forwarding for storing DODAGs. 761 A specific bandwidth allocation would be used for this join traffic 763 The production network encryption keys would be used for the join 764 traffic 766 6.1.12. step (11): Join Assistant forwards packet to joining node 768 The JOIN Assistant would forward traffic to the Joining Node. 769 Recognizing that this traffic the JOIN Network, the JOIN Assistant 770 would use the JOIN Network key. 772 6.1.13. step (12): Joining node replies 774 The joining node replies, using JOIN Network key. 776 6.1.14. step (13): Join Assistant forwards reply to JCE 778 The JOIN Assistant, recognizing that the traffic came from the JOIN 779 Network, restricts the destination that can be reached to the the JCE 780 only. It can do this in a stateless way, and it does NOT need to 781 track the traffic at (10) to open pinhole, etc. 783 Recognizing that the traffic came from the JOIN Network, the traffic 784 would be placed into a bandwidth allocation (track?) that allows such 785 traffic. 787 6.2. size of each packet 789 and number of frames needed to contain it. 791 7. resulting security properties obtained from this process 793 An end to end IPv6 CoAP/DTLS connection is created between the JCE 794 and the Joining Node. This connection carries 6top commands to 795 update security parameters. This results in either deployment of a 796 single-level, locally relevant certificate (LDevID), or deployment of 797 a network-wide symmetric "Master Key" 799 8. deployment scenarios underlying protocol requirements 801 9. device identification 803 The JCE authenticates the joining node using a certificate chain 804 provided inline during the DTLS negotiation. The certificate chain 805 is rooted in a vendor certificate that the JCE must have preloaded, 806 and is a statement as to the node's 802.1AR IDevID. The joining node 807 authenticates the 809 9.1. PCE/Proxy vs Node identification 811 9.2. Time source authentication / time validation 813 Note: RPL Root authentication is a chartered item 815 9.3. description of certificate contents 817 9.4. privacy aspects 819 The EUI-64 of the Joining node is transmitted using a Well Known 820 layer-2 encryption key. Within the ARO/EARO of the Neighbour 821 Solicitation is an OUI, which may be identical to the EUI-64 of the 822 Joining node, or it might be an unrelated IDevID. 824 An eavesdropper can therefore learn something about the manufacturer 825 of every device as it joins. 827 10. slotframes to be used during join 829 how is this communicated in the (extended) beacon. 831 11. configuration aspects 833 (allocation of slotframes after join, network statistics, 834 neighboetc.) 836 12. authorization aspects 838 lifecycle (key management, trust management) 840 12.1. how to determine a proxy/PCE from a end node 842 12.2. security considerations 844 what prevents a node from transmitting when it is not their turn 845 (part one: jamming) 847 can a node successfully communicate with a peer at a time when not 848 supposed to, may be tied to link layer security, or will it be 849 policed by receiver? 851 13. security architecture 853 security architecture and fit of e.g. join protocol and provisioning 854 into this 856 14. Posture Maintenance 858 (SACM related work) 860 15. Security Considerations 862 16. Other Related Protocols 864 17. IANA Considerations 866 18. Acknowledgements 868 19. References 870 19.1. Normative references 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, March 1997. 875 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 876 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 877 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 878 Lossy Networks", RFC 6550, March 2012. 880 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 881 "Neighbor Discovery Optimization for IPv6 over Low-Power 882 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 883 November 2012. 885 [IEEE.802.1AR] 886 Institute of Electrical and Electronics Engineers, "Secure 887 Device Identity", IEEE 802.1AR, 2009, 888 . 890 [I-D.ietf-6tisch-coap] 891 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 892 Interaction using CoAP", draft-ietf-6tisch-coap-01 (work 893 in progress), July 2014. 895 [I-D.ietf-6tisch-6top-interface] 896 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 897 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 898 6top-interface-01 (work in progress), July 2014. 900 [I-D.ietf-6tisch-architecture] 901 Thubert, P., Watteyne, T., and R. Assimiti, "An 902 Architecture for IPv6 over the TSCH mode of IEEE 903 802.15.4e", draft-ietf-6tisch-architecture-01 (work in 904 progress), February 2014. 906 [I-D.irtf-nmrg-autonomic-network-definitions] 907 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 908 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 909 Networking - Definitions and Design Goals", draft-irtf- 910 nmrg-autonomic-network-definitions-00 (work in progress), 911 December 2013. 913 [I-D.seitz-ace-problem-description] 914 Seitz, L. and G. Selander, "Problem Description for 915 Authorization in Constrained Environments", draft-seitz- 916 ace-problem-description-01 (work in progress), July 2014. 918 [I-D.richardson-6tisch-idevid-cert] 919 Richardson, M., "X509.v3 certificate extension for 920 authorization of device ownership", draft-richardson- 921 6tisch-idevid-cert-00 (work in progress), May 2014. 923 [I-D.wang-6tisch-6top-sublayer] 924 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 925 Operation Sublayer (6top)", draft-wang-6tisch-6top- 926 sublayer-00 (work in progress), February 2014. 928 [I-D.thubert-6lo-rfc6775-update-reqs] 929 Thubert, P., "Requirements for an update to 6LoWPAN ND", 930 draft-thubert-6lo-rfc6775-update-reqs-01 (work in 931 progress), June 2014. 933 19.2. Informative references 935 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 936 Housley, R., and W. Polk, "Internet X.509 Public Key 937 Infrastructure Certificate and Certificate Revocation List 938 (CRL) Profile", RFC 5280, May 2008. 940 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 941 Application Protocol (CoAP)", RFC 7252, June 2014. 943 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 944 Security Version 1.2", RFC 6347, January 2012. 946 [I-D.thubert-6lowpan-backbone-router] 947 Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 948 6lowpan-backbone-router-03 (work in progress), February 949 2013. 951 [I-D.ietf-netconf-zerotouch] 952 Watsen, K., Hanna, S., Clarke, J., and M. Abrahamsson, 953 "Zero Touch Provisioning for NETCONF Call Home 954 (ZeroTouch)", draft-ietf-netconf-zerotouch-00 (work in 955 progress), July 2014. 957 [I-D.kelsey-intarea-mesh-link-establishment] 958 Kelsey, R., "Mesh Link Establishment", draft-kelsey- 959 intarea-mesh-link-establishment-05 (work in progress), 960 February 2013. 962 [I-D.ohba-6tisch-security] 963 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and 964 A. Yegin, "Security Framework and Key Management Protocol 965 Requirements for 6TiSCH", draft-ohba-6tisch-security-01 966 (work in progress), March 2014. 968 [I-D.piro-6tisch-security-issues] 969 Piro, G., Boggia, G., and L. Grieco, "Layer-2 security 970 aspects for the IEEE 802.15.4e MAC", draft-piro-6tisch- 971 security-issues-02 (work in progress), June 2014. 973 Author's Address 974 Michael C. Richardson 975 Sandelman Software Works 976 470 Dawson Avenue 977 Ottawa, ON K1Z 5V7 978 CA 980 Email: mcr+ietf@sandelman.ca 981 URI: http://www.sandelman.ca/