idnits 2.17.1 draft-ietf-6tisch-dtsecurity-zerotouch-join-00.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 213 has weird spacing: '... pledge the p...' == Line 217 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 (August 28, 2017) is 2404 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 1147 -- Looks like a reference, but probably isn't: '3' on line 901 == Unused Reference: 'I-D.ietf-6tisch-minimal' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-grasp' is defined on line 711, but no explicit reference was found in the text == Unused Reference: 'I-D.richardson-anima-6join-discovery' is defined on line 752, but no explicit reference was found in the text == Unused Reference: 'I-D.selander-ace-cose-ecdhe' is defined on line 757, but no explicit reference was found in the text == Unused Reference: 'RFC6775' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 807, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-sid' is defined on line 848, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-useofrplinfo' is defined on line 853, but no explicit reference was found in the text == Unused Reference: 'ISA100' is defined on line 858, but no explicit reference was found in the text == Unused Reference: 'RFC7554' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'RFC7731' is defined on line 893, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-03 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-09 == Outdated reference: A later version (-15) exists of draft-ietf-ace-cbor-web-token-08 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-07 == Outdated reference: A later version (-07) exists of draft-ietf-anima-voucher-05 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-01 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-04 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-05 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-02 == Outdated reference: A later version (-03) exists of draft-richardson-6tisch-join-enhanced-beacon-02 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-07 == Outdated reference: A later version (-04) exists of draft-vanderstok-ace-coap-est-02 == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-05 == Outdated reference: A later version (-24) exists of draft-ietf-core-sid-01 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-16 Summary: 1 error (**), 0 flaws (~~), 30 warnings (==), 4 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 B. Damm 5 Expires: March 1, 2018 Silver Spring Networks 6 August 28, 2017 8 6tisch Zero-Touch Secure Join protocol 9 draft-ietf-6tisch-dtsecurity-zerotouch-join-00 11 Abstract 13 This document describes a zero-touch mechanism to enroll a new device 14 (the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch 15 signaling mechanisms. The resulting device will obtain a domain 16 specific credential that can be used with either 802.15.9 per-host 17 pair keying protocols, or to obtain the network-wide key from a 18 coordinator. The mechanism describe her is an augmentation to the 19 one-touch mechanism described in [I-D.ietf-6tisch-minimal-security]. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 1, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 57 1.2. Other Bootstrapping Approaches . . . . . . . . . . . . . 6 58 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 6 59 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 6 60 2.1. Secure Imprinting using Vouchers . . . . . . . . . . . . 6 61 2.2. Initial Device Identifier . . . . . . . . . . . . . . . . 7 62 2.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 7 63 2.4. Lack of realtime clock . . . . . . . . . . . . . . . . . 9 64 2.5. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 9 65 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.1.1. Proxy Discovery Protocol Details . . . . . . . . . . 10 68 3.1.2. Registrar Discovery Protocol Details . . . . . . . . 10 69 3.2. Pledge Requests Voucher from the Registrar . . . . . . . 10 70 3.3. Registrar Requests Voucher from MASA . . . . . . . . . . 13 71 3.4. Voucher Response . . . . . . . . . . . . . . . . . . . . 13 72 3.4.1. Completing authentication of Provisional TLS 73 connection . . . . . . . . . . . . . . . . . . . . . 13 74 3.5. Voucher Status Telemetry . . . . . . . . . . . . . . . . 13 75 3.6. MASA authorization log Request . . . . . . . . . . . . . 14 76 3.6.1. MASA authorization log Response . . . . . . . . . . . 14 77 3.7. EST Integration for PKI bootstrapping . . . . . . . . . . 14 78 3.7.1. EST Distribution of CA Certificates . . . . . . . . . 14 79 3.7.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 14 80 3.7.3. EST Client Certificate Request . . . . . . . . . . . 14 81 3.7.4. Enrollment Status Telemetry . . . . . . . . . . . . . 14 82 3.7.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 14 83 4. Reduced security operational modes . . . . . . . . . . . . . 14 84 4.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 14 85 4.2. Pledge security reductions . . . . . . . . . . . . . . . 14 86 4.3. Registrar security reductions . . . . . . . . . . . . . . 15 87 4.4. MASA security reductions . . . . . . . . . . . . . . . . 15 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 5.1. MIME-Type Registry . . . . . . . . . . . . . . . . . . . 15 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 91 6.1. Security of MASA voucher signing key(s) . . . . . . . . . 15 92 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 95 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 96 9.2. Informative References . . . . . . . . . . . . . . . . . 19 98 Appendix A. One-Touch Assumptions . . . . . . . . . . . . . . . 20 99 A.1. Factory provided credentials (if any) . . . . . . . . . . 20 100 A.1.1. Credentials to be introduced . . . . . . . . . . . . 21 101 A.2. Network Assumptions . . . . . . . . . . . . . . . . . . . 21 102 A.2.1. Security above and below IP . . . . . . . . . . . . . 21 103 A.2.2. Join network assumptions . . . . . . . . . . . . . . 22 104 A.2.3. Number and cost of round trips . . . . . . . . . . . 22 105 A.2.4. Size of packets, number of fragments . . . . . . . . 22 106 A.3. Target end-state for join process . . . . . . . . . . . . 22 107 Appendix B. Join Protocol . . . . . . . . . . . . . . . . . . . 23 108 B.1. Key Agreement process . . . . . . . . . . . . . . . . . . 23 109 B.2. Provisional Enrollment process . . . . . . . . . . . . . 24 110 B.3. Key Distribution Process . . . . . . . . . . . . . . . . 25 111 Appendix C. YANG model for BRSKI objects . . . . . . . . . . . . 25 112 C.1. Description of Pledge States in Join Process . . . . . . 26 113 Appendix D. Definition of managed objects for zero-touch 114 bootstrap . . . . . . . . . . . . . . . . . . . . . 26 115 Appendix E. Privacy Considerations . . . . . . . . . . . . . . . 27 116 E.1. Privacy Considerations for Production network . . . . . . 27 117 E.2. Privacy Considerations for New Pledges . . . . . . . . . 27 118 E.2.1. EUI-64 derived address for join time IID . . . . . . 28 119 E.3. Privacy Considerations for Join Assistant . . . . . . . . 28 120 Appendix F. Security Considerations . . . . . . . . . . . . . . 28 121 Appendix G. IANA Considerations . . . . . . . . . . . . . . . . 28 122 Appendix H. Protocol Definition . . . . . . . . . . . . . . . . 28 123 Appendix I. Acknowledgements . . . . . . . . . . . . . . . . . . 28 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 126 1. Introduction 128 Enrollment of new nodes into LLNs present unique challenges. The 129 constrained nodes has no user interfaces, and even if they did, 130 configuring thousands of such nodes manually is undesireable from a 131 human resources issue, as well as the difficulty in getting 132 consistent results. 134 This document is about a standard way to introduce new nodes into a 135 6tisch network that does not involve any direct manipulation of the 136 nodes themselves. This act has been called "zero-touch" 137 provisioning, and it does not occur by chance, but requires 138 coordination between the manufacturer of the node, the service 139 operator running the LLN, and the installers actually taking the 140 devices out of the shipping boxes. 142 This document is a constrained profile of 143 [I-D.ietf-anima-bootstrapping-keyinfra]. The above document/protocol 144 is referred by by it's acronym: BRSKI. The pronounciation of which 145 is "brew-ski", a common north american slang for beer with a pseudo- 146 polish ending. 148 This document follows the same structure as it's parent in order to 149 emphasize the similarities, but specializes a number of things to 150 constrained networks of constrained devices. Like ANIMA's BRSKI, the 151 networks which are in scope for this protocol are deployed by a 152 professional operator. The deterministic mechanisms which have been 153 designed into 6tisch have been created to satisfy the operational 154 needs of industrial settings. 156 This document builds upon the "one-touch" provisioning described in 157 [I-D.ietf-6tisch-minimal-security], reusing the OSCOAP Join Request 158 mechanism when appropriate. In addition, it uses the CoAP adaption 159 of EST defined in [I-D.vanderstok-ace-coap-est] in an identical way. 161 Otherwise, this document follows BRSKI with the following high-level 162 changes: 164 o HTTP is replaced with CoAP. 166 o TLS (HTTPS) is replaced with either DTLS+CoAP, or EDHOC/ 167 OSCOAP+CoAP 169 o the domain-registrar anchor certificate is replaced with a Raw 170 Public Key (RPK) using [RFC7250]. 172 o the PKCS7 signed JSON voucher format is replaced with CWT 174 o the GRASP discovery mechanism for the Proxy is replaced with an 175 announcement in the Enhanced Beacon 176 [I-D.richardson-6tisch-join-enhanced-beacon] 178 o the TCP circuit proxy mechanism is not used. The IPIP mechanism 179 if mandatory to implement when deployed with DTLS, while the CoAP 180 based stateless proxy mechanism is used for OSCOAP/EDHOC. 182 o real time clocks are assumed to be impossible, so expiry dates in 183 ownership vouchers are never used 185 o nonce-full vouchers are encouraged, but off-line nonce-less 186 operation is also supported 188 802.1AR Client certificates are retained, but optionally are 189 specified by reference rather than value. 191 It is expected that the back-end network operator infrastructure 192 would be able to bootstrap ANIMA BRSKI-type devices over ethernet, 193 while also being able bootstrap 6tisch devices over 802.15.4 with few 194 changes. 196 1.1. Terminology 198 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 199 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 200 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 201 [RFC2119] and indicate requirement levels for compliant STuPiD 202 implementations. 204 The reader is expected to be familiar with the terms and concepts 205 defined in [I-D.ietf-6tisch-terminology], [RFC7252], 206 [I-D.ietf-core-object-security], and 207 [I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are 208 imported: drop ship, imprint, enrollment, pledge, join proxy, 209 ownership voucher, join registrar/coordinator. The following terms 210 are repeated here for readability, but this document is not 211 authoritative for their definition: 213 pledge the prospective device, which has the identity provided to at 214 the factory. Neither the device nor the network knows if the 215 device yet knows if this device belongs with this network. 217 Joined Node the prospective device, after having completing the join 218 process, often just called a Node. 220 Join Proxy (JP): a stateless relay that provides connectivity 221 between the pledge and the join registrar/coordinator. 223 Join Registrar/Coordinator (JRC): central entity responsible for 224 authentication and authorization of joining nodes. 226 Audit Token A signed token from the manufacturer authorized signing 227 authority indicating that the bootstrapping event has been 228 successfully logged. This has been referred to as an 229 "authorization token" indicating that it authorizes bootstrapping 230 to proceed. 232 Ownership Voucher A signed voucher from the vendor vouching that a 233 specific domain "owns" the new entity as defined in 234 [I-D.ietf-anima-voucher]. 236 MIC manufacturer installed certificate. An [ieee802-1AR] identity. 237 Not to be confused with a (cryptographic) "Message Integrity 238 Check" 240 1.2. Other Bootstrapping Approaches 242 BRSKI describes a more general, more flexible approach for 243 bootstrapping devices into an ISP or Enterprise network. 245 [I-D.ietf-6tisch-minimal-security] provides an extremely streamlined 246 approach to enrolling from hundreds to thousands of devices into a 247 network, provided that a unique secret key can be installed in each 248 device. 250 1.3. Scope of solution 252 The solution described in this document is appropriate to enrolling 253 between hundreds to hundreds of thousands of diverse devices into a 254 network without any prior contact with the devices. The devices 255 could be shipped by the manufacturer directly to the customer site 256 without ever being seen by the operator of the network. As described 257 in BRSKI, in the audit-mode of operation the device will be claimed 258 by the first network that sees it. In the tracked owner mode of 259 operation, sales channel integration provides a strong connection 260 that the operator of the network is the legitimate owner of the 261 device. 263 2. Architectural Overview 265 Section 2 of BRSKI has a diagram with all of the components shown 266 together. There are no significant changes to the diagram. 268 The use of a circuit proxy is not mandated. Instead the IPIP 269 mechanism described in appendix C ("IPIP Join Proxy mechanism") 270 SHOULD be be used instead as it supports both DTLS, EDHOC and OSCOAP 271 protocols. The CoAP proxy mechanism MAY be implemented instead: the 272 decision depends upon the capabilities of the Registrar and the 273 proxy. A mechanism is included for the Registrar to announce it's 274 capabilities (XXX). 276 2.1. Secure Imprinting using Vouchers 278 As in BRSKI, the format and cryptographic mechansim of vouchers is 279 described in detail in [I-D.ietf-anima-voucher]. As described in 280 section YYY, the physical format for vouchers in this document 281 differs from that of BRSKI, in that it uses 282 [I-D.ietf-ace-cbor-web-token] to encode the voucher and to sign it. 284 2.2. Initial Device Identifier 286 The essential component of the zero-touch operation is that the 287 pledge is provisioned with an 802.1AR (PKIX) certificate installed 288 during the manufacturing process. 290 It is expected that constrained devices will use a signature 291 algorithm corresponding to the hardware acceleration that they have, 292 if they have any. The anticipated algorithms are the ECDSA P-256 293 (secp256p1) as SHOULD-, while newer devices SHOLD+ begin to appear 294 using EdDSA curves using the 25519 curves. (EDNOTE details here) 296 There are a number of simplications detailed later on in this 297 document designed to eliminate the need for an ASN.1 parser in the 298 pledge. 300 The pledge should consider it's 802.1AR certificate to be an opaque 301 blob of bytes, to be inserted into protocols at appropriate places. 302 The pledge SHOULD have access to it's public and private keys in the 303 most useable native format for computation. 305 The pledge MUST have the public key of the MASA built in a 306 manufacturer time. This is a seemingly identical requirement as for 307 BRSKI, but rather than being an abstract trust anchor that can be 308 augmented with a certificate chain, the pledge MUST be provided with 309 the Raw Public Key that the MASA will use to sign vouchers for that 310 pledge. 312 There are a number of security concerns with use of a single MASA 313 signing key, and section Section 6.1 addresses some of them with some 314 operational suggestions. 316 BRSKI places some clear requirements upon the contents of the IDevID, 317 but leaves the exact origin of the voucher serial-number open. This 318 document restricts the process to being the hwSerialNum OCTET STRING. 319 As CWT can handle binary formats, no base64 encoding is necessary. 321 The use of the MASA-URL extension is encouraged if the certificate is 322 sent at all. 324 [[EDNOTE here belongs text about sending only a reference to the 325 IDevID rather than the entire certificate]] 327 2.3. Protocol Flow 329 The diagram from BRSKI is reproduced with some edits: 331 +--------+ +---------+ +------------+ +------------+ 332 | Pledge | | IPIP | | Domain | | Vendor | 333 | | | Proxy | | Registrar | | Service | 334 | | | | | | | (Internet | 335 +--------+ +---------+ +------------+ +------------+ 336 | | | | 337 |<-RFC4862 IPv6 adr | | | 338 | | | | 339 |<--------------------| | | 340 | Enhanced Beacon | | | 341 | periodic broadcast| | | 342 | | | | 343 |<------------------->C<----------------->| | 344 | DTLS via the IPIP Proxy | | 345 |<--Registrar DTLS server authentication--| | 346 [PROVISIONAL accept of server cert] | | 347 P---X.509 client authentication---------->| | 348 P | | | 349 P---Voucher Request (include nonce)------>| | 350 P | | | 351 P | | | 352 P | [accept device?] | 353 P | [contact Vendor] | 354 P | |--Pledge ID-------->| 355 P | |--Domain ID-------->| 356 P | |--nonce------------>| 357 P | | [extract DomainID] 358 P | | | 359 P | | [update audit log] 360 P | | | 361 P | | | 362 P | | | 363 P | | | 364 P | | | 365 P | |<-device audit log--| 366 P | |<- voucher ---------| 367 P | | | 368 P | | | 369 P | [verify audit log and voucher] | 370 P | | | 371 P<------voucher---------------------------| | 372 [verify voucher ] | | | 373 [verify provisional cert| | | 374 | | | | 375 |<--------------------------------------->| | 376 | Continue with RFC7030 enrollment | | 377 | using now bidirectionally authenticated | | 378 | DTLS session. | | | 379 | | | | 380 | | | | 381 | | | | 383 Noteable changes are: 385 1. no IPv4 support/options. 387 2. no mDNS steps, 6tisch only uses Enhanced Beacon 389 3. nonce-full option is always recommended 391 2.4. Lack of realtime clock 393 For the constrained situation it is assumed that devices have no real 394 time clock. These nodes do have access to a monotonically increasing 395 clock that will not go backwards in the form of the Absolute Sequence 396 Number. Synchronization to the ASN is required in order to transmit/ 397 receive data and most nodes will maintain it in hardware. 399 The heuristic described in BRSKI under this section SHOULD be applied 400 if there are dates in the CWT format voucher. 402 Voucher requests SHOULD include a nonce. For devices intended for 403 off-line deployment, the vouchers will have been generated in advance 404 and no nonce-ful operation will not be possible. 406 2.5. Cloud Registrar 408 In 6tisch, the pledge never has network connectivity until it is 409 enrolled, so no alternate registrar is ever possible. 411 3. Protocol Details 413 BRSKI is specified to run over HTTPS. This document respecifies it 414 to run over CoAP with either DTLS or EDHOC-provided OSCOAP security. 415 There is an emerging (hybrid) possibility of DTLS-providing the 416 OSCOAP security, but such a specification does not yet exist. 418 [I-D.vanderstok-ace-coap-est] specifies that CoAP specifies the use 419 of CoAP Block-Wise Transfer ("Block") [RFC7959] to fragment EST 420 messages at the application layer. 422 BRSKI introduces the concept of a provisional state for EST. The 423 same situation must also be added to DTLS: a situation where the 424 connection is active but the identity of the Registar has not yet 425 been confirmed. The DTLS MUST validate that the exchange has been 426 signed by the Raw Public Key that is presented by the Server, even 427 though there is as yet no trust in that key. Such a key is often 428 available through APIs that provide for channel binding, such as 429 described in [RFC5056]. 431 As in [I-D.vanderstok-ace-coap-est], support for Observe CoAP options 432 [RFC7641] with BRSKI is not supported in the current BRSKI/EST 433 message flows. Observe options could be used by the server to notify 434 clients about a change in the cacerts or csr attributes (resources) 435 and might be an area of future work. 437 Redirection as described in [RFC7030] section 3.2.1 is NOT supported. 439 3.1. Discovery 441 Only IPv6 operations using Link-Local addresses are supported. Use 442 of a temporary address is NOT encouraged as the critial resource on 443 the Proxy device is the number of Neighbour Cache Entries that can be 444 used for untrusted pledge entries. 446 3.1.1. Proxy Discovery Protocol Details 448 The Proxy is discovered using the enhanced beacon defined in 449 [I-D.richardson-6tisch-join-enhanced-beacon]. 451 3.1.2. Registrar Discovery Protocol Details 453 The Registrar is not discovered by the Proxy. Any device that is 454 expected to be able to operate as a Registrar MAY be told the address 455 of the Registrar when that device joins the network. The address MAY 456 be included in the [I-D.ietf-6tisch-minimal-security] Join Response. 457 If the address is NOT included, then Proxy may assume that the 458 Registrar can be found at the DODAG root, which is well known in the 459 6tisch's use of the RPL protocol. 461 3.2. Pledge Requests Voucher from the Registrar 463 The voucher request and response as defined by BRSKI is modified 464 slightly. In order to simplify the pledge, the use of a certificate 465 (and chain) for the Registrar is not supported. Instead the newly 466 defined pinned-domain-subject-public-key-info must contain the (raw) 467 public key info for the Registrar. It MUST be byte for byte 468 identical to that which is transmitted by the Registrar during the 469 TLS ServerCertificate handshake. 471 BRSKI permits the voucher request to be signed or unsigned. This 472 document defines the voucher request to be unsigned. 474 /* -*- c -*- */ 475 module ietf-cwt-voucher { 476 yang-version 1.1; 478 namespace 479 "urn:ietf:params:xml:ns:yang:ietf-cwt-voucher"; 480 prefix "vcwt"; 482 import ietf-restconf { 483 prefix rc; 484 description 485 "This import statement is only present to access 486 the yang-data extension defined in RFC 8040."; 487 reference "RFC 8040: RESTCONF Protocol"; 488 } 490 import ietf-voucher { 491 prefix "v"; 492 } 494 organization 495 "IETF 6tisch Working Group"; 497 contact 498 "WG Web: 499 WG List: 500 Author: Michael Richardson 501 "; 503 description 504 "This module defines the format for a voucher, which is produced by 505 a pledge's manufacturer or delegate (MASA) to securely assign one 506 or more pledges to an 'owner', so that the pledges may establish a 507 secure connection to the owner's network infrastructure. 509 This version provides a very restricted subset appropriate 510 for very constrained devices. 511 In particular, it assumes that nonce-ful operation is 512 always required, that expiration dates are rather weak, as no 513 clocks can be assumed, and that the Registrar is identified 514 by a pinned Raw Public Key. 516 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 517 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 518 the module text are to be interpreted as described in RFC 2119."; 520 revision "YYYY-MM-DD" { 521 description 522 "Initial version"; 523 reference 524 "RFC XXXX: Voucher Profile for Constrained Devices"; 525 } 527 // Grouping defined for future usage 528 grouping voucher-cwt-grouping { 529 description 530 "Grouping to allow reuse/extensions in future work."; 532 uses v:voucher-artifact-grouping { 533 augment "voucher" { 534 description "Base the CWT voucher upon the regular one"; 535 leaf pinned-domain-subject-public-key-info { 536 type binary; 537 description 538 "The pinned-domain-subject replaces the 539 pinned-domain-certificate in constrained uses of 540 the voucher. The pinned-domain-public-key-info is the 541 Raw Public Key of the Registrar. This field is encoded 542 as specified in RFC7250, section 3. 543 The ECDSA algorithm MUST be supported. 544 The EdDSA algorithm as specified in 545 draft-ietf-tls-rfc4492bis-17 SHOULD be supported. 546 Support for the DSA algorithm is not recommended. 547 Support for the RSA algorithm is a MAY."; 548 } 549 } 550 } 551 } 552 } 554 This definition, translated via the rules in 555 [I-D.ietf-core-yang-cbor] produces the following CDDL for an unsigned 556 voucher (request): 558 This is a PLACEHOLDER for a CDDL definition derived from the YANG model. 559 SID experimental base 60100 is used. 561 dictionary keys are: 562 60100 ietf-cwt-voucher 563 60101 assertion 564 60102 created-on 565 60103 domain-cert-revocation-checks 566 60104 expires-on 567 60105 idevid-issuer 568 60106 last-renewal-date 569 60107 nonce 570 60108 pinned-domain-cert 571 60109 pinned-domain-subject-public-key-info 572 60110 prior-signed-voucher 573 60111 serial-number 575 3.3. Registrar Requests Voucher from MASA 577 There are no change from BRSKI, as this step is between two non- 578 constrained devices. The format of the voucher is CWT, which implies 579 changes to both the Registrar and the MASA, but semantically the 580 content is the same. 582 The manufacturer will know what algorithms are supported by the 583 pledge, and will issue a 406 (Conflict) error to the Registrar if the 584 Registar's public key format is not supported by the pledge. 586 3.4. Voucher Response 588 The voucher response MUST have an additional header called: "pinned- 589 domain-rpk". 591 3.4.1. Completing authentication of Provisional TLS connection 593 In order to simplify the pledge as much as possible, the voucher 594 response 596 3.5. Voucher Status Telemetry 598 XXX 600 3.6. MASA authorization log Request 602 XXX 604 3.6.1. MASA authorization log Response 606 XXX 608 3.7. EST Integration for PKI bootstrapping 610 XXX 612 3.7.1. EST Distribution of CA Certificates 614 XXX 616 3.7.2. EST CSR Attributes 618 XXX 620 3.7.3. EST Client Certificate Request 622 XXX 624 3.7.4. Enrollment Status Telemetry 626 XXX 628 3.7.5. EST over CoAP 630 XXX 632 4. Reduced security operational modes 634 XXX 636 4.1. Trust Model 638 XXX 640 4.2. Pledge security reductions 642 XXX 644 4.3. Registrar security reductions 646 XXX 648 4.4. MASA security reductions 650 XXX 652 5. IANA Considerations 654 XXX 656 5.1. MIME-Type Registry 658 XXX 660 6. Security Considerations 662 6.1. Security of MASA voucher signing key(s) 664 7. Privacy Considerations 666 XXX 668 8. Acknowledgements 670 9. References 672 9.1. Normative References 674 [cullenCiscoPhoneDeploy] 675 Jennings, C., "Transitive Trust Enrollment for Constrained 676 Devices", 2012, . 679 [I-D.ietf-6lo-privacy-considerations] 680 Thaler, D., "Privacy Considerations for IPv6 Adaptation 681 Layer Mechanisms", draft-ietf-6lo-privacy- 682 considerations-04 (work in progress), October 2016. 684 [I-D.ietf-6tisch-minimal] 685 Vilajosana, X., Pister, K., and T. Watteyne, "Minimal 686 6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work 687 in progress), February 2017. 689 [I-D.ietf-6tisch-minimal-security] 690 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 691 "Minimal Security Framework for 6TiSCH", draft-ietf- 692 6tisch-minimal-security-03 (work in progress), June 2017. 694 [I-D.ietf-6tisch-terminology] 695 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 696 "Terminology in IPv6 over the TSCH mode of IEEE 697 802.15.4e", draft-ietf-6tisch-terminology-09 (work in 698 progress), June 2017. 700 [I-D.ietf-ace-cbor-web-token] 701 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 702 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-08 703 (work in progress), August 2017. 705 [I-D.ietf-anima-bootstrapping-keyinfra] 706 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 707 S., and K. Watsen, "Bootstrapping Remote Secure Key 708 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 709 keyinfra-07 (work in progress), July 2017. 711 [I-D.ietf-anima-grasp] 712 Bormann, C., Carpenter, B., and B. Liu, "A Generic 713 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 714 grasp-15 (work in progress), July 2017. 716 [I-D.ietf-anima-voucher] 717 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 718 "Voucher Profile for Bootstrapping Protocols", draft-ietf- 719 anima-voucher-05 (work in progress), August 2017. 721 [I-D.ietf-core-comi] 722 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 723 Management Interface", draft-ietf-core-comi-01 (work in 724 progress), July 2017. 726 [I-D.ietf-core-object-security] 727 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 728 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 729 object-security-04 (work in progress), July 2017. 731 [I-D.ietf-core-yang-cbor] 732 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 733 Minaburo, "CBOR Encoding of Data Modeled with YANG", 734 draft-ietf-core-yang-cbor-05 (work in progress), August 735 2017. 737 [I-D.ietf-netconf-keystore] 738 Watsen, K., "Keystore Model", draft-ietf-netconf- 739 keystore-02 (work in progress), June 2017. 741 [I-D.richardson-6tisch-join-enhanced-beacon] 742 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 743 Element encapsulation of 6tisch Join Information", draft- 744 richardson-6tisch-join-enhanced-beacon-02 (work in 745 progress), July 2017. 747 [I-D.richardson-6tisch-minimal-rekey] 748 Richardson, M., "Minimal Security rekeying mechanism for 749 6TiSCH", draft-richardson-6tisch-minimal-rekey-02 (work in 750 progress), August 2017. 752 [I-D.richardson-anima-6join-discovery] 753 Richardson, M., "GRASP discovery of Registrar by Join 754 Assistant", draft-richardson-anima-6join-discovery-00 755 (work in progress), October 2016. 757 [I-D.selander-ace-cose-ecdhe] 758 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 759 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 760 cose-ecdhe-07 (work in progress), July 2017. 762 [I-D.vanderstok-ace-coap-est] 763 Kumar, S., Stok, P., Kampanakis, P., Furuhed, M., and S. 764 Raza, "EST over secure CoAP (EST-coaps)", draft- 765 vanderstok-ace-coap-est-02 (work in progress), June 2017. 767 [iec62591] 768 IEC, ., "62591:2016 Industrial networks - Wireless 769 communication network and communication profiles - 770 WirelessHART", 2016, . 773 [ieee802-1AR] 774 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 775 2009, . 778 [ieee802154] 779 IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low- 780 Rate Wireless Personal Area Networks (WPANs)", 2015, 781 . 784 [ieee802159] 785 IEEE Standard, ., "802.15.9-2016 - IEEE Approved Draft 786 Recommended Practice for Transport of Key Management 787 Protocol (KMP) Datagrams", 2016, 788 . 791 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 792 Requirement Levels", BCP 14, RFC 2119, 793 DOI 10.17487/RFC2119, March 1997, . 796 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 797 Bormann, "Neighbor Discovery Optimization for IPv6 over 798 Low-Power Wireless Personal Area Networks (6LoWPANs)", 799 RFC 6775, DOI 10.17487/RFC6775, November 2012, 800 . 802 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 803 "Enrollment over Secure Transport", RFC 7030, 804 DOI 10.17487/RFC7030, October 2013, . 807 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 808 Interface Identifiers with IPv6 Stateless Address 809 Autoconfiguration (SLAAC)", RFC 7217, 810 DOI 10.17487/RFC7217, April 2014, . 813 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 814 Constrained-Node Networks", RFC 7228, 815 DOI 10.17487/RFC7228, May 2014, . 818 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 819 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 820 Transport Layer Security (TLS) and Datagram Transport 821 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 822 June 2014, . 824 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 825 Application Protocol (CoAP)", RFC 7252, 826 DOI 10.17487/RFC7252, June 2014, . 829 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 830 the Constrained Application Protocol (CoAP)", RFC 7959, 831 DOI 10.17487/RFC7959, August 2016, . 834 9.2. Informative References 836 [duckling] 837 Stajano, F. and R. Anderson, "The resurrecting duckling: 838 security issues for ad-hoc wireless networks", 1999, 839 . 842 [I-D.ietf-ace-actors] 843 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 844 architecture for authorization in constrained 845 environments", draft-ietf-ace-actors-05 (work in 846 progress), March 2017. 848 [I-D.ietf-core-sid] 849 Veillette, M., Pelov, A., Turner, R., Minaburo, A., and A. 850 Somaraju, "YANG Schema Item iDentifier (SID)", draft-ietf- 851 core-sid-01 (work in progress), May 2017. 853 [I-D.ietf-roll-useofrplinfo] 854 Robles, I., Richardson, M., and P. Thubert, "When to use 855 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 856 useofrplinfo-16 (work in progress), July 2017. 858 [ISA100] "The Technology Behind the ISA100.11a Standard", June 859 2010, . 862 [PFS] Wikipedia, ., "Forward Secrecy", August 2016, 863 . 866 [pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, 867 . 869 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 870 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 871 November 2005, . 873 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 874 Element (PCE)-Based Architecture", RFC 4655, 875 DOI 10.17487/RFC4655, August 2006, . 878 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 879 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 880 . 882 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 883 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 884 Internet of Things (IoT): Problem Statement", RFC 7554, 885 DOI 10.17487/RFC7554, May 2015, . 888 [RFC7641] Hartke, K., "Observing Resources in the Constrained 889 Application Protocol (CoAP)", RFC 7641, 890 DOI 10.17487/RFC7641, September 2015, . 893 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 894 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 895 February 2016, . 897 9.3. URIs 899 [2] mailto:6tisch@ietf.org 901 [3] mailto:mcr+ietf@sandelman.ca 903 Appendix A. One-Touch Assumptions 905 This document interacts with the one-touch solution described in 906 [I-D.ietf-6tisch-minimal-security]. 908 A.1. Factory provided credentials (if any) 910 When a manufacturer installed certificate is provided as the IDevID, 911 it SHOULD contain a number of fields. 912 [I-D.ietf-anima-bootstrapping-keyinfra] provides a detailed set of 913 requirements. 915 A manufacturer unique serial number MUST be provided in the 916 serialNumber SubjectAltName extension, and MAY be repeated in the 917 Common Name. There are no sequential or numeric requirements on the 918 serialNumber, it may be any unique value that the manufacturer wants 919 to use. The serialNumber SHOULD be printed on the packaging and/or 920 on the device in a discrete way so that failures can be physically 921 traced to the relevant device. 923 A.1.1. Credentials to be introduced 925 The goal of the bootstrap process is to introduce one or more new 926 locally relevant credentials: 928 1. a certificate signed by a local certificate authority/registrar. 929 This is the LDevID of [ieee802-1AR]. 931 2. alternatively, a network-wide key to be used to secure L2 932 traffic. 934 3. alternatively, a network-wide key to be used to authenticate per- 935 peer keying of L2 traffic using a mechanism such as provided by 936 [ieee802159]. 938 A.2. Network Assumptions 940 This document is about enrollment of constrained devices [RFC7228] to 941 a constrained network. Constrained networks is such as [ieee802154], 942 and in particular the time-slotted, channel hopping (tsch) mode, 943 feature low bandwidths, and limited opportunities to transmit. A key 944 feature of these networks is that receivers are only listening at 945 certain times. 947 A.2.1. Security above and below IP 949 802.15.4 networks have three kinds of layer-2 security: 951 o a network key that is shared with all nodes and is used for 952 unicast and multicast. The key may be used for privacy, and it 953 may be used in some cases for authentication only (in the case of 954 enhanced beacons). 956 o a series of network keys that are shared (agreed to) between pairs 957 of nodes (the per-peer key) 959 o a network key that is shared with all nodes (through a group key 960 management system), and is used for multicast traffic only, while 961 a per-pair key is used for unicast traffic 963 Setting up the credentials to bootstrap one of these kinds of 964 security, (or directly configuring the key itself for the first case) 965 is required. This is the security below the IP layer. 967 Security is required above the IP layer: there are three aspects 968 which the credentials in the previous section are to be used. 970 o to provide for secure connection with a Path Computation Element 971 [RFC4655], or other LLC (see ({RFC7554}} section 3). 973 o to initiate a connection between a Resource Server (RS) and an 974 application layer Authorization Server (AS and CAS from 975 [I-D.ietf-ace-actors]). 977 A.2.1.1. Perfect Forward Secrecy 979 Perfert Forward Secrecy (PFS) is the property of a protocol such that 980 complete knowledge of the crypto state (for instance, via a memory 981 dump) at time X does not imply that data from a disjoint time Y can 982 also be recovered. ([PFS]). 984 PFS is important for two reasons: one is that it offers protection 985 against the compromise of a node. It does this by changing the keys 986 in a non-deterministic way. This second property also makes it much 987 easier to remove a node from the network, as any node which has not 988 participated in the key changing process will find itself no longer 989 connected. 991 A.2.2. Join network assumptions 993 The network which the new pledge will connect to will have to have 994 the following properties: 996 o a known PANID. The PANID 0xXXXX where XXXX is the assigned RFC# 997 for this document is suggested. 999 o a minimal schedule with some Aloha time. This is usually in the 1000 same slotframe as the Enhanced Beacon, but a pledge MUST listen 1001 for an unencrypted Enhanced Beacon to so that it can synchronize. 1003 A.2.3. Number and cost of round trips 1005 TBD. 1007 A.2.4. Size of packets, number of fragments 1009 A.3. Target end-state for join process 1011 At the end of the zero-touch join process there will be a symmetric 1012 key protected channel between the Join Registrar/Coordinator and the 1013 pledge, now known as a Joined Node. This channel may be rekeyed via 1014 new exchange of asymmetric exponents (ECDH for instance), 1015 authenticated using the domain specific credentials created during 1016 the join process. 1018 This channel is in the form of an OSCOAP protected connection with 1019 [I-D.ietf-core-comi] encoded objects. This document includes 1020 definition of a [I-D.ietf-netconf-keystore] compatible objects for 1021 encoding of the relevant [I-D.ietf-anima-bootstrapping-keyinfra] 1022 objects. 1024 Appendix B. Join Protocol 1026 The pledge join protocol state machine is described in 1027 [I-D.ietf-6tisch-minimal-security], in section XYZ. The pledge 1028 recognizes that it is in zero-touch configuration by the following 1029 situation: 1031 o no PSK has been configured for the network in which it has joined. 1033 o the pledge has no locally defined certificate (no LDevID), only an 1034 IDevID. 1036 o the network asserts an identity that the pledge does not 1037 recognize. 1039 All of these conditions MUST be true. If any of these are not true, 1040 then the pledge has either been connected to the wrong network, or it 1041 has already been bootstrapped into a different network, and it should 1042 wait until it finds that network. 1044 The zero-touch process consists of three stages: 1046 1. the key agreement process 1048 2. the provisional enrollment process 1050 3. the key distribution process 1052 B.1. Key Agreement process 1054 The key agreement process is identical to 1055 [I-D.ietf-6tisch-minimal-security]. The process uses EDHOC with 1056 certificates. 1058 The pledge will have to trust the JRC provisionally, as described in 1059 [I-D.ietf-anima-bootstrapping-keyinfra], section 3.1.2, and in 1060 section 4.1.1 of [RFC7030]. 1062 The JRC will be able to validate the IDevID of the pledge using the 1063 manufacturer's CA. 1065 The pledge may not know if it is in a zero-touch or one-touch 1066 situation: the pledge may be able to verify the JRC based upon trust 1067 anchors that were installed at manufacturing time. In that case, the 1068 pledge runs the simplified one-touch process. 1070 The pledge signals in the EDHOC message_2 if it has accepted the JRC 1071 certificate. The JRC will in general, not trust the pledge with the 1072 network keys until it has provided the pledge with a voucher. The 1073 pledge will notice the absence of the provisioning keys. 1075 XXX - there could be some disconnect here. May need additional 1076 signals here. 1078 B.2. Provisional Enrollment process 1080 When the pledge determines that it can not verify the certificate of 1081 the JRC using built-in trust anchors, then it enters a provisional 1082 state. In this state, it keeps the channel created by EDHOC open. 1084 A new EDHOC key derivation is done by the JRC and pledge using a new 1085 label, "6tisch-provisional". 1087 The pledge runs as a passive CoMI server, leaving the JRC to drive 1088 the enrollment process. The JRC can interrogate the pledge in a 1089 variety of fashions as shown below: the process terminates when the 1090 JRC provides the pledge with an ownership voucher and the pledge 1091 leaves the provisional state. 1093 A typical interaction involves the following requests: 1095 +-----------+ +----------+ +-----------+ +----------+ 1096 | | | | | Circuit | | New | 1097 | Vendor | | Registrar| | Proxy | | Entity | 1098 | (MASA) | | | | | | | 1099 ++----------+ +--+-------+ +-----------+ +----------+ 1100 | | GET request voucher | 1101 | |--------------------------------> 1102 | <----------voucher-token---------| 1103 |/requestvoucher| | 1104 <---------------+ | 1105 +---------------> | 1106 |/requestlog | | 1107 <---------------+ | 1108 +---------------> | 1109 | | POST voucher | 1110 | |--------------------------------> 1111 | <------------2.05 OK ------------+ 1112 | | | 1113 | | POST csr attributes | 1114 | |--------------------------------> 1115 | <------------2.05 OK ------------+ 1116 | | | 1117 | | GET cert request | 1118 | |--------------------------------> 1119 | ???? <------------2.05 OK ------------+ 1120 |<--------------| CSR | 1121 |-------------->| | 1122 | | POST certificate | 1123 | |--------------------------------> 1124 | <------------2.05 OK ------------+ 1125 | | | 1127 B.3. Key Distribution Process 1129 The key distribution process utilizes the protocol described 1130 [I-D.richardson-6tisch-minimal-rekey]. The process starts with the 1131 initial key, rather than an actual rekey. 1133 This protocol remains active for subsequent rekey operations. 1135 Appendix C. YANG model for BRSKI objects 1137 module ietf-6tisch-brski { yang-version 1.1; 1139 namespace "urn:ietf:params:xml:ns:yang:6tisch-brski"; prefix 1140 "ietf6brski"; 1141 //import ietf-yang-types { prefix yang; } //import ietf-inet-types { 1142 prefix inet; } 1144 organization "IETF 6tisch Working Group"; 1146 contact "WG Web: http://tools.ietf.org/wg/6tisch/ WG List: 1147 6tisch@ietf.org [2] Author: Michael Richardson mcr+ietf@sandelman.ca 1148 [3]"; 1150 description "This module defines an interface to set and retrieve 1151 BRSKI objects using CoMI. This interface is used as part of an 1152 enrollment process for constrained nodes and networks."; 1154 revision "2017-03-01" { description "Initial version"; reference "RFC 1155 XXXX: 6tisch zero-touch bootstrap"; } 1157 // top-level container container ietf6brski { leaf requestnonce { 1158 type binary; length XX; // how big can/should it be? mandatory true; 1159 description "Request Nonce."; } leaf voucher { type binary; 1160 description "The voucher as a serialized COSE object"; } 1162 leaf csrattributes { 1163 type binary; 1164 description "A list of attributes that MUST be in the CSR"; 1165 } 1167 leaf certificaterequest { 1168 type binary; 1169 description "A PKIX format Certificate Request"; 1170 } 1172 leaf certificate { 1173 type binary; 1174 description "The LDevID certificate"; 1175 } } } 1177 C.1. Description of Pledge States in Join Process 1179 TBD 1181 Appendix D. Definition of managed objects for zero-touch bootstrap 1183 The following is relevant YANG for use in the bootstrap protocol. 1184 The objects identified are identical in format to the named objects 1185 from [I-D.ietf-anima-bootstrapping-keyinfra]. 1187 Appendix E. Privacy Considerations 1189 [I-D.ietf-6lo-privacy-considerations] details a number of privacy 1190 considerations important in Resource Constrained nodes. There are 1191 two networks and three sets of constrained nodes to consider. They 1192 are: 1. the production nodes on the production network. 2. the new 1193 pledges, which have yet to enroll, and which are on a join network. 1194 3. the production nodes which are also acting as proxy nodes. 1196 E.1. Privacy Considerations for Production network 1198 The details of this are out of scope for this document. 1200 E.2. Privacy Considerations for New Pledges 1202 New Pledges do not yet receive Router Advertisements with PIO 1203 options, and so configure link-local addresses only based upon 1204 layer-2 addresses using the normal SLAAC mechanisms described in 1205 [RFC4191]. 1207 These link-local addresses are visible to any on-link eavesdropper 1208 (who is synchronized to the same Join Assistant), so regardless of 1209 what is chosen they can be seen. This link-layer traffic is 1210 encapsulated by the Join Assistant into IPIP packets and carried to 1211 the JCE. The traffic SHOULD never leave the operator's network, and 1212 no outside traffic should enter, so it should not be possible to do 1213 any ICMP scanning as described in 1214 [I-D.ietf-6lo-privacy-considerations]. 1216 The join process described herein requires that some identifier 1217 meaningful to the network operator be communicated to the JCE via the 1218 Neighbor Advertisement's ARO option. This need not be a manufacturer 1219 created EUI-64 as assigned by IEEE; it could be another value with 1220 higher entropy and less interesting vendor/device information. 1221 Regardless of what is chosen, it can be used to track where the 1222 device attaches. 1224 For most constrained device, network attachment occurs very 1225 infrequently, often only once in their lifetime, so tracking 1226 opportunities may be rare. 1228 Further, during the enrollment process, a DTLS connection connection 1229 will be created. Unless TLS1.3 is used, the device identity will be 1230 visible to passive observers in the 802.11AR IDevID certificate that 1231 is sent. Even when TLS1.3 is used, an active attacker could collect 1232 the information by simply connecting to the device; it would not have 1233 to successful complete the negotiation either, or even attempt to 1234 Man-In-The-Middle the device. 1236 There is, at the same time, significant value in avoiding a link- 1237 local DAD process by using an IEEE assigned EUI-64, and there is also 1238 significant advantage to the operator being able to see what the 1239 vendor of the new device is. 1241 E.2.1. EUI-64 derived address for join time IID 1243 It is therefore suggested that the IID used in the link-local address 1244 used during the join process be a vendor assigned EUI-64. After the 1245 join process has concluded, the device SHOULD be assigned a unique 1246 randomly generated long address, and a unique short address (not 1247 based upon the vendor EUI-64) for use at link-layer. At that point, 1248 all layer-3 content is encrypted by the layer-2 key. 1250 E.3. Privacy Considerations for Join Assistant 1252 Appendix F. Security Considerations 1254 Appendix G. IANA Considerations 1256 This document allocates one value from the subregistry "Address 1257 Registration Option Status Values": ND_NS_JOIN_DECLINED Join 1258 Assistant, JOIN DECLINED (TBD-AA) 1260 Appendix H. Protocol Definition 1262 Appendix I. Acknowledgements 1264 Kristofer Pister helped with many non-IETF references. 1266 Authors' Addresses 1268 Michael Richardson 1269 Sandelman Software Works 1271 Email: mcr+ietf@sandelman.ca 1273 Benjamin Damm 1274 Silver Spring Networks 1276 Email: bdamm@ssni.com