Dear Alexander: Thanks for your answers.
El 13/07/2015, a las 22:25, Alexander Pelov <[email protected]> escribió: > 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. [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 > > 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. [Rafa] Understood now. >> >> 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. [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. > >> >> 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 ------------------------------------------------------- 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
