Dear all, In our proposal for managing long-range radio networks with CoAP ( https://tools.ietf.org/html/draft-pelov-core-cosol-00 <https://tools.ietf.org/html/draft-pelov-core-cosol-00> ) we’re using EAP-over-CoAP. The use of CoAP as signaling protocol, makes it natural to go to this solution, as this way we can reuse the whole EAP framework that’s already in place.
Afterwards, you could use of your choosing either EAP-PSK or any other mechanism which would be deemed fit (e.g. certificates, USIM cards, …). EAP is already used for authentication and authorization in WiFI with WPA/WPA2, WiMax (maybe not the best example..), UMTS, LTE, … and for me is one of the few truly extensible ways for doing it (I’m still looking at OAuth for that, but for me the two are complementary solutions). I’m sorry to have been absent in the last conf call, but if you want we can discuss this in the next one. Best, Alexander > Le 7 sept. 2015 à 09:41, Giuseppe Piro <[email protected]> a écrit : > > Dear all, > > I'm trying to capture assumptions and goals related to the join process, as > discussed during the latest conf call. It is just to verify that everything > is clear in my mind :-) > > Please, reply and correct me if I'm wrong. > > > Initial assumptions: > - all nodes known K1. > - each node shares a PSK with the JCE. It is used for authentication purposes > during the join process. > - the join process is handled at the aplication layer through COAP. A message > is sent by the JN, forwarded by the JE and processed by the JCE. > - if the JN is authenticated by the JCE, the JCE sends the K2 (stored and > encrypted with the aforementione PSK in a COAP message). > - JN processes the received COAP message and installs K2. > > Main open issues: > - messages exchanged between JN and JA must be "protected". For the moment we > can assume to use K1. > - JA does not know JN; it does not have the corresponding Device Descriptor > for JN; it must implemnet a procedure for understanding if the join message > should be forwarded or not (protection against DoS ? ). > - the format of join packets should be defined. Input from COSE. The first > packet sent by JN should also contain the ASN (of course, also this field is > protected by the PSK). This should avoid replay attacks. > - definition of mechanisms for installing K2 in JN. > - the distribution of link layer keys is another problem. Two possibilities: > centralized (JCE distribute keys) or distributed (KMP). SHould we define > procedures/message formats for both of them ? > > Possible extensions: > - substitute PSK with certificates . > > > > > Starting from these premises, it seems that the main action points to target > for the moment are: > - definition of join packets along side COSE inputs > - procedures to implement at the JA side, i.e., before forwarding the join > packet towards the JCE > > > Does it make sense ? > > All the best > Giuseppe > > > -- > Giuseppe Piro, PhD > Post Doc Researcher > DEI, Politecnico di Bari > via Orabona 4 - 70125 (Bari), Italy. > email: [email protected] <mailto:[email protected]> > phone: +39 080 5963301 > web: g <http://telematics.poliba.it/piro>iuseppepiro.com > <http://iuseppepiro.com/>_______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
