Subject: Re: [radext] LoRaWAN Authentication in RADIUS

From: Stefan Winter <[email-masked]>
Date: Fri, 24 Jun 2016 09:22:43 +0200

Hello,

> Thank you for taking the time to review the I-D, your comments are very valuable indeed and we will provide a more precise version based on your comments.

Just a reminder: if you want to present about this topic at IETF96, it
would be good to have this revised draft out before the draft submission
deadline (which is 08 July).

Also plesae do signal whether you want a talking slot at IETF96 or not.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Jun 2016 09:35:00 +0100

(No hats, I've been reading a bit about LoRa recently...)

On 24/06/16 08:22, Stefan Winter wrote:
> Hello,
> 
>> Thank you for taking the time to review the I-D, your comments are
>> very valuable indeed and we will provide a more precise version
>> based on your comments.
> 
> Just a reminder: if you want to present about this topic at IETF96,
> it would be good to have this revised draft out before the draft
> submission deadline (which is 08 July).

I'd be interested in knowing how, in figure 2, the radius client
finds the right radius server. If that's suggested to use the
AppEUI, then a) ick, and b) I don't see how that would scale, if
we assume many networks and many applications.

I also think that the draft ought explain the various keys involved
and their uses. Not in the full detail that's in the LoRa spec
but enough so that a reader of this can understand the consequences
of handling the keys like this - which wasn't clear to me.

And I'd second Alan's comments too, but would note that at least
from my POV, it's entirely fine and to be expected that a -00
about a technology not previously seen at the IETF needs plenty
of work, and we should be trying to help the authors if we can.

Cheers,
S.

> _______________________________________________ radext mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/radext
>

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 27 Jun 2016 10:30:26 +0200

Dear Stefan:

We are working on the revised version. One of our co-authors will be in Berlin so we can present it. Thank you. 

Best Regards.

> El 24 jun 2016, a las 9:22, Stefan Winter <[email-masked]> escribió:
> 
> Hello,
> 
> <0x8A39DC66.asc>_______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 27 Jun 2016 11:02:07 +0200

Dear Stephen

Thank you for reading our I-D. Please see some comments inline.
> El 24 jun 2016, a las 10:35, Stephen Farrell <[email-masked]> escribió:
> 
> 

This is an important question. In fact, we have already discussed this internally after some related comments we have received. 

According to LoRaWAN 	

"The AppEUI is a global application ID in IEEE EUI64 address space that uniquely identifies the application provider (i.e., owner) of the end-device.”

 As far as I can see it, those should provide a good amount of potential owners. But that limitation is imposed by the specification in any case. Having said that, regarding the right radius server, it seems that some kind of mapping or discovery between an EUI64 identifier and a FQDN is required. One possible solution is using DNS (https://tools.ietf.org/html/rfc7043). In my opinion, that RFC is something similar what we are looking for. 

what do you think?

> of handling the keys like this - which wasn't clear to me.

Point taken, thanks. We will update the I-D accordingly.

> of work, and we should be trying to help the authors if we can.

Yes, we hope next version will be more detailed.

Best Regards.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jun 2016 10:42:32 +0100

Hiya,

On 27/06/16 10:02, Rafa Marin Lopez wrote:
>>>> Thank you for taking the time to review the I-D, your comments
>>>> are very valuable indeed and we will provide a more precise
>>>> version based on your comments.
>>> 
>>> Just a reminder: if you want to present about this topic at
>>> IETF96, it would be good to have this revised draft out before
>>> the draft submission deadline (which is 08 July).
>> 
>> AppEUI, then a) ick, and b) I don't see how that would scale, if we
>> assume many networks and many applications.
> 
> This is an important question. In fact, we have already discussed
> this internally after some related comments we have received.
> 
> According to LoRaWAN
> 
> "The AppEUI is a global application ID in IEEE EUI64 address space
> that uniquely identifies the application provider (i.e., owner) of
> the end-device.”

Right - ISTM odd to assume that the application provider is the owner
of the device, so I don't know how that will pan out, at scale.

> 
> As far as I can see it, those should provide a good amount of
> potential owners. But that limitation is imposed by the specification
> in any case. 

Perhaps that's something that needs revisiting in the LoRA specs
as those evolve.

> Having said that, regarding the right radius server, it
> seems that some kind of mapping or discovery between an EUI64
> identifier and a FQDN is required. One possible solution is using DNS
> (https://tools.ietf.org/html/rfc7043). In my opinion, that RFC is
> something similar what we are looking for.
> 
> what do you think?

While that RR might syntactically work, I'm not at all sure
that every AppEUI can map to a unique FQDN via the DNS. That
RFC also says that it's really for "private DNS namespaces"
which isn't what you're after here I think.

ISTM that LoRa really needs some kind of domain identifier
(that can map to a dns name) in the deployed device for this
stuff to be able to scale well. (And as you say, that's not
currently part of the LoRa protocol.)

I'd also not be surprised if other uses of LoRa also had a
similar need for an identifier that allows routing of some
sort. (And that'd maybe have to be MAC'd using the application
keys or something.)

Cheers,
S.

> 
>> 
>> I also think that the draft ought explain the various keys
>> involved and their uses. Not in the full detail that's in the LoRa
>> spec but enough so that a reader of this can understand the
>> consequences of handling the keys like this - which wasn't clear to
>> me.
> 
>> from my POV, it's entirely fine and to be expected that a -00 about
>> a technology not previously seen at the IETF needs plenty of work,
>> and we should be trying to help the authors if we can.
> 
>> Cheers, S.
>>> _______________________________________________ radext mailing
>>> list [email-masked]
>> _______________________________________________ radext mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/radext
> 
> ------------------------------------------------------- Rafael Marin
> Lopez, PhD Dept. Information and Communications Engineering (DIIC) 
> Faculty of Computer Science-University of Murcia 30100 Murcia -
> Spain Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]