idnits 2.17.1 draft-anoopmis-eap-autoadd-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 23, 2019) is 1579 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 ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-aura-eap-noob-07 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-31 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Anoop Kumar Pandey 3 Internet-Draft C-DAC Bangalore 4 Intended status: Informational December 23, 2019 5 Expires: June 25, 2020 7 AutoAdd - Automatic Bootstrapping of IoT Devices 8 draft-anoopmis-eap-autoadd-00 10 Abstract 12 IoT devices are fast getting embedded into our lives, and when put 13 together they have the potential to generate a precise and detailed 14 history of our lives and store them forever. Their networking and 15 communicational power can be unleashed for malicious and sabotage 16 purposes, by a motivated attacker sitting in the far corner of the 17 world. Attacks on Industrial IoT systems can cause greater 18 disasters. It is therefore essential to inculcate the security 19 aspect, right from design to development to operations. The first 20 operation of an IoT device is to bootstrap itself, and due importance 21 should be placed to ensure that this operation is carried out 22 securely and with due diligence. However, it's easier said than 23 done, and this paper outlines several approaches for secure automated 24 bootstrapping and also proposes a new method, which is compared 25 against the existing mechanisms for several qualitative factors. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 25, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Prologue . . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 3. Prior and Ongoing Contributions . . . . . . . . . . . . . . . 3 65 3.1. TOFU (Trust on First Use) . . . . . . . . . . . . . . . . 4 66 3.2. Resurrecting Duckling . . . . . . . . . . . . . . . . . . 4 67 3.3. Enrollment over Secure Transport . . . . . . . . . . . . 4 68 3.4. BRSKI . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.5. EAP-NooB . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.6. AutoAdd (Work in Progress) . . . . . . . . . . . . . . . 5 71 3.6.1. Expiration of owner certificate . . . . . . . . . . . 6 72 3.6.2. Selling a device . . . . . . . . . . . . . . . . . . 7 73 4. Comparison Chart . . . . . . . . . . . . . . . . . . . . . . 7 74 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 8.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Prologue 84 Amazon launched "Amazon Alexa" in November 2014. Alexa is a virtual 85 assistant which comes with Echo line of smart speakers. It is 86 capable of voice interaction, control of smart home devices, music 87 playback, setting alarms, making calls, checking weather and news and 88 much more. 89 Google Home series smart speakers were launched in November 2016. 90 Google Assistant can be used to control thousands of smart-home 91 products from several brands like LG, GE, Whirlpool, Nest etc... 92 Google Home can be asked to change the temperature, dim the lights, 93 turn on a microwave or kettle, and also start Roomba (robotic vacuum 94 cleaners). It can also turn the TV on/off using Chromecast. 95 The concept of smart home and devices is taking off very fast. It 96 appears to make our lives quite easy and comfortable. But turning 97 your home into a computer means facing computer-like problems. The 98 security and performance issues associated are much scary. 99 It creates a method for transformation of the physical world into 100 computer-based systems, resulting in performance and efficiency 101 enhancement, financial gains, and reduces human involvement. The 102 number of IoT devices increased 31% year-over-year to 8.4 billion in 103 2017 and it is estimated to have 30 billion IoT devices by 2020 104 [iotscale]. Many more devices are/will be connected through serial 105 link. 107 2. Introduction 109 Kevin Ashton coined the term "Internet of Things (IoT)" and defined 110 it as a system where the internet is connected to the physical world 111 via ubiquitous sensors. While, the scale of IoT is going pretty 112 bigger day by day, the task of adding new devices and bootstrapping 113 it at such a large scale, remains at large. Manual bootstrapping 114 requires a human to add an IoT device to a network (network 115 discovery), connect to registrar (system where a device can be 116 registered), setting up the key for future secure communication and 117 finally all configuration of the device for its functioning in the 118 network domain. Automatic bootstrapping methods are still evolving 119 and are under testing and scrutiny for various environments and 120 scenarios. While security experts and engineers are toiling hard to 121 mitigate risks associated with automatic bootstrapping, we propose a 122 system AutoAdd (work in progress), which ensures automatic addition 123 and initial bootstrapping of an IoT device while it is put on the 124 network. There are billions of devices and at least thousands of 125 manufacturers. So how do we identify and trust a device? Similarly 126 there are many networks, how does the device know that I am working 127 only with my owner and not with some imposter network? Remember, 128 there are hostile devices on the network, and there are hostile 129 networks that might attempt to take over the device. Basically, we 130 need to establish the identity/authenticity of the device; Check if 131 device is compromised or not; establish the identity of the network/ 132 domain; and finally check if the domain is the correct one. 134 2.1. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 3. Prior and Ongoing Contributions 141 3.1. TOFU (Trust on First Use) 143 TOFU (Trust on First Use) calls for accepting and storing a public 144 key or credential associated with an asserted identity, without 145 authenticating that assertion. Subsequent communication that is 146 authenticated using the cached key or credential is secure against an 147 MiTM attack, if such an attack did not succeed during the vulnerable 148 initial communication. 150 3.2. Resurrecting Duckling 152 In 'Resurrecting Duckling' [stajano1999resurrecting], a device 153 recognises as its owner the first entity that sends it a secret key 154 and will stay loyal to its owner for the rest of the life. It may 155 come to EoL (end of life), or may be reset. The ownership of the 156 device may also be transferred. It is analogous to imprinting in 157 ducks, where duckling emerging from its egg will recognise as its 158 mother the first moving object it sees that makes a sound, regardless 159 of what it looks like. 161 3.3. Enrollment over Secure Transport 163 In Enrollment over Secure Transport (EST) RFC 7030 [RFC7030], the 164 client starts a TLS based HTTPS session with an EST server. Through 165 a part of URI, a specific EST service is requested during the 166 session. The client authenticates the server and the server 167 authenticates the client. The server verifies if the client is 168 authorized to use the requested service. Similarly the client 169 verifies if the server has proper authorization to serve this client. 170 Upon complete authentication and authorization check of both the 171 parties, the server responds to the client request. 173 3.4. BRSKI 175 An ongoing internet draft BRSKI (Bootstrapping Remote Secure Key 176 Infrastructures) [I-D.ietf-anima-bootstrapping-keyinfra] lists steps 177 for auto bootstrapping as follow: 179 o Pledge discovers a communication channel to a Registrar. 181 o Pledge identifies itself. This is done by presenting an X.509 182 IDevID credential to the discovered Registrar (via the Proxy) in a 183 TLS handshake. (The Registrar credentials are only provisionally 184 accepted at this time) 186 o Pledge requests to join the discovered Registrar using a voucher 187 request. 189 o Registrar sends the voucher request to the MASA (manufacturer). 190 URL of MASA can be in the voucher request or embedded in 191 Registrar. 193 o MASA sends the voucher which is passed to pledge. 195 o MASA sends the voucher which is passed to pledge. 197 o Pledge verifies the voucher and imprints to the registrar by send 198 voucher status telemetry. 200 o Registrar verifies the voucher and enrolls the pledge to the 201 domain 203 Here pledge is the device to be added to network/domain; registrar is 204 the registration authority where devices are registered; MASA is 205 manufacturer authorized signing authority; IDevID is an Initial 206 Device Identity X.509 certificate installed by the vendor on new 207 equipment and voucher is a signed statement from the MASA service 208 that indicates to a Pledge the cryptographic identity of the 209 Registrar it should trust. 211 3.5. EAP-NooB 213 EAP-NooB (Extensible Authentication Protocol Nimble out of Band) 214 [I-D.aura-eap-noob] method is intended for bootstrapping all kinds of 215 Internet-of-Things (IoT) devices that have a minimal user interface 216 and no pre-configured authentication credentials. The method makes 217 use of a user-assisted one-directional OOB (out of band) channel 218 between the peer device and authentication server. The secure 219 bootstrapping in this specification makes use of a user-assisted out- 220 of-band (OOB) channel. The security is based on the assumption that 221 attackers are not able to observe or modify the messages conveyed 222 through the OOB channel. EAP-NooB follows the common approach of 223 performing a Diffie-Hellman key exchange over the insecure network 224 and authenticating the established key with the help of the OOB 225 channel in order to prevent impersonation and man-in-the-middle 226 (MitM) attacks. 228 3.6. AutoAdd (Work in Progress) 230 We propose AutoAdd: an automatic bootstrapping method for IoT 231 devices. This is a work in progress and open for comments. 232 When a device is purchased in real world, usually an invoice is 233 issued in the name of the purchaser with stamp of vendor/ 234 manufacturer. We propose that similarly, a digital invoice can be 235 issued which will contain the public key(s) of the and digitally signed by the manufacturer. The 237 digital invoice may be embedded in the device along with the IDevID. 238 A digital invoice may be contain the IDevID of the device and Public 239 key of Registrars (Ri), digital signed by Manufacturer (M) and can be 240 represented as below. 242 Dig_Invoice = DigSignM {IDevID, PubKey: [R1, R2, .., Rn]} 244 When the device starts the registration process, it will present the 245 digital invoice along with IDevID. The Registrar can verify the 246 digital signature of the manufacturer on the digital invoice and sent 247 a signed note of acceptance to the device. 249 Flag = VerifyDigSignManufacturer (Dig_Invoice, PubKeyM) 250 if (flag) Acceptance_Note = DigSignRi {Note} 252 The device can verify the signed note using the public key(s) 253 mentioned in the digital invoice, thereby verifying its true owner. 255 VerifyDigSignRegistrar (Acceptance_Note, PublicKeyFromDigInvoiceRi) 257 This process with eliminate all the communication overhead with MASA 258 and multiple level verification (voucher request, voucher, telemetry 259 etc. at Registrar/ MASA/Device. From security point of view, we can 260 claim that given that the digital invoice is digitally signed by 261 manufacturer, the public key of domain owner embedded in the digital 262 invoice can't be changed, otherwise verification of digital signature 263 of manufacturer at Registrar end will fail. We would also like to 264 share few use cases for the sake of understanding the complete 265 ecosystem of AutoAdd. 267 3.6.1. Expiration of owner certificate 269 The device has domain owner's or registrar's public key embedded in 270 its digital invoice which is used to verify the digital signature on 271 the note of acceptance and thereby authenticating the owner. If the 272 owner's digital signature certificate expires or is changed or is 273 revoked, the digital signature of the owner can't be verified and the 274 owner authentication will fail. 276 To overcome such situation, before the expiration of the certificate, 277 the owner will require to create another digital invoice by 278 specifying it's own new public key digitally signed by his old 279 private key and embedding it into the device. This will basically 280 create a chain of digital invoices. This process is similar to 281 attestation of own signature in real world. The verification will 282 basically verify the chain of digital invoices. 283 For the sake of clarity, let us consider R1_old as old public key of 284 Registrar and original digital invoice be 285 Dig_Invoice_Original = DigSign (PvtM, {IDevID, PubKey: [R1_old]}) 287 Let R1_new be the new public key of the registrar and Pvt_R1_Old be 288 the old private key of the reigstrar. The registrar need to create a 289 new digital invoice digitally signed by his old private key. 291 Dig_Invoice_New = DigSign (Pvt_R1_Old , {IDevID, PubKey: [R1_new]} ) 293 Let note of acceptance signed with new private key of R1 as follow: 295 Acceptance_Note = DigSign(Pvt_R1_new, {Note}) 297 Verification will be done as per following steps: 299 Flag1 = VerifyDigSignDigInvoiceNew (Dig_Invoice_New, 300 PublicKeyFromDigInvoiceOriginalR1) 302 If(flag1) flag2 = VerifyDigSignRegistrar (Acceptance_Note, 303 PublicKeyFromDigInvoiceNewR1) 305 If(flag2) Output "Registrar or Owner verified" 307 These steps can be chained for multiple chain of digital invoices. 309 3.6.2. Selling a device 311 A device may be resold and in the new environment, the public key of 312 the new owner may need to be embedded in the device, else owner 313 verification will fail. Addition of the public key of the new owner 314 will follow similar steps as described in the previous section 315 (3.6.1) where the old owner will create a new digital invoice by 316 specifying the new owner's public key and digitally signing it. The 317 verification of the note of acceptance by the new owner will follow 318 similar steps as illustrated in section 3.6.1. 320 4. Comparison Chart 321 +--------------+-----------------------+----------------------------+ 322 | Approach | Security | Constraints/Consequence | 323 +--------------+-----------------------+----------------------------+ 324 | TOFU | Vulnerable initial | No authentication of | 325 | | communication | initial assertion | 326 +--------------+-----------------------+----------------------------+ 327 | Resurrecting | No owner | Anyone can be the owner | 328 | Duckling | authentication | | 329 +--------------+-----------------------+----------------------------+ 330 | EST | TLS secured HTTP | Need some pre-provisioned | 331 | | session between | credentials to establish | 332 | | client and Server | secure communication | 333 +--------------+-----------------------+----------------------------+ 334 | BRSKI | Online service | Online service | 335 | | authenticating both | authenticating both device | 336 | | device and domain | and domain & MASA should | 337 | | | be always online; No | 338 | | | autorun of BRSKI on | 339 | | | network or ownership | 340 | | | change | 341 +--------------+-----------------------+----------------------------+ 342 | EAP-NooB | Security dependent on | Manual intervention for | 343 | | Ephemeral Elliptic | OOB authentication; Not | 344 | | Curve Diffie-Hellman | Scalable | 345 | | (ECDHE) key exchange | | 346 | | and manual assistance | | 347 +--------------+-----------------------+----------------------------+ 348 | AutoAdd | Easy offline | Public key is required for | 349 | | authentication of | each buyer. | 350 | | both device and | | 351 | | domain | | 352 +--------------+-----------------------+----------------------------+ 354 Table 1: Comparison of various bootstrapping methods 356 5. Conclusion 358 We have outlined a number of approaches that are currently followed 359 for bootstrapping of IoT devices along with their merits and 360 demerits. We have also highlighted several security concerns that 361 would have to be addressed for booting up and bringing an IoT device 362 for operations. We have also presented AutoAdd and have done a 363 qualitative comparison against the existing methods in terms of 364 security and ease-of-use. AutoAdd can serve as a secure automatic 365 bootstrapping method for IoT devices. 366 We are also working on a internet draft to incorporate device 367 certificates with EAP-NOOB. 369 6. IANA Considerations 371 This memo includes no request to IANA. 373 7. Security Considerations 375 This draft proposes an automatic bootstrapping method for IoT 376 devices. The security of the protocol is inherent from the security 377 of unforgeable digital signature and PKI. A detailed security 378 analysis is pending. 380 8. References 382 8.1. Normative References 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, 386 DOI 10.17487/RFC2119, March 1997, 387 . 389 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 390 "Enrollment over Secure Transport", RFC 7030, 391 DOI 10.17487/RFC7030, October 2013, 392 . 394 8.2. Informative References 396 [I-D.aura-eap-noob] 397 Aura, T. and M. Sethi, "Nimble out-of-band authentication 398 for EAP (EAP-NOOB)", draft-aura-eap-noob-07 (work in 399 progress), October 2019. 401 [I-D.ietf-anima-bootstrapping-keyinfra] 402 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 403 and K. Watsen, "Bootstrapping Remote Secure Key 404 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 405 keyinfra-31 (work in progress), December 2019. 407 [iotscale] 408 Nordrum, Amy., "Popular Internet of Things Forecast of 50 409 Billion Devices by 2020 Is Outdated", 2016, 410 . 414 [stajano1999resurrecting] 415 Frank, Stajano., "The resurrecting duckling", 1999, 416 . 419 Author's Address 421 Anoop Kumar Pandey 422 C-DAC Bangalore 423 #68, Electronics City 424 Bangalore 560100 425 India 427 Email: anoop@cdac.in