idnits 2.17.1 draft-garcia-dime-diameter-lorawan-00.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 3 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 30, 2016) is 2887 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'MIC' is mentioned on line 246, 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 Diameter Maintenance and Extensions (DIME) D. Garcia 3 Internet-Draft R. Marin 4 Intended status: Experimental University of Murcia 5 Expires: December 1, 2016 A. Kandasamy 6 A. Pelov 7 Acklio 8 May 30, 2016 10 LoRaWAN Authentication in Diameter 11 draft-garcia-dime-diameter-lorawan-00 13 Abstract 15 This document describes a proposal for a Diameter LoRaWAN 16 Application. The purpose is to integrate the LoRaWAN network join 17 procedure with an Authentication, Authorization and Accounting (AAA) 18 infrastructure based on Diameter. 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 December 1, 2016. 37 Copyright Notice 39 Copyright (c) 2016 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 Diameter . . . . . . . . . . . . . . . . . 4 57 3. LoRaWAN joining procedure . . . . . . . . . . . . . . . . . . 4 58 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Protocol Assumptions . . . . . . . . . . . . . . . . . . 5 60 4.2. Protocol Exchange . . . . . . . . . . . . . . . . . . . . 5 61 4.2.1. Join-Request AVP . . . . . . . . . . . . . . . . . . 6 62 4.2.2. Join-Answer AVP . . . . . . . . . . . . . . . . . . . 6 63 4.2.3. AppSKey AVP . . . . . . . . . . . . . . . . . . . . . 6 64 4.2.4. NwkSKey AVP . . . . . . . . . . . . . . . . . . . . . 6 65 5. Diameter-Radius Interaction . . . . . . . . . . . . . . . . . 7 66 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 9.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 Low Power Wide Area Network (LP-WAN) groups several radio 77 technologies that allow communications with nodes far from the 78 central communication endpoint (base station) in the range of 79 kilometers depending on the specifics of the technology and the 80 scenario. They are fairly recent and the protocols to manage those 81 infrastructures are in continuous development. In some cases they 82 may not consider aspects such as key management or directly tackle 83 scalability issue in terms of authentication and authorization. The 84 nodes to be authenticated and authorized is expected to be 85 considerably high in number. One of the protocols that provide a 86 complete solution is LoRaWAN [LoRaWAN]. LoRaWAN is a MAC layer 87 protocol that use LoRa as its physical medium to cover long range 88 (up-to 20km depending on the environment) devices. LoRaWAN is 89 designed for large scale networks and currently has a central entity 90 called network server which maintains a pre-configured key named 91 AppKey for each of the devices on the network. Furthermore, session 92 keys such as NwkSKey and AppSKey used for encryption of data 93 messages, are derived with the help of this AppKey. Since each 94 service provider would operate their network server individually, 95 authenticating the devices becomes a tedious process because of 96 inter-interoperability or the roaming challenges between the 97 operators. As we know the AAA infrastructure provides a flexible, 98 scalable solution. They offer an opportunity to manage all these 99 proceses in a centralized manner as happens in other type of networks 100 (e.g. cellular, wifi, etc...) making it an interesting asset when 101 integrated into the LoRaWAN architecture. 103 +-------+ +-------+ +--------+ 104 +------+ | | | | | | 105 | +--(LoRa)--+ +--(IP)--+ +-----(IP)-----+ | 106 +------+ | | | | | | 107 +-------+ +-------+ +--------+ 108 End-Device Gateway Network Application 109 Server Server 111 Figure 1: LoRAWAN Architecture 113 The End-Device communicates with the Gateway by using the LoRa 114 modulation. The Gateway acts as a simple transceiver, which forwards 115 all data do the Network Server, which performs the processing of the 116 frames, network frame authentication (MIC verification), and which 117 serves as Network Access Port. The Application Server can be 118 handling user data OR can be used during the join procedure to accept 119 an End-Node to the network. In this case, the Application Server is 120 called a Join Server. This document describes a way to use standard 121 Diameter servers as a Join Server, and to use the Diameter protocol 122 for the interaction between the Network Server and the Application 123 Server. 125 +-------+ +-------+ +--------+ 126 +------+ | | | | | | 127 |AppKey+--(LoRa)--+ +--(IP)--+ +--(Diameter)--+ AppKey | 128 +------+ | | | | | | 129 +-------+ +-------+ +--------+ 130 End-Device Gateway Network Diameter 131 Server Server 132 (+ Diameter client) 134 Figure 2: LoRAWAN Architecture with AAA and Diameter authentication. 135 End-Device and Diameter server have a shared secret - the AppKey, 136 which is used to derive the session keys (NwkSKey and AppSKey). 138 The document describes how LoRaWAN join procedure is integrated with 139 AAA infrastructure using Diameter [RFC7155] by defining the new AVPs 140 needed to support the LoRaWAN exchange. 142 1.1. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 2. LoRaWAN support in Diameter 150 Regarding the overall functionality, the Diameter LoRaWAN Application 151 relies on [RFC7155] , and defines new Command-Codes and Attribute- 152 Value. Diameter nodes that intend to support this specification MUST 153 advertise its support by including the Diameter LoRaWAN Application 154 ID (TBD.) in the AUTH-Application-Id AVP of the Capabilities- 155 Exchange-Request and the Capabilities-Exchange-Answer command 156 [RFC6733]. If the NAS receives a response with the Result-Code set 157 to DIAMETER_APPLICATION_UNSUPPORTED [RFC6733] , it indicates that the 158 Diameter server in the home realm does not support the LoRaWAN join 159 procedure. The NAS-Port-Type specifying the type of port on which 160 the NAS is authenticating the end-device in this case MAY be 18 ( 161 Wireless - Other ) or a new one specifically assigned for LoRaWAN 162 (TBD.). 164 3. LoRaWAN joining procedure 166 The LoRaWAN joining procedure as described in the LoRaWAN 167 Specification 1.0 [LoRaWAN] consists on one exchange. The first 168 message of this exchange is called join-request (JR) message and is 169 sent from the end-device to the network-server containing the AppEUI 170 and DevEUI of the end-device with additionally a nonce of 2 octets 171 called DevNonce. See Figure 3 173 +-------------+-------------+-------------+ 174 Size (bytes) | 8 | 8 | 2 | 175 +---------------------------+-------------+-------------+ 176 Join Request | AppEUI | DevEUI | DevNonce | 177 +-------------+-------------+-------------+ 179 Figure 3: Join Request Message 181 In response to the join-request, the other endpoint will answer with 182 the join-accept (JA) (Figure 4) if the end-device is successfully 183 authenticated and authorized to join the network. The join-accept 184 contains a nonce (AppNonce), a network identifier (NetID), an end- 185 device address (DevAddr), a delay between the TX and RX (RxDelay) 186 and, optionally, the CFList (see LoRaWAN specification [LoRaWAN] 187 section 7). 189 +--------+-----+-------+----------+-------+-------------+ 190 Size (bytes)| 3 | 3 | 4 | 1 | 1 |16 (Optional)| 191 +-------------------------------------------------------------------+ 192 Join Accept |AppNonce|NetID|DevAddr|DLSettings|RxDelay| CFList | 193 +--------+-----+-------+----------+-------+-------------+ 195 Figure 4: Join Accept Message 197 4. Protocol Overview 199 4.1. Protocol Assumptions 201 For the proposal of Diameter LoRaWAN Application next we describe 202 some assumptions regarding the LoRaWAN specification. The first is 203 that the AppKey is only shared between the AAA server and the end- 204 device. The outcome of the successful join procedure (i.e. NwkSKey 205 and AppSKey) are sent from the AAA server to the network-server. 206 This allows for the end-device to exchange message with the network- 207 server, once the join procedure is finished, as specified in LoRaWAN 208 [LoRaWAN]. 210 4.2. Protocol Exchange 212 The join procedure between the end-device and the network-server 213 entails one exchange consisting on a join-request message and a join- 214 response message. In Diameter-LoRaWAN the network-server implements 215 a Diameter client to communicate with the AAA Server. Upon reception 216 of the LoRaWAN join-request message, the network-server creates a 217 Diameter-LoRaWAN-Request, with the Join-Request AVP containing the 218 original message from the end-device, and the Join-Answer AVP with 219 all the fields, except for the MIC that will be calculated by the AAA 220 Server, since is the one that holds the AppKey. Once the AAA Server 221 authenticates and authorizes the end-device, sends back the Join- 222 Answer with the MIC generated as specified by the LoRaWAN 223 specification. Furthermore, as a consequence of a successful join 224 procedure, the AppSKey (optional) and NwkSKey are generated and sent 225 along in AppSKey AVP and NwkSKey respectively. The NAS receives the 226 Diameter-LoRaWAN-Answer, obtains the content of the Join-Request AVP 227 and sends it to the end-device, storing in association with that end- 228 device the NwSKey and the AppSKey. 230 network-server AAA 231 end-device (NAS) Server 232 ----------- --------- ------- 233 | | | 234 | JR[MIC] | Diameter-LoRaWAN-Request | 235 |------------------------>| Join-Request AVP | 236 | | Join-Answer AVP* | 237 | |----------------------------------->| 238 | | | 239 | gen | | gen 240 | | | Diameter-LoRaWAN-Answer | | 241 | | | Result-Code=DIAMETER_SUCCESS | | 242 | v | Join-Answer AVP | v 243 | AppSKey | AppSKey AVP* | AppSKey 244 | NwkSKey | NwSKey AVP | NwkSKey 245 | |<-----------------------------------| 246 | JA[MIC] | | 247 |<------------------------| | 248 | | | 250 Figure 5: Protocol 252 4.2.1. Join-Request AVP 254 This AVP contains the original Join-Request message. This AVP will 255 only be present in the Diameter-LoRaWAN-Request. 257 4.2.2. Join-Answer AVP 259 This AVP is used in both Diameter-LoRaWAN-Request and Diameter- 260 LoRaWAN-Response messages. In the first case it contains the Join 261 Answer message with all the needed values by the network-server so 262 the AAA server that holds the AppKey is able to create the MIC, that 263 in this case is not present (marked with an *). In the second case, 264 it contains the message with the MIC generated by the AAA server. 266 4.2.3. AppSKey AVP 268 This AVP contains the AppSKey, an application session key specific 269 for the end-device. This AVP will only be present in the Diameter- 270 LoRaWAN-Response and its optional. 272 4.2.4. NwkSKey AVP 274 This AVP contains the NwkSKey, an network session key specific for 275 the end-device. This AVP will only be present in the Diameter- 276 LoRaWAN-Response. 278 5. Diameter-Radius Interaction 280 TBD. 282 6. Acknowledgments 284 This work has been possible partially by the SMARTIE project 285 (FP7-SMARTIE-609062 EU Project) and the Spanish National Project 286 CICYT EDISON (TIN2014-52099-R) granted by the Ministry of Economy and 287 Competitiveness of Spain (including ERDF support). 289 7. Security Considerations 291 TBD. 293 8. IANA Considerations 295 This document has no actions for IANA. 297 9. References 299 9.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, 303 DOI 10.17487/RFC2119, March 1997, 304 . 306 [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 307 Ed., "Diameter Base Protocol", RFC 6733, 308 DOI 10.17487/RFC6733, October 2012, 309 . 311 [RFC7155] Zorn, G., Ed., "Diameter Network Access Server 312 Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, 313 . 315 9.2. Informative References 317 [LoRaWAN] Sornin, N., Luis, M., Eirich, T., and T. Kramp, "LoRa 318 Specification V1.0", January 2015, . 321 Authors' Addresses 322 Dan Garcia Carrillo (Ed.) 323 University of Murcia 324 Campus de Espinardo S/N, Faculty of Computer Science 325 Murcia 30100 326 Spain 328 Phone: +34 868 88 78 82 329 Email: dan.garcia@um.es 331 Rafa Marin-Lopez 332 University of Murcia 333 Campus de Espinardo S/N, Faculty of Computer Science 334 Murcia 30100 335 Spain 337 Phone: +34 868 88 85 01 338 Email: rafa@um.es 340 Arunprabhu Kandasamy 341 Acklio 342 2bis rue de la Chataigneraie 343 35510 Cesson-Sevigne Cedex 344 France 346 Email: arun@ackl.io 348 Alexander Pelov 349 Acklio 350 2bis rue de la Chataigneraie 351 35510 Cesson-Sevigne Cedex 352 France 354 Email: a@ackl.io