idnits 2.17.1 draft-ietf-6tisch-dtsecurity-zerotouch-join-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-6tisch-minimal-security], [I-D.ietf-anima-bootstrapping-keyinfra]), 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 285 has weird spacing: '... pledge the p...' == Line 289 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 (April 30, 2018) is 2189 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-6tisch-minimal' is defined on line 1191, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-grasp' is defined on line 1224, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-yang-cbor' is defined on line 1245, but no explicit reference was found in the text == Unused Reference: 'RFC6775' is defined on line 1322, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 1333, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-sid' is defined on line 1379, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-useofrplinfo' is defined on line 1384, but no explicit reference was found in the text == Unused Reference: 'ISA100' is defined on line 1389, but no explicit reference was found in the text == Unused Reference: 'RFC7554' is defined on line 1414, but no explicit reference was found in the text == Unused Reference: 'RFC7731' is defined on line 1425, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-05 == Outdated reference: A later version (-18) exists of draft-ietf-ace-coap-est-00 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-14 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-02 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-12 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-06 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-04 == Outdated reference: A later version (-03) exists of draft-schaad-cose-x509-01 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-08 == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-06 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-13 == Outdated reference: A later version (-24) exists of draft-ietf-core-sid-03 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-22 Summary: 1 error (**), 0 flaws (~~), 27 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 B. Damm 5 Expires: November 1, 2018 Silver Spring Networks 6 April 30, 2018 8 6tisch Zero-Touch Secure Join protocol 9 draft-ietf-6tisch-dtsecurity-zerotouch-join-02 11 Abstract 13 This document describes a Zero-touch Secure Join (ZSJ) mechanism to 14 enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network 15 using the 6tisch signaling mechanisms. The resulting device will 16 obtain a domain specific credential that can be used with either 17 802.15.9 per-host pair keying protocols, or to obtain the network- 18 wide key from a coordinator. The mechanism describe here is an 19 augmentation to the one-touch mechanism described in 20 [I-D.ietf-6tisch-minimal-security], and a constrained version of 21 [I-D.ietf-anima-bootstrapping-keyinfra]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 1, 2018. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 60 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 7 61 1.3.1. Support environment . . . . . . . . . . . . . . . . . 8 62 1.3.2. Constrained environments . . . . . . . . . . . . . . 8 63 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 8 64 1.4. Leveraging the new key infrastructure / next steps . . . 8 65 1.4.1. Key Distribution Process . . . . . . . . . . . . . . 8 66 1.5. Requirements for Autonomic Network Infrastructure (ANI) 67 devices . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 8 69 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 9 70 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 10 71 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 10 72 2.3.1. Identification of the Pledge . . . . . . . . . . . . 11 73 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 11 74 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 12 75 2.5. Architectural Components . . . . . . . . . . . . . . . . 13 76 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 13 77 2.5.2. Stateless IPIP Join Proxy . . . . . . . . . . . . . . 13 78 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 13 79 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 14 80 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 14 81 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 14 82 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 14 83 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 14 84 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 14 85 2.8. Determining the MASA to contact . . . . . . . . . . . . . 14 86 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 15 87 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 15 88 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 15 89 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 15 90 4.3. HTTPS proxy connection to Registrar . . . . . . . . . . . 15 91 4.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 15 92 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 16 93 5.1. BRSKI-EST (D)TLS establishment details . . . . . . . . . 16 94 5.1.1. BRSKI-EST CoAP/DTLS estasblishment details . . . . . 16 95 5.1.2. BRSKI-EST CoAP/EDHOC estasblishment details . . . . . 17 96 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 18 97 5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 18 98 5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 19 99 5.4.1. MASA renewal of expired vouchers . . . . . . . . . . 19 100 5.4.2. MASA verification of voucher-request signature 101 consistency . . . . . . . . . . . . . . . . . . . . . 19 102 5.4.3. MASA authentication of registrar (certificate) . . . 19 103 5.4.4. MASA revocation checking of registrar (certificate) . 20 104 5.4.5. MASA verification of pledge prior-signed-voucher- 105 request . . . . . . . . . . . . . . . . . . . . . . . 20 106 5.4.6. MASA pinning of registrar . . . . . . . . . . . . . . 20 107 5.4.7. MASA nonce handling . . . . . . . . . . . . . . . . . 20 108 5.5. MASA Voucher Response . . . . . . . . . . . . . . . . . . 20 109 5.5.1. Pledge voucher verification . . . . . . . . . . . . . 21 110 5.5.2. Pledge authentication of provisional TLS connection . 21 111 5.6. Pledge Voucher Status Telemetry . . . . . . . . . . . . . 21 112 5.7. Registrar audit log request . . . . . . . . . . . . . . . 21 113 5.7.1. MASA audit log response . . . . . . . . . . . . . . . 21 114 5.7.2. Registrar audit log verification . . . . . . . . . . 21 115 5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 21 116 5.8.1. EST Distribution of CA Certificates . . . . . . . . . 21 117 5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 21 118 5.8.3. EST Client Certificate Request . . . . . . . . . . . 22 119 5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 22 120 5.8.5. Multiple certificates . . . . . . . . . . . . . . . . 22 121 5.8.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 22 122 5.9. Use of Secure Transport for Minimal Join . . . . . . . . 22 123 6. Reduced security operational modes . . . . . . . . . . . . . 22 124 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 23 125 6.2. Pledge security reductions . . . . . . . . . . . . . . . 23 126 6.3. Registrar security reductions . . . . . . . . . . . . . . 23 127 6.4. MASA security reductions . . . . . . . . . . . . . . . . 23 128 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 129 7.1. Well-known EST registration . . . . . . . . . . . . . . . 23 130 7.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 23 131 7.3. Voucher Status Telemetry . . . . . . . . . . . . . . . . 23 132 7.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 23 133 7.5. MUD File Extension for the MASA server . . . . . . . . . 23 134 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 135 8.1. Privacy Considerations for Production network . . . . . . 24 136 8.2. Privacy Considerations for New Pledges . . . . . . . . . 24 137 8.2.1. EUI-64 derived address for join time IID . . . . . . 25 138 8.3. Privacy Considerations for Join Proxy . . . . . . . . . . 25 139 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 140 9.1. Security of MASA voucher signing key(s) . . . . . . . . . 25 141 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 142 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 143 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 144 11.2. Informative References . . . . . . . . . . . . . . . . . 29 146 Appendix A. Extra text . . . . . . . . . . . . . . . . . . . . . 31 147 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 31 148 A.1.1. One-Touch Assumptions . . . . . . . . . . . . . . . . 31 149 A.1.2. Factory provided credentials (if any) . . . . . . . . 31 150 A.1.3. Credentials to be introduced . . . . . . . . . . . . 31 151 A.2. Network Assumptions . . . . . . . . . . . . . . . . . . . 32 152 A.2.1. Security above and below IP . . . . . . . . . . . . . 32 153 A.2.2. Join network assumptions . . . . . . . . . . . . . . 33 154 A.2.3. Number and cost of round trips . . . . . . . . . . . 33 155 A.2.4. Size of packets, number of fragments . . . . . . . . 33 156 A.3. Target end-state for join process . . . . . . . . . . . . 33 157 Appendix B. Join Protocol . . . . . . . . . . . . . . . . . . . 34 158 B.1. Key Agreement process . . . . . . . . . . . . . . . . . . 34 159 B.2. Provisional Enrollment process . . . . . . . . . . . . . 35 160 Appendix C. IANA Considerations . . . . . . . . . . . . . . . . 36 161 Appendix D. Protocol Definition . . . . . . . . . . . . . . . . 36 162 D.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 36 163 D.1.1. Proxy Discovery Protocol Details . . . . . . . . . . 37 164 D.1.2. Registrar Discovery Protocol Details . . . . . . . . 37 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 167 1. Introduction 169 Enrollment of new nodes into LLNs present unique challenges. The 170 constrained nodes has no user interfaces, and even if they did, 171 configuring thousands of such nodes manually is undesireable from a 172 human resources issue, as well as the difficulty in getting 173 consistent results. 175 This document is about a standard way to introduce new nodes into a 176 6tisch network that does not involve any direct manipulation of the 177 nodes themselves. This act has been called "zero-touch" 178 provisioning, and it does not occur by chance, but requires 179 coordination between the manufacturer of the node, the service 180 operator running the LLN, and the installers actually taking the 181 devices out of the shipping boxes. 183 This document is a constrained profile of 184 [I-D.ietf-anima-bootstrapping-keyinfra]. The above document/protocol 185 is referred by by it's acronym: BRSKI. The pronounciation of which 186 is "brew-ski", a common north american slang for beer with a pseudo- 187 polish ending. This constrained protocol is called ZSJ. 189 This document follows the same structure as it's parent in order to 190 emphasize the similarities, but specializes a number of things to 191 constrained networks of constrained devices. Like 192 [I-D.ietf-anima-bootstrapping-keyinfra], the networks which are in 193 scope for this protocol are deployed by a professional operator. The 194 deterministic mechanisms which have been designed into 6tisch have 195 been created to satisfy the operational needs of industrial settings 196 where such an operator exists. 198 This document builds upon the "one-touch" provisioning described in 199 [I-D.ietf-6tisch-minimal-security], reusing the OSCOAP Join Request 200 mechanism when appropriate, but preceeding it with either the EDHOC 201 key agreement protocol, or a DTLS channel. The [RFC7030] EST 202 protocol extended in [I-D.ietf-6tisch-minimal-security], has been 203 mapped by [I-D.ietf-ace-coap-est] into CoAP. 205 Otherwise, this document follows BRSKI with the following high-level 206 changes: 208 o HTTP is replaced with CoAP. 210 o TLS (HTTPS) is replaced with either DTLS+CoAP, or EDHOC/ 211 OSCOAP+CoAP 213 o the domain-registrar anchor certificate is replaced with a Raw 214 Public Key (RPK) using [RFC7250]. 216 o the PKCS7 signed JSON voucher format is replaced with CWT 218 o the GRASP discovery mechanism for the Proxy is replaced with an 219 announcement in the Enhanced Beacon 220 [I-D.richardson-6tisch-join-enhanced-beacon] 222 o the TCP circuit proxy mechanism is not used. The IPIP mechanism 223 if mandatory to implement when deployed with DTLS, while the CoAP 224 based stateless proxy mechanism is used for OSCOAP/EDHOC. 226 o real time clocks are assumed to be unavailable, so expiry dates in 227 ownership vouchers are never used 229 o nonce-full vouchers are encouraged, but off-line nonce-less 230 operation is also supported, however, the resulting vouchers have 231 infinite life. 233 802.1AR Client certificates are retained, but optionally are 234 specified by reference rather than value. 236 It is expected that the back-end network operator infrastructure 237 would be able to bootstrap ANIMA BRSKI-type devices over ethernet, 238 while also being able bootstrap 6tisch devices over 802.15.4 with few 239 changes. 241 NOTE TO RFC-EDITOR: during production of this document, it was 242 matched against [I-D.ietf-anima-bootstrapping-keyinfra] section by 243 section. This results in a few sections, such as IANA Considerations 244 where there is no requested activity. Those sections are marked "NO 245 ACTION, PLEASE REMOVE" and should be removed (along with this 246 paragraph) from the final document. 248 1.1. Prior Bootstrapping Approaches 250 Constrained devices as used in industrial control systems are usually 251 installed (or replaced) by technicians with expertise in the 252 equipment being serviced, not in secure enrollment of devices. 254 Devices therefore are typically pre-configured in advance, marked for 255 a particular factory, assembly line, or even down to the specific 256 machine. It is not uncommon for manufacturers to have a product code 257 (stock keeping unit -SKU) for each part, and for each customer as the 258 part will be loaded with customer specifc security configuration. 259 The resulting customer-specific parts are hard to inventory and 260 spare, and should parts be delivered to the wrong customer, 261 determining the reason for inability to configure is difficult and 262 time consuming. 264 End-user actions to configure the part at the time of installation, 265 aside from being error prone, also suffer from requiring a part that 266 has an interface. 268 1.2. Terminology 270 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 271 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 272 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 273 [RFC2119] and indicate requirement levels for compliant STuPiD 274 implementations. 276 The reader is expected to be familiar with the terms and concepts 277 defined in [I-D.ietf-6tisch-terminology], [RFC7252], 278 [I-D.ietf-core-object-security], and 279 [I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are 280 imported: drop ship, imprint, enrollment, pledge, join proxy, 281 ownership voucher, join registrar/coordinator. The following terms 282 are repeated here for readability, but this document is not 283 authoritative for their definition: 285 pledge the prospective device, which has the identity provided to at 286 the factory. Neither the device nor the network knows if the 287 device yet knows if this device belongs with this network. 289 Joined Node the prospective device, after having completing the join 290 process, often just called a Node. 292 Join Proxy (JP): a stateless relay that provides connectivity 293 between the pledge and the join registrar/coordinator. 295 Join Registrar/Coordinator (JRC): central entity responsible for 296 authentication and authorization of joining nodes. 298 Audit Token A signed token from the manufacturer authorized signing 299 authority indicating that the bootstrapping event has been 300 successfully logged. This has been referred to as an 301 "authorization token" indicating that it authorizes bootstrapping 302 to proceed. 304 Ownership Voucher A signed voucher from the vendor vouching that a 305 specific domain "owns" the new entity as defined in 306 [I-D.ietf-anima-voucher]. 308 MIC manufacturer installed certificate. An [ieee802-1AR] identity. 309 Not to be confused with a (cryptographic) "Message Integrity 310 Check" 312 1.3. Scope of solution 314 The solution described in this document is appropriate to enrolling 315 between hundreds to hundreds of thousands of diverse devices into a 316 network without any prior contact with the devices. The devices 317 could be shipped by the manufacturer directly to the customer site 318 without ever being seen by the operator of the network. As described 319 in BRSKI, in the audit-mode of operation the device will be claimed 320 by the first network that sees it. In the tracked owner mode of 321 operation, sales channel integration provides a strong connection 322 that the operator of the network is the legitimate owner of the 323 device. 325 BRSKI describes a more general, more flexible approach for 326 bootstrapping devices into an ISP or Enterprise network. 328 [I-D.ietf-6tisch-minimal-security] provides an extremely streamlined 329 approach to enrolling from hundreds to thousands of devices into a 330 network, provided that a unique secret key can be installed in each 331 device. 333 1.3.1. Support environment 335 TBD 337 1.3.2. Constrained environments 339 TBD 341 1.3.3. Network Access Controls 343 TBD 345 1.4. Leveraging the new key infrastructure / next steps 347 In constrained networks, it is unlikely that an ACP be formed. This 348 document does not preclude such a thing, but it is not mandated. 350 The resulting secure channel MAY be used just to distribute network- 351 wide keys using a protocol such as 352 [I-D.ietf-6tisch-minimal-security]. (XXX - do we need to signal this 353 somehow?) 355 The resulting secure channel MAY be instead used to do an enrollment 356 of an LDevID as in BRSKI, but the resulting certificate is used to do 357 per-pair keying such as described by {{ieee802159}. 359 1.4.1. Key Distribution Process 361 In addition to being used for the initial enrollment process, the 362 secure channel may be kept open (and reversed) to use for network 363 rekeying. Such a process is out of scope of this document, please 364 see future work such as [I-D.richardson-6tisch-minimal-rekey]. 366 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices 368 TBD 370 2. Architectural Overview 372 Section 2 of BRSKI has a diagram with all of the components shown 373 together. There are no significant changes to the diagram. 375 The use of a circuit proxy is not mandated. Instead the IPIP 376 mechanism described in appendix C ("IPIP Join Proxy mechanism") 377 SHOULD be be used instead as it supports both DTLS, EDHOC and OSCOAP 378 protocols. 380 The CoAP proxy mechanism MAY be implemented instead: the decision 381 depends upon the capabilities of the Registrar and the proxy. A 382 mechanism is included for the Registrar to announce it's capabilities 383 (XXX) 385 2.1. Behavior of a Pledge 387 The pledge goes through a series of steps which are outlined here at 388 a high level. 390 +--------------+ 391 | Factory | 392 | default | 393 +------+-------+ 394 | 395 +------v-------+ 396 | (1) Discover | 397 +------------> | 398 | +------+-------+ 399 | | 400 | +------v-------+ 401 | | (2) Identity | 402 ^------------+ | 403 | rejected +------+-------+ 404 | | 405 | +------v-------+ 406 | | (3) Request | 407 | | Join | 408 | +------+-------+ 409 | | 410 | +------v-------+ 411 | | (4) Imprint | 412 ^------------+ | 413 | Bad MASA +------+-------+ 414 | response | send Voucher Status Telemetry 415 | +------v-------+ 416 | | (5) Enroll | 417 ^------------+ | 418 | Enroll +------+-------+ 419 | Failure | 420 | +------v-------+ 421 | | (6) Enrolled | 422 ^------------+ | 423 Factory +--------------+ 424 reset 426 State descriptions for the pledge are as follows: 428 1. Discover a communication channel to a Registrar. This is done by 429 listening for beacons as described by 430 [I-D.richardson-anima-6join-discovery] 432 2. Identify itself. This is done by presenting an X.509 IDevID 433 credential to the discovered Registrar (via the Proxy) in a DTLS 434 or EDHOC handshake. (The Registrar credentials are only 435 provisionally accepted at this time). 437 The registrar identifies itself using a raw public key, while the 438 the pledge identifies itself to the registrar using an IDevID 439 credential. 441 3. Requests to Join the discovered Registrar. A unique nonce can be 442 included ensuring that any responses can be associated with this 443 particular bootstrapping attempt. 445 4. Imprint on the Registrar. This requires verification of the 446 vendor service (MASA) provided voucher. A voucher contains 447 sufficient information for the Pledge to complete authentication 448 of a Registrar. The voucher is signed by the vendor (MASA) using 449 a raw public key, previously installed into the pledge at 450 manufacturing time. 452 5. Optionally Enroll. By accepting the domain specific information 453 from a Registrar, and by obtaining a domain certificate from a 454 Registrar using a standard enrollment protocol, e.g. Enrollment 455 over Secure Transport (EST) [RFC7030]. 457 6. The Pledge is now a member of, and can be managed by, the domain 458 and will only repeat the discovery aspects of bootstrapping if it 459 is returned to factory default settings. 461 2.2. Secure Imprinting using Vouchers 463 As in BRSKI, the format and cryptographic mechansim of vouchers is 464 described in detail in [I-D.ietf-anima-voucher]. As described in 465 section YYY, the physical format for vouchers in this document 466 differs from that of BRSKI, in that it uses 467 [I-D.ietf-ace-cbor-web-token] to encode the voucher and to sign it. 469 2.3. Initial Device Identifier 471 The essential component of the zero-touch operation is that the 472 pledge is provisioned with an 802.1AR (PKIX) certificate installed 473 during the manufacturing process. 475 It is expected that constrained devices will use a signature 476 algorithm corresponding to the hardware acceleration that they have, 477 if they have any. The anticipated algorithms are the ECDSA P-256 478 (secp256p1) as SHOULD-, while newer devices SHOLD+ begin to appear 479 using EdDSA curves using the 25519 curves. (EDNOTE details here) 481 There are a number of simplications detailed later on in this 482 document designed to eliminate the need for an ASN.1 parser in the 483 pledge. 485 The pledge should consider it's 802.1AR certificate to be an opaque 486 blob of bytes, to be inserted into protocols at appropriate places. 487 The pledge SHOULD have access to it's public and private keys in the 488 most useable native format for computation. 490 The pledge MUST have the public key of the MASA built in a 491 manufacturer time. This is a seemingly identical requirement as for 492 BRSKI, but rather than being an abstract trust anchor that can be 493 augmented with a certificate chain, the pledge MUST be provided with 494 the Raw Public Key that the MASA will use to sign vouchers for that 495 pledge. 497 There are a number of security concerns with use of a single MASA 498 signing key, and section Section 9.1 addresses some of them with some 499 operational suggestions. 501 BRSKI places some clear requirements upon the contents of the IDevID, 502 but leaves the exact origin of the voucher serial-number open. This 503 document restricts the process to being the hwSerialNum OCTET STRING. 504 As CWT can handle binary formats, no base64 encoding is necessary. 506 The use of the MASA-URL extension is encouraged if the certificate is 507 sent at all. 509 EDNOTE: here belongs text about sending only a reference to the 510 IDevID rather than the entire certificate 512 2.3.1. Identification of the Pledge 514 TBD 516 2.3.2. MASA URI extension 518 TBD 520 2.4. Protocol Flow 522 The diagram from BRSKI is reproduced with some edits: 524 +--------+ +---------+ +------------+ +------------+ 525 | Pledge | | IPIP | | Domain | | Vendor | 526 | | | Proxy | | Registrar | | Service | 527 | | | | | (JRC) | | (MASA) | 528 +--------+ +---------+ +------------+ +------------+ 529 | | | | 530 |<-RFC4862 IPv6 adr | | | 531 | | | | 532 |<--------------------| | | 533 | Enhanced Beacon | | | 534 | periodic broadcast| | | 535 | | | | 536 |<------------------->C<----------------->| | 537 | DTLS via the IPIP Proxy | | 538 |<--Registrar DTLS server authentication--| | 539 [PROVISIONAL accept of server cert] | | 540 P---X.509 client authentication---------->| | 541 P | | | 542 P---Voucher Request (include nonce)------>| | 543 P | | | 544 P | | | 545 P | [accept device?] | 546 P | [contact Vendor] | 547 P | |--Pledge ID-------->| 548 P | |--Domain ID-------->| 549 P | |--nonce------------>| 550 P | | [extract DomainID] 551 P | | | 552 P | | [update audit log] 553 P | | | 554 P | | | 555 P | | | 556 P | | | 557 P | | | 558 P | |<-device audit log--| 559 P | |<- voucher ---------| 560 P | | | 561 P | | | 562 P | [verify audit log and voucher] | 563 P | | | 564 P<------voucher---------------------------| | 565 [verify voucher ] | | | 566 [verify provisional cert| | | 567 | | | | 568 |<--------------------------------------->| | 569 | Continue with RFC7030 enrollment | | 570 | using now bidirectionally authenticated | | 571 | DTLS session. | | | 572 | | | | 573 |<--------------------------------------->| | 574 | Use 6tisch-minimal-security join request | 576 Noteable changes are: 578 1. no IPv4 support/options. 580 2. no mDNS steps, 6tisch only uses Enhanced Beacon 582 3. nonce-full option is always mandatory 584 2.5. Architectural Components 586 The bootstrap process includes the following architectural 587 components: 589 2.5.1. Pledge 591 The Pledge is the device which is attempting to join. Until the 592 pledge completes the enrollment process, it has network connectivity 593 only to the Proxy. 595 2.5.2. Stateless IPIP Join Proxy 597 The stateless CoAP or DTLS Proxy provides CoAP or DTLS connectivity 598 (respectively) between the pledge and the registrar. The stateless 599 CoAP proxy mechanism is described in 600 [I-D.ietf-6tisch-minimal-security] section 5.1. 602 The stateless DTLS mechanism is not yet described (TBD). 604 2.5.3. Domain Registrar 606 The Domain Registrar (having the formal name Join Registrar/ 607 Coordinator (JRC)), operates as a CMC Registrar, terminating the EST 608 and BRSKI connections. The Registrar is manually configured or 609 distributed with a list of trust anchors necessary to authenticate 610 any Pledge device expected on the network. The Registrar 611 communicates with the Vendor supplied MASA to establish ownership. 613 The JRC is typically located on the 6LBR/DODAG root, but it may be 614 located elsewhere, provided IP level connectivity can be established. 615 The 6LBR may also provide a proxy or relay function to connect to the 616 actual registrar in addition to the IPIP proxy described above. The 617 existence of such an additional proxy is a private matter, and this 618 documents assumes without loss of generality that the registrar is 619 co-located with the 6LBR. 621 2.5.4. Manufacturer Service 623 The Manufacturer Service provides two logically seperate functions: 624 the Manufacturer Authorized Signing Authority (MASA), and an 625 ownership tracking/auditing function. This function is identical to 626 that used by BRSKI, except that a different format voucher is used. 628 2.5.5. Public Key Infrastructure (PKI) 630 TBD 632 2.6. Certificate Time Validation 634 2.6.1. Lack of realtime clock 636 For the constrained situation it is assumed that devices have no real 637 time clock. These nodes do have access to a monotonically increasing 638 clock that will not go backwards in the form of the Absolute Sequence 639 Number. Synchronization to the ASN is required in order to transmit/ 640 receive data and most nodes will maintain it in hardware. 642 The heuristic described in BRSKI under this section SHOULD be applied 643 if there are dates in the CWT format voucher. 645 Voucher requests SHOULD include a nonce. For devices intended for 646 off-line deployment, the vouchers will have been generated in advance 647 and no nonce-ful operation will not be possible. 649 2.6.2. Infinite Lifetime of IDevID 651 TBD 653 2.7. Cloud Registrar 655 In 6tisch, the pledge never has network connectivity until it is 656 enrolled, so no alternate registrar is ever possible. 658 2.8. Determining the MASA to contact 660 There are no changes from BRSKI: the IDevID provided by the pledge 661 will contain a MASA URL extension. 663 3. Voucher-Request artifact 665 The voucher-request artifact is defined in 666 [I-D.richardson-anima-ace-constrained-voucher] section 6.1. 668 For the 6tisch ZSJ protocol defined in this document, only COSE 669 signed vouchers as described in 670 [I-D.richardson-anima-ace-constrained-voucher] section 6.3.2 are 671 supported. 673 4. Proxying details (Pledge - Proxy - Registrar) 675 The role of the Proxy is to facilitate communication. In the 676 constrained situation the proxy needs to be stateless as there is 677 very little ram to begin with, and none can be allocated to keep 678 state for an unlimited number of potential pledges. 680 4.1. Pledge discovery of Proxy 682 In BRSKI, the pledge discovers the proxy via use of a GRASP M_FLOOD 683 messages sent by the proxy. In 6tisch ZSJ, the existence of the 684 proxy is announced by the Enhanced Beacon defined in 685 [I-D.richardson-6tisch-join-enhanced-beacon]. 687 4.2. CoAP connection to Registrar 689 In BRSKI CoAP is future work. This document represents this work. 691 4.3. HTTPS proxy connection to Registrar 693 HTTPS connections are not used between the Pledge, Proxy and 694 Registrar. The Proxy relays CoAP or DTLS packets and does not 695 interpret or terminate either CoAP or DTLS connections. (HTTPS is 696 still used between the Registrar and MASA) 698 4.4. Proxy discovery of Registrar 700 In BRSKI, the proxy autonomically discovers the Registrar by 701 listening for GRASP messages. 703 In the constrained network, the proxies are optionally configured 704 with the address of the JRC by the Join Response in 705 [I-D.ietf-6tisch-minimal-security] section 8. As specified in that 706 section, if the address of the registrar otherwise defaults to be 707 that of the DODAG root. 709 Whether or not a 6LR will announce itself as a possible Join Proxy is 710 outside the scope of this document. 712 5. Protocol Details (Pledge - Registrar - MASA) 714 BRSKI is specified to run over HTTPS. This document respecifies it 715 to run over CoAP with either DTLS or EDHOC-provided OSCOAP security. 717 There is an emerging (hybrid) possibility of DTLS-providing the 718 OSCOAP security, but such a specification does not yet exist, and 719 this document does at this point specify it. 721 [I-D.ietf-ace-coap-est] specifies that CoAP specifies the use of CoAP 722 Block-Wise Transfer ("Block") [RFC7959] to fragment EST messages at 723 the application layer. 725 BRSKI introduces the concept of a provisional state for EST. The 726 same situation must also be added to DTLS: a situation where the 727 connection is active but the identity of the Registar has not yet 728 been confirmed. 730 The DTLS MUST validate that the exchange has been signed by the Raw 731 Public Key that is presented by the Server, even though there is as 732 yet no trust in that key. Such a key is often available through APIs 733 that provide for channel binding, such as described in [RFC5056]. 735 As in [I-D.ietf-ace-coap-est], support for Observe CoAP options 736 [RFC7641] with BRSKI is not supported in the current BRSKI/EST 737 message flows. 739 Observe options could be used by the server to notify clients about a 740 change in the cacerts or csr attributes (resources) and might be an 741 area of future work. 743 Redirection as described in [RFC7030] section 3.2.1 is NOT supported. 745 5.1. BRSKI-EST (D)TLS establishment details 747 6tisch ZSJ does not use TLS. The connection is either CoAP over 748 DTLS, or CoAP with EDHOC security. 750 5.1.1. BRSKI-EST CoAP/DTLS estasblishment details 752 The details in the BRSKI document apply directly to use of DTLS. 754 The registrar SHOULD authenticate itself with a raw public key. A 755 256 bit ECDSA raw public key is RECOMMENDED. Pledges SHOULD support 756 EDDSA keys if they contain hardware that supports doing so 757 efficiently. 759 TBD: the Pledge needs to signal what kind of Raw Public Key it 760 supports before the Registrar sends its ServerCertificate. Can SNI 761 be used to do this? 763 The pledge SHOULD authenticate itself with the built-in IDevID 764 certificate as a ClientCertificate. 766 5.1.2. BRSKI-EST CoAP/EDHOC estasblishment details 768 [I-D.selander-ace-cose-ecdhe] details how to use EDHOC. The EDHOC 769 description identifiers a party U (the initiator), and a party V. 770 The Pledge is the party U, and the JRC is the party V. 772 The communication from the Pledge is via CoAP via the Join Proxy. 773 The Join proxy relays traffic to the JRC, and using the mechanism 774 described in [I-D.ietf-6tisch-minimal-security] section 5.1. This is 775 designed so that the Join Proxy does not need to know if it is 776 performing the one-touch enrollment described in 777 [I-D.ietf-6tisch-minimal-security] or the zero-touch enrollment 778 protocol described in this document. A network could consist of a 779 mix of nodes of each type. 781 As generating ephemeral keys is expensive for a low-resource Pledge, 782 the use of a common E_U by the Pledge for multiple enrollment 783 attempts (should the first turn out to be the wrong network) is 784 encouraged. 786 The first communication detailed in [I-D.ietf-ace-coap-est] is to 787 query the "/.well-known/core" resource to request the Link for EST. 788 This is where the initial CoAP request is to sent. 790 The JRC MAY replace it's E_V ephermal key on a periodic basis, or 791 even for every communication session. 793 The Pledge's ID_U is the Pledge's IDevID. It is transmitted in an 794 x5bag [I-D.schaad-cose-x509]. An x5u (URL) MAY be used. An x5t 795 (hash) MAY also be used and would be the smallest, but the Registrar 796 may not know where to find the Pledge's IDevID unless the JRC has 797 been preloaded will all the IDevIDs via out-of-band mechanism. It is 798 impossible for the Pledge to know if the JRC has been loaded in such 799 a way so x5t is discouraged for general use. 801 The JRC's ID_V is the JRC's Raw Public Key. It is transmitted as a 802 key in COSE's YYY parameter. 804 The initial Mandatory to Implement (MTI) of an HKDF of SHA2-256, an 805 AEAD based upon AES-CCM-16-64-128, a signature verification of BBBB, 806 and signature generation of BBBB. The Pledge proposes a set of 807 algorithms that it supports, and Pledge need not support more than 808 one combination. 810 JRCs are expected to run on non-constrained servers, and are expected 811 to support the above initial MTI, and any subsequent ones that become 812 common. A JRC SHOULD support all available algorithms for a 813 significant amount of time. Even when algorithms become weak or 814 suspect, it is likely that it will still have to perform secure join 815 for older devices. A JRC that responds to such an older device might 816 not in the end accept the device into the network, but it is 817 important that it be able to audit the event and communicate the 818 event to an operator. 820 While EDHOC supports sending additional data in the message_3, in the 821 constrained network situation, it is anticipated that the size of the 822 this message will already be large, and no additional data is to be 823 sent. 825 A COAP confirmable message SHOULD be used. 827 [I-D.ietf-6tisch-minimal-security] section 6 details how to setup 828 OSCORE context given a shared key derived by EDHOC. 830 The registrar SHOULD authenticate itself with a raw public key. 832 The pledge SHOULD authenticate itself with the built-in IDevID 833 certificate. 835 5.2. Pledge Requests Voucher from the Registrar 837 The voucher request and response as defined by BRSKI is modified 838 slightly. 840 In order to simplify the pledge, the use of a certificate (and chain) 841 for the Registrar is not supported. Instead the newly defined 842 pinned-domain-subject-public-key-info must contain the (raw) public 843 key info for the Registrar. It MUST be byte for byte identical to 844 that which is transmitted by the Registrar during the TLS 845 ServerCertificate handshake. 847 BRSKI permits the voucher request to be signed or unsigned. This 848 document defines the voucher request to be unsigned. 850 5.3. BRSKI-MASA TLS establishment details 852 There are no changes. The connection from the Registrar to MASA is 853 still HTTPS. 855 5.4. Registrar Requests Voucher from MASA 857 There are no change from BRSKI, as this step is between two non- 858 constrained devices. 860 The format of the voucher is COSE, which implies changes to both the 861 Registrar and the MASA, but semantically the content is the same. 863 The manufacturer will know what algorithms are supported by the 864 pledge, and will issue a 406 (Conflict) error to the Registrar if the 865 Registar's public key format is not supported by the pledge. It is 866 however, too late for the Registar to use a different key, but at 867 least it can log a reason for a failure. It is likely that the ZSJ- 868 BRSKI-EST connection has already failed, and this step is never 869 reached. 871 5.4.1. MASA renewal of expired vouchers 873 There are assumed to be no useful real-time clocks on constrained 874 devices, so all vouchers are in effect infinite duration. Pledges 875 will use nonces for freshness, and a request for a new voucher with a 876 new voucher for the same Registrar is not unusual. A token-bucket 877 system SHOULD be used such that no more than 24 vouchers are issued 878 per-day, but more than one voucher can be issued in a one hour 879 period. Tokens should not accumulate for more than one day! 881 5.4.2. MASA verification of voucher-request signature consistency 883 The voucher-request is signed by the Registrar using it's Raw Public 884 Key. There is no additional certificate authority to sign this key. 885 The MASA MAY have this key via sales-channel integration, but in most 886 cases it will be seeing the key for the first time. 888 XXX-should the TLS connection from Registrar to MASA have a 889 ClientCertificate? If so, then should it use the same Public Key? 890 Or a different one? 892 5.4.3. MASA authentication of registrar (certificate) 894 IDEA: The MASA SHOULD pin the Raw Public Key (RPK) to the IP address 895 that was first used to make a request with it. Should the RPK <-> IP 896 address relationship be 1:1, 1:N, N:1? Should we take IP address to 897 mean, "IP subnet", essentially the IPv4/24, and IPv6/64? The value 898 of doing is about DDoS mitigation? 900 Should above mapping be on a per-Pledge basis? 902 5.4.4. MASA revocation checking of registrar (certificate) 904 As the Registrar has a Raw Public Key as an identity, there is no 905 meaningful standard revocation checking that can be done. The MASA 906 SHOULD have a blacklist table, and a way to add entries, but this 907 process is out of scope. 909 5.4.5. MASA verification of pledge prior-signed-voucher-request 911 The MASA will know whether or not the Pledge is capable of producing 912 a signed voucher-request for inclusion by the Registrar. In the case 913 where the Pledge can sign the voucher-request to the Registrar, then 914 the Registrar will have put it in the 'prior-signed-voucher-request'. 915 The MASA can verify the signature from the Pledge using the MASA's 916 copy of the Pledge's IDevID public key. 918 In many cases, the Pledge will not be capable of doing signatures in 919 real time, so no 'prior-signed-voucher-request' will be present. The 920 MASA will have rely on the audit log as a history function to 921 determine if the Pledge has previously been claimed, and to identify 922 situations where the claim from the Registrar is fraudulent. 924 5.4.6. MASA pinning of registrar 926 When the MASA creates a voucher, it puts the Registrar's Raw Public 927 Key into the 'pinned-domain-subject-public-key-info' leaf of the 928 voucher. 930 The MASA does not include the 'pinned-domain-cert' field. 932 5.4.7. MASA nonce handling 934 Use of nonces is highly RECOMMENDED, but there are situations where 935 not all components are connected at the same time in which the nonce 936 will not be present. 938 There are no significant changes from BRSKI. 940 5.5. MASA Voucher Response 942 The MASA responses with a voucher as specified in 943 [I-D.richardson-anima-ace-constrained-voucher] section 6.2. 945 This result is communicated back with a MIME Content-Type of 946 'application/voucher-cose+cbor' 948 5.5.1. Pledge voucher verification 950 The Pledge receives the voucher from the Registrar over it's CoAP 951 connection. It verifies the signature using the MASA anchor built 952 in, as in the BRSKI case. 954 5.5.2. Pledge authentication of provisional TLS connection 956 The BRSKI process uses the pinned-domain-cert field of the voucher to 957 validate the registrar's ServerCertificate. In the ZeroTouch case, 958 the voucher will contain a pinned-domain-subject-public-key-info 959 field containing the raw public key of the certificate. It should 960 match, byte-to-byte with the raw public key ServerCertificate. 962 5.6. Pledge Voucher Status Telemetry 964 The voucher status telemetry report is communicated from the pledge 965 to the registrar over CoAP channel. The shortened URL is as 966 described in table QQQ. 968 5.7. Registrar audit log request 970 There are no changes to the Registrar audit log request. 972 5.7.1. MASA audit log response 974 There are no changes to the MASA audit log response. 976 5.7.2. Registrar audit log verification 978 There are no changes to how the Registrar verifies the audit log. 980 5.8. EST Integration for PKI bootstrapping 982 TBD. 984 5.8.1. EST Distribution of CA Certificates 986 TBD. 988 5.8.2. EST CSR Attributes 990 In 6tisch, no Autonomic Control Plane will be created, so none of the 991 criteria for SubjectAltname found in 992 [I-D.ietf-anima-autonomic-control-plane] apply. 994 The CSR Attributes request SHOULD NOT be performed. 996 5.8.3. EST Client Certificate Request 998 6tisch will use a certificate to: 1000 1. to authenticate an 802.15.9 key agreement protocol. 1002 2. to terminate an incoming DTLS or EDHOC key agreement as part of 1003 application data protection. 1005 It is recommended that the requested subjectAltName contain only the 1006 [RFC4514] hwSerialNum. 1008 5.8.4. Enrollment Status Telemetry 1010 There are no changes to the status telemetry between Registrar and 1011 MASA. 1013 5.8.5. Multiple certificates 1015 Multiple certificates are not supported. 1017 5.8.6. EST over CoAP 1019 This document and [I-D.ietf-ace-coap-est] detail how to run EST over 1020 CoAP. 1022 5.9. Use of Secure Transport for Minimal Join 1024 Rather than bootstrap to a public key infrastructure, the secure 1025 channel MAY instead be for the minimal security join process 1026 described in [I-D.ietf-6tisch-minimal-security]. 1028 The desire to do a minimal-security join process is signaled by the 1029 Registrar in it's voucher-request by including a 'join-process' value 1030 of 'minimal'. The MASA copies this value into the voucher that is 1031 creates, and also logs this to the audit log. 1033 When the secure channel was created with EDHOC, then the keys setup 1034 by EDHOC are simply used by OSCORE exactly as if they had been Pre- 1035 Shared. The keys derived by EDHOC SHOULD be stored by both Registrar 1036 and Pledge as their long term key should the join process need to be 1037 repeated. 1039 6. Reduced security operational modes 1041 This document defines a specific reduced security operational mode, 1042 specifically: 1044 1. X 1046 2. Y 1048 3. Z 1050 6.1. Trust Model 1052 TBD 1054 6.2. Pledge security reductions 1056 TBD 1058 6.3. Registrar security reductions 1060 TBD 1062 6.4. MASA security reductions 1064 TBD 1066 7. IANA Considerations 1068 XXX 1070 7.1. Well-known EST registration 1072 XXX 1074 7.2. PKIX Registry 1076 TBD 1078 7.3. Voucher Status Telemetry 1080 TBD 1082 7.4. DNS Service Names 1084 TBD 1086 7.5. MUD File Extension for the MASA server 1088 TBD 1090 8. Privacy Considerations 1092 [I-D.ietf-6lo-privacy-considerations] details a number of privacy 1093 considerations important in Resource Constrained nodes. There are 1094 two networks and three sets of constrained nodes to consider. They 1095 are: 1. the production nodes on the production network. 2. the new 1096 pledges, which have yet to enroll, and which are on a join network. 1097 3. the production nodes which are also acting as proxy nodes. 1099 8.1. Privacy Considerations for Production network 1101 The details of this are out of scope for this document. 1103 8.2. Privacy Considerations for New Pledges 1105 New Pledges do not yet receive Router Advertisements with PIO 1106 options, and so configure link-local addresses only based upon 1107 layer-2 addresses using the normal SLAAC mechanisms described in 1108 [RFC4191]. 1110 These link-local addresses are visible to any on-link eavesdropper 1111 (who is synchronized to the same Join Assistant), so regardless of 1112 what is chosen they can be seen. This link-layer traffic is 1113 encapsulated by the Join Proxy into IPIP packets and carried to the 1114 JRC. The traffic SHOULD never leave the operator's network, will be 1115 kept confidential by the layer-2 keys inside the LLN. As no outside 1116 traffic can enter the join network, to do any ICMP scanning as 1117 described in [I-D.ietf-6lo-privacy-considerations]. 1119 The join process described herein requires that some identifier 1120 meaningful to the network operator be communicated to the JRC. The 1121 join request with this object occurs within a secured CoAP channel, 1122 although the link-local address configured by the pledge will be 1123 visible in either the CoAP stateless proxy option (section 5.1 of 1124 [I-D.ietf-6tisch-minimal-security]), or in the equivalent DTLS 1125 stateless proxy option (reference TBD). 1127 This need not be a manufacturer created EUI-64 as assigned by IEEE; 1128 it could be another value with higher entropy and less interesting 1129 vendor/device information. Regardless of what is chosen, it can be 1130 used to track where the device attaches. 1132 For most constrained device, network attachment occurs very 1133 infrequently, often only once in their lifetime, so tracking 1134 opportunities may be rare. Once connected, the long 8-byte EUI64 1135 layer-2 address is usually replaced with a short JRC assigned 2-byte 1136 address. 1138 Additionally, during the enrollment process, a DTLS connection or 1139 EDHOC connection will be created. TLS1.3 will keep contents of the 1140 certificates transmitted private while TLS 1.2 will not. If the 1141 client certificate can be observed, then the device identity will be 1142 visible to passive observers in the 802.11AR IDevID certificate that 1143 is sent. 1145 Even when TLS 1.3 is used, an active attacker could collect the 1146 information by creating a rogue proxy. 1148 The use of a manufacturer assigned EUI64 (whether derived from IEEE 1149 assignment or created through another process during manufacturing 1150 time) is encouraged. 1152 8.2.1. EUI-64 derived address for join time IID 1154 The IID used in the link-local address used during the join process 1155 be a vendor assigned EUI-64. After the join process has concluded, 1156 the device SHOULD be assigned a unique randomly generated long 1157 address, and a unique short address (not based upon the vendor EUI- 1158 64) for use at link-layer address. At that point, all layer-3 1159 content is encrypted by the layer-2 key. 1161 8.3. Privacy Considerations for Join Proxy 1163 TBD. 1165 9. Security Considerations 1167 TBD 1169 9.1. Security of MASA voucher signing key(s) 1171 TBD 1173 10. Acknowledgements 1175 Kristofer Pister helped with many non-IETF references. 1177 11. References 1179 11.1. Normative References 1181 [cullenCiscoPhoneDeploy] 1182 Jennings, C., "Transitive Trust Enrollment for Constrained 1183 Devices", 2012, . 1186 [I-D.ietf-6lo-privacy-considerations] 1187 Thaler, D., "Privacy Considerations for IPv6 Adaptation 1188 Layer Mechanisms", draft-ietf-6lo-privacy- 1189 considerations-04 (work in progress), October 2016. 1191 [I-D.ietf-6tisch-minimal] 1192 Vilajosana, X., Pister, K., and T. Watteyne, "Minimal 1193 6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work 1194 in progress), February 2017. 1196 [I-D.ietf-6tisch-minimal-security] 1197 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 1198 "Minimal Security Framework for 6TiSCH", draft-ietf- 1199 6tisch-minimal-security-05 (work in progress), March 2018. 1201 [I-D.ietf-6tisch-terminology] 1202 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1203 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 1204 draft-ietf-6tisch-terminology-10 (work in progress), March 1205 2018. 1207 [I-D.ietf-ace-cbor-web-token] 1208 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1209 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15 1210 (work in progress), March 2018. 1212 [I-D.ietf-ace-coap-est] 1213 Stok, P., Kampanakis, P., Kumar, S., Richardson, M., 1214 Furuhed, M., and S. Raza, "EST over secure CoAP (EST- 1215 coaps)", draft-ietf-ace-coap-est-00 (work in progress), 1216 February 2018. 1218 [I-D.ietf-anima-bootstrapping-keyinfra] 1219 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1220 S., and K. Watsen, "Bootstrapping Remote Secure Key 1221 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1222 keyinfra-14 (work in progress), April 2018. 1224 [I-D.ietf-anima-grasp] 1225 Bormann, C., Carpenter, B., and B. Liu, "A Generic 1226 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 1227 grasp-15 (work in progress), July 2017. 1229 [I-D.ietf-anima-voucher] 1230 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1231 "Voucher Profile for Bootstrapping Protocols", draft-ietf- 1232 anima-voucher-07 (work in progress), January 2018. 1234 [I-D.ietf-core-comi] 1235 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 1236 Management Interface", draft-ietf-core-comi-02 (work in 1237 progress), December 2017. 1239 [I-D.ietf-core-object-security] 1240 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1241 "Object Security for Constrained RESTful Environments 1242 (OSCORE)", draft-ietf-core-object-security-12 (work in 1243 progress), March 2018. 1245 [I-D.ietf-core-yang-cbor] 1246 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 1247 Minaburo, "CBOR Encoding of Data Modeled with YANG", 1248 draft-ietf-core-yang-cbor-06 (work in progress), February 1249 2018. 1251 [I-D.ietf-netconf-keystore] 1252 Watsen, K., "YANG Data Model for a "Keystore" Mechanism", 1253 draft-ietf-netconf-keystore-04 (work in progress), October 1254 2017. 1256 [I-D.richardson-6tisch-join-enhanced-beacon] 1257 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 1258 Element encapsulation of 6tisch Join Information", draft- 1259 richardson-6tisch-join-enhanced-beacon-03 (work in 1260 progress), January 2018. 1262 [I-D.richardson-6tisch-minimal-rekey] 1263 Richardson, M., "Minimal Security rekeying mechanism for 1264 6TiSCH", draft-richardson-6tisch-minimal-rekey-02 (work in 1265 progress), August 2017. 1267 [I-D.richardson-anima-6join-discovery] 1268 Richardson, M., "GRASP discovery of Registrar by Join 1269 Assistant", draft-richardson-anima-6join-discovery-00 1270 (work in progress), October 2016. 1272 [I-D.richardson-anima-ace-constrained-voucher] 1273 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 1274 Voucher Profile for Bootstrapping Protocols", draft- 1275 richardson-anima-ace-constrained-voucher-03 (work in 1276 progress), February 2018. 1278 [I-D.schaad-cose-x509] 1279 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1280 Headers for carrying and referencing X.509 certificates", 1281 draft-schaad-cose-x509-01 (work in progress), May 2017. 1283 [I-D.selander-ace-cose-ecdhe] 1284 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 1285 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 1286 cose-ecdhe-08 (work in progress), March 2018. 1288 [iec62591] 1289 IEC, ., "62591:2016 Industrial networks - Wireless 1290 communication network and communication profiles - 1291 WirelessHART", 2016, 1292 . 1294 [ieee802-1AR] 1295 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 1296 2009, . 1299 [ieee802154] 1300 IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low- 1301 Rate Wireless Personal Area Networks (WPANs)", 2015, 1302 . 1305 [ieee802159] 1306 IEEE Standard, ., "802.15.9-2016 - IEEE Approved Draft 1307 Recommended Practice for Transport of Key Management 1308 Protocol (KMP) Datagrams", 2016, 1309 . 1312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1313 Requirement Levels", BCP 14, RFC 2119, 1314 DOI 10.17487/RFC2119, March 1997, 1315 . 1317 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 1318 (LDAP): String Representation of Distinguished Names", 1319 RFC 4514, DOI 10.17487/RFC4514, June 2006, 1320 . 1322 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1323 Bormann, "Neighbor Discovery Optimization for IPv6 over 1324 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1325 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1326 . 1328 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1329 "Enrollment over Secure Transport", RFC 7030, 1330 DOI 10.17487/RFC7030, October 2013, 1331 . 1333 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1334 Interface Identifiers with IPv6 Stateless Address 1335 Autoconfiguration (SLAAC)", RFC 7217, 1336 DOI 10.17487/RFC7217, April 2014, 1337 . 1339 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1340 Constrained-Node Networks", RFC 7228, 1341 DOI 10.17487/RFC7228, May 2014, 1342 . 1344 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1345 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1346 Transport Layer Security (TLS) and Datagram Transport 1347 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1348 June 2014, . 1350 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1351 Application Protocol (CoAP)", RFC 7252, 1352 DOI 10.17487/RFC7252, June 2014, 1353 . 1355 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1356 the Constrained Application Protocol (CoAP)", RFC 7959, 1357 DOI 10.17487/RFC7959, August 2016, 1358 . 1360 11.2. Informative References 1362 [duckling] 1363 Stajano, F. and R. Anderson, "The resurrecting duckling: 1364 security issues for ad-hoc wireless networks", 1999, 1365 . 1368 [I-D.ietf-ace-actors] 1369 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 1370 architecture for authorization in constrained 1371 environments", draft-ietf-ace-actors-06 (work in 1372 progress), November 2017. 1374 [I-D.ietf-anima-autonomic-control-plane] 1375 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 1376 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 1377 plane-13 (work in progress), December 2017. 1379 [I-D.ietf-core-sid] 1380 Veillette, M. and A. Pelov, "YANG Schema Item iDentifier 1381 (SID)", draft-ietf-core-sid-03 (work in progress), 1382 December 2017. 1384 [I-D.ietf-roll-useofrplinfo] 1385 Robles, I., Richardson, M., and P. Thubert, "When to use 1386 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 1387 useofrplinfo-22 (work in progress), March 2018. 1389 [ISA100] "The Technology Behind the ISA100.11a Standard", June 1390 2010, . 1393 [PFS] Wikipedia, ., "Forward Secrecy", August 2016, 1394 . 1397 [pledge-word] 1398 Dictionary.com, ., "Dictionary.com Unabridged", 2015, 1399 . 1401 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1402 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1403 November 2005, . 1405 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1406 Element (PCE)-Based Architecture", RFC 4655, 1407 DOI 10.17487/RFC4655, August 2006, 1408 . 1410 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1411 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 1412 . 1414 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1415 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1416 Internet of Things (IoT): Problem Statement", RFC 7554, 1417 DOI 10.17487/RFC7554, May 2015, 1418 . 1420 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1421 Application Protocol (CoAP)", RFC 7641, 1422 DOI 10.17487/RFC7641, September 2015, 1423 . 1425 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1426 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1427 February 2016, . 1429 Appendix A. Extra text 1431 The following text is from previous versions of this document. The 1432 document has been re-organized to match the flow of 1433 [I-D.ietf-anima-bootstrapping-keyinfra]. 1435 A.1. Assumptions 1437 A.1.1. One-Touch Assumptions 1439 This document interacts with the one-touch solution described in 1440 [I-D.ietf-6tisch-minimal-security]. 1442 A.1.2. Factory provided credentials (if any) 1444 When a manufacturer installed certificate is provided as the IDevID, 1445 it SHOULD contain a number of fields. 1446 [I-D.ietf-anima-bootstrapping-keyinfra] provides a detailed set of 1447 requirements. 1449 A manufacturer unique serial number MUST be provided in the 1450 serialNumber SubjectAltName extension, and MAY be repeated in the 1451 Common Name. There are no sequential or numeric requirements on the 1452 serialNumber, it may be any unique value that the manufacturer wants 1453 to use. The serialNumber SHOULD be printed on the packaging and/or 1454 on the device in a discrete way so that failures can be physically 1455 traced to the relevant device. 1457 A.1.3. Credentials to be introduced 1459 The goal of the bootstrap process is to introduce one or more new 1460 locally relevant credentials: 1462 1. a certificate signed by a local certificate authority/registrar. 1463 This is the LDevID of [ieee802-1AR]. 1465 2. alternatively, a network-wide key to be used to secure L2 1466 traffic. 1468 3. alternatively, a network-wide key to be used to authenticate per- 1469 peer keying of L2 traffic using a mechanism such as provided by 1470 [ieee802159]. 1472 A.2. Network Assumptions 1474 This document is about enrollment of constrained devices [RFC7228] to 1475 a constrained network. Constrained networks is such as [ieee802154], 1476 and in particular the time-slotted, channel hopping (tsch) mode, 1477 feature low bandwidths, and limited opportunities to transmit. A key 1478 feature of these networks is that receivers are only listening at 1479 certain times. 1481 A.2.1. Security above and below IP 1483 802.15.4 networks have three kinds of layer-2 security: 1485 o a network key that is shared with all nodes and is used for 1486 unicast and multicast. The key may be used for privacy, and it 1487 may be used in some cases for authentication only (in the case of 1488 enhanced beacons). 1490 o a series of network keys that are shared (agreed to) between pairs 1491 of nodes (the per-peer key) 1493 o a network key that is shared with all nodes (through a group key 1494 management system), and is used for multicast traffic only, while 1495 a per-pair key is used for unicast traffic 1497 Setting up the credentials to bootstrap one of these kinds of 1498 security, (or directly configuring the key itself for the first case) 1499 is required. This is the security below the IP layer. 1501 Security is required above the IP layer: there are three aspects 1502 which the credentials in the previous section are to be used. 1504 o to provide for secure connection with a Path Computation Element 1505 [RFC4655], or other LLC (see ({RFC7554}} section 3). 1507 o to initiate a connection between a Resource Server (RS) and an 1508 application layer Authorization Server (AS and CAS from 1509 [I-D.ietf-ace-actors]). 1511 A.2.1.1. Perfect Forward Secrecy 1513 Perfert Forward Secrecy (PFS) is the property of a protocol such that 1514 complete knowledge of the crypto state (for instance, via a memory 1515 dump) at time X does not imply that data from a disjoint time Y can 1516 also be recovered. ([PFS]). 1518 PFS is important for two reasons: one is that it offers protection 1519 against the compromise of a node. It does this by changing the keys 1520 in a non-deterministic way. This second property also makes it much 1521 easier to remove a node from the network, as any node which has not 1522 participated in the key changing process will find itself no longer 1523 connected. 1525 A.2.2. Join network assumptions 1527 The network which the new pledge will connect to will have to have 1528 the following properties: 1530 o a known PANID. The PANID 0xXXXX where XXXX is the assigned RFC# 1531 for this document is suggested. 1533 o a minimal schedule with some Aloha time. This is usually in the 1534 same slotframe as the Enhanced Beacon, but a pledge MUST listen 1535 for an unencrypted Enhanced Beacon to so that it can synchronize. 1537 A.2.3. Number and cost of round trips 1539 TBD. 1541 A.2.4. Size of packets, number of fragments 1543 TBD 1545 A.3. Target end-state for join process 1547 At the end of the zero-touch join process there will be a symmetric 1548 key protected channel between the Join Registrar/Coordinator and the 1549 pledge, now known as a Joined Node. This channel may be rekeyed via 1550 new exchange of asymmetric exponents (ECDH for instance), 1551 authenticated using the domain specific credentials created during 1552 the join process. 1554 This channel is in the form of an OSCOAP protected connection with 1555 [I-D.ietf-core-comi] encoded objects. This document includes 1556 definition of a [I-D.ietf-netconf-keystore] compatible objects for 1557 encoding of the relevant [I-D.ietf-anima-bootstrapping-keyinfra] 1558 objects. 1560 Appendix B. Join Protocol 1562 The pledge join protocol state machine is described in 1563 [I-D.ietf-6tisch-minimal-security], in section XYZ. The pledge 1564 recognizes that it is in zero-touch configuration by the following 1565 situation: 1567 o no PSK has been configured for the network in which it has joined. 1569 o the pledge has no locally defined certificate (no LDevID), only an 1570 IDevID. 1572 o the network asserts an identity that the pledge does not 1573 recognize. 1575 All of these conditions MUST be true. If any of these are not true, 1576 then the pledge has either been connected to the wrong network, or it 1577 has already been bootstrapped into a different network, and it should 1578 wait until it finds that network. 1580 The zero-touch process consists of three stages: 1582 1. the key agreement process 1584 2. the provisional enrollment process 1586 3. the key distribution process 1588 B.1. Key Agreement process 1590 The key agreement process is identical to 1591 [I-D.ietf-6tisch-minimal-security]. The process uses EDHOC with 1592 certificates. 1594 The pledge will have to trust the JRC provisionally, as described in 1595 [I-D.ietf-anima-bootstrapping-keyinfra], section 3.1.2, and in 1596 section 4.1.1 of [RFC7030]. 1598 The JRC will be able to validate the IDevID of the pledge using the 1599 manufacturer's CA. 1601 The pledge may not know if it is in a zero-touch or one-touch 1602 situation: the pledge may be able to verify the JRC based upon trust 1603 anchors that were installed at manufacturing time. In that case, the 1604 pledge runs the simplified one-touch process. 1606 The pledge signals in the EDHOC message_2 if it has accepted the JRC 1607 certificate. The JRC will in general, not trust the pledge with the 1608 network keys until it has provided the pledge with a voucher. The 1609 pledge will notice the absence of the provisioning keys. 1611 XXX - there could be some disconnect here. May need additional 1612 signals here. 1614 B.2. Provisional Enrollment process 1616 When the pledge determines that it can not verify the certificate of 1617 the JRC using built-in trust anchors, then it enters a provisional 1618 state. In this state, it keeps the channel created by EDHOC open. 1620 A new EDHOC key derivation is done by the JRC and pledge using a new 1621 label, "6tisch-provisional". 1623 The pledge runs as a passive CoMI server, leaving the JRC to drive 1624 the enrollment process. The JRC can interrogate the pledge in a 1625 variety of fashions as shown below: the process terminates when the 1626 JRC provides the pledge with an ownership voucher and the pledge 1627 leaves the provisional state. 1629 A typical interaction involves the following requests: 1631 +-----------+ +----------+ +-----------+ +----------+ 1632 | | | | | Circuit | | New | 1633 | Vendor | | Registrar| | Proxy | | Entity | 1634 | (MASA) | | | | | | | 1635 ++----------+ +--+-------+ +-----------+ +----------+ 1636 | | GET request voucher | 1637 | |--------------------------------> 1638 | <----------voucher-token---------| 1639 |/requestvoucher| | 1640 <---------------+ | 1641 +---------------> | 1642 |/requestlog | | 1643 <---------------+ | 1644 +---------------> | 1645 | | POST voucher | 1646 | |--------------------------------> 1647 | <------------2.05 OK ------------+ 1648 | | | 1649 | | POST csr attributes | 1650 | |--------------------------------> 1651 | <------------2.05 OK ------------+ 1652 | | | 1653 | | GET cert request | 1654 | |--------------------------------> 1655 | ???? <------------2.05 OK ------------+ 1656 |<--------------| CSR | 1657 |-------------->| | 1658 | | POST certificate | 1659 | |--------------------------------> 1660 | <------------2.05 OK ------------+ 1661 | | | 1663 Appendix C. IANA Considerations 1665 This document allocates one value from the subregistry "Address 1666 Registration Option Status Values": ND_NS_JOIN_DECLINED Join 1667 Assistant, JOIN DECLINED (TBD-AA) 1669 Appendix D. Protocol Definition 1671 D.1. Discovery 1673 Only IPv6 operations using Link-Local addresses are supported. Use 1674 of a temporary address is NOT encouraged as the critial resource on 1675 the Proxy device is the number of Neighbour Cache Entries that can be 1676 used for untrusted pledge entries. 1678 D.1.1. Proxy Discovery Protocol Details 1680 The Proxy is discovered using the enhanced beacon defined in 1681 [I-D.richardson-6tisch-join-enhanced-beacon]. 1683 D.1.2. Registrar Discovery Protocol Details 1685 The Registrar is not discovered by the Proxy. Any device that is 1686 expected to be able to operate as a Registrar MAY be told the address 1687 of the Registrar when that device joins the network. The address MAY 1688 be included in the [I-D.ietf-6tisch-minimal-security] Join Response. 1689 If the address is NOT included, then Proxy may assume that the 1690 Registrar can be found at the DODAG root, which is well known in the 1691 6tisch's use of the RPL protocol. 1693 Authors' Addresses 1695 Michael Richardson 1696 Sandelman Software Works 1698 Email: mcr+ietf@sandelman.ca 1700 Benjamin Damm 1701 Silver Spring Networks 1703 Email: bdamm@ssni.com