idnits 2.17.1 draft-garcia-radext-radius-lorawan-03.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 9 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 2, 2017) is 2551 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'MIC' is mentioned on line 368, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Garcia 3 Internet-Draft R. Marin 4 Intended status: Experimental University of Murcia 5 Expires: November 3, 2017 A. Kandasamy 6 A. Pelov 7 Acklio 8 May 2, 2017 10 LoRaWAN Authentication in RADIUS 11 draft-garcia-radext-radius-lorawan-03 13 Abstract 15 This document describes a proposal for adding LoRaWAN support in 16 RADIUS. The purpose is to integrate the LoRaWAN network join 17 procedure with an Authentication, Authorization and Accounting (AAA) 18 infrastructure based on RADIUS. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 3, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 56 2. LoRaWAN support in RADIUS . . . . . . . . . . . . . . . . . . 4 57 3. LoRaWAN Overview . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. LoRaWAN join procedure Key Material . . . . . . . . . . . 4 60 3.3. LoRaWAN joining procedure . . . . . . . . . . . . . . . . 5 61 3.4. LoRaWAN Key Derivation . . . . . . . . . . . . . . . . . 6 62 4. Integration Overview . . . . . . . . . . . . . . . . . . . . 7 63 4.1. Mapping LoRaWAN Entities to AAA Infrastructure . . . . . 7 64 4.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Protocol Exchange . . . . . . . . . . . . . . . . . . . . 7 66 4.3.1. Join-Request Attribute . . . . . . . . . . . . . . . 8 67 4.3.2. Join-Answer Attribute . . . . . . . . . . . . . . . . 9 68 4.3.3. AppSKey Attribute . . . . . . . . . . . . . . . . . . 10 69 4.3.4. NwkSKey Attribute . . . . . . . . . . . . . . . . . . 11 70 4.3.5. Table of Attribute . . . . . . . . . . . . . . . . . 11 71 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 73 7. Proof of concept implementation . . . . . . . . . . . . . . . 13 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 10.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 Low Power Wide Area Network (LP-WAN) groups several radio 84 technologies that allow communications with nodes far from the 85 central communication endpoint (base station) in the range of 86 kilometers depending on the specifics of the technology and the 87 scenario. They are fairly recent and the protocols to manage those 88 infrastructures are in continuous development. In some cases they 89 may not consider aspects such as key management or directly tackle 90 scalability issue in terms of authentication and authorization. The 91 nodes to be authenticated and authorized is expected to be 92 considerably high in number. One of the protocols that provide a 93 complete solution is LoRaWAN [LoRaWAN]. LoRaWAN is a MAC layer 94 protocol that use LoRa as its physical medium to cover long range 95 (up-to 20 km depending on the environment) devices. LoRaWAN is 96 designed for large scale networks and currently has a central entity 97 called Network Server which maintains a pre-configured key named 98 AppKey for each of the devices on the network. Furthermore, session 99 keys such as NwkSKey and AppSKey used for encryption of data 100 messages, are derived with the help of this AppKey. Since each 101 service provider would operate their Network Server individually, 102 authenticating the devices becomes a tedious process because of 103 inter-interoperability or the roaming challenges between the 104 operators. An illustration of the LoRaWAN architecture can be seen 105 in figure Figure 1. As we know the AAA infrastructure provides a 106 flexible, scalable solution. They offer an opportunity to manage all 107 these processes in a centralized manner as happens in other type of 108 networks (e.g. cellular, WiFi, etc...) making it an interesting asset 109 when integrated into the LoRaWAN architecture. 111 +-------+ +-------+ +--------+ 112 +------+ | | | | | | 113 | +--(LoRa)--+ +--(IP)--+ +-----(IP)-----+ | 114 +------+ | | | | | | 115 +-------+ +-------+ +--------+ 116 End-Device Gateway Network Join 117 Server Server 119 Figure 1: LoRAWAN Architecture 121 The End-Device communicates with the Gateway by using the LoRa 122 modulation. The Gateway acts as a simple transceiver, which forwards 123 all data do the Network Server, which performs the processing of the 124 frames, network frame authentication (MIC verification), and which 125 serves as Network Access Port. This document describes a way to use 126 standard RADIUS servers as a Join Server, and to use the RADIUS 127 protocol for the interaction between the Network Server and the 128 Application Server. This integration is illustrated in figure 129 Figure 2 131 +-------+ +-------+ +--------+ 132 +------+ | | | | | | 133 |AppKey+--(LoRa)--+ +--(IP)--+ +---(RADIUS)---+ AppKey | 134 +------+ | | | | | | 135 +-------+ +-------+ +--------+ 136 End-Device Gateway Network Join 137 Server Server 138 (+ RADIUS client) (+ RADIUS server) 140 Figure 2: LoRAWAN Architecture with AAA and RADIUS authentication. 141 End-Device and RADIUS server have a shared secret - the AppKey, which 142 is used to derive the session keys (NwkSKey and AppSKey). 144 The document describes how LoRaWAN join procedure is integrated with 145 AAA infrastructure using RADIUS [RFC2865] by defining the new 146 attributes needed to support the LoRaWAN exchange. 148 1.1. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 2. LoRaWAN support in RADIUS 156 Regarding the overall functionality, the RADIUS LoRaWAN support 157 defines the new Attributes needed for the management of the join 158 procedure. The Network Server will implement a RADIUS client 159 supporting this specification and therefore, it MUST implement the 160 RADIUS attributes for this service. The NAS-Port-Type specifying the 161 type of port on which the Network Server is authenticating the End- 162 Device in this case MAY be 18 ( Wireless - Other ) or a new one 163 specifically assigned for LoRaWAN (TBD.). 165 3. LoRaWAN Overview 167 3.1. Introduction 169 The LoRAWAN specification defines how the MAC and PHY layer will be 170 used with the LoRa radio technologies. It defines a process by which 171 the smart objects can securely join the network in an authenticated 172 way and exchange application information ciphered and integrity 173 protected. The focus of this document is to extend how the process 174 of joining is performed by the specification including a AAA 175 infrastructure (RADIUS) to accomplish this. Next we review how the 176 keys, and each message is used in the joining procedure. Then we 177 elaborate some assumptions to design the integration of AAA in the 178 joining procedure possible. 180 3.2. LoRaWAN join procedure Key Material 182 The LoRaWAN specification describes 3 keys involved in the joining 183 procedure. One as a root key that will be used to generate the other 184 two, which will be used to secure the message exchanges after the 185 joining procedure success. The AppKey key used to derive the other 186 two keys, NwkSKey and AppSKey: 188 o The AppKey is an AES-128 application specific key assigned by the 189 owner of the application. This key is derived from an 190 application-specific root key that is only known to the 191 application owner and is stored in each device and in the Join 192 Server that will perform the authentication. 194 o The NwkSKey is a network session key that is specific to each End- 195 Device. It is shared between the Network Server and the End- 196 Device and used to calculate and verify the Message Integrity Code 197 (MIC) for each data message, between both entities. Furthermore, 198 it is used to cipher and decipher the payload of MAC-only data 199 message. 201 o The AppSKey is an application session key specific to each End- 202 Device. It is in charge of ciphering and deciphering the payload 203 of application-specific data messages and is also used to 204 calculate and verify the MIC that may be added to the payload of 205 application-specific data messages. 207 3.3. LoRaWAN joining procedure 209 The LoRaWAN joining procedure, as described in the LoRaWAN 210 Specification 1.0 [LoRaWAN], consists on one exchange. The first 211 message of this exchange is called join-request (JR) message and is 212 sent from the End-Device to the Network Server containing the AppEUI 213 and DevEUI of the End-Device with a nonce of 2 octets called 214 DevNonce. Figure 3 summarizes the format. 216 +-------------+-------------+-------------+ 217 Size (bytes) | 8 | 8 | 2 | 218 +---------------------------+-------------+-------------+ 219 Join Request | AppEUI | DevEUI | DevNonce | 220 +-------------+-------------+-------------+ 222 Figure 3: Join Request Message 224 In response to the join-request, the other endpoint will answer with 225 the join-accept (JA) (Figure 4) if the End-Device is successfully 226 authenticated and authorized to join the network. The join-accept 227 contains a nonce (AppNonce), a network identifier (NetID), an End- 228 Device address (DevAddr), a delay between the TX and RX (RxDelay) 229 and, optionally, the CFList (see LoRaWAN specification [LoRaWAN] 230 section 7). 232 +--------+-----+-------+----------+-------+-------------+ 233 Size (bytes)| 3 | 3 | 4 | 1 | 1 |16 (Optional)| 234 +-------------------------------------------------------------------+ 235 Join Accept |AppNonce|NetID|DevAddr|DLSettings|RxDelay| CFList | 236 +--------+-----+-------+----------+-------+-------------+ 238 Figure 4: Join Accept Message 240 Next, we enumerate and describe each field involved in the join 241 procedure message exchange. 243 o AppEUI: Global application ID in IEEE EUI64 to uniquely identify 244 the application provider. 246 o DevEUI: Global End-Device ID in IEEE EUI64 to uniquely identify 247 the End-Device 249 o DevNonce: A random value. 251 o AppNonce: A random value or some kind of unique ID provided by the 252 Network Server. This value can be also generated by the AAA 253 server, in case the network server wants to rely on the AAA server 254 pseudo random number generation. For this, the AppNonce would be 255 empty (set to zero), signaling the AAA server it has to generate 256 the AppNonce. 258 o NetID: A network identifier 260 o DevAddr: A 32 bit identifier of the End-Device in the current 261 network. It is composed of the Network ID and the Network 262 Address. 264 o DLSettings: 8 bits containing the down-link configuration. 266 o RxDelay: 8 bits containing the delay between TX and RX. 268 o CFList (Optional): Channel frequency list. 270 3.4. LoRaWAN Key Derivation 272 The keys NwkSKey and AppSKey are derived from the AppKey in both the 273 Join Server and the End-Device according to the LoRaWAN specification 274 [LoRaWAN] as follows: 276 Derivation of the NwkSkey: 278 NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce | 279 pad16) 281 Derivation of the AppSkey: 283 AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | 284 pad16) 286 Note: The pad16 function appends octets of containing "zero" so that 287 the length of the data is a multiple of 16. 289 4. Integration Overview 291 4.1. Mapping LoRaWAN Entities to AAA Infrastructure 293 In the current specification of LoRaWAN [LoRaWAN], there is no 294 explicit reference to an external entity to which the Network Server 295 can go to authenticate the End-Device. However, ongoing work related 296 to LoRaWAN, such as the work in the LoRa Alliance 297 [LoRaAllianceSecurity] sketches the use of a new entity, the Join 298 Server, that will be in charge of performing the authentication. 299 This separation of responsibilities is also the aim of our work, 300 where the Join Server acts as an external AAA server in a AAA 301 infrastructure using RADIUS as the protocol to communicate the 302 Network Server and the Join Server. Further, it is under 303 consideration the distribution of the AppSKey to a target application 304 server instead of the Network Server. Therefore, the Join Server 305 would need another protocol to deliver the AppSKey. Another RADIUS 306 interface could be used for this purpose, though this I-D focuses on 307 the joining procedure so far. 309 4.2. Assumptions 311 For the integration of LoRaWAN joining procedure with RADIUS next we 312 describe some assumptions regarding the LoRaWAN specification. The 313 first is that the AppKey is only shared between the AAA server (Join 314 Server) and the End-Device. The outcome of the successful join 315 procedure (i.e. NwkSKey and AppSKey) are sent from the AAA server to 316 the network-server. This allows for the End-Device to exchange 317 message with the network-server, once the join procedure is finished, 318 as specified in LoRaWAN [LoRaWAN]. 320 4.3. Protocol Exchange 322 The join procedure between the End-Device and the network-server 323 entails one exchange consisting on a join-request message and a join- 324 response message. In RADIUS the network-server implements a RADIUS 325 client to communicate with the Join Server, which act as AAA Server. 327 The protocol exchange is done in the following steps: 329 1. The End-Device sends the join-request message to to the Network 330 Server. 332 2. Upon reception of the LoRaWAN join-request message, the Network 333 Server creates a RADIUS Access-Request message, with the Join- 334 Request attribute containing the original message from the End- 335 Device, and the Join-Answer Attribute with all the fields of a 336 join-answer message except for the MIC, which will be calculated 337 by the AAA Server (Join Server), since is the one that holds the 338 AppKey. 340 3. Once the AAA Server authenticates and authorizes the End-Device, 341 sends back the Join-Answer with the MIC generated as specified by 342 the LoRaWAN specification. Furthermore, as a consequence of a 343 successful join procedure, the AppSKey (optional) and NwkSKey are 344 generated and sent along in AppSKey and NwkSKey Attributes 345 respectively. 347 4. The Network Server receives the Access-Accept (if successful), 348 obtains the content of the Join-Request attribute and sends it to 349 the End-Device, storing in association with that End-Device the 350 NwkSKey and the AppSKey. 352 AAA 353 End-Device Network Server Server (Join Server) 354 ----------- --------- ------- 355 | | | 356 1) | JR[MIC] | Access-Request | 357 |------------------------>| Join-Request Att | 358 | | Join-Answer Att* | 359 2) | |----------------------------------->| 360 | | | 361 | gen | | gen 362 | | | | | 363 | | | Access-Accept | | 364 | v | Join-Answer Att | v 365 | AppSKey | AppSKey Att* | AppSKey 366 3) | NwkSKey | NwkSKey Att | NwkSKey 367 | |<-----------------------------------| 368 | JA[MIC] | | 369 4) |<------------------------| | 370 | | | 372 Figure 5: Protocol 374 4.3.1. Join-Request Attribute 376 Description 378 This Attribute contains the original Join-Request message. This 379 attribute will only appear in the Access-Request message. A summary 380 of the Join-Request attribute format is shown below. The fields are 381 transmitted from left to right. 383 0 1 2 384 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Type | Length | String... 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Type 391 TBD. for Join-Request 393 Length 395 18 397 String 399 The String field contains an octet string with the Join-Request 400 message as received over the network, such as defined in [LoRaWAN]. 402 4.3.2. Join-Answer Attribute 404 Description 406 This Attribute is used in both RADIUS Access-Request and RADIUS 407 Access-Accept messages. In the first case, it contains the Join 408 Answer message with all the needed values filled by the network- 409 server except the MIC (this fact is marked with an *). With these 410 values, the Join Server (AAA server) that holds the AppKey is able to 411 create the MIC and compose the final Join Answer message. In the 412 second case, it contains the Join Answer with the MIC generated by 413 the Join Server (AAA server). A summary of the Join-Answer attribute 414 format is shown below. The fields are transmitted from left to 415 right. 417 0 1 2 418 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Type | Length | String... 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 Type 425 TBD. for Join-Answer 427 Length 429 28 431 String 433 The String field contains an octet string with the Join-Answer as 434 received over the network , as defined in [LoRaWAN]. 436 4.3.3. AppSKey Attribute 438 Description 440 This Attribute contains the AppSKey, an application session key 441 specific for the End-Device. This attribute is optional, and will 442 only appear in the RADIUS Access-Accept message. A summary of the 443 AppSKey attribute format is shown below. The fields are transmitted 444 from left to right. 446 0 1 2 447 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Type | Length | String... 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Type 454 TBD. for AppSKey 456 Length 458 16+ 460 String 461 The String field contains an octet string containing the Application 462 Session Key, as defined in [LoRaWAN]. 464 4.3.4. NwkSKey Attribute 466 Description 468 This Attribute contains the NwkSKey, an network session key specific 469 for the End-Device. This attribute will only appear in the Access- 470 Accept message. A summary of the NwkSKey attribute format is shown 471 below. The fields are transmitted from left to right. 473 0 1 2 474 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Type | Length | String... 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 Type 481 TBD. for NwkSKey 483 Length 485 16+ 487 String 489 The String field contains the octet string of the Network Session Key 490 , as defined in [LoRaWAN]. 492 4.3.5. Table of Attribute 494 Request Accept Reject Challenge # Attribute 495 1 0 0 0 TBD. Join-Request 496 1 1 0 0 TBD. Join-Answer 497 0 0-1 0 0 TBD. AppSKey 498 0 1 0 0 TBD. NwkSKey 499 Request Accept Reject Challenge # Attribute 501 Figure 6: Attributes Table 503 5. Open Issues 505 With the purpose of extending the authentication process via AAA 506 infrastructures, and concretely, RADIUS, we have faced a question 507 regarding the relationship between the AppEUI associated to the 508 organization operating the Join Server and the realm used by RADIUS 509 to route the AAA information to the AAA Server (Join Server) of that 510 organization. 512 In particular, the Network Server knows the AppEUI included in the 513 Join Request, but it needs to discover the realm (Fully Qualified 514 Domain Name) that corresponds to that organizations ID to be able to 515 communicate with the concrete RADIUS server. 517 NOTE: One option MAY be to use the DNS system to provide the FQDN 518 associated to an AppEUI (which is an EUI64 address). The mapping 519 using DNS to find out the domain name associated to an EUI64 address 520 has been described in [RFC7043]. However, we would need the inverse 521 process. Nevertheless, this needs further discussion. 523 6. Security Considerations 525 In the LoRaWAN 1.0 specification, the AppSKey and NwkSKey are not 526 sent over the network, they are derived in each of the endpoints that 527 communicate, namely the End-Device and the Network Server. In this 528 document we propose relegating the responsibility of deriving the 529 Network Session Key and Application Session Key to the RADIUS server 530 (the Join Server). These session keys need to be sent to the Network 531 Server and if necessary to the application server. 533 To send the messages over the network between the RADIUS server and 534 the RADIUS client (in this case the Network Server). How to provide 535 confidentiality to the key distributed is outside the scope of this 536 document, nevertheless RadSec (RFC6614) or extensions such as those 537 defined in RFC 6218 may be considered to protect the distribution. 539 The AAA framework and its key management features become increasingly 540 important as the use case of LoRaWAN adds functionality and 541 complexity. This is the case for having the Application Server and 542 Network Server as separate entities and each receive its keys. 543 Although the utility is apparent in that specific case, it has to be 544 considered in any other future use-case that may require key 545 management and key distribution. Another point in favor of using AAA 546 can be also appreciated since the modifications required by this 547 proposal does not imply the modification of the protocols of the 548 constrained link, but the unrestricted network that is used to manage 549 LP-WAN. 551 7. Proof of concept implementation 553 The proof of concept is implemented using the Go programming 554 language, that is well suited for the development of web servers or a 555 network servers as in this case. 557 The implementation of the network server is from [LoRaSERVER] which 558 is tailored with the features of a RADIUS Client and the RADIUS 559 server implementation from [RADIUSGo] that is modified to handle 560 LoRaWAN attributes. 562 The LoRa end-device, pre-configured with AppKey, from Nemeus [MK002] 563 is a USB key that can be controlled by UART (AT command) through USB 564 interface. A JAVA application installed on a Linux machine is used 565 to send control and data messages from the End-Device. 567 The LoRa Gateway is from EXPEMB [EXPEMB] which uses the packet 568 forwarder to forward the LoRa packets to the LoRa Network Server. 569 The Network Server is run in a docker container on a Linux machine 570 transfers the LoRa packets into the RADIUS attributes to be sent to 571 the RADIUS server. For now, the packets are sent to the default 572 RADIUS server but in the future this would be changed as per the 573 discussion in Section 5 in order to redirect the RADIUS request to 574 appropriate RADIUS server. 576 The RADIUS server is run in a docker container on a Linux machine 577 which contains the mapping between the DevEUI of the End-Device and 578 the AppKey. This AppKey from the map along with the received LoRa 579 attributes is used to derive the session keys, NwkSKey and AppSKey, 580 in the RADIUS server. These keys are transported as RADIUS 581 attributes back to the network server. 583 +----------+ +---------+ +-------------+ +---------+ 584 | | | LoRa | | Nwk server/ | | Radius | 585 |End-device+---------+ Gateway +----------+ RADIUS +--------+ Server | 586 | | LoRa | | IP | client | IP | | 587 +----------+ +---------+ +-------------+ +---------+ 589 A successful authentication would result in the session keys, NwkSKey 590 and AppSKey, being visible on the network server that can be viewed 591 using a web interface and the DevAddr being acquired by the End- 592 Device from the Join Accept Lora message. Running Wireshark on the 593 interface between RADIUS server and the Network Server shows the 594 RADIUS packets with the LoRa attributes. 596 To simplify the design and implementation, we opted for creating one 597 RADIUS Attribute per message, instead of per each field within the 598 message since only the authenticating module responsible for the Join 599 Procedure in the current network server is delegated to the AAA 600 server and the AAA server would be able to obtain the required fields 601 from this single attribute, i.e either JoinRequest or JoinAccept 602 message. This design choice would follow the RADIUS guidelines given 603 in [RFC6158] identifying it as string for being an opaque 604 encapsulation of data structures defined outside RADIUS. Creating an 605 attribute per field, would be useful in case the AAA infrastructure 606 would change its behavior depending on the specific content of one or 607 more of the fields contained in the message. This could be the case 608 when the LoRaWAN use case becomes more complex and add more 609 functionality. 611 As future work, we intend to implement the proof of concept in 612 FreeRADIUS 614 8. Acknowledgments 616 This work has been possible partially by the SMARTIE project 617 (FP7-SMARTIE-609062 EU Project) and the Spanish National Project 618 CICYT EDISON (TIN2014-52099-R) granted by the Ministry of Economy and 619 Competitiveness of Spain (including ERDF support). 621 We also wanted to thank for the comments received about this document 622 by Sri Gundavelli, Yeoh Chun-Yeow, Alan DeKok, Stephen Farrell and 623 Mark Grayson. 625 9. IANA Considerations 627 In this document we define 4 new RADIUS Attributes that would need 628 actions from IANA to assign the corresponding numbers. 630 +--------+--------------+----------------------------+ 631 | Number | Name | Reference | 632 +----------------------------------------------------+ 633 | TBD | Join-Request | Section 4 of this document | 634 | TBD | Join-Answer | Section 4 of this document | 635 | TBD | AppSKey | Section 4 of this document | 636 | TBD | NwkSKey | Section 4 of this document | 637 +--------+--------------+----------------------------+ 639 10. References 640 10.1. Normative References 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, 644 DOI 10.17487/RFC2119, March 1997, 645 . 647 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 648 "Remote Authentication Dial In User Service (RADIUS)", 649 RFC 2865, DOI 10.17487/RFC2865, June 2000, 650 . 652 [RFC6158] DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines", 653 BCP 158, RFC 6158, DOI 10.17487/RFC6158, March 2011, 654 . 656 [RFC7043] Abley, J., "Resource Records for EUI-48 and EUI-64 657 Addresses in the DNS", RFC 7043, DOI 10.17487/RFC7043, 658 October 2013, . 660 10.2. Informative References 662 [EXPEMB] EXPEMB, E., "LoRa MultiConnectivity Service Gateway - Last 663 Accessed:", July 2016, . 667 [LoRaAllianceSecurity] 668 Girard, P., "LoRaWAN - SECURITY a comprehensive insight - 669 Online Resource: Last Accessed", July 2016, 670 . 674 [LoRaSERVER] 675 Acklio, A., "LoRa Server", July 2016, 676 . 678 [LoRaWAN] Sornin, N., Luis, M., Eirich, T., and T. Kramp, "LoRa 679 Specification V1.0", January 2015, . 683 [MK002] Nemesus, N., "MK002-xx-EU - Last Accessed:", July 2016, 684 . 686 [RADIUSGo] 687 bronze1man, B., "Radius: A golang radius library - Last 688 Accessed:", July 2016, . 691 Authors' Addresses 693 Dan Garcia-Carrillo (Ed.) 694 University of Murcia 695 Campus de Espinardo S/N, Faculty of Computer Science 696 Murcia 30100 697 Spain 699 Phone: +34 868 88 78 82 700 Email: dan.garcia@um.es 702 Rafa Marin-Lopez 703 University of Murcia 704 Campus de Espinardo S/N, Faculty of Computer Science 705 Murcia 30100 706 Spain 708 Phone: +34 868 88 85 01 709 Email: rafa@um.es 711 Arunprabhu Kandasamy 712 Acklio 713 2bis rue de la Chataigneraie 714 35510 Cesson-Sevigne Cedex 715 France 717 Email: arun@ackl.io 719 Alexander Pelov 720 Acklio 721 2bis rue de la Chataigneraie 722 35510 Cesson-Sevigne Cedex 723 France 725 Email: a@ackl.io