idnits 2.17.1 draft-st-t2trg-nw-access-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. 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 (October 18, 2018) is 1989 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-aura-eap-noob-03 == Outdated reference: A later version (-16) exists of draft-irtf-t2trg-iot-seccons-15 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Sethi 3 Internet-Draft Ericsson 4 Intended status: Informational October 18, 2018 5 Expires: April 21, 2019 7 Enabling Network Access for IoT devices from the Cloud 8 draft-st-t2trg-nw-access-01 10 Abstract 12 This document describes a method for enabling and configuring network 13 access for IoT devices that are first authenticated at a server. 14 This server may be run by the manufacturer of the IoT device as an 15 online cloud service. This specification is intended for off-the- 16 shelf IoT devices that have just been purchased by the user. Many of 17 these devices have only limited user interfaces that can be used for 18 configuring network access credentials. The device configuration is 19 also made more challenging by the fact that these devices may exist 20 in large numbers. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 21, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Deployment Architecture . . . . . . . . . . . . . . . . . . . 4 59 4. Manufacturer Dependancy and End-of-life . . . . . . . . . . . 7 60 5. Alternative Manufacture Independent Deployment Models . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8.1. Normative references . . . . . . . . . . . . . . . . . . 9 65 8.2. Informative references . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 68 1. Introduction 70 There is an increase in the deployment of Internet of Things (IoT) 71 appliances such as wireless baby monitors, printers, speakers and 72 smart TVs. To enable rapid adoption while reducing the cost of 73 deployment, these appliances typically use the existing Wi-Fi 74 infrastructure (Access Point) for Internet connectivity. However, 75 configuring the network-access credentials for these off-the-shelf 76 appliances is cumbersome. Typically this process requires the user 77 to pair the appliance with his/her smartphone over bluetooth and then 78 configure the Wi-Fi SSID and passphrase. 80 This process is not only cumbersome, but requires the appliance to be 81 shipped with an additional network interface (only for 82 configuration). It also moves the problem of securely configuring 83 the network-access credentials to the problem of secure bluetooth 84 pairing. Besides, relying on a single passphrase for the entire 85 network may not be sustainable in the long run. While changing the 86 passphrase to revoke/remove a device from the network is easy today 87 when most devices have a keyboard and only a few (2-5) devices are 88 connected to the network (Access Point), this would be much harder 89 when the devices are many (10-100) and have limited input 90 capabilities. 92 Once configured and connected to the Internet, the user still has to 93 register the IoT device with the manufacturer. This maybe to receive 94 services or software updates. For example, the user may connect his/ 95 her Wi-Fi weighing scale to keep track his/her weight online and 96 receive software updates for new features. 98 This draft explains an example deployment scenario that relies on 99 802.1x [IEEE-802.1X] and EAP [RFC3748] authentication to register the 100 device with the manufacturer and enable network access (provision 101 WiFi credentials) for the IoT device at the same time. Using the 102 802.1x authentication even in SOHO (small office and home) scenarios 103 is a big assumption. The following arguments may correctly apply 104 against such a model: 106 o Most home access points currently do not support 802.1x 107 authentication: This is however in most cases only a software 108 limitation. Many existing APs can support 802.1x authentication 109 after firmware updates. 111 o Home users do not understand RADIUS [RFC6929] peering and cannot 112 configure 802.1x authentication: This is often very true. 113 However, there are mechanisms with which the burden on the user 114 can be significantly reduced. We will discuss some possible 115 alternatives in the next section. 117 o Most SOHO (Small office and Home) deployments are small and a 118 network wide shared secret provides reasonable security: This is 119 an incorrect assumption. While the deployments are small today, 120 as more and more physical devices such as barbie dolls [barbie], 121 weighing scales [scale], door bells [doorbell], and thermostats 122 [nest] are connected to the Internet, using the same secret for 123 the entire network is no longer sustainable. This is necessary to 124 prevent attacks where for example, a compromised WiFi weighing 125 scale also compromises the NEST thermostat that is using the same 126 network secret. 128 o An enterprise simply won't trust an external entity to remotely 129 control their network and add new devices: This is true. However, 130 what we are suggesting in this memo is to allow an IoT device 131 manufacturer to put a new IoT device into a separate Virtual LAN 132 and enable limited Internet connectivity for it. It is possible 133 that certain enterprises may be willing. However, we accept that 134 this may not be the case in all enterprise settings. 136 The architecture and solution presented in this draft is a 137 generalized version of the original idea presented by Sethi et al. 138 [Sethi14]. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 3. Deployment Architecture 148 We first look at deployments where the online cloud service is run by 149 the manufacturer. One such deployment architecture is shown in 150 Figure 1. The IoT device is shown on the left. The device uses EAP 151 for network-access authentication. 153 The Manufacturer IoT device registration portal is shown on the 154 right. The manufacturer is responsible for running a AAA server that 155 authenticates the IoT devices and then informs the users Access Point 156 (AP) to enable Internet connectivity for the IoT device. 158 The Access Point (AP) at the user premises is shown in the middle. 159 The AP provides Internet connectivity to the user devices. The AP 160 must support 802.1x authentication and it uses RADIUS [RFC6929] or 161 DIAMETER [RFC6733] to communicate with the Manufacturer IoT device 162 registration portal. For simplicity, the rest of this memo uses 163 RADIUS as the example protocol. However, it should be noted that the 164 same objectives can be achieved with DIAMETER. 166 As shown in Figure 1 the AP may optionally have a local RADIUS server 167 (which maybe the case in small office environments). In another 168 deployment scenario shown in Figure 2, it is possible that the AP 169 only has a local RADIUS client and routes all the EAP authentication 170 messages to a single online RADIUS server (which maybe the case in 171 home environments). In this case (Figure 2), the online RADIUS 172 server may be run by the AP manufacturer for example. This would 173 unburden the user from the task of maintaining a secure RADIUS server 174 and setting up the necessary RADIUS peerings for IoT devices from 175 different manufacturers. 177 For routing the EAP messages between the IoT device and the 178 manufacturer portal, a RADIUS peering is needed between the AP 179 (authenticator) and the AAA server that is run by the manufacturer. 180 This peering may be secured with a shared secret or certificate-based 181 TLS. 183 For correct routing of EAP messages from an IoT device to the device 184 portal of the manufacturer, the realm part of the Network Access 185 Identifier (NAI) [RFC7542] is used by the local RADIUS server in the 186 AP (Figure 1) or the online RADIUS server (Figure 2). For example, 187 the RADIUS server in either case could see that the NAI is of the 188 form "device@examplevendor.com" and proxy the authentication request 189 to the online service run by the Example Vendor at 190 aaa.examplevendor.com on port 1812. As stated, the vendor service 191 would only allow authentication request from trusted RADIUS servers 192 that have peering relationship. The vendor service will then run 193 several rounds of EAP message exchanges to authenticate the device. 195 On successful authentication, the vendor service informs the RADIUS 196 server to enable network access for the device by sending a RADIUS 197 Access-Accept message. 199 +------------------+ 200 |Manufacturer IoT | 201 +------------+ | device portal | 202 |Access Point| | +----------+ | 203 +-----------+ | +--------+ | RADIUS | | RADIUS | | 204 | | | | RADIUS +--------------+ Server | | 205 | IoT | EAP | | Server | |DIAMETER | +-----+----+ | 206 | Device +------+ +--------+ | | | | 207 | | | | | +-----+----+ | 208 +-----------+ | | | | AAA | | 209 +------------+ | | Server | | 210 | +----------+ | 211 +------------------+ 213 Figure 1: Deployment Architecture (Small Office) 215 +------------------+ 216 |Manufacturer IoT | 217 +------------+ +-----------+ |device portal | 218 |Access Point| |AP Manf. | | +----------+ | 219 +-------+ | +--------+ | |Service | | |RADIUS | | 220 | IoT | | | RADIUS | | | +-------+------+Server | | 221 | Device| EAP| | Client +------+RADIUS | | | +-----+----+ | 222 | +----+ +--------+ | | |Server | | | | | 223 +-------+ | | | +-------+ | | +-----+----+ | 224 | | | | | | AAA | | 225 +------------+ +-----------+ | | Server | | 226 | +----------+ | 227 +------------------+ 229 Figure 2: Deployment Architecture (Home) 231 The exact EAP method used for authentication can be decided by the 232 IoT device manufacturer. For example, the manufacturer may provision 233 certificates on the device which are then used for EAP-TLS [RFC5216] 234 authentication. After successful authentication, the AAA server 235 sends a RADIUS Access-Accept message enabling Internet connectivity 236 for the IoT device. An example message flow in shown in Figure 3. 238 IoT device AP Manufacturer IoT 239 device portal 240 ------------------- ------------- -------------------- 241 <- EAP-Request/ 242 Identity 243 EAP-Response/ 244 Identity (MyID) -> 246 Forward auth messages 247 to IoT device portal 248 by looking at realm 249 in MyID 251 <- EAP-Request/ 252 EAP-Type=EAP-TLS 253 (TLS Start) 254 EAP-Response/ 255 EAP-Type=EAP-TLS 256 (TLS client_hello)-> 257 <- EAP-Request/ 258 EAP-Type=EAP-TLS 259 (TLS server_hello, 260 TLS certificate, 261 [TLS server_key_exchange,] 262 TLS certificate_request, 263 TLS server_hello_done) 264 EAP-Response/ 265 EAP-Type=EAP-TLS 266 (TLS certificate, 267 TLS client_key_exchange, 268 TLS certificate_verify, 269 TLS change_cipher_spec, 270 TLS finished) -> 271 <- EAP-Request/ 272 EAP-Type=EAP-TLS 273 (TLS change_cipher_spec, 274 TLS finished) 275 EAP-Response/ 276 EAP-Type=EAP-TLS -> 277 <- EAP-Success <-Radius Access-Accept 279 Figure 3: Example message sequence 281 4. Manufacturer Dependancy and End-of-life 283 There is a valid concern about the over-reliance on the IoT device 284 manufacturer for the initial network bootstrapping. After all, not 285 all device manufacturers maybe willing or capable to run such an 286 online service throughout the lifetime of the IoT device. 288 For example, the Revolv smart home hub lost all manufacturer support 289 after the it was acquired [revolv]. As noted by 290 [I-D.irtf-t2trg-iot-seccons], such end-of-life of devices may be 291 planned or unplanned (for example when the manufacturer goes bankrupt 292 or when the vendor just decides to abandon a product). A user should 293 still be able to use/bootstrap/re-bootstrap this device. This can 294 require some form of authorization handover. 296 Another question is whether there would be someone willing to 297 continue offering an online AAA service for devices which are no 298 longer supported by the original manufacturer. Whether this can be 299 mandated by regulation or by having sufficient business incentives 300 cannot be addressed in this draft. However, we would note that there 301 are examples of open-source communities supporting existing devices 302 irrespective of any manufacturer support. OpenWrt for home routers 303 and Cyanogenmod (continued as Lineage OS) for smartphones are two 304 such popular examples. 306 With some support from the IoT device manufacturer, the deployment 307 models described thus far in this document are thankfully flexible 308 enough to allow the user to choose an online AAA server different 309 from the original device manufacturer. The RADIUS peering can simply 310 be updated to reflect this change. For example, once the credentials 311 for all the devices at aaa.examplevendor.com have been transferred to 312 a new AAA server run by an open source community at 313 aaa.openvendor.com, the RADIUS peering in can simply be updated to 314 forward EAP requests from devices with NAI realm as examplevendor.com 315 to aaa.openvendor.com at port 1812. 317 5. Alternative Manufacture Independent Deployment Models 319 In this section we look at some alternative deployment modes which 320 don't rely on any pre-provisioned credentials of any sort on the IoT 321 device. Consider the deployment architecture shown in Figure 4. 322 While it looks similar to the figures above, the key difference is 323 that the IoT device portal can now be any third-party online service 324 rather than relying on manufacturer. As above, the AP is expected to 325 forward all EAP authentication requests from IoT devices to a single 326 online RADIUS server by setting up the necessary peering. 328 The user can now pre-register the credentials for new devices that 329 will join the WiFi network. For example, the user can specify a 330 secret that will be used by the device for joining the network. The 331 device can then run EAP-PSK [RFC4764] with the online RADIUS server 332 for securely joining the network. The online RADIUS server can 333 prevent the user from registering the same (or similar) secrets for 334 the different devices in the network. This would ensure that devices 335 in network do not share the same secret. 337 +------------------+ 338 | IoT | 339 +------------+ | device portal | 340 |Access Point| | +----------+ | 341 +-----------+ | +--------+ | RADIUS | | RADIUS | | 342 | | | | RADIUS +--------------+ Server | | 343 | IoT | EAP | | Client | | | +-----+----+ | 344 | Device +------+ +--------+ | | | | 345 | | | | | +-----+----+ | 346 +-----------+ | | | | AAA | | 347 +------------+ | | Server | | 348 | +----------+ | 349 +------------------+ 351 Figure 4: Deployment Architecture (Home) 353 Other EAP methods, such as EAP-NOOB [I-D.aura-eap-noob] can also be 354 deployed with the architecture shown above. EAP-NOOB does not 355 require any pre-provisioned credentials on the IoT device. Instead 356 of requiring the user to input the same PSK on the two ends, the user 357 simply transfers an out-of-band (OOB) message between the device and 358 the server. This can be especially useful for IoT devices which lack 359 the necessary user interface for entering PSKs. 361 6. Security Considerations 363 Fake device: It may seem that any device can simply join the users 364 network because the attacker can always setup a fake registration 365 portal and pretend to successfully authenticate every device. 366 However, this is not really the case. Any device can be connected to 367 the user's access point only if there is radius peering to the 368 attackers registration portal. 370 There still remains the question of how does the device know which AP 371 to try and connect to. To aid this discovery, it is necessary that 372 IoT devices only use EAP methods that provide mutual authentication 373 (such as EAP-TLS, EAP-PSK and EAP-NOOB). 375 The devices can then opportunistically try to connect with APs that 376 are withing range (ignoring all open APs and APs that use WPA2-PSK). 377 The devices would successfully connect to an AP, if it can forward 378 the EAP messages to the right RADIUS server in the device portal. 379 However, there may be scenarios where many APs setup peering with a 380 few popular online IoT device portals. The devices in this case 381 would connect to an unintended AP. While encryption of higher layer 382 traffic is expected, this would still have negative consequences as 383 IoT devices may inadvertently connect to and consume bandwidth from 384 the wrong AP. 386 To prevent such inadvertent scenarios, additional information about 387 the AP must be provided to the IoT device portal when the RADIUS 388 peering is setup. The IoT device portal can then ask the user 389 whether he/she wants to allow a new IoT device that is attempting to 390 connect through his AP. Fortunately, such AP information can easily 391 be communicated over RADIUS using, for example, the NAS-Identifier 392 attribute. 394 7. IANA Considerations 396 There are no IANA impacts in this memo. 398 8. References 400 8.1. Normative references 402 [I-D.aura-eap-noob] 403 Aura, T. and M. Sethi, "Nimble out-of-band authentication 404 for EAP (EAP-NOOB)", draft-aura-eap-noob-03 (work in 405 progress), July 2018. 407 [I-D.irtf-t2trg-iot-seccons] 408 Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- 409 the-Art and Challenges for the Internet of Things 410 Security", draft-irtf-t2trg-iot-seccons-15 (work in 411 progress), May 2018. 413 [IEEE-802.1X] 414 Institute of Electrical and Electronics Engineers, "Local 415 and Metropolitan Area Networks: Port-Based Network Access 416 Control", IEEE Standard 802.1X-2004. , December 2004. 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, 420 DOI 10.17487/RFC2119, March 1997, 421 . 423 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 424 Levkowetz, Ed., "Extensible Authentication Protocol 425 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 426 . 428 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 429 Pre-Shared Key Extensible Authentication Protocol (EAP) 430 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 431 . 433 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 434 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 435 March 2008, . 437 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 438 Ed., "Diameter Base Protocol", RFC 6733, 439 DOI 10.17487/RFC6733, October 2012, 440 . 442 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 443 Service (RADIUS) Protocol Extensions", RFC 6929, 444 DOI 10.17487/RFC6929, April 2013, 445 . 447 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 448 DOI 10.17487/RFC7542, May 2015, 449 . 451 8.2. Informative references 453 [barbie] Gibbs, Samuel., "Hackers can hijack Wi-Fi Hello Barbie to 454 spy on your children", November 2015, 455 . 459 [doorbell] 460 Kumar, M., "How to Hack WiFi Password from Smart 461 Doorbells", January 2016, . 464 [nest] Nest, "Nest Learning Thermostat", January 2016, 465 . 467 [revolv] "Nest is permanently disabling the Revolv smart home hub", 468 The Verge , April 2016, 469 . 472 [scale] Withings, "Body", January 2016, 473 . 475 [Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure 476 Bootstrapping of Cloud-Managed Ubiquitous Displays", 477 Proceedings of ACM International Joint Conference on 478 Pervasive and Ubiquitous Computing (UbiComp 2014), pp. 479 739-750, Seattle, USA , September 2014, 480 . 482 Author's Address 484 Mohit Sethi 485 Ericsson 486 Hirsalantie 11 487 Jorvas 02420 488 Finland 490 EMail: mohit@piuha.net