Dear Rafa,
Thanks for the comments! Please, see inline.
Le 13/07/2015 00:38, Rafa Marin Lopez a écrit :
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?
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".
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?
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.
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?
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.
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?
Yes, you are correct.
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.
Thanks for catching this!
Hope this helps.
Best Regards.
Thanks a lot for your remarks!
Best,
Alexander
El 06/07/2015, a las 17:27, Alexander Pelov <[email protected]> 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 protected]
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 protected]
-------------------------------------------------------
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
