idnits 2.17.1 draft-richardson-6tisch--security-6top-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 21, 2014) is 3566 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6550' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-nmrg-autonomic-network-definitions' is defined on line 788, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 828, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-zerotouch' is defined on line 833, 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 July 21, 2014 5 Expires: January 22, 2015 7 6tisch secure join using 6top 8 draft-richardson-6tisch--security-6top-02 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 January 22, 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 . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology and Roles . . . . . . . . . . . . . . . . . . . . 4 63 3. Architectural requirements of join protocol . . . . . . . . . 6 64 3.1. prefixes to use for join traffic . . . . . . . . . . . . 9 65 4. security requirements . . . . . . . . . . . . . . . . . . . . 9 66 4.1. threat model . . . . . . . . . . . . . . . . . . . . . . 9 67 4.1.1. threats to the joining node . . . . . . . . . . . . . 9 68 4.1.2. threats to the resources of the network . . . . . . . 10 69 4.1.3. threats to other joining nodes . . . . . . . . . . . 11 70 4.2. implementation cost . . . . . . . . . . . . . . . . . . . 11 71 4.3. denial of service . . . . . . . . . . . . . . . . . . . . 11 72 5. protocol requirements/constraints/assumptions . . . . . . . . 12 73 5.1. inline/offline . . . . . . . . . . . . . . . . . . . . . 12 74 6. time sequence diagram . . . . . . . . . . . . . . . . . . . . 12 75 6.1. explanation of each step . . . . . . . . . . . . . . . . 13 76 6.1.1. step (1): enhanced beacon . . . . . . . . . . . . . . 13 77 6.1.2. step (1B): send router solicitation . . . . . . . . . 13 78 6.1.3. step (1C): receive router advertisement . . . . . . . 13 79 6.1.4. step (2): certificate cache load . . . . . . . . . . 13 80 6.1.5. step (3): receive certificate cache . . . . . . . . . 14 81 6.1.6. step (4): join request . . . . . . . . . . . . . . . 14 82 6.1.7. step (5): NS duplicate address request (DAR) . . . . 14 83 6.1.8. step (7): 6LBR informs JCE of new node . . . . . . . 14 84 6.1.9. step (8): JCE informs/acks to 6LBR of new node . . . 14 85 6.1.10. step (9): NS duplicate address confirmation (DAC) . . 14 86 6.1.11. step (10): JCE initiates connection to joining node . 14 87 6.1.12. step (11): Join Assistant forwards packet to joining 88 node . . . . . . . . . . . . . . . . . . . . . . . . 14 89 6.1.13. step (12): Joining node replies . . . . . . . . . . . 14 90 6.1.14. step (13): Join Assistant forwards reply to JCE . . . 14 91 6.2. size of each packet . . . . . . . . . . . . . . . . . . . 15 92 7. resulting security properties obtained from this process . . 15 93 8. deployment scenarios underlying protocol requirements . . . . 15 94 9. device identification . . . . . . . . . . . . . . . . . . . . 15 95 9.1. PCE/Proxy vs Node identification . . . . . . . . . . . . 15 96 9.2. Time source authentication / time validation . . . . . . 15 97 9.3. description of certificate contents . . . . . . . . . . . 15 98 9.4. privacy aspects . . . . . . . . . . . . . . . . . . . . . 15 99 10. slotframes to be used during join . . . . . . . . . . . . . . 16 100 11. configuration aspects . . . . . . . . . . . . . . . . . . . . 16 101 12. authorization aspects . . . . . . . . . . . . . . . . . . . . 16 102 12.1. how to determine a proxy/PCE from a end node . . . . . . 16 103 12.2. security considerations . . . . . . . . . . . . . . . . 16 104 13. security architecture . . . . . . . . . . . . . . . . . . . . 16 105 14. Posture Maintenance . . . . . . . . . . . . . . . . . . . . . 16 106 15. Security Considerations . . . . . . . . . . . . . . . . . . . 16 107 16. Other Related Protocols . . . . . . . . . . . . . . . . . . . 16 108 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 109 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 110 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 111 19.1. Normative references . . . . . . . . . . . . . . . . . . 17 112 19.2. Informative references . . . . . . . . . . . . . . . . . 18 113 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 115 1. Introduction 117 A challenging part with constructing an LLN with nodes from multiple 118 vendors is providing enough security context to each node such that 119 the network communication can form and remain secure. Most LLNs are 120 small and have no operator interfaces at all, and even if they have 121 debug interfaces (such as JTAG) with personnel trained to use that, 122 doing any kind of interaction involving electrical connections in a 123 dirty environment such as a factory or refinery is hopeless. 125 It is necessary to have a way to introduce new nodes into a 6tisch 126 network that does not involve any direct manipulation of the nodes 127 themselves. This act has been called "zero-touch" provisioning, and 128 it does not occur by chance, but requires coordination between the 129 manufacturer of the node, the service operator running the LLN, and 130 the installers actually taking the devices out of the shipping boxes. 132 1.1. Assumptions 134 For the process described in this document to work, some assumptions 135 about available infrastructure are made. These are perhaps more than 136 assumptions, but rather architectural requirements; the exact 137 operation of said infrastructure to be defined in a subsequent 138 document. 140 In the diagrams and text that follows entities are named (and defined 141 in the terminology section). Unless otherwise stated these are 142 roles, not actual machines/systems. The roles are seperated by 143 network protocols in order that they roles can be performed by 144 different systems, not because they have to be. Different 145 deployments will have different scaling requirements for those 146 entities. Smaller deployments might co-located many roles together 147 into a single ruggedized platform, while other deployments might 148 operate all of the roles on distinct, multiply-redundant server 149 classes located in a fully equipped datacentre. 151 2. Terminology and Roles 153 Most terminology should be taken from [I-D.ietf-6tisch-architecture] 154 and from [I-D.ietf-6tisch-6top-interface] and 155 [I-D.wang-6tisch-6top-sublayer]. As well, many terms are taken from 156 [RFC6775]. 158 The following roles/things are defined: 160 PCE the Path Computation Engine. This entity reaches 161 out to each of the nodes in the LLN, and 162 configures an appropriate schedule using 6top. 164 Authz Server/ACE the Authorization Server. This offloads 165 calculation of access control lists and other 166 access control decisions for constrainted nodes. 167 See [I-D.seitz-ace-problem-description] 169 6top the 6top protocol is defined abstractly in 170 [I-D.ietf-6tisch-6top-interface] and mapped to 171 run over CoAP in [I-D.ietf-6tisch-coap]. The 172 6top protocol is defined primarily to provision 173 the 6TiSCH schedule; this document proposes to 174 extend it for also provisioning of layer-2 175 security parameters. 177 JCE the Join Coordination Entity. This acronym is 178 chosen to parallel the PCE. 180 joining node The newly unboxed constrained node that needs to 181 join a network. 183 join assistant A constrained node near the joining node that 184 will act as it's first 6LR, and will relay 185 traffic to/from the joining node. 187 join network A 802.15.4e network whose encryption and 188 authentication key is "JOIN6TISCH". 190 production network A 802.15.4e network whose encryption/ 191 authentication keys are determined by some 192 algorithm. There may have network-wide group 193 keys, or per-link keys. 195 The following terms are used in this document and come from other 196 documents: 198 DevID [IEEE.802.1AR] defines the secure DEVice 199 IDentifier as a device identifier that is 200 cryptographically bound to the device and is 201 composed of the Secure Device Identifier Secret 202 and the Secure Device Identifier Credential. 204 IDevID The Initial secure DEVice IDentifier (IDevID) is 205 the Device Identifier which was installed on the 206 device by the manufacturer. 208 LDevID A Locally significant secure DEVice IDentifiers 209 (LDevIDs) is a Secure Device Identifier 210 credential that is unique in the local 211 administrative domain in which the device is 212 used. The LDevID is usually a new certificate 213 provisioned by some local means, such as the 6top 214 mechanism defined in this document. 216 CoAP The CoAP protocol, defined in [RFC7252] is an 217 HTTP-like resource access protocol. CoAP runs 218 over UDP. 220 DTLS The datagram version of TLS, defined in 221 [RFC6347], and which can be used to secure CoAP 222 in the same way that TLS secures HTTP. 224 ARO [RFC6775]defines a number of new Neighbor 225 Discovery options including the Address 226 Registration Option 228 DAR/DAC [RFC6775]defines the Duplicate Address Request 229 and Duplicate Address Confirmation options to 230 turn the multicasted Duplicate Address Detection 231 protocol into a client/server process 233 EARO [I-D.thubert-6lo-rfc6775-update-reqs]extends the 234 ARO option to include some additional fields 235 necessary to distinguish duplicate addresses from 236 nodes that have moved networks when there are 237 mulitple LLNs linked over a backbone. 239 3. Architectural requirements of join protocol 241 This section works from the ultimate goal, and goes backwards to 242 prerequisit actions. Section 6 presents the protocol from beginning 243 to end order. 245 The ultimate goal of the join protocol is to provide a new node with 246 enough locally significant security credentials that it is able to 247 take part in the network directly. The credentials may vary by 248 deployment. They can be: 250 1) a network-wide shared symmetric key 252 2) a locally significant (one-level only) 802.11AR type DevID 253 certificate 255 Given one of the the above, there are a number of possible protocols 256 that can be used to generate layer-2 sessions keys for the node, 257 including: 259 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] 261 2) work in 802.15.9 263 3) Security Framework and Key Management Protocol Requirements for 264 6TiSCH [I-D.ohba-6tisch-security] (this document provides the 265 phase 0 required) 267 4) Layer-2 security aspects for the IEEE 802.15.4e MAC 268 [I-D.piro-6tisch-security-issues] 270 The intermediate goal of the join protocol is to enable a Join 271 Coordination Entity (JCE) to reach out to the new node, and install 272 the credentials detailed above. The JCE must authenticate itself to 273 the joining node so that the joining node will know that it has 274 joined the correct network, and the joining node must authenticate 275 itself to the JCE so that the JCE will know that this node belongs in 276 the network. This two way authentication occurs in the 6top/CoAP/ 277 DTLS session that is established between the JCE and the joining 278 node. 280 [I-D.ietf-6tisch-6top-interface] presents a way to interface to a 281 6top information model (defined in YANG). [I-D.ietf-6tisch-coap] 282 explains how to access that information model using CoAP. That model 283 is to be extended to include security attributes for the network. 284 The JCE would therefore reach out to the joining node and simply 285 provision appropriate security properties into the joining node, much 286 like the PCE will provision schedules. 288 This 6top-based secure join protocol has defined a push model for 289 security provisioning by the JCE. This has been done for three 290 reasons: 292 1) 6tisch nodes already have to have a 6top CoAP server for schedule 293 provising 295 2) this permits the JCE to manage how many nodes are trying to join 296 at the same time, and limit how much bandwidth/energy is used for 297 the join operation, and also for the JCE to prioritize the join 298 order for nodes. 300 3) making the JCE initiate the DTLS connection significantly 301 simplies the certificate chains that must be exchanged as the 302 most constrained side (the joining node) provides it's 303 credentials first, and lets the much richer JCE figure out what 304 kind of certificate chain will be required to authenticate the 305 JCE. In EAP-TLS/802.1x situations, the TLS channel is created in 306 the opposite direction, and it would have to complete in a 307 tentative way, and then further authorization occur in-band. 309 In order for a 6top/DTLS/CoAP connection to occur between the JCE and 310 the joining node, there needs to be end-to-end IPv6 connectivity 311 between those two entities. The joining node will not participate in 312 the route-over RPL mesh, but rather will be seen by the network as 313 being a 6lowpan only leaf-node. 315 There are some alternatives to having full end to end connectivity 316 which are discussed in the security considerations section. 318 The specific mechanism to enable end to end connectivity with the JCE 319 are still open but will consist of one of: 321 (1) IPIP tunnel between Join Assistant and JCE 323 (2) using straight RPL routing: the Join Assistant sends a DAO 325 (3) using a separate RPL DODAG for join traffic 327 (4) establishing a specific multi-hop 6tisch track for join traffic 328 for each Join Assistant 330 Of these mechanisms, the only one which does not require additional 331 state on the Join Assistant (which is also a constrained device) is 332 (1) and (2). Mechanism (2) additionally requires no specific state 333 on the Join Assistant. Mechanism (2), in a non-storing DODAG 334 requires additional state on the DODAG root (6LBR) only; while 335 mechanism (1) requires a similar amount of state on the JCE. For 336 deployments where the JCE is part of the 6LBR, the amount of state is 337 similar, but in any case, the 6LBR is assumed to be a non-constrained 338 node. 340 As long as the Join Assistant does not do any kind of stateful 341 firewalling, the IPIP tunnel and the DAO (2) method can be done by 342 the Join Assistant statelessly. Upward traffic from the Join Network 343 must be restricted to a 6tisch slotframe(s) to which join traffic is 344 welcome, no tunnelling is necessary as the upwards routes are all in 345 place. A destination address ACL on traffic from the Join Network 346 restricts the Joining Nodes to sending traffic only to the address of 347 the JCE. (If JCE and 6LBR are colocated, then this is the address in 348 the ABRO, if they are not colocated, then this address needs to have 349 been provisioning in the Join Assistant when it joined, or could be 350 carried in a new RA option) 352 When using option (2), networks that have storing mode DODAGs will 353 consume routing resources on all intermediate nodes between the Join 354 Assistant and the DODAG root. This resource will be depleted without 355 any authentication, and this threat is detailed below. 357 Continuing to work backwards, in order the JCE reach out to provision 358 the Joining Node, it needs to know that the new node is present. 359 This is done by taking advantage of the 6lowPAN Address Resolution 360 Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address 361 to also be sent up to the 6LBR for duplicate detection using the DAR/ 362 DAC mechanism. The 6LBR simply needs to tell the JCE about this 363 using a protocol that needs to be defined, but could be either DAR or 364 NS. 366 In addition to needing to know the joining devices address from the 367 DAR/NS, the JCE also needs to know the joining node' IDevID. If the 368 serialNumber attribute of the IDevID is less than 64 bits, then it is 369 possible that it could be placed into the EUI-64 option of the ARO, 370 or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs] EARO. The 371 JCE needs to know the joining node's serialNumber to know if this is 372 device that it should even attempt to provision; and if so, it may 373 need to retrieve an appropriate certificate chain (see 374 [I-D.richardson-6tisch-idevid-cert]) from the Factory in order for 375 the JCE to prove it is the legitimate owner of the joining node. 377 Neither 802.1AR nor [RFC5280] provide any structure for the 378 serialNumber, except that they are positive integers of up-to 20 379 octets in size (numbers up to 2^160). This specification would 380 require that the serialNumber encoded in the IDevID is the same as 381 the EUI-64 used by the device. Some consideration needs to be given 382 as to whether there are privacy considerations to doing this: any 383 observer that can see the join traffic, can also see the source MAC 384 address of the node as well. 386 Prior to being able to announce itself in a NS, the joining node 387 needs to find the Join Network. This is done by listening to an 388 extended beacon which are broadcast in designated slotframes by Join 389 Assistants. The Extended Beacon provides a way for the Joining Node 390 to synchronize itself to the overall timeslot schedule and provides 391 an Aloha period in which the Joining Node can send a Router 392 Soliticiation, and receive an appropriate Router Advertisement giving 393 the Joining Node a prefix and default route to which to send join 394 traffic. 396 It may be possible to eliminate a message exchange if space for a 397 Router Advertisement can be found as part of the Join Network 398 Extended Beacon. This Enhanced Beacon would be distinct to the Join 399 Network, and would be encrypted with the well-known Join Network key. 401 3.1. prefixes to use for join traffic 403 What prefix would the joining node for communication? There are 404 three options: 406 (1) just use link-local addresses (requires all traffic be tunneled) 408 (2) use a prefix specifically for join traffic (may be easier with a 409 join-only DODAG) 411 (3) use the same prefix as the rest of the traffic (may require more 412 complex ACLs, and leaks information to attackers) 414 4. security requirements 416 4.1. threat model 418 There are three kinds of threats that a join process must deal with: 419 threats to the joining node, threats to the resources of the network, 420 and threats to other joining nodes. 422 4.1.1. threats to the joining node 423 A node may be taken out of it's box by a malicious entity and powered 424 on. This could happen during shipping, while being stored in a 425 warehouse. The device may be subject to physical theft, or the goal 426 of the attacker may be to turn the device into a trojan horse of some 427 kind. Physical protection of the device is out of scope for this 428 document; this document will henceforth assume that the device is 429 sealed in some tamper-evident way and this document deals with 430 attacks over the network. 432 An attacker may attempt to convince the joining node that it is the 433 legitimate Production Network; this is done by putting up a 434 legitimate looking Join Network, and following the protocol as 435 described in this document. The Joining Node can not know if it has 436 the corrrect Production Network until steps 11-13, when it attempts 437 to validate the ClientCertificate provided by the JCE. 439 When the joining node determines that this is the incorrect network, 440 it must remember the PANID of the network that it has attempted to 441 join, and then look for another network to try. It SHOULD have some 442 limit as the number of times it will try before going back to sleep, 443 or shutting down, and it SHOULD take care not to consume more than 444 some specified percentage of any battery it might have. 446 Should a malicious production network be present at the same time/ 447 place as the legitimate production network, a the malicious agent 448 could intercept and replay various packets from the proper join 449 network, but ultimately this either results in a jamming-like denial 450 of service, and/or the the ClientCertificate will not validate. 452 It is a legitimate situation for there to be multiple possible join 453 networks, and the joining node may have to try each one before it 454 finds the network that it the right one for it. The incorrect, but 455 non-malicious networks will not attempt the 6top provisioning step, 456 and SHOULD return a negative result in steps 8/9, refusing the node's 457 NS. Those incorrect networks will be recognize that the node does 458 not belong to them, because they will be able to see the Joining 459 Node's IDevID in the ARO of step 4. 461 4.1.2. threats to the resources of the network 463 The production network has two important resources that may be 464 attacked by malicious Joining nodes: 1) energy/bandwidth, 2) memory 465 for routing entries. 467 A malicious joining node could send many NS messages to the Join 468 Assistant (from many made up addresses), which would send many NS/DAR 469 messages to the 6LBR, and this would consume bandwidth, and therefore 470 energy from the members of the mesh along the path to the 6LBR. This 471 can be mitigated by limited the total bandwidth available for 472 joining. 474 A malicious joining node could send many NS messages, and if the 6LBR 475 agreed to accept the new node (by IDevID), then the Join Assistant 476 would MAY inject routing information into mesh for the Joining node. 477 Non-storing DODAGs store are routing information in the DODAG Root 478 (probably the 6LBR), which is generally not a constrained node. 479 Storing DODAGs store routing entries at all nodes up to the DODAG, 480 and those are constrained nodes. Using a separate Join DODAG, and 481 having that DODAG be non-storing will reduce any impact on 482 intermediate nodes, but it does cause resources to be used for the 483 second DODAG, and it may have a code impact if the nodes otherwise 484 would not implement non-storing RPL. 486 4.1.3. threats to other joining nodes 488 A joining node (or the nodes of a malicious network, co-located near 489 the legitimate production network) may mount attacks on legitimate 490 nodes which have not yet joined. 492 The malicious nodes may attempt to perform 6top operations against 493 the joining node to keep it from being able to respond to the 494 legitimate 6top session from the legitimate JCE. During the Join 495 phase, the Joining node MUST have all other resources and protocols 496 turned off, even if they would normally be accessible as read-only 497 unauthenticated CoAP resources. 499 Malicious nodes could use the Join Network to mount various DTLS 500 based attacks against the joining node, such as sending very long 501 certificate chains to validate. One might think to limit the length 502 of such chains, but as shown in [I-D.richardson-6tisch-idevid-cert] 503 the chain may as a long as the supplier chain, plus may include 504 additional certificates due to resales of plants/equipment/etc. 505 Validating from a trusted certificate down to the specific 506 certificate which proves ownership would eliminate random certificate 507 chains, but the attacker could just feed the joining node legitimate 508 chains that it observed (and replayed) from the legitimate JCE. This 509 does no good; the Joining node finds that the DTLS connection is 510 invalid, but it may significantly run batteries down. 512 4.2. implementation cost 514 (storage of security material, computational cost) 516 4.3. denial of service 518 other communication impacts of security protocol mechanics 520 5. protocol requirements/constraints/assumptions 522 5.1. inline/offline 524 dependencies on centralized or external functionality, inline and 525 offline 527 6. time sequence diagram 529 +-----+ +------+ +----------+ +-----------+ 530 | | | | | JOIN | | Joining | 531 | JCE | | 6LBR | | Assistant| | Node | 532 +-----+ +------+ | (proxy) | | | 533 | | +----------+ +-----------+ 534 | | | | 535 | | |-------BEACON (1)---------->| 536 | | | | 537 | | |<----Router Solicitation----| 538 | | |---Router Advertisement---->| 539 | | | | 540 | | |<------CERT CACHE-----------| 541 | | | LOAD (2) | 542 | | | | 543 | | | | 544 | | |-------CERT CACHE---------->| 545 | | | RESPONSE (multiple) | 546 | | | (packets) | 547 | | | | 548 | | |<-----JOIN REQUEST (4) -----| 549 | | | (NS w/ARO ) | 550 | | | | 551 | |<---NS (DAR) (5)-----| | 552 |<--??(6)-| | | 553 | | | | 554 |--??(7)->| | | 555 | | | | 556 | |----NS (DAC)-(8)---->| | 557 | | +------+ | | 558 | || | 560 | | ACK +------+ | | 561 | | |-------JOIN ACK (9)-------->| 562 | | | | 563 | | | | 564 |================(10)==========>|----------6top----(11)----->| 565 | | | DTLS | 566 |<===============(13)===========|<---------CoAP----(12)------| 567 | | | (many packets) | 569 Figure 1: Message sequence for JOIN message 571 6.1. explanation of each step 573 6.1.1. step (1): enhanced beacon 575 A 6tisch join/synchronization beacon is broadcast periodically, and 576 is authenticated with a symmetric "beacon key": 578 well known JOIN key, such "JOIN6TISCH" 580 another key, provisioned in advance (OOB) 582 a shared symmetric key derived from public part of top level 583 certificate (a closely held "secret") 585 The purpose of this key is not to provide a high level of assurance, 586 but rather to filter out 6tisch traffic from another random traffic 587 that may be sharing the same radio frequencies. 589 These beacons are used for JOIN purpose only, and are not related to 590 the Enhanced Beacons used in the rest of 6tisch. 592 6.1.2. step (1B): send router solicitation 594 The joining node sends a router solicitation during the Aloha period 595 of the beacon. 597 6.1.3. step (1C): receive router advertisement 599 The joining node receives a router advertisement from the Join 600 Assistant. It could include 6CO options to help compress packets, 601 and should contain a prefix appropriate for join traffic. 603 6.1.4. step (2): certificate cache load 605 At step 10, the JCE will need to present a certificate chain anchored 606 at a trusted CA built into the joining node. It has been speculated 607 that a significant amount of traffic could be avoided at step (10) if 608 the common parts of the certificate chains could be cached in the 609 join assistant. 611 This optional step involves the joining node asking for certificates 612 from the join assistant. 614 6.1.5. step (3): receive certificate cache 616 the proxy neighbour sends requested cached certificates to the 617 joining node 619 6.1.6. step (4): join request 621 A regular Neighbour Solicitation is sent. This should contain an ARO 622 (or EARO) option containing the Joining Nodes' IDevID. The ARO/EARO 623 will be proxied by the Join Assistant as part of normal 6LowPAN 624 processing for leaf nodes (non-RPL nodes) upwards to the 6LBR 626 6.1.7. step (5): NS duplicate address request (DAR) 628 6.1.8. step (7): 6LBR informs JCE of new node 630 6.1.9. step (8): JCE informs/acks to 6LBR of new node 632 The JCE could reply in the negative, and this would cause a DAC 633 failure, TBD 635 6.1.10. step (9): NS duplicate address confirmation (DAC) 637 6.1.11. step (10): JCE initiates connection to joining node 639 The double lines indicate that an IPIP tunnel operation may be 640 required. If a straight DAO or seperate Join DODAG is used, then 641 this is just a straight forwarding root to leaf node forwarding 642 operation, and involves either using source routes (non-storing), or 643 just forwarding for storing DODAGs. 645 A specific bandwidth allocation would be used for this join traffic 647 The production network encryption keys would be used for the join 648 traffic 650 6.1.12. step (11): Join Assistant forwards packet to joining node 652 The JOIN Assistant would forward traffic to the Joining Node. 653 Recognizing that this traffic the JOIN Network, the JOIN Assistant 654 would use the JOIN Network key. 656 6.1.13. step (12): Joining node replies 658 The joining node replies, using JOIN Network key. 660 6.1.14. step (13): Join Assistant forwards reply to JCE 661 The JOIN Assistant, recognizing that the traffic came from the JOIN 662 Network, restricts the destination that can be reached to the the JCE 663 only. It can do this in a stateless way, and it does NOT need to 664 track the traffic at (10) to open pinhole, etc. 666 Recognizing that the traffic came from the JOIN Network, the traffic 667 would be placed into a bandwidth allocation (track?) that allows such 668 traffic. 670 6.2. size of each packet 672 and number of frames needed to contain it. 674 7. resulting security properties obtained from this process 676 An end to end IPv6 CoAP/DTLS connection is created between the JCE 677 and the Joining Node. This connection carries 6top commands to 678 update security parameters. This results in either deployment of a 679 single-level, locally relevant certificate (LDevID), or deployment of 680 a network-wide symmetric "Master Key" 682 8. deployment scenarios underlying protocol requirements 684 9. device identification 686 The JCE authenticates the joining node using a certificate chain 687 provided inline during the DTLS negotiation. The certificate chain 688 is rooted in a vendor certificate that the JCE must have preloaded, 689 and is a statement as to the node's 802.1AR IDevID. The joining node 690 authenticates the 692 9.1. PCE/Proxy vs Node identification 694 9.2. Time source authentication / time validation 696 Note: RPL Root authentication is a chartered item 698 9.3. description of certificate contents 700 9.4. privacy aspects 702 The EUI-64 of the Joining node is transmitted using a Well Known 703 layer-2 encryption key. Within the ARO/EARO of the Neighbour 704 Solicitation is an OUI, which may be identical to the EUI-64 of the 705 Joining node, or it might be an unrelated IDevID. 707 An eavesdropper can therefore learn something about the manufacturer 708 of every device as it joins. 710 10. slotframes to be used during join 712 how is this communicated in the (extended) beacon. 714 11. configuration aspects 716 (allocation of slotframes after join, network statistics, 717 neighboetc.) 719 12. authorization aspects 721 lifecycle (key management, trust management) 723 12.1. how to determine a proxy/PCE from a end node 725 12.2. security considerations 727 what prevents a node from transmitting when it is not their turn 728 (part one: jamming) 730 can a node successfully communicate with a peer at a time when not 731 supposed to, may be tied to link layer security, or will it be 732 policed by receiver? 734 13. security architecture 736 security architecture and fit of e.g. join protocol and provisioning 737 into this 739 14. Posture Maintenance 741 (SACM related work) 743 15. Security Considerations 745 16. Other Related Protocols 747 17. IANA Considerations 749 18. Acknowledgements 751 19. References 752 19.1. Normative references 754 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 755 Requirement Levels", BCP 14, RFC 2119, March 1997. 757 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 758 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 759 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 760 Lossy Networks", RFC 6550, March 2012. 762 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 763 "Neighbor Discovery Optimization for IPv6 over Low-Power 764 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 765 November 2012. 767 [IEEE.802.1AR] 768 Institute of Electrical and Electronics Engineers, "Secure 769 Device Identity", IEEE 802.1AR, 2009, 770 . 772 [I-D.ietf-6tisch-coap] 773 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 774 Interaction using CoAP", draft-ietf-6tisch-coap-01 (work 775 in progress), July 2014. 777 [I-D.ietf-6tisch-6top-interface] 778 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 779 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 780 6top-interface-01 (work in progress), July 2014. 782 [I-D.ietf-6tisch-architecture] 783 Thubert, P., Watteyne, T., and R. Assimiti, "An 784 Architecture for IPv6 over the TSCH mode of IEEE 785 802.15.4e", draft-ietf-6tisch-architecture-01 (work in 786 progress), February 2014. 788 [I-D.irtf-nmrg-autonomic-network-definitions] 789 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 790 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 791 Networking - Definitions and Design Goals", draft-irtf- 792 nmrg-autonomic-network-definitions-00 (work in progress), 793 December 2013. 795 [I-D.seitz-ace-problem-description] 796 Seitz, L. and G. Selander, "Problem Description for 797 Authorization in Constrained Environments", draft-seitz- 798 ace-problem-description-01 (work in progress), July 2014. 800 [I-D.richardson-6tisch-idevid-cert] 801 Richardson, M., "X509.v3 certificate extension for 802 authorization of device ownership", draft-richardson- 803 6tisch-idevid-cert-00 (work in progress), May 2014. 805 [I-D.wang-6tisch-6top-sublayer] 806 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 807 Operation Sublayer (6top)", draft-wang-6tisch-6top- 808 sublayer-00 (work in progress), February 2014. 810 [I-D.thubert-6lo-rfc6775-update-reqs] 811 Thubert, P., "Requirements for an update to 6LoWPAN ND", 812 draft-thubert-6lo-rfc6775-update-reqs-01 (work in 813 progress), June 2014. 815 19.2. Informative references 817 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 818 Housley, R., and W. Polk, "Internet X.509 Public Key 819 Infrastructure Certificate and Certificate Revocation List 820 (CRL) Profile", RFC 5280, May 2008. 822 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 823 Application Protocol (CoAP)", RFC 7252, June 2014. 825 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 826 Security Version 1.2", RFC 6347, January 2012. 828 [I-D.thubert-6lowpan-backbone-router] 829 Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 830 6lowpan-backbone-router-03 (work in progress), February 831 2013. 833 [I-D.ietf-netconf-zerotouch] 834 Watsen, K., Hanna, S., Clarke, J., and M. Abrahamsson, 835 "Zero Touch Provisioning for NETCONF Call Home 836 (ZeroTouch)", draft-ietf-netconf-zerotouch-00 (work in 837 progress), July 2014. 839 [I-D.kelsey-intarea-mesh-link-establishment] 840 Kelsey, R., "Mesh Link Establishment", draft-kelsey- 841 intarea-mesh-link-establishment-05 (work in progress), 842 February 2013. 844 [I-D.ohba-6tisch-security] 845 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and 846 A. Yegin, "Security Framework and Key Management Protocol 847 Requirements for 6TiSCH", draft-ohba-6tisch-security-01 848 (work in progress), March 2014. 850 [I-D.piro-6tisch-security-issues] 851 Piro, G., Boggia, G., and L. Grieco, "Layer-2 security 852 aspects for the IEEE 802.15.4e MAC", draft-piro-6tisch- 853 security-issues-02 (work in progress), June 2014. 855 Author's Address 857 Michael C. Richardson 858 Sandelman Software Works 859 470 Dawson Avenue 860 Ottawa, ON K1Z 5V7 861 CA 863 Email: mcr+ietf@sandelman.ca 864 URI: http://www.sandelman.ca/