Skip to main content

Enabling Network Access for IoT devices from the Cloud

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author Mohit Sethi
Last updated 2018-07-19
RFC stream (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
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


   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

   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
   ( in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Sethi                   Expires January 20, 2019                [Page 1]
Internet-Draft                NW-IoT-Cloud                     July 2018

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Deployment Architecture . . . . . . . . . . . . . . . . . . .   4
   4.  Security considerations . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative references  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative references  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

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

   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.

Sethi                   Expires January 20, 2019                [Page 2]
Internet-Draft                NW-IoT-Cloud                     July 2018

   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:

   o  Most home access points currently do not support 802.1x
      authentication: This is however in most cases only a software
      limitation.  Many existing APs can support 802.1x authentication
      after firmware updates.

   o  Home users do not understand RADIUS peering and cannot configure
      802.1x authentication: This is often very true.  However, there
      are mechanisms with which the burden on the user can be
      significantly reduced.  We will discuss some possible alternatives
      in the next section.

   o  Most SOHO (Small office and Home) deployments are small and a
      network wide shared secret provides reasonable security: This is
      an incorrect assumption.  While the deployments are small today,
      as more and more physical devices such as barbie dolls [barbie],
      weighing scales [scale], door bells [doorbell], and thermostats
      [nest] are connected to the Internet, using the same secret for
      the entire network is no longer sustainable.  This is necessary to
      prevent attacks where for example, a compromised WiFi weighing
      scale also compromises the NEST thermostat that is using the same
      network secret.

   o  An enterprise simply won't trust an external entity to remotely
      control their network and add new devices: This is true.  However,
      what we are suggesting in this memo is to allow an IoT device
      manufacturer to put a new IoT device into a separate Virtual LAN
      and enable limited Internet connectivity for it.  It is possible
      that certain enterprises may be willing.  However, we accept that
      this may not be the case in all enterprise settings.

   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",
   document are to be interpreted as described in [RFC2119].

Sethi                   Expires January 20, 2019                [Page 3]
Internet-Draft                NW-IoT-Cloud                     July 2018

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

   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:

   o  The user can pre-register the credentials for new devices that
      will join the WiFi network.  For example, the user can specify a
      secret that will be used by the device for joining the network.
      The device can then run EAP-PSK with the online RADIUS server for
      securely joining the network.  The online RADIUS server can
      prevent the user from registering the same (or similar) secrets
      for the different devices in the network.  This would ensure that
      devices in network do not share the same secret.

   o  Alternatively, the online RADIUS server may only act as proxy and
      route the authentication requests from the IoT device to the
      respective manufacturer portal for authentication.  This would
      however require RADIUS peering between the online RADIUS server
      and the manufacturer IoT device portal.  Since the user does not
      have to run this server, he does not have to worry about how this
      peering is accomplished.

   For routing the EAP messages between the IoT device and the
   manufacturer portal, a RADIUS peering is needed between the AP

Sethi                   Expires January 20, 2019                [Page 4]
Internet-Draft                NW-IoT-Cloud                     July 2018

   (authenticator) and the AAA server that is run by the manufacturer.
   This peering may be secured with a shared secret or certificate-based

   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 "" and proxy the authentciation request
   to the online service run by the Example Vendor at 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)

Sethi                   Expires January 20, 2019                [Page 5]
Internet-Draft                NW-IoT-Cloud                     July 2018

                                               |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.

Sethi                   Expires January 20, 2019                [Page 6]
Internet-Draft                NW-IoT-Cloud                     July 2018

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

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

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

                    Figure 3: Example message sequence

Sethi                   Expires January 20, 2019                [Page 7]
Internet-Draft                NW-IoT-Cloud                     July 2018

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

              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, Ed., "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., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "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,

Sethi                   Expires January 20, 2019                [Page 8]
Internet-Draft                NW-IoT-Cloud                     July 2018

   [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,

              Kumar, M., "How to Hack WiFi Password from Smart
              Doorbells", January 2016, <

   [nest]     Nest, "Nest Learning Thermostat", January 2016,

   [scale]    Withings, "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
   Hirsalantie 11
   Jorvas  02420


Sethi                   Expires January 20, 2019                [Page 9]