One document matched: draft-garcia-radext-radius-lorawan-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc ipr="trust200902" category="exp" docName="draft-garcia-radext-radius-lorawan-00">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="LoRaWAN-RADIUS">LoRaWAN Authentication in RADIUS</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Dan Garcia-Carrillo (Ed.)" initials="D." surname="Garcia">
<organization>University of Murcia</organization>
<address>
<postal>
<street>Campus de Espinardo S/N, Faculty of Computer Science</street>
<!-- Reorder these if your country does things differently -->
<city>Murcia</city>
<region></region>
<code>30100</code>
<country>Spain</country>
</postal>
<phone>+34 868 88 78 82</phone>
<email>dan.garcia@um.es</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Rafa Marin-Lopez" initials="R." surname="Marin">
<organization>University of Murcia</organization>
<address>
<postal>
<street>Campus de Espinardo S/N, Faculty of Computer Science</street>
<!-- Reorder these if your country does things differently -->
<city>Murcia</city>
<region></region>
<code>30100</code>
<country>Spain</country>
</postal>
<phone>+34 868 88 85 01</phone>
<email>rafa@um.es</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Arunprabhu Kandasamy" initials="A" surname="Kandasamy">
<organization>Acklio</organization>
<address>
<postal>
<street>2bis rue de la Chataigneraie</street>
<city>35510 Cesson-Sevigne Cedex</city>
<country>France</country>
</postal>
<email>arun@ackl.io</email>
</address>
</author>
<author fullname="Alexander Pelov" initials="A" surname="Pelov">
<organization>Acklio</organization>
<address>
<postal>
<street>2bis rue de la Chataigneraie</street>
<city>35510 Cesson-Sevigne Cedex</city>
<country>France</country>
</postal>
<email>a@ackl.io</email>
</address>
</author>
<date month="May" year="2016" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Network Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> 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 <xref target="LoRaWAN"></xref>. 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 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.
</t>
<t>
<figure align="center" anchor="lorawan-architecture" title="LoRAWAN Architecture">
<!-- maximum wide of the figure -->
<artwork align="left"><![CDATA[
+-------+ +-------+ +--------+
+------+ | | | | | |
| +--(LoRa)--+ +--(IP)--+ +-----(IP)-----+ |
+------+ | | | | | |
+-------+ +-------+ +--------+
End-Device Gateway Network Application
Server Server
]]></artwork>
</figure>
</t>
<t>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.</t>
<t>
<figure align="center" anchor="lorawan-radius" title="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).">
<!-- maximum wide of the figure -->
<artwork align="left"><![CDATA[
+-------+ +-------+ +--------+
+------+ | | | | | |
|AppKey+--(LoRa)--+ +--(IP)--+ +---(RADIUS)---+ AppKey |
+------+ | | | | | |
+-------+ +-------+ +--------+
End-Device Gateway Network RADIUS
Server Server
(+ RADIUS client)
]]></artwork>
</figure>
</t>
<t> The document describes how LoRaWAN join procedure is integrated with AAA infrastructure using RADIUS <xref target="RFC2865"/> by defining the new attributes needed to support the LoRaWAN exchange.
</t>
<section title="Requirements Language">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</section>
</section>
<section title="LoRaWAN support in RADIUS">
<t>
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.).
</t>
</section>
<section title="LoRaWAN joining procedure">
<t>
The LoRaWAN joining procedure as described in the LoRaWAN Specification 1.0 <xref target="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 <xref target="join-request"/>
</t>
<t>
<figure align="center" anchor="join-request" title="Join Request Message">
<!-- maximum wide of the figure -->
<artwork align="left"><![CDATA[
+-------------+-------------+-------------+
Size (bytes) | 8 | 8 | 2 |
+---------------------------+-------------+-------------+
Join Request | AppEUI | DevEUI | DevNonce |
+-------------+-------------+-------------+
]]></artwork>
</figure>
</t>
<t>In response to the join-request, the other endpoint will answer with the join-accept (JA) (<xref target="join-accept" />) 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 <xref target="LoRaWAN"/> section 7).
</t>
<t>
<figure align="center" anchor="join-accept" title="Join Accept Message">
<!-- maximum wide of the figure -->
<artwork align="left"><![CDATA[
+--------+-----+-------+----------+-------+-------------+
Size (bytes)| 3 | 3 | 4 | 1 | 1 |16 (Optional)|
+-------------------------------------------------------------------+
Join Accept |AppNonce|NetID|DevAddr|DLSettings|RxDelay| CFList |
+--------+-----+-------+----------+-------+-------------+
]]></artwork>
</figure>
</t>
</section>
<section title="Protocol Overview">
<section title="Protocol Assumptions">
<t>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 <xref target="LoRaWAN"/>.
</t>
</section>
<section title="Protocol Exchange">
<t>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.
<figure align="center" anchor="protocol-overview" title="Protocol">
<!-- maximum wide of the figure -->
<artwork align="left"><![CDATA[
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] | |
|<------------------------| |
| | |
]]></artwork>
</figure>
</t>
<section title="Join-Request Attribute">
<t> This Attribute contains the original Join-Request message. This attribute will only appear in the Access-Request message.
</t>
</section>
<section title="Join-Answer Attribute">
<t> 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.
</t>
</section>
<section title="AppSKey Attribute">
<t> 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.
</t>
</section>
<section title="NwkSKey Attribute">
<t> This Attribute contains the NwkSKey, an network session key specific for the end-device. This attribute will only appear in the Access-Accept message.
</t>
</section>
</section>
</section>
<section title="RADIUS-Diameter Interaction">
<t>
TBD.
</t>
</section>
<section title="Acknowledgments">
<t>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).
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
TBD.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
This document has no actions for IANA.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2865;
</references>
<references title="Informative References">
<reference anchor="LoRaWAN" target="https://www.lora-alliance.org/">
<front>
<title>LoRa Specification V1.0</title>
<author initials="N." surname="Sornin"></author>
<author initials="M." surname="Luis"></author>
<author initials="T." surname="Eirich"></author>
<author initials="T." surname="Kramp"></author>
<date month="January" year="2015" />
</front>
</reference>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 09:35:31 |