Network Working Group M. Sethi
Internet-Draft Ericsson
Intended status: Informational July 19, 2018
Expires: January 20, 2019

Enabling Network Access for IoT devices from the Cloud
draft-st-t2trg-nw-access-00

Abstract

This document describes a method for enabling and configuring network access for IoT devices that are first authenticated at a server. In typical implementations, this server may be run by the manufacturer of the IoT device as an online cloud service. This specification is intended for off-the-shelf IoT devices that have just been purchased by the user. Many of these devices have only limited user interfaces that can be used for configuring network access credentials. The device configuration is also made more challenging by the fact that these devices may exist in large numbers.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 20, 2019.

Copyright Notice

Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

There is an increase in the deployment of Internet of Things (IoT) appliances such as wireless baby monitors, printers, speakers and smart TVs. To enable rapid adoption while reducing the cost of deployment, these appliances typically use the existing Wi-Fi infrastructure (Access Point) for Internet connectivity. However, configuring the network-access credentials for these off-the-shelf appliances is cumbersome. Typically this process requires the user to pair the appliance with his/her smartphone over bluetooth and then configure the Wi-Fi SSID and passphrase.

This process is not only cumbersome, but requires the appliance to be shipped with an additional network interface (only for configuration). It also moves the problem of securely configuring the network-access credentials to the problem of secure bluetooth pairing. Besides, relying on a single passphrase for the entire network may not be sustainable in the long run. While changing the passphrase to revoke/remove a device from the network is easy today when most devices have a keyboard and only a few (2-5) devices are connected to the network (Access Point), this would be much harder when the devices are many (10-100) and have limited input capabilities.

Once configured and connected to the Internet, the user still has to register the IoT device with the manufacturer. This maybe to receive services or software updates. For example, the user may connect his/her Wi-Fi weighing scale to keep track his/her weight online and receive software updates for new features.

This draft explains an example deployment scenario that relies on 802.1x [IEEE-802.1X] and EAP [RFC3748] authentication to register the device with the manufacturer and enable network access (provision WiFi credentials) for the IoT device at the same time. Using the 802.1x authentication even in SOHO (small office and home) scenarios is a big assumption. The following arguments may correctly apply against such a model:

The architecture and solution presented in this draft is a generalized version of the original idea presented by Sethi et al..

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Deployment Architecture

One possible deployment architecture is shown in Figure 1. The IoT device is shown on the left. The device uses EAP for network-access authentication.

The Manufacturer IoT device registration portal is shown on the right. The manufacturer is responsible for running a AAA server that authenticates the IoT devices and then informs the users Access Point (AP) to enable Internet connectivity for the IoT device.

The Access Point (AP) at the user premises is shown in the middle. The AP provides Internet connectivity to the user devices. The AP must support 802.1x authentication and it uses RADIUS [RFC6929] or DIAMETER [RFC6733] to communicate with the Manufacturer IoT device registration portal. For simplicity, the rest of this memo uses RADIUS as the example protocol. However, it should be noted that the same objectives can be achieved with DIAMETER.

As shown in Figure 1 the AP may optionally have a local RADIUS server (which maybe the case in small office environments). In another deployment scenario shown in Figure 2, it is possible that the AP only has a local RADIUS client and routes all the EAP-requests to a online RADIUS server (which maybe the case in home environments). In this case, the online RADIUS server may be run by the AP manufacturer for example. This would unburden the user from the task of maintaining a secure database with credentials for his/her WiFi devices. This online RADIUS server can be used as follows:

For routing the EAP messages between the IoT device and the manufacturer portal, a RADIUS peering is needed between the AP (authenticator) and the AAA server that is run by the manufacturer. This peering may be secured with a shared secret or certificate-based TLS.

For the routing of EAP messages from an IoT device to the device portal of the manufacturer, the realm part of the Network Access Identifier (NAI) [RFC7542] is used by the local RADIUS server in the AP (Figure 1) or the online RADIUS server (Figure 2). For example, the RADIUS server in either case could see that the NAI is of the form "device@examplevendor.com" and proxy the authentciation request to the online service run by the Example Vendor at aaa.examplevendor.com on port 1812. As stated, the vendor service would only allow authentication request from trusted RADIUS servers that have peering relationship. The vendor service will then run several rounds of EAP message exchanges to authenticate the device. On successful authentication, the vendor service informs the RADIUS server to enable network access for the device by sending a RADIUS Access-Accept message.

 
                                           +------------------+
                                           |Manufacturer IoT  |
                   +------------+          |  device portal   |
                   |Access Point|          | +----------+     |
