idnits 2.17.1 draft-richardson-6tisch-dtsecurity-secure-join-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 == Line 142 has weird spacing: '...imprint the p...' == Line 153 has weird spacing: '...ollment the p...' == Line 158 has weird spacing: '... pledge the p...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 20, 2016) is 2745 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC7554' is defined on line 892, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-6lo-privacy-considerations-03 == Outdated reference: A later version (-21) exists of draft-ietf-6tisch-minimal-16 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-03 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-07 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-09 == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-04 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-08 Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6tisch Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Informational October 20, 2016 5 Expires: April 23, 2017 7 6tisch Secure Join protocol 8 draft-richardson-6tisch-dtsecurity-secure-join-01 10 Abstract 12 Charter: The WG will continue working on securing the join process 13 and making that fit within the constraints of high latency, low 14 throughput and small frame sizes that characterize IEEE802.15.4 TSCH. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 23, 2017. 33 Copyright Notice 35 Copyright (c) 2016 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.2.1. One-Touch Assumptions . . . . . . . . . . . . . . . . 4 54 1.2.2. Factory provided credentials (if any) . . . . . . . . 5 55 1.2.3. Credentials to be introduced . . . . . . . . . . . . 5 56 1.3. Network Assumptions . . . . . . . . . . . . . . . . . . . 5 57 1.3.1. Security above and below IP . . . . . . . . . . . . . 6 58 1.3.2. Join network assumptions . . . . . . . . . . . . . . 7 59 1.3.3. Number and cost of round trips . . . . . . . . . . . 7 60 1.3.4. Size of packets, number of fragments . . . . . . . . 7 61 1.4. Target end-state for join process . . . . . . . . . . . . 7 62 2. Join Protocol . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.1. Diagram of Join Process . . . . . . . . . . . . . . . . . 7 64 2.2. Description of Pledge States in Join Process . . . . . . 8 65 2.2.1. (1) Layer-2 Enhanced Beacon . . . . . . . . . . . . . 8 66 2.2.2. (1B) Layer-3 Router Advertisement . . . . . . . . . . 8 67 2.2.3. (2) Pledge sends (unicast) Neighbor Solicitation to 68 Join Assistant . . . . . . . . . . . . . . . . . . . 8 69 2.2.4. (3) Join Assistant sends Query to Registar . . . . . 9 70 2.2.5. (4) Join Assistant receives Acceptance response from 71 Registrar . . . . . . . . . . . . . . . . . . . . . . 9 72 2.2.6. (5) Pledge receives (unicast) Neighbor Advertisement 73 from join assistant . . . . . . . . . . . . . . . . . 9 74 2.3. Join process state machine for pledge . . . . . . . . . . 10 75 2.4. Description of Join Assistant States in Join Process . . 11 76 2.4.1. Processing of Insecure Packets . . . . . . . . . . . 12 77 3. Join Assistant to Registrar protocol . . . . . . . . . . . . 13 78 3.1. Discovery of Registrar . . . . . . . . . . . . . . . . . 13 79 3.2. Notification of a new pledge to Registar . . . . . . . . 14 80 3.3. Passing of traffic from Pledge to Registar . . . . . . . 14 81 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 82 4.1. Privacy Considerations for Production network . . . . . . 15 83 4.2. Privacy Considerations for New Pledges . . . . . . . . . 15 84 4.2.1. EUI-64 derived address for join time IID . . . . . . 16 85 4.3. Privacy Considerations for Join Assistant . . . . . . . . 16 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 88 7. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 17 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 8.2. Informative References . . . . . . . . . . . . . . . . . 19 92 Appendix A. appendix . . . . . . . . . . . . . . . . . . . . . . 20 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 95 1. Introduction 97 Enrollment of new nodes into LLNs present unique challenges. The 98 constrained nodes has no user interfaces, and even if they did, 99 configuring thousands of such nodes manually is undesireable from a 100 human resources issue, as well as the difficulty in getting 101 consistent results. 103 This document is about a standard way to introduce new nodes into a 104 6tisch network that does not involve any direct manipulation of the 105 nodes themselves. This act has been called "zero-touch" 106 provisioning, and it does not occur by chance, but requires 107 coordination between the manufacturer of the node, the service 108 operator running the LLN, and the installers actually taking the 109 devices out of the shipping boxes. 111 In other installations (such as some factory/industrial settings, and 112 for some utilities), it is possible to pass devices through a 113 "provisioning" room of some kind where the device in factory default 114 state may be touched once (via a cable, or a push button, or by being 115 placed in a faraday cage, etc.) such that the devices can be 116 initialized in a way specific to that installation. The devices are 117 then returned to inventory, and may be deployed at some future time. 118 The node is not provisioned with the current keying material, as the 119 network will need to be regularly rekeyed (even the algorithms may 120 change!), so in the one-touch provisioning case, the goal is simply 121 to introduce some elements into the new node (the "pledge") such that 122 the enrollment process will take less energy and fewer network 123 resources. 125 1.1. Terminology 127 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 128 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 129 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 130 [RFC2119] and indicate requirement levels for compliant STuPiD 131 implementations. 133 The following terminology is repeated from 134 [I-D.ietf-anima-bootstrapping-keyinfra] so as to have a common way to 135 speak: 137 drop ship The physical distribution of equipment containing the 138 "factory default" configuration to a final destination. In zero- 139 touch scenarios there is no staging or pre-configuration during 140 drop-ship. 142 imprint the process where a device obtains the cryptographic key 143 material to identity and trust future interactions with a network. 144 This term is taken from Konrad Lorenz's work in biology with new 145 ducklings: during a critical period, the duckling would assume 146 that anything that looks like a mother duck is in fact their 147 mother. An equivalent for a device is to obtain the fingerprint 148 of the network's root certification authority certificate. A 149 device that imprints on an attacker suffers a similar fate to a 150 duckling that imprints on a hungry wolf. Securely imprinting is a 151 primary focus of this document. [duckling] anticipates this use. 153 enrollment the process where a device presents key material to a 154 network and acquires a network specific identity. For example 155 when a certificate signing request is presented to a certification 156 authority and a certificate is obtained in response. 158 pledge the prospective device, which has the identity provided to at 159 the factory. Neither the device nor the network knows if the 160 device yet knows if this device belongs with this network. This 161 is definition 6, according to [pledge]. 163 Audit Token A signed token from the manufacturer authorized signing 164 authority indicating that the bootstrapping event has been 165 successfully logged. This has been referred to as an 166 "authorization token" indicating that it authorizes bootstrapping 167 to proceed. 169 Ownership Voucher A signed voucher from the vendor vouching that a 170 specific domain "owns" the new entity as defined in 171 [I-D.ietf-netconf-zerotouch]. 173 1.2. Credentials 175 In the zero-touch scenario, every device expected to be drop shipped 176 would have an [ieee802-1AR] manufacturer installed certificate (MIC). 177 The private key part of the certificate would either be generated in 178 the device, or installed securely (and privately) as part of the 179 manufacturer process. [cullenCiscoPhoneDeploy] provides an example 180 of process which has been active for a good part of a decade. 182 The MIC would be signed by the manufacturer's CA, the public key 183 component of that would be included in the firmware. 185 1.2.1. One-Touch Assumptions 187 In a one-touch scenario, devices would be provided with some 188 mechanism by which a secure association may be made in a controlled 189 environment. There are many ways in which this might be done, and 190 detailing any of them is out of scope for this document. But, some 191 notion of how this might be done is important so that the underlying 192 assumptions can be reasoned about. 194 Some examples of how to do this could include: * JTAG interface * 195 serial (craft) console interface * pushes of physical buttons 196 simulatenous to network attachment * insecured devices operated in a 197 Faraday cage 199 There are likely many other ways as well. What is assumed is that 200 there can be a secure, private conversation between the Join 201 Coordination Entity, and the Pledge, and that the two devices can 202 exchange some trusted bytes of information. 204 1.2.2. Factory provided credentials (if any) 206 When a manufacturer installed certificate is provided as the IDevID, 207 it SHOULD contain a number of fields. 208 [I-D.ietf-anima-bootstrapping-keyinfra] provides a detailed set of 209 requirements. 211 A manufacturer unique serial number MUST be provided in the 212 serialNumber SubjectAltName extension, and MAY be repeated in the 213 Common Name. There are no sequential or numeric requirements on the 214 serialNumber, it may be any unique value that the manufacturer wants 215 to use. The serialNumber SHOULD be printed on the packaging and/or 216 on the device in a discrete way. 218 1.2.3. Credentials to be introduced 220 The goal of the bootstrap process is to introduce one or more new 221 locally relevant credentials: 223 1. a certificate signed by a local certificate authority/registrar. 224 This is the LDevID of [ieee802-1AR]. 226 2. alternatively, a network-wide key to be used to secure L2 227 traffic. 229 3. alternatively, a network-wide key to be used to authenticate per- 230 peer keying of L2 traffic using a mechanism such as provided by 231 [ieee802159]. 233 1.3. Network Assumptions 235 This document is about enrollment of constrained devices [RFC7228] to 236 a constrained network. Constrained networks is such as [ieee802154], 237 and in particular the time-slotted, channel hopping (tsch) mode, 238 feature low bandwidths, and limited opportunities to transmit. A key 239 feature of these networks is that receivers are only listening at 240 certain times. 242 1.3.1. Security above and below IP 244 802.15.4 networks have three kinds of layer-2 security: 246 o a network key that is shared with all nodes and is used for 247 unicast and multicast. 249 o a series of network keys that are shared (agreed to) between pairs 250 of nodes (the per-peer key) 252 o a network key that is shared with all nodes (through a group key 253 management system), and is used for multicast traffic only 255 Setting up the credentials to bootstrap one of these kinds of 256 security, (or directly configuring the key itself for the first case) 257 is required. This is the security below the IP layer. 259 Security is required above the IP layer: there are three aspects 260 which the credentials in the previous section are to be used. 262 o to provide for secure connection with a Path Computation Element 263 [RFC4655], or other LLC (see ({RFC7554}} section 3). 265 o to initiate a connection between a Resource Server (RS) and an 266 application layer Authorization Server (AS and CAS from 267 [I-D.ietf-ace-actors]). 269 1.3.1.1. Perfect Forward Secrecy 271 Perfert Forward Secrecy (PFS) is the property of a protocol such that 272 complete knowledge of the crypto state (for instance, via a memory 273 dump) at time X does not imply that data from a disjoint time Y can 274 also be recovered. ([PFS]). 276 PFS is important for two reasons: one is that it offers protection 277 against the compromise of a node. It does this by changing the keys 278 in a non-deterministic way. This second property also makes it much 279 easier to remove a node from the network, as any node which has not 280 participated in the key changing process will find itself no longer 281 connected. 283 1.3.2. Join network assumptions 285 The network which the new pledge will connect to will have to have 286 the following properties: 288 o a known PANID. The PANID 0xXXXX where XXXX is the assigned RFC# 289 for this document is suggested. 291 o a minimal schedule with some Aloha time. This is usually in the 292 same slotframe as the Extended Beacon, but a pledge MUST listen 293 for an unencrypted Extended Beacon to so that it can synchronize. 295 o a known K1 key, as described in [I-D.ietf-6tisch-minimal] section 296 10, and used for reasons similar to [iec62591]. 298 1.3.3. Number and cost of round trips 300 1.3.4. Size of packets, number of fragments 302 1.4. Target end-state for join process 304 2. Join Protocol 306 This section describes the interaction between a new pledge and the 307 Join Assistant. 309 2.1. Diagram of Join Process 311 This time sequence diagram intentionally shows additional layer-2 and 312 layer-3 interactions, in order to put the entire process into 313 context. 315 PLEDGE(JN) JOIN ASSISTANT(JA) JCE 316 <--------------- BEACON-L2 (1) 317 <-------RA ------ (1B) 318 ---- NS w/ARO ---> (2) 319 ------- QUERY----> (3) 320 <------ REPLY----- (4) 321 <--- NA answer---- (5) 323 some time later 324 <-----coaps--------<=======IPIP-COAPS==== (6) 325 multiple trips 326 ------------------->====================> (7) 328 2.2. Description of Pledge States in Join Process 330 2.2.1. (1) Layer-2 Enhanced Beacon 332 A new pledge must listen for a beacon for a period of at least 2s 333 (HELP) on each of the 16 possible channels. The pledge SHOULD 334 collect all beacons from heard on all channels before selecting a 335 beacon to start with. If the pledge is unable to record all of the 336 beacons that it hears due to limitations on volatile storage, then it 337 should at least attempt to record the detail as to how to find that 338 beacon again (channel, time sequence). 340 This search process entails having the pledge keep the receiver 341 portion of it's radio active for the entire period of time. 343 The selection of which beacon to start with is outside the scope of 344 this document. Implementers SHOULD make use of information such as: 345 whether the L2 address of the Beacon has been tried before, whether a 346 Router Advertisement IE is present, any Network Identifier 347 [I-D.richardson-6lo-ra-in-ie] seen, and the strength of the signal. 349 Once a candidate network has been selected, the pledge can transition 350 into a low-power duty cycle, waking only when the provided schedule 351 indicates ALOHA slots which the pledge may use for the join process. 353 2.2.2. (1B) Layer-3 Router Advertisement 355 If [I-D.richardson-6lo-ra-in-ie] has not been used to embed a router 356 advertisement in the Enhanced Beacon, then the pledge MUST wait to 357 hear a Router Advertisement to know the layer-3 address of the 358 adjacent router. These will be broadcast periodically during the 359 ALOHA slot. 361 A pledge MAY timeout and send a layer-2 unicast Router Solicitation 362 (to the layer-2 of the Enhanced Beacon) to the layer-3 all-routers 363 address. A pledge MAY also take this timeout to mean that this 364 router is unwilling to perform Join Assistant activities and the 365 pledge should move on to another Enhanced Beacon. 367 2.2.3. (2) Pledge sends (unicast) Neighbor Solicitation to Join 368 Assistant 370 This NS message is formed much like a Duplicate Address Detection 371 (DAD) message described in [RFC6775] section-4.3: it is a 372 solicitation by the pledge for it's own address. [RFC6775] does not 373 describe doing DAD for link-local address however, so this aspect is 374 new. 376 The Join Assistant will not validate the uniqueness using the DAR/DAC 377 mechanism, but will otherwise process the NS as per normal: 378 populating neighbor cache entries. The Join Assistant will take 379 extra care with expiring neighbor cache entries: unsecured NS should 380 never push secured NCE entries out of the cache or overwrite them. 381 There are two equivalent ways to do this: 383 1. marking the origin of the NCE and limiting unsecured ones to some 384 portion of the entries; 386 2. by considering unsecured NS to be arriving from a different 387 virtual interface (different if_index) than secured ones. NCEs 388 from different interfaces SHOULD already not be mixed. 390 The pledge SHOULD NOT have configured a short Layer-2 address as it 391 has no way to allocate a non-duplicate short address. It SHOULD have 392 formed a standard 64-bit layer-3 link-local address using a built-in 393 IID. This IID MUST be placed into the Address Resolution option 394 (ARO) option in the Neighbor Soliciation, as it serves as the index 395 by which the domain registrar will use to identify the device. 397 The IID MAY be related to the layer-2 address, but privacy 398 considerations recommend that the IID SHOULD instead be a form a 399 stable privacy address [RFC7217]. Whichever method is used MUST be 400 decided at manufacturing time, as the IID is also repeated as the 401 SerialNumber in the Manufacturer Installed Certificate (MIC), also 402 referred to as the 802.1AR IDevID. 404 2.2.4. (3) Join Assistant sends Query to Registar 406 This step does not involve the pledge, and it is described in section 407 (#jastates). 409 2.2.5. (4) Join Assistant receives Acceptance response from Registrar 411 This step does not involve the pledge, and it is described in section 412 (#jastates). 414 2.2.6. (5) Pledge receives (unicast) Neighbor Advertisement from join 415 assistant 417 This NA message is again identical to the Duplicate Address Detection 418 mechanism described in [RFC6775]. The status field of the ARO is 419 extended (see (#ianaconsiderations)) to include an additional status 420 value ND_NS_JOIN_DECLINED. 422 The pledge, upon receipt of ND_NS_JOIN_DECLINED considers that this 423 network is not an appropriate network to join, and SHOULD move on to 424 attempt other networks. The pledge MUST also realize that this NA 425 message MAY have been forced, and it SHOULD attempt joining this 426 network again at a future time, but MUST NOT repeatedly attempt to 427 join the same network. 429 The pledge, upon receipt of a Neighbor Cache Full response SHOULD 430 attempt to join using a different join assistant on the same network. 432 The pledge, upon receipt of a Duplicate Address response SHOULD 433 attempt to join using a different join assistant on a different 434 network, if it has such offers. If it has no such offers, it should 435 wait at least NEIGHBOR-CACHE TIMEOUT, and then retry. This may be a 436 sign of a Denial of Service attack, or it may be a non-malicious mis- 437 configuration. 439 Upon receive of a successful NA, the pledge SHOULD consider that it 440 is now in enrolled in a join queue. The pledge SHOULD resend 441 Neighbor Soliciation (NUD) messages periodically as described in 442 [RFC6775] to maintain the neighbor cache entry. 444 A pledge with other Join Assistant offers MAY abandon this Join 445 Assistant after a period of XXX minutes and attempt to join using a 446 different Join Assistant. 448 2.3. Join process state machine for pledge 450 +----------------+ +----------+ 451 | collecting |-------->| sleep 1m | 452 | beacons |<----- +~~~~~~~~~~+ 453 +----------------+ \______/ ^ 454 | | 455 V | no beacons 456 +-----------------+ | remain 457 | try next/first | | 458 | beacon/sched |-----------------/ 459 +-----------------+<____________ timeout 460 | \--.<--. 461 | send NS/DAD <-------. | | 462 /-------->| w/ARO | | | 463 | | timeout| | | 464 | V retries<3 | | | 465 | +-----------------+ | | | 466 | | waiting for | | | | 467 | | NA w/ARO |----------->----> | 468 | +-----------------+ or invalid NA | 469 | | | 470 | | | 471 | | | 472 | V | 473 | +-----------------+ DTLS failure | 474 | | open DTLS 6p |--------------------/ 475 | | for system | ^ 476 | | keychain |<--------\ | 477 | +-----------------+ | | 478 | | | conclude | 479 | | kill DTLS | not net | 480 | | try again | looking | 481 | | retries<3 | for | 482 | V | | 483 | +-----------------+ | | 484 | | validate audit |---------/----------/ 485 | |token posted to | does not validate 486 | | proper URL | 487 | +-----------------+ 488 | | 489 |too long | validate 490 |try | audit 491 |again | token 492 | V 493 | +-----------------+ 494 \-| accept 6p trans-| 495 | actions for new | 496 | certificate | 497 +-----------------+ 498 | 499 | receive new certificate, 500 V restart with beacon 501 X run appropriate KMP 503 2.4. Description of Join Assistant States in Join Process 505 The Join Assistant is a standard 6LR. It processes packets as 506 described in [RFC6775], [I-D.ietf-6tisch-minimal] from secured 507 (encrypted) sources. 509 In particular the maintenance of Neighbor Cache Entries as described 510 in [RFC6775] section 3.5. The Join Assistant maintains two sets of 511 NCE for each physical interface that it has: one set is for secured 512 neighbors, and the other is for new pledges that wish to join. The 513 storage allocated for pledges will generally be a small fraction of 514 available space. The Join Assistant will garbage collect the 515 different caches according to different thresholds. It MAY chose to 516 free space from the insecure cache to make space for additional 517 secure entries, but it MUST NOT do the opposite. 519 It sends Enhanced Beacons which are authenticated with the network- 520 wide key ("K2"), but it does not encrypt the Beacons. 522 In addition, it listen for packets "encrypted" with the well-known 523 "K1" key, and when it receives them, it considers them to be as 524 "Insecure Packets". It MAY also accept unencrypted, unauthenticated 525 packets as being "Insecure Packets" 527 Non-Join Assistant 6LRs would never accept K1 packets, nor 528 unauthenticated packets. Normal 6LRs and hosts MUST accept 529 unencrypted Enhanced Beacons which can be authenticated with the "K2" 530 key. 532 In addition to seperating the secured and insecured packets for 533 inbound processing, the Join Assistant also allocates a unique IID 534 for the insecured interface. This IID is used to configure the Link 535 Local address on that virtual interface. This Link Local address is 536 called the Insecure Join Assistant Link Local, or IJALL. 538 In addition, this IID is combined with the global prefix(es) (as 539 found in various PIO(s) from the routing protocols). This additional 540 address is configured as an alias on the loopback interface such that 541 the Join Assistant can receive packets to this address via secured 542 network. This activity SHOULD generate a routing protocol update 543 (such as an updated DAO). This IID SHOULD be generated using a 544 stable privacy address mechanism as described in [RFC7217]. The 545 easiest is to assign the insecure virtual interface a unique 546 if_index. This new address is called the Pledge Tunnel End Point 547 Address, or PTEPA. 549 2.4.1. Processing of Insecure Packets 551 Only the following insecure packets are to be accepted by the Join 552 Assistant: 554 1. Unicast Neighbor Solicitations. 556 2. Unicast Link-Local UDP packets with a destination port that map 557 to the Join Assistant's IPIP proxy. 559 2.4.1.1. Processing of Insecure Neighbor Solicitation packets 561 Upon receipt of an insecure unicast NS with an ARO option, the Join 562 Assistant looks up an NCE by the IID contained in the ARO in the 563 insecure cache. If it finds an existing there are three 564 possibilities: 566 1. a lookup for this entry has previously been completed, and has 567 resulted in a negative result. In this case, a negative 568 ND_NS_JOIN_DECLINED NA is returned. The Join Assistant SHOULD 569 rate limit the number of these messages that it is willing to 570 return. 572 2. a lookup for this entry has previously been done, and has 573 resulted in a positive result. The NCE entry should be 574 "refresh", to keep it in the cache for a longer period of time, 575 and a new NA returned with a positive status. 577 3. a lookup for this entry has previously been started, but no 578 result has been received. In this case the Join Assistant SHOULD 579 remain silent. The Join Assistant may wish to send a GRASP 580 M_NOOP message to verify that the connection is still useable if 581 it has not receive any traffic in some time. 583 If it does not find an existing entry, and there is space for another 584 entry, (or it can make space via garbage collection), then a new 585 entry is created, marked to be "in progress", and a new GRASP 6JOIN 586 query is initiated, see section (#6joingrasp). 588 3. Join Assistant to Registrar protocol 590 There are three aspects to the protocols that the Join Assistant uses 591 to communicate about its needs. They are: 593 1. Discovery of Registrar 595 2. Notification of new pledge to Registrar 597 3. Passing of traffic from Pledge to Registar 599 3.1. Discovery of Registrar 601 The address of the registrar MAY be determined by other protocols, 602 such as DHCP, RA or RPL extensions, or provisioned into the Join 603 Assistant via other configuration protocol such as 6p. 605 In order to support fully autonomic operations, the Join Assistant 606 MAY use a GRASP discovery ([I-D.ietf-anima-grasp]) to find the 607 address of the Registrar. [I-D.richardson-anima-6join-discovery] 608 describes the details of the process. 610 In 6tisch networks multicast is not always available, requiring 611 additional protocol [RFC7731] effort. Instead of doing a multicast 612 GRASP discovery, the Join Assistant SHOULD instead to a TCP connect 613 to the GRASP_LISTEN_PORT on the IP address of the DODAG root (when 614 RPL is used as the routing protocol for 6tisch), or the ABRO address 615 when another protocol is used. The Join Assistant should then issue 616 the appropriate M_DISCOVERY method using the 6JOIN objective. The 617 GRASP discovery will then reply using the same TCP connection as per 618 Unicast Discovery in [I-D.ietf-anima-grasp] section TBD. 620 3.2. Notification of a new pledge to Registar 622 As illustrated in (#joindiagram), when the Join Assistant receives a 623 Neighbor Solication from a pledge, it must notify the Registar of the 624 pledge, indicating to it how to reach the new pledge. The Registrar 625 will respond with a positive acknowledgement if the Registrar is 626 willing/able to accept the pledge. The Registrar will respond with a 627 negative acknowledgement if the provided pledge identity (the IID in 628 the ARO) is not one that the Registrar recognizes as belonging to 629 this network. 631 The Registrar runs an ASA which is called the 6JOIN ASA (which can be 632 discovered above). This query/response is done using GRASP with the 633 discovered ASA process. 635 The query process is described in CDDL as: 637 request-6join-query = [M_REQ_NEG, session-id, "6JOIN", [IID, "6p-ipip"]] 638 IID = bytes .size 8 640 The response from the Registrar is describe as: 642 response-6join-query = [M_END, session-id, [O_ACCEPT]] 644 or for a negative response: 646 response-6join-query = [M_END, session-id, [O_DECLINE]] 648 for the 6p-ipip, the Registrar will need to know where to send the 649 IPIP packets to. The Join Assistant will initiate the TCP connection 650 to the Registrar's ASA using the IPv6 address associated with the 651 insecure interface on which the pledge is located, i.e. using the 652 PTEPA. 654 3.3. Passing of traffic from Pledge to Registar 656 When the Registrar is ready to initiate the pledge into the domain, 657 the Registrar will reach out to the pledge using a secure CoAP 658 protocol (6p). The security is provided using DTLS or EDHOC. As the 659 pledge has only a link-local address, and the Registrar is not co- 660 located on the same layer-2 as the pledge, the traffic must be 661 relayed through the Join Assistant. 663 To do this the Registrar needs to configure a Link Local address on a 664 virtual inteface which is the same as the PTEPA derived address. 666 The Registrar then sends it's traffic (UDP packets with CoAPS 667 inside), inside of an IPIP header to the Join Assistant. The outer 668 IP header is from the Registrar to the PTEPA. The inner IP is from 669 the link local address configured above, and the destination is the 670 Link Local address of the pledge. 672 The Registrar knows the IJALL by taking the IID from the connection 673 address above, and knows the Link Local of the pledge from the IID in 674 the objective message. 676 The Join Assistant, upon receipt of the IPIP traffic from the 677 Registar on it's PTEPA, then decapsulates it and forwards it on the 678 appropriate. (This is identical code to decapsulation of IPIP 679 headers as specified in [I-D.ietf-roll-useofrplinfo]. 681 The Join Assistant, upon receiving traffic from the pledge to the 682 IJALL, it encapsulates it into an IPIP header, setting the source of 683 this outer header to the PTEPA, and the destination being the 684 Registrar. 686 The Join Assistant can do this for as many pledges as the Registrar 687 decides to communicate with, without using any additional per-pledge 688 state other than the obligatory Neighbor Cache Entries needed to 689 translate L3 addresses to L2 addresses. 691 4. Privacy Considerations 693 [I-D.ietf-6lo-privacy-considerations] details a number of privacy 694 considerations important in Resource Constrained nodes. There are 695 two networks and three sets of constrained nodes to consider. They 696 are: 1. the production nodes on the production network. 2. the new 697 pledges, which have yet to enroll, and which are on a join network. 698 3. the production nodes which are also acting as proxy nodes. 700 4.1. Privacy Considerations for Production network 702 The details of this are out of scope for this document. 704 4.2. Privacy Considerations for New Pledges 706 New Pledges do not yet receive Router Advertisements with PIO 707 options, and so configure link-local addresses only based upon 708 layer-2 addresses using the normal SLAAC mechanisms described in 709 [RFC4191]. 711 These link-local addresses are visible to any on-link eavesdropper 712 (who is synchronized to the same Join Assistant), so regardless of 713 what is chosen they can be seen. This link-layer traffic is 714 encapsulated by the Join Assistant into IPIP packets and carried to 715 the JCE. The traffic SHOULD never leave the operator's network, and 716 no outside traffic should enter, so it should not be possible to do 717 any ICMP scanning as described in 718 [I-D.ietf-6lo-privacy-considerations]. 720 The join process described herein requires that some identifier 721 meaningful to the network operator be communicated to the JCE via the 722 Neighbor Advertisement's ARO option. This need not be a manufacturer 723 created EUI-64 as assigned by IEEE; it could be another value with 724 higher entropy and less interesting vendor/device information. 725 Regardless of what is chosen, it can be used to track where the 726 device attaches. 728 For most constrained device, network attachment occurs very 729 infrequently, often only once in their lifetime, so tracking 730 opportunities may be rare. 732 Further, during the enrollment process, a DTLS connection connection 733 will be created. Unless TLS1.3 is used, the device identity will be 734 visible to passive observers in the 802.11AR IDevID certificate that 735 is sent. Even when TLS1.3 is used, an active attacker could collect 736 the information by simply connecting to the device; it would not have 737 to successful complete the negotiation either, or even attempt to 738 Man-In-The-Middle the device. 740 There is, at the same time, significant value in avoiding a link- 741 local DAD process by using an IEEE assigned EUI-64, and there is also 742 significant advantage to the operator being able to see what the 743 vendor of the new device is. 745 4.2.1. EUI-64 derived address for join time IID 747 It is therefore suggested that the IID used in the link-local address 748 used during the join process be a vendor assigned EUI-64. After the 749 join process has concluded, the device SHOULD be assigned a unique 750 randomly generated long address, and a unique short address (not 751 based upon the vendor EUI-64) for use at link-layer. At that point, 752 all layer-3 content is encrypted by the layer-2 key. 754 4.3. Privacy Considerations for Join Assistant 755 5. Security Considerations 757 6. IANA Considerations 759 This document allocates one value from the subregistry "Address 760 Registration Option Status Values": ND_NS_JOIN_DECLINED Join 761 Assistant, JOIN DECLINED (TBD-AA) 763 7. Protocol Definition 765 8. References 767 8.1. Normative References 769 [cullenCiscoPhoneDeploy] 770 Jennings, C., "Transitive Trust Enrollment for Constrained 771 Devices", 2012, . 774 [I-D.ietf-6lo-privacy-considerations] 775 Thaler, D., "Privacy Considerations for IPv6 over Networks 776 of Resource-Constrained Nodes", draft-ietf-6lo-privacy- 777 considerations-03 (work in progress), September 2016. 779 [I-D.ietf-6tisch-minimal] 780 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 781 Configuration", draft-ietf-6tisch-minimal-16 (work in 782 progress), June 2016. 784 [I-D.ietf-anima-bootstrapping-keyinfra] 785 Pritikin, M., Richardson, M., Behringer, M., and S. 786 Bjarnason, "Bootstrapping Remote Secure Key 787 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 788 keyinfra-03 (work in progress), June 2016. 790 [I-D.ietf-anima-grasp] 791 Bormann, C., Carpenter, B., and B. Liu, "A Generic 792 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 793 grasp-07 (work in progress), September 2016. 795 [I-D.ietf-netconf-zerotouch] 796 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 797 for NETCONF or RESTCONF based Management", draft-ietf- 798 netconf-zerotouch-09 (work in progress), July 2016. 800 [I-D.richardson-6lo-ra-in-ie] 801 Richardson, M., "802.15.4 Informational Element 802 encapsulation of ICMPv6 Router Advertisements", draft- 803 richardson-6lo-ra-in-ie-00 (work in progress), October 804 2016. 806 [I-D.richardson-anima-6join-discovery] 807 Richardson, M., "GRASP discovery of Registrar by Join 808 Assistant", draft-richardson-anima-6join-discovery-00 809 (work in progress), October 2016. 811 [iec62591] 812 IEC, ., "62591:2016 Industrial networks - Wireless 813 communication network and communication profiles - 814 WirelessHART", 2016, . 817 [ieee802-1AR] 818 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 819 2009, . 822 [ieee802154] 823 IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low- 824 Rate Wireless Personal Area Networks (WPANs)", 2015, 825 . 828 [ieee802159] 829 IEEE Standard, ., "802.15.9-2016 - IEEE Approved Draft 830 Recommended Practice for Transport of Key Management 831 Protocol (KMP) Datagrams", 2016, 832 . 835 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 836 Requirement Levels", BCP 14, RFC 2119, 837 DOI 10.17487/RFC2119, March 1997, 838 . 840 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 841 Bormann, "Neighbor Discovery Optimization for IPv6 over 842 Low-Power Wireless Personal Area Networks (6LoWPANs)", 843 RFC 6775, DOI 10.17487/RFC6775, November 2012, 844 . 846 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 847 Interface Identifiers with IPv6 Stateless Address 848 Autoconfiguration (SLAAC)", RFC 7217, 849 DOI 10.17487/RFC7217, April 2014, 850 . 852 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 853 Constrained-Node Networks", RFC 7228, 854 DOI 10.17487/RFC7228, May 2014, 855 . 857 8.2. Informative References 859 [duckling] 860 Stajano, F. and R. Anderson, "The resurrecting duckling: 861 security issues for ad-hoc wireless networks", 1999, 862 . 865 [I-D.ietf-ace-actors] 866 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 867 architecture for authorization in constrained 868 environments", draft-ietf-ace-actors-04 (work in 869 progress), September 2016. 871 [I-D.ietf-roll-useofrplinfo] 872 Robles, I., Richardson, M., and P. Thubert, "When to use 873 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 874 useofrplinfo-08 (work in progress), September 2016. 876 [PFS] Wikipedia, ., "Forward Secrecy", August 2016, 877 . 880 [pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, 881 . 883 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 884 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 885 November 2005, . 887 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 888 Element (PCE)-Based Architecture", RFC 4655, 889 DOI 10.17487/RFC4655, August 2006, 890 . 892 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 893 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 894 Internet of Things (IoT): Problem Statement", RFC 7554, 895 DOI 10.17487/RFC7554, May 2015, 896 . 898 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 899 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 900 February 2016, . 902 Appendix A. appendix 904 insert appendix here 906 Author's Address 908 Michael Richardson 909 Sandelman Software Works 911 Email: mcr+ietf@sandelman.ca