Subject: [lp-wan] drafts AAA in LP-WAN

From: Dan García Carrillo <[email-masked]>
Date: Mon, 30 May 2016 11:47:01 +0200

Dear all,

We have uploaded a couple of drafts to show an initiative towards the integration of AAA infrastructures into LP-WAN. These documents show an example of how the LoRaWAN join procedure can be used with Diameter and RADIUS. 

Comments are welcome and hope this can be a starting point towards the inclusion of AAA infrastructures in the management of authentication and authorization in LP-WAN deployments.

https://datatracker.ietf.org/doc/draft-garcia-dime-diameter-lorawan/
https://datatracker.ietf.org/doc/draft-garcia-radext-radius-lorawan/

Best Regards,
Dan.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 30 May 2016 15:09:27 +0000

Dan,

Good to see this. We worked out similar call flows for AAA integration
internally. 

We clearly want to a separation of AS and NS. In that sense, I¹m not sure
if the AppSKey should be sent back to the NS in Access-Accept. I¹d think
there should be another interface between AAA and AS and potentially the
AppSKey can be delivered as RADIUS CoA, or the AS can download the key
from AAA.

Sri

On 5/30/16, 2:47 AM, "lp-wan on behalf of Dan García Carrillo"
<[email-masked] on behalf of [email-masked]> wrote:

>Dear all,
>
>We have uploaded a couple of drafts to show an initiative towards the
>integration of AAA infrastructures into LP-WAN. These documents show an
>example of how the LoRaWAN join procedure can be used with Diameter and
>RADIUS. 
>
>Comments are welcome and hope this can be a starting point towards the
>inclusion of AAA infrastructures in the management of authentication and
>authorization in LP-WAN deployments.
>
>_______________________________________________
>lp-wan mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/lp-wan

---

From: Dan García Carrillo <[email-masked]>
Date: Mon, 30 May 2016 19:23:57 +0200

Sri, 

Thank you for your comments. 

We agree with what you say about having the possibility of sending the AppSKey to another entity (e.g. AS) through other interfaces. In fact is something that we discussed internally and, as a result of that, we have mentioned in the text that we consider the AppSKey attribute as optional, though it may be needed to be consistent with the LoRaWAN 1.0 Specification. That is something we will clarify in a following version of the I-D to reflect your comments.

Best, 
Dan.

> El 30 may 2016, a las 17:09, Sri Gundavelli (sgundave) <[email-masked]> escribió:
> 
> Dan,
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 30 May 2016 18:19:14 +0000

Hi Dan,

These interfaces towards AAA should not have any impact on the LoRa
specification. Either for OTA/AAA, the aspect of key generation/management
can be decoupled from the NS/AS function and without impacting the base
call flows. BTW, to most part the LoRa specification should have very
little influence/impact on these interfaces such as this with AAA, gateway
management or some of these topics that IETF can work on.

BTW, DIME WG may have a view on this.

Regards
Sri

On 5/30/16, 10:23 AM, "Dan García Carrillo" <[email-masked]> wrote:

>We agree with what you say about having the possibility of sending the
>AppSKey to another entity (e.g. AS) through other interfaces. In fact is
>something that we discussed internally and, as a result of that, we have
>mentioned in the text that we consider the AppSKey attribute as optional,
>though it may be needed to be consistent with the LoRaWAN 1.0
>Specification. That is something we will clarify in a following version
>of the I-D to reflect your comments.
>
>Best, 
>Dan.
>
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 30 May 2016 18:21:08 +0000

OTA/AAA —> OTA/ABP …

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 30 May 2016 19:07:39 +0000

Regarding "AAA specifications should not have an impact on the LoRa specifications"

That's true when the authors of the LoRa specification have considered the use of AAA upfront. You can see how RADIUS impacted the front-end with the WiFi specs.

Ciao
Hannes

