idnits 2.17.1 draft-ietf-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-6tisch-minimal-security]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 143 has weird spacing: '... pledge the p...' == Line 147 has weird spacing: '...ed Node 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 (February 25, 2017) is 2588 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 726 -- Looks like a reference, but probably isn't: '3' on line 728 == Unused Reference: 'I-D.ietf-6tisch-minimal' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-grasp' is defined on line 579, but no explicit reference was found in the text == Unused Reference: 'I-D.richardson-6tisch-join-enhanced-beacon' is defined on line 603, but no explicit reference was found in the text == Unused Reference: 'I-D.richardson-anima-6join-discovery' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'RFC6775' is defined on line 648, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-useofrplinfo' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'ISA100' is defined on line 694, but no explicit reference was found in the text == Unused Reference: 'RFC7554' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'RFC7731' is defined on line 720, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-01 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-08 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-04 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-09 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-00 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-01 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-00 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-12 == Outdated reference: A later version (-03) exists of draft-richardson-6tisch-join-enhanced-beacon-00 == Outdated reference: A later version (-02) exists of draft-richardson-6tisch-minimal-rekey-00 == 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-10 Summary: 1 error (**), 0 flaws (~~), 26 warnings (==), 3 comments (--). 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 February 25, 2017 5 Expires: August 29, 2017 7 6tisch Secure Join protocol 8 draft-ietf-6tisch-dtsecurity-secure-join-01 10 Abstract 12 This document describes a zero-touch mechanism to enroll a new device 13 (the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch 14 signaling mechanisms. The resulting device will obtain a domain 15 specific credential that can be used with either 802.15.9 per-host 16 pair keying protocols, or to obtain the network-wide key from a 17 coordinator. The mechanism describe her is an augmentation to the 18 one-touch mechanism described in [I-D.ietf-6tisch-minimal-security]. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 29, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.2.1. One-Touch Assumptions . . . . . . . . . . . . . . . . 4 58 1.2.2. Factory provided credentials (if any) . . . . . . . . 4 59 1.2.3. Credentials to be introduced . . . . . . . . . . . . 5 60 1.3. Network Assumptions . . . . . . . . . . . . . . . . . . . 5 61 1.3.1. Security above and below IP . . . . . . . . . . . . . 5 62 1.3.2. Join network assumptions . . . . . . . . . . . . . . 6 63 1.3.3. Number and cost of round trips . . . . . . . . . . . 6 64 1.3.4. Size of packets, number of fragments . . . . . . . . 7 65 1.4. Target end-state for join process . . . . . . . . . . . . 7 66 2. Join Protocol . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.1. Key Agreement process . . . . . . . . . . . . . . . . . . 8 68 2.2. Provisional Enrollment process . . . . . . . . . . . . . 8 69 2.3. Key Distribution Process . . . . . . . . . . . . . . . . 9 70 3. YANG model for BRSKI objects . . . . . . . . . . . . . . . . 9 71 3.1. Description of Pledge States in Join Process . . . . . . 10 72 4. Definition of managed objects for zero-touch bootstrap . . . 10 73 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 74 5.1. Privacy Considerations for Production network . . . . . . 11 75 5.2. Privacy Considerations for New Pledges . . . . . . . . . 11 76 5.2.1. EUI-64 derived address for join time IID . . . . . . 12 77 5.3. Privacy Considerations for Join Assistant . . . . . . . . 12 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 8. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 12 81 9. Acknwoledgements . . . . . . . . . . . . . . . . . . . . . . 12 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 10.2. Informative References . . . . . . . . . . . . . . . . . 15 85 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 Appendix A. appendix . . . . . . . . . . . . . . . . . . . . . . 16 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 Enrollment of new nodes into LLNs present unique challenges. The 92 constrained nodes has no user interfaces, and even if they did, 93 configuring thousands of such nodes manually is undesireable from a 94 human resources issue, as well as the difficulty in getting 95 consistent results. 97 This document is about a standard way to introduce new nodes into a 98 6tisch network that does not involve any direct manipulation of the 99 nodes themselves. This act has been called "zero-touch" 100 provisioning, and it does not occur by chance, but requires 101 coordination between the manufacturer of the node, the service 102 operator running the LLN, and the installers actually taking the 103 devices out of the shipping boxes. 105 The act of doing "one-touch" provisioning, where a node undergoes a 106 site-specific indoctrination process is described in 107 [I-D.ietf-6tisch-minimal-security]. 109 The mechanism described here and in 110 [I-D.ietf-6tisch-minimal-security] can be discovered by a new node in 111 a running network, so a device which has received a network-specific 112 "one-touch" setup, but which is located in another network, and is 113 capable of "zero-touch" operation could discovery this fact and 114 operate in other mode. 116 Many of the components of the zero-touch mechanisms described here 117 are in common with [I-D.ietf-anima-bootstrapping-keyinfra] and 118 [I-D.ietf-netconf-zerotouch]. The on-the-wire pledge to join 119 registrar protocols are different in this protocol from those 120 described in ANIMA, but conceptually operate identically. The 121 vouchers are identical. It is expected that the back-end network 122 operator infrastructure would be able to bootstrap ANIMA-type devices 123 over ethernet, while also being able bootstrap 6tisch devices over 124 802.15.4 with few changes. 126 1.1. Terminology 128 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 129 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 130 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 131 [RFC2119] and indicate requirement levels for compliant STuPiD 132 implementations. 134 The reader is expected to be familiar with the terms and concepts 135 defined in [I-D.ietf-6tisch-terminology], [RFC7252], 136 [I-D.ietf-core-object-security], and 137 [I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are 138 imported: drop ship, imprint, enrollment, pledge, join proxy, 139 ownership voucher, join registrar/coordinator. The following terms 140 are repeated here for readability, but this document is not 141 authoritative for their definition: 143 pledge the prospective device, which has the identity provided to at 144 the factory. Neither the device nor the network knows if the 145 device yet knows if this device belongs with this network. 147 Joined Node the prospective device, after having completing the join 148 process, often just called a Node. 150 Join Proxy (JP): a stateless relay that provides connectivity 151 between the pledge and the join registrar/coordinator. 153 Join Registrar/Coordinator (JRC): central entity responsible for 154 authentication and authorization of joining nodes. 156 Audit Token A signed token from the manufacturer authorized signing 157 authority indicating that the bootstrapping event has been 158 successfully logged. This has been referred to as an 159 "authorization token" indicating that it authorizes bootstrapping 160 to proceed. 162 Ownership Voucher A signed voucher from the vendor vouching that a 163 specific domain "owns" the new entity as defined in 164 [I-D.ietf-netconf-zerotouch]. 166 MIC manufacturer installed certificate. An [ieee802-1AR] identity. 168 1.2. Credentials 170 In the zero-touch scenario, every device expected to be drop shipped 171 would have an [ieee802-1AR] manufacturer installed certificate (MIC). 172 The private key part of the certificate would either be generated in 173 the device, or installed securely (and privately) as part of the 174 manufacturing process. [cullenCiscoPhoneDeploy] provides an example 175 of process which has been active for a good part of a decade. 177 The MIC would be signed by the manufacturer's CA, the public key 178 component of that would be included in the firmware. 180 1.2.1. One-Touch Assumptions 182 This document interacts with the one-touch solution described in 183 [I-D.ietf-6tisch-minimal-security]. 185 1.2.2. Factory provided credentials (if any) 187 When a manufacturer installed certificate is provided as the IDevID, 188 it SHOULD contain a number of fields. 189 [I-D.ietf-anima-bootstrapping-keyinfra] provides a detailed set of 190 requirements. 192 A manufacturer unique serial number MUST be provided in the 193 serialNumber SubjectAltName extension, and MAY be repeated in the 194 Common Name. There are no sequential or numeric requirements on the 195 serialNumber, it may be any unique value that the manufacturer wants 196 to use. The serialNumber SHOULD be printed on the packaging and/or 197 on the device in a discrete way so that failures can be physically 198 traced to the relevant device. 200 1.2.3. Credentials to be introduced 202 The goal of the bootstrap process is to introduce one or more new 203 locally relevant credentials: 205 1. a certificate signed by a local certificate authority/registrar. 206 This is the LDevID of [ieee802-1AR]. 208 2. alternatively, a network-wide key to be used to secure L2 209 traffic. 211 3. alternatively, a network-wide key to be used to authenticate per- 212 peer keying of L2 traffic using a mechanism such as provided by 213 [ieee802159]. 215 1.3. Network Assumptions 217 This document is about enrollment of constrained devices [RFC7228] to 218 a constrained network. Constrained networks is such as [ieee802154], 219 and in particular the time-slotted, channel hopping (tsch) mode, 220 feature low bandwidths, and limited opportunities to transmit. A key 221 feature of these networks is that receivers are only listening at 222 certain times. 224 1.3.1. Security above and below IP 226 802.15.4 networks have three kinds of layer-2 security: 228 o a network key that is shared with all nodes and is used for 229 unicast and multicast. The key may be used for privacy, and it 230 may be used in some cases for authentication only (in the case of 231 enhanced beacons). 233 o a series of network keys that are shared (agreed to) between pairs 234 of nodes (the per-peer key) 236 o a network key that is shared with all nodes (through a group key 237 management system), and is used for multicast traffic only, while 238 a per-pair key is used for unicast traffic 240 Setting up the credentials to bootstrap one of these kinds of 241 security, (or directly configuring the key itself for the first case) 242 is required. This is the security below the IP layer. 244 Security is required above the IP layer: there are three aspects 245 which the credentials in the previous section are to be used. 247 o to provide for secure connection with a Path Computation Element 248 [RFC4655], or other LLC (see ({RFC7554}} section 3). 250 o to initiate a connection between a Resource Server (RS) and an 251 application layer Authorization Server (AS and CAS from 252 [I-D.ietf-ace-actors]). 254 1.3.1.1. Perfect Forward Secrecy 256 Perfert Forward Secrecy (PFS) is the property of a protocol such that 257 complete knowledge of the crypto state (for instance, via a memory 258 dump) at time X does not imply that data from a disjoint time Y can 259 also be recovered. ([PFS]). 261 PFS is important for two reasons: one is that it offers protection 262 against the compromise of a node. It does this by changing the keys 263 in a non-deterministic way. This second property also makes it much 264 easier to remove a node from the network, as any node which has not 265 participated in the key changing process will find itself no longer 266 connected. 268 1.3.2. Join network assumptions 270 The network which the new pledge will connect to will have to have 271 the following properties: 273 o a known PANID. The PANID 0xXXXX where XXXX is the assigned RFC# 274 for this document is suggested. 276 o a minimal schedule with some Aloha time. This is usually in the 277 same slotframe as the Enhanced Beacon, but a pledge MUST listen 278 for an unencrypted Enhanced Beacon to so that it can synchronize. 280 1.3.3. Number and cost of round trips 282 TBD. 284 1.3.4. Size of packets, number of fragments 286 1.4. Target end-state for join process 288 At the end of the zero-touch join process there will be a symmetric 289 key protected channel between the Join Registrar/Coordinator and the 290 pledge, now known as a Joined Node. This channel may be rekeyed via 291 new exchange of asymmetric exponents (ECDH for instance), 292 authenticated using the domain specific credentials created during 293 the join process. 295 This channel is in the form of an OSCOAP protected connection with 296 [I-D.ietf-core-comi] encoded objects. This document includes 297 definition of a [I-D.ietf-netconf-keystore] compatible objects for 298 encoding of the relevant [I-D.ietf-anima-bootstrapping-keyinfra] 299 objects. 301 2. Join Protocol 303 The pledge join protocol state machine is described in 304 [I-D.ietf-6tisch-minimal-security], in section XYZ. The pledge 305 recognizes that it is in zero-touch configuration by the following 306 situation: 308 o no PSK has been configured for the network in which it has joined. 310 o the pledge has no locally defined certificate (no LDevID), only an 311 IDevID. 313 o the network asserts an identity that the pledge does not 314 recognize. 316 All of these conditions MUST be true. If any of these are not true, 317 then the pledge has either been connected to the wrong network, or it 318 has already been bootstrapped into a different network, and it should 319 wait until it finds that network. 321 The zero-touch process consists of three stages: 323 1. the key agreement process 325 2. the provisional enrollment process 327 3. the key distribution process 329 2.1. Key Agreement process 331 The key agreement process is identical to 332 [I-D.ietf-6tisch-minimal-security]. The process uses EDHOC with 333 certificates. 335 The pledge will have to trust the JRC provisionally, as described in 336 [I-D.ietf-anima-bootstrapping-keyinfra], section 3.1.2, and in 337 section 4.1.1 of [RFC7030]. 339 The JRC will be able to validate the IDevID of the pledge using the 340 manufacturer's CA. 342 The pledge may not know if it is in a zero-touch or one-touch 343 situation: the pledge may be able to verify the JRC based upon trust 344 anchors that were installed at manufacturing time. In that case, the 345 pledge runs the simplified one-touch process. 347 The pledge signals in the EDHOC message_2 if it has accepted the JRC 348 certificate. The JRC will in general, not trust the pledge with the 349 network keys until it has provided the pledge with a voucher. The 350 pledge will notice the absence of the provisioning keys. 352 XXX - there could be some disconnect here. May need additional 353 signals here. 355 2.2. Provisional Enrollment process 357 When the pledge determines that it can not verify the certificate of 358 the JRC using built-in trust anchors, then it enters a provisional 359 state. In this state, it keeps the channel created by EDHOC open. 361 A new EDHOC key derivation is done by the JRC and pledge using a new 362 label, "6tisch-provisional". 364 The pledge runs as a passive CoMI server, leaving the JRC to drive 365 the enrollment process. The JRC can interrogate the pledge in a 366 variety of fashions as shown below: the process terminates when the 367 JRC provides the pledge with an ownership voucher and the pledge 368 leaves the provisional state. 370 A typical interaction involves the following requests: 372 +-----------+ +----------+ +-----------+ +----------+ 373 | | | | | Circuit | | New | 374 | Vendor | | Registrar| | Proxy | | Entity | 375 | (MASA) | | | | | | | 376 ++----------+ +--+-------+ +-----------+ +----------+ 377 | | GET request voucher | 378 | |--------------------------------> 379 | <----------voucher-token---------| 380 |/requestvoucher| | 381 <---------------+ | 382 +---------------> | 383 |/requestlog | | 384 <---------------+ | 385 +---------------> | 386 | | POST voucher | 387 | |--------------------------------> 388 | <------------2.05 OK ------------+ 389 | | | 390 | | POST csr attributes | 391 | |--------------------------------> 392 | <------------2.05 OK ------------+ 393 | | | 394 | | GET cert request | 395 | |--------------------------------> 396 | ???? <------------2.05 OK ------------+ 397 |<--------------| CSR | 398 |-------------->| | 399 | | POST certificate | 400 | |--------------------------------> 401 | <------------2.05 OK ------------+ 402 | | | 404 2.3. Key Distribution Process 406 The key distribution process utilizes the protocol described 407 [I-D.richardson-6tisch-minimal-rekey]. The process starts with the 408 initial key, rather than an actual rekey. 410 This protocol remains active for subsequent rekey operations. 412 3. YANG model for BRSKI objects 414 module ietf-6tisch-brski { yang-version 1.1; 416 namespace "urn:ietf:params:xml:ns:yang:6tisch-brski"; prefix 417 "ietf6brski"; 418 //import ietf-yang-types { prefix yang; } //import ietf-inet-types { 419 prefix inet; } 421 organization "IETF 6tisch Working Group"; 423 contact "WG Web: http://tools.ietf.org/wg/6tisch/ WG List: 424 6tisch@ietf.org [2] Author: Michael Richardson mcr+ietf@sandelman.ca 425 [3]"; 427 description "This module defines an interface to set and retrieve 428 BRSKI objects using CoMI. This interface is used as part of an 429 enrollment process for constrained nodes and networks."; 431 revision "2017-03-01" { description "Initial version"; reference "RFC 432 XXXX: 6tisch zero-touch bootstrap"; } 434 // top-level container container ietf6brski { leaf requestnonce { 435 type binary; length XX; // how big can/should it be? mandatory true; 436 description "Request Nonce."; } leaf voucher { type binary; 437 description "The voucher as a serialized COSE object"; } 439 leaf csrattributes { 440 type binary; 441 description "A list of attributes that MUST be in the CSR"; 442 } 444 leaf certificaterequest { 445 type binary; 446 description "A PKIX format Certificate Request"; 447 } 449 leaf certificate { 450 type binary; 451 description "The LDevID certificate"; 452 } } } 454 3.1. Description of Pledge States in Join Process 456 TBD 458 4. Definition of managed objects for zero-touch bootstrap 460 The following is relevant YANG for use in the bootstrap protocol. 461 The objects identified are identical in format to the named objects 462 from [I-D.ietf-anima-bootstrapping-keyinfra]. 464 5. Privacy Considerations 466 [I-D.ietf-6lo-privacy-considerations] details a number of privacy 467 considerations important in Resource Constrained nodes. There are 468 two networks and three sets of constrained nodes to consider. They 469 are: 1. the production nodes on the production network. 2. the new 470 pledges, which have yet to enroll, and which are on a join network. 471 3. the production nodes which are also acting as proxy nodes. 473 5.1. Privacy Considerations for Production network 475 The details of this are out of scope for this document. 477 5.2. Privacy Considerations for New Pledges 479 New Pledges do not yet receive Router Advertisements with PIO 480 options, and so configure link-local addresses only based upon 481 layer-2 addresses using the normal SLAAC mechanisms described in 482 [RFC4191]. 484 These link-local addresses are visible to any on-link eavesdropper 485 (who is synchronized to the same Join Assistant), so regardless of 486 what is chosen they can be seen. This link-layer traffic is 487 encapsulated by the Join Assistant into IPIP packets and carried to 488 the JCE. The traffic SHOULD never leave the operator's network, and 489 no outside traffic should enter, so it should not be possible to do 490 any ICMP scanning as described in 491 [I-D.ietf-6lo-privacy-considerations]. 493 The join process described herein requires that some identifier 494 meaningful to the network operator be communicated to the JCE via the 495 Neighbor Advertisement's ARO option. This need not be a manufacturer 496 created EUI-64 as assigned by IEEE; it could be another value with 497 higher entropy and less interesting vendor/device information. 498 Regardless of what is chosen, it can be used to track where the 499 device attaches. 501 For most constrained device, network attachment occurs very 502 infrequently, often only once in their lifetime, so tracking 503 opportunities may be rare. 505 Further, during the enrollment process, a DTLS connection connection 506 will be created. Unless TLS1.3 is used, the device identity will be 507 visible to passive observers in the 802.11AR IDevID certificate that 508 is sent. Even when TLS1.3 is used, an active attacker could collect 509 the information by simply connecting to the device; it would not have 510 to successful complete the negotiation either, or even attempt to 511 Man-In-The-Middle the device. 513 There is, at the same time, significant value in avoiding a link- 514 local DAD process by using an IEEE assigned EUI-64, and there is also 515 significant advantage to the operator being able to see what the 516 vendor of the new device is. 518 5.2.1. EUI-64 derived address for join time IID 520 It is therefore suggested that the IID used in the link-local address 521 used during the join process be a vendor assigned EUI-64. After the 522 join process has concluded, the device SHOULD be assigned a unique 523 randomly generated long address, and a unique short address (not 524 based upon the vendor EUI-64) for use at link-layer. At that point, 525 all layer-3 content is encrypted by the layer-2 key. 527 5.3. Privacy Considerations for Join Assistant 529 6. Security Considerations 531 7. IANA Considerations 533 This document allocates one value from the subregistry "Address 534 Registration Option Status Values": ND_NS_JOIN_DECLINED Join 535 Assistant, JOIN DECLINED (TBD-AA) 537 8. Protocol Definition 539 9. Acknwoledgements 541 Kristofer Pister helped with many non-IETF references. 543 10. References 545 10.1. Normative References 547 [cullenCiscoPhoneDeploy] 548 Jennings, C., "Transitive Trust Enrollment for Constrained 549 Devices", 2012, . 552 [I-D.ietf-6lo-privacy-considerations] 553 Thaler, D., "Privacy Considerations for IPv6 Adaptation 554 Layer Mechanisms", draft-ietf-6lo-privacy- 555 considerations-04 (work in progress), October 2016. 557 [I-D.ietf-6tisch-minimal] 558 Vilajosana, X., Pister, K., and T. Watteyne, "Minimal 559 6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work 560 in progress), February 2017. 562 [I-D.ietf-6tisch-minimal-security] 563 Vucinic, M., Simon, J., and K. Pister, "Minimal Security 564 Framework for 6TiSCH", draft-ietf-6tisch-minimal- 565 security-01 (work in progress), February 2017. 567 [I-D.ietf-6tisch-terminology] 568 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 569 "Terminology in IPv6 over the TSCH mode of IEEE 570 802.15.4e", draft-ietf-6tisch-terminology-08 (work in 571 progress), December 2016. 573 [I-D.ietf-anima-bootstrapping-keyinfra] 574 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 575 S., and K. Watsen, "Bootstrapping Remote Secure Key 576 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 577 keyinfra-04 (work in progress), October 2016. 579 [I-D.ietf-anima-grasp] 580 Bormann, C., Carpenter, B., and B. Liu, "A Generic 581 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 582 grasp-09 (work in progress), December 2016. 584 [I-D.ietf-core-comi] 585 Stok, P., Bierman, A., Veillette, M., and A. Pelov, "CoAP 586 Management Interface", draft-ietf-core-comi-00 (work in 587 progress), January 2017. 589 [I-D.ietf-core-object-security] 590 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 591 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 592 object-security-01 (work in progress), December 2016. 594 [I-D.ietf-netconf-keystore] 595 Watsen, K. and G. Wu, "Keystore Model", draft-ietf- 596 netconf-keystore-00 (work in progress), October 2016. 598 [I-D.ietf-netconf-zerotouch] 599 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 600 for NETCONF or RESTCONF based Management", draft-ietf- 601 netconf-zerotouch-12 (work in progress), January 2017. 603 [I-D.richardson-6tisch-join-enhanced-beacon] 604 Richardson, M., "802.15.4 Informational Element 605 encapsulation of 6tisch Join Information", draft- 606 richardson-6tisch-join-enhanced-beacon-00 (work in 607 progress), February 2017. 609 [I-D.richardson-6tisch-minimal-rekey] 610 Richardson, M., "Minimal Security rekeying mechanism for 611 6TiSCH", draft-richardson-6tisch-minimal-rekey-00 (work in 612 progress), February 2017. 614 [I-D.richardson-anima-6join-discovery] 615 Richardson, M., "GRASP discovery of Registrar by Join 616 Assistant", draft-richardson-anima-6join-discovery-00 617 (work in progress), October 2016. 619 [iec62591] 620 IEC, ., "62591:2016 Industrial networks - Wireless 621 communication network and communication profiles - 622 WirelessHART", 2016, . 625 [ieee802-1AR] 626 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 627 2009, . 630 [ieee802154] 631 IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low- 632 Rate Wireless Personal Area Networks (WPANs)", 2015, 633 . 636 [ieee802159] 637 IEEE Standard, ., "802.15.9-2016 - IEEE Approved Draft 638 Recommended Practice for Transport of Key Management 639 Protocol (KMP) Datagrams", 2016, 640 . 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, 645 DOI 10.17487/RFC2119, March 1997, 646 . 648 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 649 Bormann, "Neighbor Discovery Optimization for IPv6 over 650 Low-Power Wireless Personal Area Networks (6LoWPANs)", 651 RFC 6775, DOI 10.17487/RFC6775, November 2012, 652 . 654 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 655 "Enrollment over Secure Transport", RFC 7030, 656 DOI 10.17487/RFC7030, October 2013, 657 . 659 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 660 Interface Identifiers with IPv6 Stateless Address 661 Autoconfiguration (SLAAC)", RFC 7217, 662 DOI 10.17487/RFC7217, April 2014, 663 . 665 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 666 Constrained-Node Networks", RFC 7228, 667 DOI 10.17487/RFC7228, May 2014, 668 . 670 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 671 Application Protocol (CoAP)", RFC 7252, 672 DOI 10.17487/RFC7252, June 2014, 673 . 675 10.2. Informative References 677 [duckling] 678 Stajano, F. and R. Anderson, "The resurrecting duckling: 679 security issues for ad-hoc wireless networks", 1999, 680 . 683 [I-D.ietf-ace-actors] 684 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 685 architecture for authorization in constrained 686 environments", draft-ietf-ace-actors-04 (work in 687 progress), September 2016. 689 [I-D.ietf-roll-useofrplinfo] 690 Robles, I., Richardson, M., and P. Thubert, "When to use 691 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 692 useofrplinfo-10 (work in progress), December 2016. 694 [ISA100] "The Technology Behind the ISA100.11a Standard", June 695 2010, . 698 [PFS] Wikipedia, ., "Forward Secrecy", August 2016, 699 . 702 [pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, 703 . 705 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 706 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 707 November 2005, . 709 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 710 Element (PCE)-Based Architecture", RFC 4655, 711 DOI 10.17487/RFC4655, August 2006, 712 . 714 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 715 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 716 Internet of Things (IoT): Problem Statement", RFC 7554, 717 DOI 10.17487/RFC7554, May 2015, 718 . 720 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 721 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 722 February 2016, . 724 10.3. URIs 726 [2] mailto:6tisch@ietf.org 728 [3] mailto:mcr+ietf@sandelman.ca 730 Appendix A. appendix 732 insert appendix here 734 Author's Address 736 Michael Richardson 737 Sandelman Software Works 739 Email: mcr+ietf@sandelman.ca