idnits 2.17.1 draft-st-t2trg-nw-access-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 : ---------------------------------------------------------------------------- == There are 1 instance 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 (July 19, 2018) is 2080 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 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 July 19, 2018 5 Expires: January 20, 2019 7 Enabling Network Access for IoT devices from the Cloud 8 draft-st-t2trg-nw-access-00 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. In 14 typical implementations, this server may be run by the manufacturer 15 of the IoT device as an online cloud service. This specification is 16 intended for off-the-shelf IoT devices that have just been purchased 17 by the user. Many of these devices have only limited user interfaces 18 that can be used for configuring network access credentials. The 19 device configuration is also made more challenging by the fact that 20 these devices may exist 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 January 20, 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. Security considerations . . . . . . . . . . . . . . . . . . . 8 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6.1. Normative references . . . . . . . . . . . . . . . . . . 8 63 6.2. Informative references . . . . . . . . . . . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 66 1. Introduction 68 There is an increase in the deployment of Internet of Things (IoT) 69 appliances such as wireless baby monitors, printers, speakers and 70 smart TVs. To enable rapid adoption while reducing the cost of 71 deployment, these appliances typically use the existing Wi-Fi 72 infrastructure (Access Point) for Internet connectivity. However, 73 configuring the network-access credentials for these off-the-shelf 74 appliances is cumbersome. Typically this process requires the user 75 to pair the appliance with his/her smartphone over bluetooth and then 76 configure the Wi-Fi SSID and passphrase. 78 This process is not only cumbersome, but requires the appliance to be 79 shipped with an additional network interface (only for 80 configuration). It also moves the problem of securely configuring 81 the network-access credentials to the problem of secure bluetooth 82 pairing. Besides, relying on a single passphrase for the entire 83 network may not be sustainable in the long run. While changing the 84 passphrase to revoke/remove a device from the network is easy today 85 when most devices have a keyboard and only a few (2-5) devices are 86 connected to the network (Access Point), this would be much harder 87 when the devices are many (10-100) and have limited input 88 capabilities. 90 Once configured and connected to the Internet, the user still has to 91 register the IoT device with the manufacturer. This maybe to receive 92 services or software updates. For example, the user may connect his/ 93 her Wi-Fi weighing scale to keep track his/her weight online and 94 receive software updates for new features. 96 This draft explains an example deployment scenario that relies on 97 802.1x [IEEE-802.1X] and EAP [RFC3748] authentication to register the 98 device with the manufacturer and enable network access (provision 99 WiFi credentials) for the IoT device at the same time. Using the 100 802.1x authentication even in SOHO (small office and home) scenarios 101 is a big assumption. The following arguments may correctly apply 102 against such a model: 104 o Most home access points currently do not support 802.1x 105 authentication: This is however in most cases only a software 106 limitation. Many existing APs can support 802.1x authentication 107 after firmware updates. 109 o Home users do not understand RADIUS peering and cannot configure 110 802.1x authentication: This is often very true. However, there 111 are mechanisms with which the burden on the user can be 112 significantly reduced. We will discuss some possible alternatives 113 in the next section. 115 o Most SOHO (Small office and Home) deployments are small and a 116 network wide shared secret provides reasonable security: This is 117 an incorrect assumption. While the deployments are small today, 118 as more and more physical devices such as barbie dolls [barbie], 119 weighing scales [scale], door bells [doorbell], and thermostats 120 [nest] are connected to the Internet, using the same secret for 121 the entire network is no longer sustainable. This is necessary to 122 prevent attacks where for example, a compromised WiFi weighing 123 scale also compromises the NEST thermostat that is using the same 124 network secret. 126 o An enterprise simply won't trust an external entity to remotely 127 control their network and add new devices: This is true. However, 128 what we are suggesting in this memo is to allow an IoT device 129 manufacturer to put a new IoT device into a separate Virtual LAN 130 and enable limited Internet connectivity for it. It is possible 131 that certain enterprises may be willing. However, we accept that 132 this may not be the case in all enterprise settings. 134 The architecture and solution presented in this draft is a 135 generalized version of the original idea presented by Sethi et al. 136 [Sethi14]. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. Deployment Architecture 146 One possible deployment architecture is shown in Figure 1. The IoT 147 device is shown on the left. The device uses EAP for network-access 148 authentication. 150 The Manufacturer IoT device registration portal is shown on the 151 right. The manufacturer is responsible for running a AAA server that 152 authenticates the IoT devices and then informs the users Access Point 153 (AP) to enable Internet connectivity for the IoT device. 155 The Access Point (AP) at the user premises is shown in the middle. 156 The AP provides Internet connectivity to the user devices. The AP 157 must support 802.1x authentication and it uses RADIUS [RFC6929] or 158 DIAMETER [RFC6733] to communicate with the Manufacturer IoT device 159 registration portal. For simplicity, the rest of this memo uses 160 RADIUS as the example protocol. However, it should be noted that the 161 same objectives can be achieved with DIAMETER. 163 As shown in Figure 1 the AP may optionally have a local RADIUS server 164 (which maybe the case in small office environments). In another 165 deployment scenario shown in Figure 2, it is possible that the AP 166 only has a local RADIUS client and routes all the EAP-requests to a 167 online RADIUS server (which maybe the case in home environments). In 168 this case, the online RADIUS server may be run by the AP manufacturer 169 for example. This would unburden the user from the task of 170 maintaining a secure database with credentials for his/her WiFi 171 devices. This online RADIUS server can be used as follows: 173 o The user can pre-register the credentials for new devices that 174 will join the WiFi network. For example, the user can specify a 175 secret that will be used by the device for joining the network. 176 The device can then run EAP-PSK with the online RADIUS server for 177 securely joining the network. The online RADIUS server can 178 prevent the user from registering the same (or similar) secrets 179 for the different devices in the network. This would ensure that 180 devices in network do not share the same secret. 182 o Alternatively, the online RADIUS server may only act as proxy and 183 route the authentication requests from the IoT device to the 184 respective manufacturer portal for authentication. This would 185 however require RADIUS peering between the online RADIUS server 186 and the manufacturer IoT device portal. Since the user does not 187 have to run this server, he does not have to worry about how this 188 peering is accomplished. 190 For routing the EAP messages between the IoT device and the 191 manufacturer portal, a RADIUS peering is needed between the AP 192 (authenticator) and the AAA server that is run by the manufacturer. 193 This peering may be secured with a shared secret or certificate-based 194 TLS. 196 For the routing of EAP messages from an IoT device to the device 197 portal of the manufacturer, the realm part of the Network Access 198 Identifier (NAI) [RFC7542] is used by the local RADIUS server in the 199 AP (Figure 1) or the online RADIUS server (Figure 2). For example, 200 the RADIUS server in either case could see that the NAI is of the 201 form "device@examplevendor.com" and proxy the authentciation request 202 to the online service run by the Example Vendor at 203 aaa.examplevendor.com on port 1812. As stated, the vendor service 204 would only allow authentication request from trusted RADIUS servers 205 that have peering relationship. The vendor service will then run 206 several rounds of EAP message exchanges to authenticate the device. 207 On successful authentication, the vendor service informs the RADIUS 208 server to enable network access for the device by sending a RADIUS 209 Access-Accept message. 211 +------------------+ 212 |Manufacturer IoT | 213 +------------+ | device portal | 214 |Access Point| | +----------+ | 215 +-----------+ | +--------+ | RADIUS | | RADIUS | | 216 | | | | RADIUS +--------------+ Server | | 217 | IoT | EAP | | Server | |DIAMETER | +-----+----+ | 218 | Device +------+ +--------+ | | | | 219 | | | | | +-----+----+ | 220 +-----------+ | | | | AAA | | 221 +------------+ | | Server | | 222 | +----------+ | 223 +------------------+ 225 Figure 1: Deployment Architecture (Small Office) 226 +------------------+ 227 |Manufacturer IoT | 228 +------------+ +-----------+ |device portal | 229 |Access Point| |AP Manf. | | +----------+ | 230 +-------+ | +--------+ | |Service | | |RADIUS | | 231 | IoT | | | RADIUS | | | +-------+------+Server | | 232 | Device| EAP| | Client +------+RADIUS | | | +-----+----+ | 233 | +----+ +--------+ | | |Server | | | | | 234 +-------+ | | | +-------+ | | +-----+----+ | 235 | | | | | | AAA | | 236 +------------+ +-----------+ | | Server | | 237 | +----------+ | 238 +------------------+ 240 Figure 2: Deployment Architecture (Home) 242 The exact EAP method used for authentication can be decided by the 243 IoT device manufacturer. For example, the manufacturer may provision 244 802.1AR certificates on the device which are then used for EAP-TLS 245 [RFC5216] authentication. After successful authentication, the AAA 246 server sends a RADIUS Access-Accept message enabling Internet 247 connectivity for the IoT device. An example message flow in shown in 248 Figure 3. 250 IoT device AP Manufacturer IoT 251 device portal 252 ------------------- ------------- -------------------- 253 <- EAP-Request/ 254 Identity 255 EAP-Response/ 256 Identity (MyID) -> 258 Forward auth messages 259 to IoT device portal 260 by looking at realm 261 in MyID 263 <- EAP-Request/ 264 EAP-Type=EAP-TLS 265 (TLS Start) 266 EAP-Response/ 267 EAP-Type=EAP-TLS 268 (TLS client_hello)-> 269 <- EAP-Request/ 270 EAP-Type=EAP-TLS 271 (TLS server_hello, 272 TLS certificate, 273 [TLS server_key_exchange,] 274 TLS certificate_request, 275 TLS server_hello_done) 276 EAP-Response/ 277 EAP-Type=EAP-TLS 278 (TLS certificate, 279 TLS client_key_exchange, 280 TLS certificate_verify, 281 TLS change_cipher_spec, 282 TLS finished) -> 283 <- EAP-Request/ 284 EAP-Type=EAP-TLS 285 (TLS change_cipher_spec, 286 TLS finished) 287 EAP-Response/ 288 EAP-Type=EAP-TLS -> 289 <- EAP-Success <-Radius Access-Accept 291 Figure 3: Example message sequence 293 4. Security considerations 295 It may seem from our proposal that any device can simply join the 296 users network because the attacker can always setup a fake IoT device 297 registration portal to pretend that it is an authentic device. 298 However, this is not really the case. Any device can be connected to 299 the user's access point only if there is radius peering. So in a 300 small office environment the administrator can decide which IoT 301 devices are allowed to connect to the network. 303 5. IANA Considerations 305 There are no IANA impacts in this memo. 307 6. References 309 6.1. Normative references 311 [IEEE-802.1X] 312 Institute of Electrical and Electronics Engineers, "Local 313 and Metropolitan Area Networks: Port-Based Network Access 314 Control", IEEE Standard 802.1X-2004. , December 2004. 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, 318 DOI 10.17487/RFC2119, March 1997, 319 . 321 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 322 Levkowetz, Ed., "Extensible Authentication Protocol 323 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 324 . 326 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 327 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 328 March 2008, . 330 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 331 Ed., "Diameter Base Protocol", RFC 6733, 332 DOI 10.17487/RFC6733, October 2012, 333 . 335 [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User 336 Service (RADIUS) Protocol Extensions", RFC 6929, 337 DOI 10.17487/RFC6929, April 2013, 338 . 340 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 341 DOI 10.17487/RFC7542, May 2015, 342 . 344 6.2. Informative references 346 [barbie] Gibbs, Samuel., "Hackers can hijack Wi-Fi Hello Barbie to 347 spy on your children", November 2015, 348 . 352 [doorbell] 353 Kumar, M., "How to Hack WiFi Password from Smart 354 Doorbells", January 2016, . 357 [nest] Nest, "Nest Learning Thermostat", January 2016, 358 . 360 [scale] Withings, "Body", January 2016, 361 . 363 [Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure 364 Bootstrapping of Cloud-Managed Ubiquitous Displays", 365 Proceedings of ACM International Joint Conference on 366 Pervasive and Ubiquitous Computing (UbiComp 2014), pp. 367 739-750, Seattle, USA , September 2014, 368 . 370 Author's Address 372 Mohit Sethi 373 Ericsson 374 Hirsalantie 11 375 Jorvas 02420 376 Finland 378 EMail: mohit@piuha.net