-----Original Message-----
From: lp-wan [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: 30 May 2016 20:19
To: Dan García Carrillo
Cc: [email-masked]
Subject: Re: [lp-wan] drafts AAA in LP-WAN

Hi Dan,

These interfaces towards AAA should not have any impact on the LoRa specification. Either for OTA/AAA, the aspect of key generation/management can be decoupled from the NS/AS function and without impacting the base call flows. BTW, to most part the LoRa specification should have very little influence/impact on these interfaces such as this with AAA, gateway management or some of these topics that IETF can work on.

Regards
Sri

On 5/30/16, 10:23 AM, "Dan García Carrillo" <[email-masked]> wrote:

>AppSKey to another entity (e.g. AS) through other interfaces. In fact
>is something that we discussed internally and, as a result of that, we
>have mentioned in the text that we consider the AppSKey attribute as
>optional, though it may be needed to be consistent with the LoRaWAN 1.0
>> Good to see this. We worked out similar call flows for AAA
>> integration internally.
>>
>> We clearly want to a separation of AS and NS. In that sense, I¹m not
>>sure  if the AppSKey should be sent back to the NS in Access-Accept.
>>I¹d think  there should be another interface between AAA and AS and
>>potentially the  AppSKey can be delivered as RADIUS CoA, or the AS can
>>download the key  from AAA.
>>
>>
>> Sri
>>
>>
>>
>>
>>
>>> We have uploaded a couple of drafts to show an initiative towards
>>> the integration of AAA infrastructures into LP-WAN. These documents
>>> show an example of how the LoRaWAN join procedure can be used with
>>> Diameter and RADIUS.
>>>
>>> Comments are welcome and hope this can be a starting point towards
>>>the  inclusion of AAA infrastructures in the management of
>>>authentication and  authorization in LP-WAN deployments.
>>>

_______________________________________________
lp-wan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lp-wan
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 30 May 2016 19:21:28 +0000

Or that is by accident? :) …  initial version did not allow the NS/AS or a
clean transport/App key separation; spec is getting better now ..

On 5/30/16, 12:07 PM, "Hannes Tschofenig" <[email-masked]>
wrote:

>That's true when the authors of the LoRa specification have considered
>the use of AAA upfront. You can see how RADIUS impacted the front-end
>with the WiFi specs.
>
>Ciao
>Hannes
>
>
>specification. Either for OTA/AAA, the aspect of key
>generation/management can be decoupled from the NS/AS function and
>without impacting the base call flows. BTW, to most part the LoRa
>specification should have very little influence/impact on these
>interfaces such as this with AAA, gateway management or some of these
>topics that IETF can work on.
>
>IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended
>recipient, please notify the sender immediately and do not disclose the
>contents to any other person, use it for any purpose, or store or copy
>the information in any medium. Thank you.

---

From: Yeoh Chun-Yeow <[email-masked]>
Date: Wed, 1 Jun 2016 00:00:44 +0800

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

RADIUS server is used as a Join Server. But the sentence said that
"the Application Server is called a Join Server" seems to be
misleading.

----
Chun-Yeow

---

From: Arun <[email-masked]>
Date: Tue, 31 May 2016 18:37:58 +0200

Hi Chun-Yeow,

Thanks for your feedback on this. In the LoRaWAN specification you have the Network Server talking to Application Servers. During the join process the NS is using a particular type of Application Server - a server that we could call the "Join Server". 

This is, of course, a question of terminology. I suppose that this should change when the next version of the LoRaWAN specification gets out. 

Do you think that it would be more readable to simply call it the Join Server? Or maybe rephrase the paragraph, so that it is more explicit?

- Arun

---

From: Yeoh Chun-Yeow <[email-masked]>
Date: Wed, 1 Jun 2016 00:55:59 +0800

Refer here:
http://portal.lora-alliance.org/DesktopModules/Inventures_Document/FileDownload.aspx?ContentID=1085

In LoRaWAN specification, the terminology given here is End devices,
Gateway, Network Server and Application Server.

Application server is the one handling the user data while network
server is the one used during the join procedure to accept an end
device to the network. In slide 19, the join server is introduced as
the one accepting an end device to the network.

So I assume that application server that you mentioned here should be
instead the network server.

---
Chun-Yeow

---

From: Alexander Pelov <[email-masked]>
Date: Tue, 31 May 2016 22:21:57 +0200

Dear Chun-Yeow,

In the current specification you’ll have an Application Server perform the join procedure and provide the keys to the Network Server. This is where we provide a way of performing this interaction through RADIUS/Diameter.

The goal of these drafts is to outline the necessity of having a AAA infrastructure for LP-WANs and to provide a simple mapping of the current spec (in this case LoraWAN) to some existing protocols (RADIUS/Diameter). 

Best,
Alexander

> Le 31 mai 2016 à 18:55, Yeoh Chun-Yeow <[email-masked]> a écrit :
> 
> Refer here:

---

From: Yeoh Chun-Yeow <[email-masked]>
Date: Wed, 1 Jun 2016 09:47:10 +0800

Since it is trying to map to the current LoRaWAN spec, perhaps
clarification on the terminology as according to the spec is the best
way to move forward.

---
Chun-Yeow