idnits 2.17.1 draft-richardson-6tisch--security-6top-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 4, 2014) is 3556 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6550' is defined on line 701, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-6tisch-coap-00 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-6top-interface-00 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-01 == Outdated reference: A later version (-03) exists of draft-seitz-ace-problem-description-00 == 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 (-03) exists of draft-thubert-6lowpan-backbone-router-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 (~~), 11 warnings (==), 1 comment (--). 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 4, 2014 5 Expires: January 5, 2015 7 6tisch secure join using 6top 8 draft-richardson-6tisch--security-6top-01 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 5, 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 . . . . . . . . . 5 64 3.1. prefixes to use for join traffic . . . . . . . . . . . . 8 65 4. security requirements . . . . . . . . . . . . . . . . . . . . 8 66 4.1. threat model . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1.1. threats to the joining node . . . . . . . . . . . . . 8 68 4.1.2. threats to the resources of the network . . . . . . . 9 69 4.1.3. threats to other joining nodes . . . . . . . . . . . 10 70 4.2. implementation cost . . . . . . . . . . . . . . . . . . . 10 71 4.3. denial of service . . . . . . . . . . . . . . . . . . . . 10 72 5. protocol requirements/constraints/assumptions . . . . . . . . 10 73 5.1. inline/offline . . . . . . . . . . . . . . . . . . . . . 10 74 6. time sequence diagram . . . . . . . . . . . . . . . . . . . . 10 75 6.1. explanation of each step . . . . . . . . . . . . . . . . 11 76 6.1.1. step (1): enhanced beacon . . . . . . . . . . . . . . 12 77 6.1.2. step (1B): send router solicitation . . . . . . . . . 12 78 6.1.3. step (1C): receive router advertisement . . . . . . . 12 79 6.1.4. step (2): acquire authorizer key . . . . . . . . . . 12 80 6.1.5. step (3): receive authorizer key . . . . . . . . . . 12 81 6.1.6. step (4): join request . . . . . . . . . . . . . . . 13 82 6.1.7. step (5): NS duplicate address request (DAR) . . . . 13 83 6.1.8. step (7): 6LBR informs JCE of new node . . . . . . . 13 84 6.1.9. step (8): JCE informs/acks to 6LBR of new node . . . 13 85 6.1.10. step (9): NS duplicate address confirmation (DAC) . . 13 86 6.1.11. step (10): JCE initiates connection to joining node . 13 87 6.1.12. step (11): Join Assistant forwards packet to joining 88 node . . . . . . . . . . . . . . . . . . . . . . . . 13 89 6.1.13. step (12): Joining node replies . . . . . . . . . . . 13 90 6.1.14. step (13): Join Assistant forwards reply to JCE . . . 13 91 6.2. size of each packet . . . . . . . . . . . . . . . . . . . 14 92 7. resulting security properties obtained from this process . . 14 93 8. deployment scenarios underlying protocol requirements . . . . 14 94 9. device identification . . . . . . . . . . . . . . . . . . . . 14 95 9.1. PCE/Proxy vs Node identification . . . . . . . . . . . . 14 96 9.2. Time source authentication / time validation . . . . . . 14 97 9.3. description of certificate contents . . . . . . . . . . . 14 98 9.4. privacy aspects . . . . . . . . . . . . . . . . . . . . . 14 99 10. slotframes to be used during join . . . . . . . . . . . . . . 15 100 11. configuration aspects . . . . . . . . . . . . . . . . . . . . 15 101 12. authorization aspects . . . . . . . . . . . . . . . . . . . . 15 102 12.1. how to determine a proxy/PCE from a end node . . . . . . 15 103 12.2. security considerations . . . . . . . . . . . . . . . . 15 104 13. security architecture . . . . . . . . . . . . . . . . . . . . 15 105 14. Posture Maintenance . . . . . . . . . . . . . . . . . . . . . 15 106 15. Security Considerations . . . . . . . . . . . . . . . . . . . 15 107 16. Other Related Protocols . . . . . . . . . . . . . . . . . . . 15 108 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 109 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 110 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 111 19.1. Normative references . . . . . . . . . . . . . . . . . . 15 112 19.2. Informative references . . . . . . . . . . . . . . . . . 17 113 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 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 JCE the Join Coordination Entity. This acronym is 170 chosen to parallel the PCE. 172 802.1AR a certificate created according the specification 173 in [IEEE.802.1AR] 175 joining node The newly unboxed constrained node that needs to 176 join a network. 178 join assistant A constrained node near the joining node that 179 will act as it's first 6LR, and will relay 180 traffic to/from the joining node. 182 join network A 802.15.4e network whose encryption and 183 authentication key is "JOIN6TISCH". 185 production network A 802.15.4e network whose encryption/ 186 authentication keys are determined by some 187 algorithm. There may have network-wide group 188 keys, or per-link keys. 190 3. Architectural requirements of join protocol 192 This section works from the ultimate goal, and goes backwards to 193 prerequisit actions. Section 6 presents the protocol from beginning 194 to end order. 196 The ultimate goal of the join protocol is to provide a new node with 197 enough locally significant security credentials that it is able to 198 take part in the network directly. The credentials may vary by 199 deployment. They can be: 201 1) a network-wide shared symmetric key 203 2) a locally significant (one-level only) 802.11AR type DevID 204 certificate 206 Given one of the the above, there are a number of possible protocols 207 that can be used to generate layer-2 sessions keys for the node, 208 including: 210 1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment] 212 2) work in 802.15.9 214 3) Security Framework and Key Management Protocol Requirements for 215 6TiSCH [I-D.ohba-6tisch-security] (this document provides the 216 phase 0 required) 218 4) Layer-2 security aspects for the IEEE 802.15.4e MAC 219 [I-D.piro-6tisch-security-issues] 221 The intermediate goal of the join protocol is to enable a Join 222 Coordination Entity (JCE) to reach out to the new node, and install 223 the credentials detailed above. The JCE must authenticate itself to 224 the joining node so that the joining node will know that it has 225 joined the correct network, and the joining node must authenticate 226 itself to the JCE so that the JCE will know that this node belongs in 227 the network. This two way authentication occurs in the 6top/CoAP/ 228 DTLS session that is established between the JCE and the joining 229 node. 231 [I-D.ietf-6tisch-6top-interface] presents a way to interface to a 232 6top MIB. [I-D.ietf-6tisch-coap] explains how to access that MIB 233 using CoAP. That model is to be extended to include security 234 attributes for the network. The JCE would therefore reach out to the 235 joining node and simply provision appropriate security properties 236 into the joining node, much like the PCE will provision schedules. 238 This 6top-based secure join protocol has defined a push model for 239 security provisioning by the JCE. This has been done for three 240 reasons: 242 1) 6tisch nodes already have to have a 6top CoAP server for schedule 243 provising 245 2) this permits the JCE to manage how many nodes are trying to join 246 at the same time, and limit how much bandwidth/energy is used for 247 the join operation, and also for the JCE to prioritize the join 248 order for nodes. 250 3) making the JCE initiate the DTLS connection significantly 251 simplies the certificate chains that must be exchanged as the 252 most constrained side (the joining node) provides it's 253 credentials first, and lets the much richer JCE figure out what 254 kind of certificate chain will be required to authenticate the 255 JCE. In EAP-TLS/802.1x situations, the TLS channel is created in 256 the opposite direction, and it would have to complete in a 257 tentative way, and then further authorization occur in-band. 259 In order for a 6top/DTLS/CoAP connection to occur between the JCE and 260 the joining node, there needs to be end-to-end IPv6 connectivity 261 between those two entities. The joining node will not participate in 262 the route-over RPL mesh, but rather will be seen by the network as 263 being a 6lowpan only leaf-node. 265 There are some alternatives to having full end to end connectivity 266 which are discussed in the security considerations section. 268 The specific mechanism to enable end to end connectivity with the JCE 269 are still open but will consist of one of: 271 (1) IPIP tunnel between Join Assistant and JCE 273 (2) using straight RPL routing: the Join Assistant sends a DAO 275 (3) using a separate RPL DODAG for join traffic 277 (4) establishing a specific multi-hop 6tisch track for join traffic 278 for each Join Assistant 280 Of these mechanisms, the only one which does not require additional 281 state on the Join Assistant (which is also a constrained device) is 282 (1) and (2). Mechanism (2) additionally requires no specific state 283 on the Join Assistant. Mechanism (2), in a non-storing DODAG 284 requires additional state on the DODAG root (6LBR) only; while 285 mechanism (1) requires a similar amount of state on the JCE. For 286 deployments where the JCE is part of the 6LBR, the amount of state is 287 similar, but in any case, the 6LBR is assumed to be a non-constrained 288 node. 290 As long as the Join Assistant does not do any kind of stateful 291 firewalling, the IPIP tunnel and the DAO (2) method can be done by 292 the Join Assistant statelessly. Upward traffic from the Join Network 293 must be restricted to a 6tisch slotframe(s) to which join traffic is 294 welcome, no tunnelling is necessary as the upwards routes are all in 295 place. A destination address ACL on traffic from the Join Network 296 restricts the Joining Nodes to sending traffic only to the address of 297 the JCE. (If JCE and 6LBR are colocated, then this is the address in 298 the ABRO, if they are not colocated, then this address needs to have 299 been provisioning in the Join Assistant when it joined, or could be 300 carried in a new RA option) 302 When using option (2), networks that have storing mode DODAGs will 303 consume routing resources on all intermediate nodes between the Join 304 Assistant and the DODAG root. This resource will be depleted without 305 any authentication, and this threat is detailed below. 307 Continuing to work backwards, in order the JCE reach out to provision 308 the Joining Node, it needs to know that the new node is present. 309 This is done by taking advantage of the 6lowPAN Address Resolution 310 Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address 311 to also be sent up to the 6LBR for duplicate detection using the DAR/ 312 DAC mechanism. The 6LBR simply needs to tell the JCE about this 313 using a protocol that needs to be defined, but could be either DAR or 314 NS. 316 In addition to needing to know the joining devices address from the 317 DAR/NS, the JCE also needs to know the joining node' IDevID. If the 318 IDevID is less than 64 bits, then it is possible that it could be 319 placed into the EUI-64 option of the ARO, or the OUI of the 320 [I-D.thubert-6lowpan-backbone-router] EARO. The JCE needs to know 321 the joining node's IDevID to know if this is device that it should 322 even attempt to provision; and if so, it may need to retrieve an 323 appropriate certificate chain (see 324 [I-D.richardson-6tisch-idevid-cert]) from the Factory in order for 325 the JCE to prove it is the legitimate owner of the joining node. 327 Prior to being able to announce itself in a NS, the joining node 328 needs to find the Join Network. This is done by listening to an 329 extended beacon which are broadcast in designated slotframes by Join 330 Assistants. The Extended Beacon provides a way for the Joining Node 331 to synchronize itself to the overall timeslot schedule and provides 332 an Aloha period in which the Joining Node can send a Router 333 Soliticiation, and receive an appropriate Router Advertisement giving 334 the Joining Node a prefix and default route to which to send join 335 traffic. 337 It may be possible to eliminate a message exchange if space for a 338 Router Advertisement can be found as part of the Join Network 339 Extended Beacon. This Enhanced Beacon would be distinct to the Join 340 Network, and would be encrypted with the well-known Join Network key. 342 3.1. prefixes to use for join traffic 344 What prefix would the joining node for communication? There are 345 three options: 347 (1) just use link-local addresses (requires all traffic be tunneled) 349 (2) use a prefix specifically for join traffic (may be easier with a 350 join-only DODAG) 352 (3) use the same prefix as the rest of the traffic (may require more 353 complex ACLs, and leaks information to attackers) 355 4. security requirements 357 4.1. threat model 359 There are three kinds of threats that a join process must deal with: 360 threats to the joining node, threats to the resources of the network, 361 and threats to other joining nodes. 363 4.1.1. threats to the joining node 365 A node may be taken out of it's box by a malicious entity and powered 366 on. This could happen during shipping, while being stored in a 367 warehouse. The device may be subject to physical theft, or the goal 368 of the attacker may be to turn the device into a trojan horse of some 369 kind. Physical protection of the device is out of scope for this 370 document; this document will henceforth assume that the device is 371 sealed in some tamper-evident way and this document deals with 372 attacks over the network. 374 An attacker may attempt to convince the joining node that it is the 375 legitimate Production Network; this is done by putting up a 376 legitimate looking Join Network, and following the protocol as 377 described in this document. The Joining Node can not know if it has 378 the corrrect Production Network until steps 11-13, when it attempts 379 to validate the ClientCertificate provided by the JCE. 381 When the joining node determines that this is the incorrect network, 382 it must remember the PANID of the network that it has attempted to 383 join, and then look for another network to try. It SHOULD have some 384 limit as the number of times it will try before going back to sleep, 385 or shutting down, and it SHOULD take care not to consume more than 386 some specified percentage of any battery it might have. 388 Should a malicious production network be present at the same time/ 389 place as the legitimate production network, a the malicious agent 390 could intercept and replay various packets from the proper join 391 network, but ultimately this either results in a jamming-like denial 392 of service, and/or the the ClientCertificate will not validate. 394 It is a legitimate situation for there to be multiple possible join 395 networks, and the joining node may have to try each one before it 396 finds the network that it the right one for it. The incorrect, but 397 non-malicious networks will not attempt the 6top provisioning step, 398 and SHOULD return a negative result in steps 8/9, refusing the node's 399 NS. Those incorrect networks will be recognize that the node does 400 not belong to them, because they will be able to see the Joining 401 Node's IDevID in the ARO of step 4. 403 4.1.2. threats to the resources of the network 405 The production network has two important resources that may be 406 attacked by malicious Joining nodes: 1) energy/bandwidth, 2) memory 407 for routing entries. 409 A malicious joining node could send many NS messages to the Join 410 Assistant (from many made up addresses), which would send many NS/DAR 411 messages to the 6LBR, and this would consume bandwidth, and therefore 412 energy from the members of the mesh along the path to the 6LBR. This 413 can be mitigated by limited the total bandwidth available for 414 joining. 416 A malicious joining node could send many NS messages, and if the 6LBR 417 agreed to accept the new node (by IDevID), then the Join Assistant 418 would MAY inject routing information into mesh for the Joining node. 419 Non-storing DODAGs store are routing information in the DODAG Root 420 (probably the 6LBR), which is generally not a constrained node. 421 Storing DODAGs store routing entries at all nodes up to the DODAG, 422 and those are constrained nodes. Using a separate Join DODAG, and 423 having that DODAG be non-storing will reduce any impact on 424 intermediate nodes, but it does cause resources to be used for the 425 second DODAG, and it may have a code impact if the nodes otherwise 426 would not implement non-storing RPL. 428 4.1.3. threats to other joining nodes 430 A joining node (or the nodes of a malicious network, co-located near 431 the legitimate production network) may mount attacks on legitimate 432 nodes which have not yet joined. 434 The malicious nodes may attempt to perform 6top operations against 435 the joining node to keep it from being able to respond to the 436 legitimate 6top session from the legitimate JCE. During the Join 437 phase, the Joining node MUST have all other resources and protocols 438 turned off, even if they would normally be accessible as read-only 439 unauthenticated CoAP resources. 441 Malicious nodes could use the Join Network to mount various DTLS 442 based attacks against the joining node, such as sending very long 443 certificate chains to validate. One might think to limit the length 444 of such chains, but as shown in [I-D.richardson-6tisch-idevid-cert] 445 the chain may as a long as the supplier chain, plus may include 446 additional certificates due to resales of plants/equipment/etc. 447 Validating from a trusted certificate down to the specific 448 certificate which proves ownership would eliminate random certificate 449 chains, but the attacker could just feed the joining node legitimate 450 chains that it observed (and replayed) from the legitimate JCE. This 451 does no good; the Joining node finds that the DTLS connection is 452 invalid, but it may significantly run batteries down. 454 4.2. implementation cost 456 (storage of security material, computational cost) 458 4.3. denial of service 460 other communication impacts of security protocol mechanics 462 5. protocol requirements/constraints/assumptions 464 5.1. inline/offline 466 dependencies on centralized or external functionality, inline and 467 offline 469 6. time sequence diagram 470 +-----+ +------+ +----------+ +-----------+ 471 | | | | | JOIN | | Joining | 472 | JCE | | 6LBR | | Assistant| | Node | 473 +-----+ +------+ | (proxy) | | | 474 | | +----------+ +-----------+ 475 | | | | 476 | | |-------BEACON (1)---------->| 477 | | | | 478 | | |<----Router Solicitation----| 479 | | |---Router Advertisement---->| 480 | | | | 481 | | |<------CERTIFICATE----------| 482 | | | REQUEST (2) | 483 | | | | 484 | | | | 485 | | |-------CERTIFICATE--------->| 486 | | | RESPONSE (multiple) | 487 | | | (packets) | 488 | | | | 489 | | |<-----JOIN REQUEST (4) -----| 490 | | | (NS w/ARO ) | 491 | | | | 492 | |<---NS (DAR) (5)-----| | 493 |<--??(6)-| | | 494 | | | | 495 |--??(7)->| | | 496 | | | | 497 | |----NS (DAC)-(8)---->| | 498 | | +------+ | | 499 | || | 501 | | ACK +------+ | | 502 | | |-------JOIN ACK (9)-------->| 503 | | | | 504 | | | | 505 |================(10)==========>|----------6top----(11)----->| 506 | | | DTLS | 507 |<===============(13)===========|<---------CoAP----(12)------| 508 | | | (many packets) | 510 Figure 1: Message sequence for JOIN message 512 6.1. explanation of each step 513 6.1.1. step (1): enhanced beacon 515 A 6tisch join/synchronization beacon is broadcast periodically, and 516 is authenticated with a symmetric "beacon key": 518 well known JOIN key, such "JOIN6TISCH" 520 another key, provisioned in advance (OOB) 522 a shared symmetric key derived from public part of top level 523 certificate (a closely held "secret") 525 The purpose of this key is not to provide a high level of assurance, 526 but rather to filter out 6tisch traffic from another random traffic 527 that may be sharing the same radio frequencies. 529 These beacons are used for JOIN purpose only, and are not related to 530 the Enhanced Beacons used in the rest of 6tisch. 532 6.1.2. step (1B): send router solicitation 534 The joining node sends a router solicitation during the Aloha period 535 of the beacon. 537 6.1.3. step (1C): receive router advertisement 539 The joining node receives a router advertisement from the Join 540 Assistant. It could include 6CO options to help compress packets, 541 and should contain a prefix appropriate for join traffic. 543 6.1.4. step (2): acquire authorizer key 545 Step (4) will involve doing a public key encryption to node 546 performing the authorization management role. In order to do this, 547 the new node needs to know the public key of the manager, and so in 548 this step it requests that certificate from the neighbour that that 549 it received the beacon from. 551 This step is optional, and it's benefit has not been demonstrated by 552 a real world use case, but has been retained for now 554 6.1.5. step (3): receive authorizer key 556 the proxy neighbour sends the key in one or more messages, along with 557 the address of the authorizing server. The address of the 558 authorization server could be an attribute of the certificate that is 559 received. 561 6.1.6. step (4): join request 563 A regular Neighbour Solicitation is sent. This should contain an ARO 564 (or EARO) option containing the Joining Nodes' IDevID. The ARO/EARO 565 will be proxied by the Join Assistant as part of normal 6LowPAN 566 processing for leaf nodes (non-RPL nodes) upwards to the 6LBR 568 6.1.7. step (5): NS duplicate address request (DAR) 570 6.1.8. step (7): 6LBR informs JCE of new node 572 6.1.9. step (8): JCE informs/acks to 6LBR of new node 574 The JCE could reply in the negative, and this would cause a DAC 575 failure, TBD 577 6.1.10. step (9): NS duplicate address confirmation (DAC) 579 6.1.11. step (10): JCE initiates connection to joining node 581 The double lines indicate that an IPIP tunnel operation may be 582 required. If a straight DAO or seperate Join DODAG is used, then 583 this is just a straight forwarding root to leaf node forwarding 584 operation, and involves either using source routes (non-storing), or 585 just forwarding for storing DODAGs. 587 A specific bandwidth allocation would be used for this join traffic 589 The production network encryption keys would be used for the join 590 traffic 592 6.1.12. step (11): Join Assistant forwards packet to joining node 594 The JOIN Assistant would forward traffic to the Joining Node. 595 Recognizing that this traffic the JOIN Network, the JOIN Assistant 596 would use the JOIN Network key. 598 6.1.13. step (12): Joining node replies 600 The joining node replies, using JOIN Network key. 602 6.1.14. step (13): Join Assistant forwards reply to JCE 604 The JOIN Assistant, recognizing that the traffic came from the JOIN 605 Network, restricts the destination that can be reached to the the JCE 606 only. It can do this in a stateless way, and it does NOT need to 607 track the traffic at (10) to open pinhole, etc. 609 Recognizing that the traffic came from the JOIN Network, the traffic 610 would be placed into a bandwidth allocation (track?) that allows such 611 traffic. 613 6.2. size of each packet 615 and number of frames needed to contain it. 617 7. resulting security properties obtained from this process 619 An end to end IPv6 CoAP/DTLS connection is created between the JCE 620 and the Joining Node. This connection carries 6top commands to 621 update security parameters. This results in either deployment of a 622 single-level, locally relevant certificate, or deployment of a 623 network-wide symmetric "Master Key" 625 8. deployment scenarios underlying protocol requirements 627 9. device identification 629 The JCE authenticates the joining node using a certificate chain 630 provided inline during the DTLS negotiation. The certificate chain 631 is rooted in a vendor certificate that the JCE must have preloaded, 632 and is a statement as to the node's 802.1AR IDevID. The joining node 633 authenticates the 635 9.1. PCE/Proxy vs Node identification 637 9.2. Time source authentication / time validation 639 Note: RPL Root authentication is a chartered item 641 9.3. description of certificate contents 643 9.4. privacy aspects 645 The EUI-64 of the Joining node is transmitted using a Well Known 646 layer-2 encryption key. Within the ARO/EARO of the Neighbour 647 Solicitation is an OUI, which may be identical to the EUI-64 of the 648 Joining node, or it might be an unrelated IDevID. 650 An eavesdropper can therefore learn something about the manufacturer 651 of every device as it joins. 653 10. slotframes to be used during join 655 how is this communicated in the (extended) beacon. 657 11. configuration aspects 659 (allocation of slotframes after join, network statistics, 660 neighboetc.) 662 12. authorization aspects 664 lifecycle (key management, trust management) 666 12.1. how to determine a proxy/PCE from a end node 668 12.2. security considerations 670 what prevents a node from transmitting when it is not their turn 671 (part one: jamming) 673 can a node successfully communicate with a peer at a time when not 674 supposed to, may be tied to link layer security, or will it be 675 policed by receiver? 677 13. security architecture 679 security architecture and fit of e.g. join protocol and provisioning 680 into this 682 14. Posture Maintenance 684 (SACM related work) 686 15. Security Considerations 688 16. Other Related Protocols 690 17. IANA Considerations 692 18. Acknowledgements 694 19. References 696 19.1. Normative references 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC 2119, March 1997. 701 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 702 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 703 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 704 Lossy Networks", RFC 6550, March 2012. 706 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 707 "Neighbor Discovery Optimization for IPv6 over Low-Power 708 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 709 November 2012. 711 [IEEE.802.1AR] 712 Institute of Electrical and Electronics Engineers, "Secure 713 Device Identity", IEEE 802.1AR, 2009, 714 . 716 [I-D.ietf-6tisch-coap] 717 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 718 Interaction using CoAP", draft-ietf-6tisch-coap-00 (work 719 in progress), May 2014. 721 [I-D.ietf-6tisch-6top-interface] 722 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 723 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 724 6top-interface-00 (work in progress), March 2014. 726 [I-D.ietf-6tisch-architecture] 727 Thubert, P., Watteyne, T., and R. Assimiti, "An 728 Architecture for IPv6 over the TSCH mode of IEEE 729 802.15.4e", draft-ietf-6tisch-architecture-01 (work in 730 progress), February 2014. 732 [I-D.seitz-ace-problem-description] 733 Seitz, L. and G. Selander, "Problem Description for 734 Authorization in Constrained Environments", draft-seitz- 735 ace-problem-description-00 (work in progress), May 2014. 737 [I-D.richardson-6tisch-idevid-cert] 738 Richardson, M., "X509.v3 certificate extension for 739 authorization of device ownership", draft-richardson- 740 6tisch-idevid-cert-00 (work in progress), May 2014. 742 [I-D.wang-6tisch-6top-sublayer] 743 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 744 Operation Sublayer (6top)", draft-wang-6tisch-6top- 745 sublayer-00 (work in progress), February 2014. 747 19.2. Informative references 749 [I-D.thubert-6lowpan-backbone-router] 750 Thubert, P., "LoWPAN Backbone Router", draft-thubert- 751 6lowpan-backbone-router-00 (work in progress), March 2008. 753 [I-D.kelsey-intarea-mesh-link-establishment] 754 Kelsey, R., "Mesh Link Establishment", draft-kelsey- 755 intarea-mesh-link-establishment-05 (work in progress), 756 February 2013. 758 [I-D.ohba-6tisch-security] 759 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P., and 760 A. Yegin, "Security Framework and Key Management Protocol 761 Requirements for 6TiSCH", draft-ohba-6tisch-security-01 762 (work in progress), March 2014. 764 [I-D.piro-6tisch-security-issues] 765 Piro, G., Boggia, G., and L. Grieco, "Layer-2 security 766 aspects for the IEEE 802.15.4e MAC", draft-piro-6tisch- 767 security-issues-02 (work in progress), June 2014. 769 Author's Address 771 Michael C. Richardson 772 Sandelman Software Works 773 470 Dawson Avenue 774 Ottawa, ON K1Z 5V7 775 CA 777 Email: mcr+ietf@sandelman.ca 778 URI: http://www.sandelman.ca/