[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

Network Working Group                                          D. Garcia
Internet-Draft                                                  R. Marin
Intended status: Experimental                       University of Murcia
Expires: December 1, 2016                                   A. Kandasamy
                                                                A. Pelov
                                                                  Acklio
                                                            May 30, 2016


                    LoRaWAN Authentication in RADIUS
                 draft-garcia-radext-radius-lorawan-00

Abstract

   This document describes a proposal for adding LoRaWAN support in
   RADIUS.  The purpose is to integrate the LoRaWAN network join
   procedure with an Authentication, Authorization and Accounting (AAA)
   infrastructure based on RADIUS.

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 http://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 December 1, 2016.

Copyright Notice

   Copyright (c) 2016 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
   (http://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



Garcia, et al.          Expires December 1, 2016                [Page 1]


Internet-Draft               LoRaWAN-RADIUS                     May 2016


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4
   2.  LoRaWAN support in RADIUS . . . . . . . . . . . . . . . . . .   4
   3.  LoRaWAN joining procedure . . . . . . . . . . . . . . . . . .   4
   4.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Protocol Assumptions  . . . . . . . . . . . . . . . . . .   5
     4.2.  Protocol Exchange . . . . . . . . . . . . . . . . . . . .   5
       4.2.1.  Join-Request Attribute  . . . . . . . . . . . . . . .   6
       4.2.2.  Join-Answer Attribute . . . . . . . . . . . . . . . .   6
       4.2.3.  AppSKey Attribute . . . . . . . . . . . . . . . . . .   6
       4.2.4.  NwkSKey Attribute . . . . . . . . . . . . . . . . . .   6
   5.  RADIUS-Diameter Interaction . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Low Power Wide Area Network (LP-WAN) groups several radio
   technologies that allow communications with nodes far from the
   central communication endpoint (base station) in the range of
   kilometers depending on the specifics of the technology and the
   scenario.  They are fairly recent and the protocols to manage those
   infrastructures are in continuous development.  In some cases they
   may not consider aspects such as key management or directly tackle
   scalability issue in terms of authentication and authorization.  The
   nodes to be authenticated and authorized is expected to be
   considerably high in number.  One of the protocols that provide a
   complete solution is LoRaWAN [LoRaWAN].  LoRaWAN is a MAC layer
   protocol that use LoRa as its physical medium to cover long range
   (up-to 20km depending on the environment) devices.  LoRaWAN is
   designed for large scale networks and currently has a central entity
   called network server which maintains a pre-configured key named
   AppKey for each of the devices on the network.  Furthermore, session
   keys such as NwkSKey and AppSKey used for encryption of data
   messages, are derived with the help of this AppKey.  Since each
   service provider would operate their network server individually,
   authenticating the devices becomes a tedious process because of
   inter-interoperability or the roaming challenges between the



Garcia, et al.          Expires December 1, 2016                [Page 2]


Internet-Draft               LoRaWAN-RADIUS                     May 2016


   operators.  As we know the AAA infrastructure provides a flexible,
   scalable solution.  They offer an opportunity to manage all these
   proceses in a centralized manner as happens in other type of networks
   (e.g. cellular, wifi, etc...) making it an interesting asset when
   integrated into the LoRaWAN architecture.

                     +-------+        +-------+              +--------+
   +------+          |       |        |       |              |        |
   |      +--(LoRa)--+       +--(IP)--+       +-----(IP)-----+        |
   +------+          |       |        |       |              |        |
                     +-------+        +-------+              +--------+
   End-Device         Gateway          Network               Application
                                       Server                  Server

                      Figure 1: LoRAWAN Architecture

   The End-Device communicates with the Gateway by using the LoRa
   modulation.  The Gateway acts as a simple transceiver, which forwards
   all data do the Network Server, which performs the processing of the
   frames, network frame authentication (MIC verification), and which
   serves as Network Access Port.  The Application Server can be
   handling user data OR can be used during the join procedure to accept
   an End-Node to the network.  In this case, the Application Server is
   called a Join Server.  This document describes a way to use standard
   RADIUS servers as a Join Server, and to use the RADIUS protocol for
   the interaction between the Network Server and the Application
   Server.

                     +-------+        +-------+              +--------+
   +------+          |       |        |       |              |        |
   |AppKey+--(LoRa)--+       +--(IP)--+       +---(RADIUS)---+ AppKey |
   +------+          |       |        |       |              |        |
                     +-------+        +-------+              +--------+
   End-Device         Gateway          Network                 RADIUS
                                       Server                  Server
                                  (+ RADIUS client)

    Figure 2: LoRAWAN Architecture with AAA and RADIUS authentication.
   End-Device and RADIUS server have a shared secret - the AppKey, which
         is used to derive the session keys (NwkSKey and AppSKey).

   The document describes how LoRaWAN join procedure is integrated with
   AAA infrastructure using RADIUS [RFC2865] by defining the new
   attributes needed to support the LoRaWAN exchange.







Garcia, et al.          Expires December 1, 2016                [Page 3]


Internet-Draft               LoRaWAN-RADIUS                     May 2016


1.1.  Requirements Language

   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 RFC 2119 [RFC2119].

2.  LoRaWAN support in RADIUS

   Regarding the overall functionality, the RADIUS LoRaWAN support
   defines the new Attributes needed for the management of the join
   procedure.  A NAS (RADIUS client) that that intends to support this
   specification MUST implement the RADIUS attributes for this service.
   The NAS-Port-Type specifying the type of port on which the NAS is
   authenticating the end-device in this case MAY be 18 ( Wireless -
   Other ) or a new one specifically assigned for LoRaWAN (TBD.).

3.  LoRaWAN joining procedure

   The LoRaWAN joining procedure as described in the LoRaWAN
   Specification 1.0 [LoRaWAN] consists on one exchange.  The first
   message of this exchange is called join-request (JR) message and is
   sent from the end-device to the network server containing the AppEUI
   and DevEUI of the end-device with additionally a nonce of 2 octets
   called DevNonce.  See Figure 3

                 +-------------+-------------+-------------+
   Size (bytes)  |      8      |      8      |      2      |
   +---------------------------+-------------+-------------+
   Join Request  |   AppEUI    |    DevEUI   |   DevNonce  |
                 +-------------+-------------+-------------+

                      Figure 3: Join Request Message

   In response to the join-request, the other endpoint will answer with
   the join-accept (JA) (Figure 4) if the end-device is successfully
   authenticated and authorized to join the network.  The join-accept
   contains a nonce (AppNonce), a network identifier (NetID), an end-
   device address (DevAddr), a delay between the TX and RX (RxDelay)
   and, optionally, the CFList (see LoRaWAN specification [LoRaWAN]
   section 7).

               +--------+-----+-------+----------+-------+-------------+
   Size (bytes)|   3    |  3  |   4   |    1     |   1   |16 (Optional)|
   +-------------------------------------------------------------------+
   Join Accept |AppNonce|NetID|DevAddr|DLSettings|RxDelay|    CFList   |
               +--------+-----+-------+----------+-------+-------------+

                       Figure 4: Join Accept Message



Garcia, et al.          Expires December 1, 2016                [Page 4]


Internet-Draft               LoRaWAN-RADIUS                     May 2016


4.  Protocol Overview

4.1.  Protocol Assumptions

   For the proposal for LoRaWAN support in RADIUS next we describe some
   assumptions regarding the LoRaWAN specification.  The first is that
   the AppKey is only shared between the AAA server and the end-device.
   The outcome of the successful join procedure (i.e.  NwkSKey and
   AppSKey) are sent from the AAA server to the network-server.  This
   allows for the end-device to exchange message with the network-
   server, once the join procedure is finished, as specified in LoRaWAN
   [LoRaWAN].

4.2.  Protocol Exchange

   The join procedure between the end-device and the network-server
   entails one exchange consisting on a join-request message and a join-
   response message.  In RADIUS the network-server implements a RADIUS
   client to communicate with the AAA Server.  Upon reception of the
   LoRaWAN join-request message, the network-server creates an Access-
   Request message, with the Join-Request attribute containing the
   original message from the end-device, and the Join-Answer Attribute
   with all the fields, except for the MIC that will be calculated by
   the AAA Server, since is the one that holds the AppKey.  Once the AAA
   Server authenticates and authorizes the end-device, sends back the
   Join-Answer with the MIC generated as specified by the LoRaWAN
   specification.  Furthermore, as a consequence of a successful join
   procedure, the AppSKey (optional) and NwkSKey are generated and sent
   along in AppSKey and NwkSKey Attributes respectively.  The NAS
   receives the Access-Accept (if successful), obtains the content of
   the Join-Request attribute and sends it to the end-device, storing in
   association with that end-device the NwSKey and the AppSKey.



















Garcia, et al.          Expires December 1, 2016                [Page 5]


Internet-Draft               LoRaWAN-RADIUS                     May 2016


                        network-server                            AAA
end-device                   (NAS)                               Server
-----------                ---------                            -------
    |                         |                                    |
    |  JR[MIC]                |                   Access-Request   |
    |------------------------>|                  Join-Request Att  |
    |                         |                  Join-Answer Att*  |
    |                         |----------------------------------->|
    |                         |                                    |
    |   gen                   |                                    |  gen
    |    |                    |                                    |   |
    |    |                    |                      Access-Accept |   |
    |    v                    |                   Join-Answer Att  |   v
    | AppSKey                 |                      AppSKey Att*  | AppSKey
    | NwkSKey                 |                        NwSKey Att  | NwkSKey
    |                         |<-----------------------------------|
    |  JA[MIC]                |                                    |
    |<------------------------|                                    |
    |                         |                                    |

                            Figure 5: Protocol

4.2.1.  Join-Request Attribute

   This Attribute contains the original Join-Request message.  This
   attribute will only appear in the Access-Request message.

4.2.2.  Join-Answer Attribute

   This Attribute is used in both Access-Request and Access-Accept
   messages.  In the first case it contains the Join Answer message with
   all the needed values filled by the network-server so the AAA server
   that holds the AppKey is able to create the MIC, that in this case is
   not present (marked with an *).  In the second case, it contains the
   message with the MIC generated by the AAA server.

4.2.3.  AppSKey Attribute

   This Attribute contains the AppSKey, an application session key
   specific for the end-device.  This attribute is optional, and will
   only appear in the Access-Accept message.

4.2.4.  NwkSKey Attribute

   This Attribute contains the NwkSKey, an network session key specific
   for the end-device.  This attribute will only appear in the Access-
   Accept message.




Garcia, et al.          Expires December 1, 2016                [Page 6]


Internet-Draft               LoRaWAN-RADIUS                     May 2016


5.  RADIUS-Diameter Interaction

   TBD.

6.  Acknowledgments

   This work has been possible partially by the SMARTIE project
   (FP7-SMARTIE-609062 EU Project) and the Spanish National Project
   CICYT EDISON (TIN2014-52099-R) granted by the Ministry of Economy and
   Competitiveness of Spain (including ERDF support).

7.  Security Considerations

   TBD.

8.  IANA Considerations

   This document has no actions for IANA.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, DOI 10.17487/RFC2865, June 2000,
              <http://www.rfc-editor.org/info/rfc2865>.

9.2.  Informative References

   [LoRaWAN]  Sornin, N., Luis, M., Eirich, T., and T. Kramp, "LoRa
              Specification V1.0", January 2015, <https://www.lora-
              alliance.org/>.

Authors' Addresses











Garcia, et al.          Expires December 1, 2016                [Page 7]


Internet-Draft               LoRaWAN-RADIUS                     May 2016


   Dan Garcia-Carrillo (Ed.)
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia  30100
   Spain

   Phone: +34 868 88 78 82
   Email: dan.garcia@um.es


   Rafa Marin-Lopez
   University of Murcia
   Campus de Espinardo S/N, Faculty of Computer Science
   Murcia  30100
   Spain

   Phone: +34 868 88 85 01
   Email: rafa@um.es


   Arunprabhu Kandasamy
   Acklio
   2bis rue de la Chataigneraie
   35510 Cesson-Sevigne Cedex
   France

   Email: arun@ackl.io


   Alexander Pelov
   Acklio
   2bis rue de la Chataigneraie
   35510 Cesson-Sevigne Cedex
   France

   Email: a@ackl.io















Garcia, et al.          Expires December 1, 2016                [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/