+-----------+      | +--------+ | RADIUS   | |  RADIUS  |     |
|           |      | | RADIUS +--------------+  Server  |     |
|   IoT     | EAP  | | Server | |DIAMETER  | +-----+----+     |
|  Device   +------+ +--------+ |          |       |          |
|           |      |            |          | +-----+----+     |
+-----------+      |            |          | |    AAA   |     |
                   +------------+          | |   Server |     |
                                           | +----------+     |
                                           +------------------+

 
            

Figure 1: Deployment Architecture (Small Office)

 
                                            +------------------+
                                            |Manufacturer IoT  |
             +------------+  +-----------+  |device portal     |
             |Access Point|  |AP Manf.   |  | +----------+     |
+-------+    | +--------+ |  |Service    |  | |RADIUS    |     |
|  IoT  |    | | RADIUS | |  | +-------+------+Server    |     |
| Device| EAP| | Client +------+RADIUS | |  | +-----+----+     |
|       +----+ +--------+ |  | |Server | |  |       |          |
+-------+    |            |  | +-------+ |  | +-----+----+     |
             |            |  |           |  | |    AAA   |     |
             +------------+  +-----------+  | |   Server |     |
                                            | +----------+     |
                                            +------------------+

 
            

Figure 2: Deployment Architecture (Home)

The exact EAP method used for authentication can be decided by the IoT device manufacturer. For example, the manufacturer may provision 802.1AR certificates on the device which are then used for EAP-TLS [RFC5216] authentication. After successful authentication, the AAA server sends a RADIUS Access-Accept message enabling Internet connectivity for the IoT device. An example message flow in shown in Figure 3.

        
        IoT device             AP                 Manufacturer IoT
                                                   device portal  
   -------------------     -------------         --------------------
                           <- EAP-Request/
                           Identity
   EAP-Response/
   Identity (MyID) ->

                           Forward auth messages
                           to IoT device portal
                           by looking at realm 
                           in MyID

                                                    <- EAP-Request/
                                                   EAP-Type=EAP-TLS
                                                     (TLS Start)  
   EAP-Response/
   EAP-Type=EAP-TLS
   (TLS client_hello)->
                                                 <- EAP-Request/
                                                 EAP-Type=EAP-TLS
                                                 (TLS server_hello,
                                                   TLS certificate,
                                          [TLS server_key_exchange,]
                                           TLS certificate_request,
                                              TLS server_hello_done)
   EAP-Response/
   EAP-Type=EAP-TLS
   (TLS certificate,
    TLS client_key_exchange,
    TLS certificate_verify,
    TLS change_cipher_spec,
    TLS finished) ->
                                               <- EAP-Request/
                                               EAP-Type=EAP-TLS
                                           (TLS change_cipher_spec,
                                                TLS finished)
   EAP-Response/
   EAP-Type=EAP-TLS ->
                           <- EAP-Success    <-Radius Access-Accept

        
              

Figure 3: Example message sequence

4. Security considerations

It may seem from our proposal that any device can simply join the users network because the attacker can always setup a fake IoT device registration portal to pretend that it is an authentic device. However, this is not really the case. Any device can be connected to the user's access point only if there is radius peering. So in a small office environment the administrator can decide which IoT devices are allowed to connect to the network.

5. IANA Considerations

There are no IANA impacts in this memo.

6. References

6.1. Normative references

[IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004. , December 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004.
[RFC5216] Simon, D., Aboba, B. and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J. and G. Zorn, "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012.
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015.

6.2. Informative references

[barbie] Gibbs, Samuel., "Hackers can hijack Wi-Fi Hello Barbie to spy on your children", November 2015.
[doorbell] Kumar, M., "How to Hack WiFi Password from Smart Doorbells", January 2016.
[nest] , "Nest Learning Thermostat", January 2016.
[scale] , "Body", January 2016.
[Sethi14] Sethi, M., Oat, E., Di Francesco, M. and T. Aura, "Secure Bootstrapping of Cloud-Managed Ubiquitous Displays", Proceedings of ACM International Joint Conference on Pervasive and Ubiquitous Computing (UbiComp 2014), pp. 739-750, Seattle, USA , September 2014.

Author's Address

Mohit Sethi Ericsson Hirsalantie 11 Jorvas, 02420 Finland EMail: mohit@piuha.net