Subject: [T2TRG] Annoncement draft-pelov-core-cosol-00

From: Alexander Pelov <[email-masked]>
Date: Mon, 6 Jul 2015 17:27:59 +0200

Dear all,

I'd like to bring to your attention a new document, which was submitted 
this weekend: draft-pelov-core-cosol-00

It presents a new type of far-reaching, low-rate radio technologies 
(such as Semtech LoRa and SigFox) and an extensible mechanism to operate 
these networks based on CoAP.  We document the way REST can be used to 
manage these networks.

You can find the current text at the following address: 
https://tools.ietf.org/html/draft-pelov-core-cosol-00

We would be happy to discuss with anyone interested the contents of the 
draft and the possible future works on it. Also, we will be glad if 
there is any possibility to present even briefly during a session.

Best,
Alexander

---

From: Rafa Marin Lopez <[email-masked]>
Date: Mon, 13 Jul 2015 00:38:35 +0200

Hi Alexander 

This is interesting work and use case. 

Some comments:

"It can be used during all stages of the lifecycle of the network,
   e.g. discovery, authentication, operation. " --> Basically authentication is based on DTLS... is that what you mean?

Figure 3 says associated then authenticated but in the text is different authenticated -> associated

In semi-associated state you mention: "In that state, the Node-F broadcasts frames, handled by the Node-G,
   but the network cannot join the Node-F on a regular basis." What do you mean? The node-G cannot contact node-F? 

In section 3.3.1:

"The frames SHOULD be signed,
   so that they could be authenticated by the network." This signing process is before the authentication and key management. How is it possible to sign the frames? Any pre-shared key?

In fact, you say:

"and enough information for the Node-G to
   authenticate the message sender.  This can be achieved through a
   Confirmable CoAP message, where the user data are POSTed to a well-
   known resource defined on the Node-G.  DTLS with integrity check can
   be used, with long-lived keys negotiated by the Node-F and the
   network."

DTLS is established for protection (Confirmable CoAP message does not achieve authentication by itself). Again, if DTLS is used and those messages are authenticated, why do you need authentication phase?

In section 3.3.3:

"For example, it may provide the AAA server, which could authenticate
   the Node-F, or its EAP-Identity. " --> Assuming that an AAA infrastructure is used for authentication ( I think that assumption should be expressed in the document), typically Node G will have the AAA client and, actually, it does not need to know the IP address of the AAA server that authenticates the node F, just the next hop AAA server. On the other hand, Node G will not typically provide the EAP identity, are you referring to that?

In section 3.3.4 

The reference to EAP-over-CoAP is https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-01 and not [I-D.garcia-core-security] where the general problem of bootstrapping is explained. 

Hope this helps.

Best Regards.

El 06/07/2015, a las 17:27, Alexander Pelov <[email-masked]> escribió:

> Dear all,
> 
> I'd like to bring to your attention a new document, which was submitted this weekend: draft-pelov-core-cosol-00
> 
> It presents a new type of far-reaching, low-rate radio technologies (such as Semtech LoRa and SigFox) and an extensible mechanism to operate these networks based on CoAP.  We document the way REST can be used to manage these networks.
> 
> You can find the current text at the following address: https://tools.ietf.org/html/draft-pelov-core-cosol-00
> 
> We would be happy to discuss with anyone interested the contents of the draft and the possible future works on it. Also, we will be glad if there is any possibility to present even briefly during a session.
> 
> Best,
> Alexander
> 
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

-------------------------------------------------------
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: Alexander Pelov <[email-masked]>
Date: Mon, 13 Jul 2015 22:25:14 +0200

Dear Rafa,

Thanks for the comments! Please, see inline.

>     e.g. discovery, authentication, operation. " --> Basically authentication is based on DTLS... is that what you mean?
Actually, here we are referring to the use of your draft - EAP-over-CoAP 
- for the authentication. Upon authentication, the exchanges may be 
protected with DTLS (which uses the MSK generated after the EAP 
exchanges), or with the AUTH option you are proposing. I think that this 
should be the recommended way to do authentication in LRWANs.

However, one can imagine having DTLS negotiation (e.g. with PSK), but 
this seems less flexible and appropriate for this types of networks.

What do you think?

> Figure 3 says associated then authenticated but in the text is different authenticated -> associated
That's a typo. Thanks for catching that - the text is correct, the 
schema is wrong. It should be "authenticated -> associated".

>     but the network cannot join the Node-F on a regular basis." What do you mean? The node-G cannot contact node-F?
The goal behind the semi-associated state is that there are some network 
operators that rely heavily on uni-directional traffic (node-F to 
node-G). Also, there are services which can be implemented in that way 
(e.g. tracking goods). There CAN be L2 interaction (e.g. L2 ACK), or in 
some cases even CoAP ACK, but that is not a necessary condition for many 
applications.

