idnits 2.17.1 draft-nordmark-iotops-onboarding-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (26 July 2021) is 1005 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-irtf-t2trg-secure-bootstrapping-00 == Outdated reference: A later version (-06) exists of draft-ietf-emu-eap-noob-05 == Outdated reference: A later version (-14) exists of draft-ietf-rats-tpm-based-network-device-attest-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Nordmark 3 Internet-Draft Zededa 4 Intended status: Informational 26 July 2021 5 Expires: 27 January 2022 7 Different aspects of onboarding for IoT/Edge Devices 8 draft-nordmark-iotops-onboarding-00 10 Abstract 12 Previous onboarding discussions have focused on network onboarding. 13 In this note we put that in the context of the larger onboarding 14 picture to also discuss the onboarding to some management or 15 orchestration system. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 27 January 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. What is onboarding? . . . . . . . . . . . . . . . . . . . . . 2 52 3. IoT vs. Edge Computing? . . . . . . . . . . . . . . . . . . . 3 53 4. Network onboarding . . . . . . . . . . . . . . . . . . . . . 4 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 6. Example: Project EVE . . . . . . . . . . . . . . . . . . . . 5 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 8. Informative References . . . . . . . . . . . . . . . . . . . 5 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 60 1. Introduction 62 The iotops group has discussed LwM2M [oma], FIDO [fidospec] and 63 [I-D.lear-iotops-deep-thoughts-on-onboarding] where the last one 64 intentionally focuses on network onboarding. This note broadens the 65 discussion to all aspects of onboarding of IoT and edge devices to 66 try to expose what is common and different at different layers. 68 Some of these topics has previously come up in T2TRG for example in 69 [I-D.irtf-t2trg-secure-bootstrapping] but also with a strong 70 networking focus. 72 2. What is onboarding? 74 One aspect of onboarding a device is providing network access to the 75 device. That might involve both L2 and L3 aspects, such as Cellular 76 and WiFi credentials at L2 and LAN as Internet access at L3. 77 Furthermore, the L3 access might differentiate between LAN and 78 Internet access and be subject to access control for instance 79 controlled by MUD [RFC8520]. 81 However, there are also higher levels of onboarding. For instance, 82 Anima supports a notion of Secure Bootstrap over an Unconfigured 83 Network [RFC8994] which not only includes the secure keys (BRSKI 84 [RFC8995]) but also the configuration of the routers and switches 85 (using GRASP [RFC8990]). Such configuration can have rather wide 86 span and one can think of it as consisting of configuring the device 87 plus configuring various applications (which might be routing 88 protocols and management agents in the case of Anima use cases). 90 If we look at more compute-centric workloads are likely to have a 91 larger set of applications which might be configured and managed 92 separately from the device. We can already see examples of this in 93 cloud datacenters where there is a IaaS layer provisioning and 94 managing the servers, which is largely invisible to the users, and a 95 set of applications (in the form for virtual machines or containers) 96 which are provisioned and managed using application-specific 97 mechanisms and management systems. For instance, a firewall virtual 98 appliance/VNF might be managed the same way as a physical firewall 99 appliance. 101 3. IoT vs. Edge Computing? 103 The IOTOPS charter scopes its use of "IoT devices" to devices that 105 * are networked, either to the Internet or within limited 106 administrative domains 108 * have a very limited end user interface or no end-user interface at 109 all 111 * are deployed in sufficiently large numbers that they cannot easily 112 be managed or maintained manually 114 The definitions of the various parts of Edge Computing by the Linux 115 Foundation in [lfedge-wp] defines the constrained device edge and the 116 smart device edge, which captures devices with different levels of 117 flexibility, but they both fit into the above IOTOPS scope. Thus for 118 the purposes of this discussion we can use Edge Computing devices and 119 IoT devices interchangeably. 121 However, the devices at the constrained device edge are more likely 122 to be single or fixed function in that they do not have the capacity 123 or flexibility to perform other functions than envisioned prior to 124 their deployment. Such fixed function devices still require a 125 software/firmware update capability as discussed in [RFC8240], but 126 they do not require handling new application deployment and 127 associated new communication patterns. 129 The more flexible devices at the smart device edge are likely to be 130 larger than the class 2 devices defined in [RFC7228], however if 131 applications are sufficiently small, constrained devices might very 132 well be edge computing devices. But in general it makes sense to 133 think about devices of the Raspberry Pi class and larger at the smart 134 device edge. 136 For such devices it is clear that the onboarding of the device (to 137 the network and to some management system or controller) should be 138 separable from the onboarding of some particular application (to its 139 controller or management system). Hence the separation between 140 device onboarding and application (instance) onboarding seems 141 required from an architectural perspective. 143 4. Network onboarding 145 Network onboarding starts at L2 access and can take several different 146 forms such as: 148 * Physical access to an Ethernet port 150 * Protocols like EAP-NOOB [I-D.ietf-emu-eap-noob], DPP [dpp], etc. 152 In the world of laptop computers and smartphones such access might 153 include traditional EAP but also additional steps such as Endpoint 154 Assessment [RFC5209][RFC7632] before granting full access to the 155 network. Thus the onboarding to the network is not a new thing; what 156 is new is applying it to IoT and Edge Computing devices with to user 157 in front of the device as it is onboarded. 159 As indicated above, if MUD [RFC8520] is used the network onboarding 160 would logically include the retrieval and application of the usage 161 descriptions. 163 5. Security Considerations 165 This informational note discusses onboarding with the assumption that 166 onboarding needs to address various security threats, but does not go 167 into details. 169 It seems like the roots of trust used for onboarding at the different 170 levels relates closely to the design center for the different 171 onboarding approaches. Loosely we seem to have a few differently 172 approaches (and this list is not exhaustive): 174 * Use Hardware manufacturer certificates. This makes it possible to 175 verify with the manufacturer that device is valid, but it does not 176 indicate which management system or controller which a device 177 should trust. 179 * Track the transfers of ownership through supply chain as done in 180 FIDO [fidospec]. This enables secure late binding to a management 181 system/controller since the signature chain from manufacturer to 182 end user establishes trust in controller. 184 * Imprinting/configuring for/by the owner of the device. This makes 185 assumptions that either the future owner is known at the time of 186 manufacturing or that there is some leap of faith involving a 187 certificate (in e.g., text or bar code form) being registered in 188 the controller by someone claiming to be the device owner. 190 The trust might also include initial measurement/attestation of 191 firmware/software along the lines of RATS 192 [I-D.ietf-rats-tpm-based-network-device-attest] to create a baseline 193 before the device leaves the factory. 195 6. Example: Project EVE 197 Project EVE [eve] is an example of a secure but minimal approach to 198 enable secure onboarding, without having a hard dependency on 199 manufacturers and manufacturer certificates. 201 * When software is installed (factory or elsewhere): 203 - Imprint device which controller to trust (a root certificate) 204 and initial URL to contact 206 - Generate a device certificate using the TPM 208 - Extract the device certificate and pass to final user (paper, 209 bar code, etc) 211 - Perform initial measured boot to get baseline measurements 212 along the lines of RATS TPM 213 [I-D.ietf-rats-tpm-based-network-device-attest] 215 * Then in any order 217 - User registers device certificate in controller 219 - Device is installed and powered on and connects to its 220 controller 222 At that point in time the EVE controller can specify which 223 applications to deploy/boot/halt on device. 225 Potentially EVE can also leverage [sdo], which is an open source 226 implementation of the FIDO specification [fidospec], for the future 227 cases where there is sufficient support in the supply chain for the 228 FIDO signature chains. 230 7. IANA Considerations 232 There are no IANA actions needed for this document. 234 8. Informative References 236 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 237 Tardo, "Network Endpoint Assessment (NEA): Overview and 238 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 239 . 241 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 242 Constrained-Node Networks", RFC 7228, 243 DOI 10.17487/RFC7228, May 2014, 244 . 246 [RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security 247 Posture Assessment: Enterprise Use Cases", RFC 7632, 248 DOI 10.17487/RFC7632, September 2015, 249 . 251 [RFC8240] Tschofenig, H. and S. Farrell, "Report from the Internet 252 of Things Software Update (IoTSU) Workshop 2016", 253 RFC 8240, DOI 10.17487/RFC8240, September 2017, 254 . 256 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 257 Description Specification", RFC 8520, 258 DOI 10.17487/RFC8520, March 2019, 259 . 261 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 262 Autonomic Signaling Protocol (GRASP)", RFC 8990, 263 DOI 10.17487/RFC8990, May 2021, 264 . 266 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 267 Autonomic Control Plane (ACP)", RFC 8994, 268 DOI 10.17487/RFC8994, May 2021, 269 . 271 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 272 and K. Watsen, "Bootstrapping Remote Secure Key 273 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 274 May 2021, . 276 [I-D.lear-iotops-deep-thoughts-on-onboarding] 277 Lear, E., "Deep Thoughts on Network Onboarding 278 Challenges", Work in Progress, Internet-Draft, draft-lear- 279 iotops-deep-thoughts-on-onboarding-00, 9 March 2021, 280 . 283 [I-D.irtf-t2trg-secure-bootstrapping] 284 Sethi, M., Sarikaya, B., and D. Garcia-Carrillo, "Secure 285 IoT Bootstrapping: A Survey", Work in Progress, Internet- 286 Draft, draft-irtf-t2trg-secure-bootstrapping-00, 7 April 287 2021, . 290 [I-D.ietf-emu-eap-noob] 291 Aura, T., Sethi, M., and A. Peltonen, "Nimble out-of-band 292 authentication for EAP (EAP-NOOB)", Work in Progress, 293 Internet-Draft, draft-ietf-emu-eap-noob-05, 12 July 2021, 294 . 297 [I-D.ietf-rats-tpm-based-network-device-attest] 298 Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- 299 based Network Device Remote Integrity Verification", Work 300 in Progress, Internet-Draft, draft-ietf-rats-tpm-based- 301 network-device-attest-07, 10 June 2021, 302 . 305 [dpp] Wi-Fi Alliance, "Wi-Fi Device Provisioning Protocol 306 (DPP)", Wi-Fi Alliance , 2018, . 310 [fidospec] FIDO Alliance, "FIDO Device Onboard Specification", 311 December 2020, . 314 [oma] Open Mobile Alliance, "Lightweight Machine to Machine 315 Technical Specification: Core", Open Mobile Alliance , 316 June 2019, 317 . 321 [lfedge-wp] 322 Linux Foundation, "Sharpening the Edge: Overview of the LF 323 Edge Taxonomy and Framework", 2020, 324 . 327 [eve] Linux Foundation, "EVE is Edge Virtualization Engine", 328 July 2021, . 330 [sdo] Linux Foundation, "Secure Device OnBoard", July 2021, 331 . 333 Author's Address 335 Erik Nordmark 336 Zededa 337 Santa Clara, CA, 338 United States of America 340 Email: nordmark@sonic.net