To sum up, the case to imagine is a device, which wakes up periodically, 
and without checking any connectivity or other types of information, 
sends a message to the network, after which it sleeps again. If there is 
a network present, and a node-G willing to process the message, then 
everything works.

I strongly believe that this behavior should be managed carefully (e.g. 
a node-F MUST send a CoAP CONfirmable message every N messages), giving 
the opportunity to the network to actually interact with the node-F from 
time to time.

Once again, this is a real-world operation scheme of an IoT network 
operator.
> DTLS is established for protection (Confirmable CoAP message does not achieve authentication by itself). Again, if DTLS is used and those messages are authenticated, why do you need authentication…
Here I think that one of the transitions in Figure 3 is making the 
things more complex than it should (and is causing a lot of questions). 
The Disconnected -> Semi-associated state should be removed. The 
reasoning behind is, that the device (node-F) MUST authenticate at least 
once to the network before entering the semi-associated state. This way, 
there is a secure association between the network and the node-F. The 
node-F can then sleep for (very) long periods, wake up, and send a 
signed message to the network.

The tricky part is that in the mean time the node-F could have moved and 
could be located in a different part of the network, e.g. located under 
a different node-G. For that reason, the sent message should contain 
enough information, so that a node-G receiving a signer CoAP message 
could determine the secure association (e.g. to which other node-G in 
the network it is associated), and forward the message. Note that it may 
be appropriate to use Constrained Object Signing and Encryption (COSE), 
instead (in addition of) DTLS.

>     the Node-F, or its EAP-Identity. " --> Assuming that an AAA infrastructure is used for authentication ( I think that assumption should be expressed in the document), typically Node G will have…
Yes, you are correct.

> The reference to EAP-over-CoAP is https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-01 and not [I-D.garcia-core-security] where the general problem of bootstrapping is explained.
Thanks for catching this!

> Best Regards.
Thanks a lot for your remarks!

Best,
Alexander

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 15 Jul 2015 20:03:54 +0200

Dear Alexander:

Thanks for your answers.

El 13/07/2015, a las 22:25, Alexander Pelov <[email-masked]> escribió:

> Actually, here we are referring to the use of your draft - EAP-over-CoAP - for the authentication. Upon authentication, the exchanges may be protected with DTLS (which uses the MSK generated after the EAP exchanges), or with the AUTH option you are proposing. I think that this should be the recommended way to do authentication in LRWANs.

[Rafa] So, in the end, the authentication is NOT with DTLS but to secure the path between the Node-F and Node-G

> 
> However, one can imagine having DTLS negotiation (e.g. with PSK), but this seems less flexible and appropriate for this types of networks.

[Rafa] Right, that is also possible but it is definitely less scalable 

> That's a typo. Thanks for catching that - the text is correct, the schema is wrong. It should be "authenticated -> associated".
> 
>> 
> The goal behind the semi-associated state is that there are some network operators that rely heavily on uni-directional traffic (node-F to node-G). Also, there are services which can be implemented in that way (e.g. tracking goods). There CAN be L2 interaction (e.g. L2 ACK), or in some cases even CoAP ACK, but that is not a necessary condition for many applications.
> 
> To sum up, the case to imagine is a device, which wakes up periodically, and without checking any connectivity or other types of information, sends a message to the network, after which it sleeps again. If there is a network present, and a node-G willing to process the message, then everything works.
> 
> I strongly believe that this behavior should be managed carefully (e.g. a node-F MUST send a CoAP CONfirmable message every N messages), giving the opportunity to the network to actually interact with the node-F from time to time.
> 
> Once again, this is a real-world operation scheme of an IoT network operator.

[Rafa] Understood now.

> Here I think that one of the transitions in Figure 3 is making the things more complex than it should (and is causing a lot of questions). The Disconnected -> Semi-associated state should be removed. The reasoning behind is, that the device (node-F) MUST authenticate at least once to the network before entering the semi-associated state. This way, there is a secure association between the network and the node-F. The node-F can then sleep for (very) long periods, wake up, and send a signed message to the network.

[Rafa] Ok, so after all, a semi-associated and associated should in the same side of the state machine. That is: authenticated -> (semi-)associated

> 
> The tricky part is that in the mean time the node-F could have moved and could be located in a different part of the network, e.g. located under a different node-G. For that reason, the sent message should contain enough information, so that a node-G receiving a signer CoAP message could determine the secure association (e.g. to which other node-G in the network it is associated), and forward the message. Note that it may be appropriate to use Constrained Object Signing and Encryption (COSE), instead (in addition of) DTLS.

[Rafa] What you describe here it is a problem that involves an inter-authenticator (each Node-G acts as authenticator) "handoff" and the problem of building the security association with the node-G without running the full authentication from the scratch, correct? 

Best Regards.