Hello Malisa, just another little consideration.
In the case we would still consider PSK + COSE for handling the join procedure at the application layer, can we introduce a pre-join phase between JN and JA, useful for authenticating JN locally ? It can be done by 6top, for example. Some possibilities may exist. - JN sends a certificate. JA knowns that CA and verifies the certificate. Then JA assists JN in the join process. - JN sends a certificate. JA does not known that CA and it cannot verify the certificate. JA may be configured for running different behaviors (i.e., accept the request and postpone the authentication to the JCE; discard the join request, ... other ? ) - JN does not have a certificate. JA may follow the same decisions as in the previous point. - other ? Hence, we may have join procedure at the application layer (COSE) and a pre-join process at the MAC/6top layer. Does it make sense ? Giuseppe On Fri, Sep 11, 2015 at 2:28 PM, Giuseppe Piro <[email protected]> wrote: > Hello Malisa, > > The traffic load generated during the join process could be an > important aspect to consider. Thanks for the mail. > > However, if you use only PSK + COSE, you are imposing that a message > received by the JA must be forwarded towards the JCE. Is the network > vulnerable against DoS and DDoS attacks (same comment discussed during > the last phone conf) ? > > Please, have a look to the following examples. > > > If you have a legitimate JN, the exchange of messages is simple: > > legitimate JN ---(1)--> JA ---(2)--> X ---(2) --> JCE > > legitimate JN <---(4)-- JA <---(3)-- X <---(3) -- JCE > > where > X is a generic intermediate node (we have a multihop network) > (1) join request message containing COSE object and processed at the > MAC layer through K1 > (2) join request message forwarded by JA or intermediate node X > towards JCE. It can be protected at the MAC layer through network-wide > keys or unicast layer-2 keys. > (3) join response message forwarded by JCE or intermediate node X > towards JN. It can be protected at the MAC layer through network-wide > keys or unicast layer-2 keys. It contains network-wide keys or any > other key materials (in a COSE object, I guess) > (4) join response message sent by JA to JN. It is processed at the mac > layer through K1. It contains network-wide keys or any other key > materials (in a COSE object, I guess) > > > If you have a malicious JN (or more malicious JNs), the exchange of > messages could be: > > malicious JN ---(1)--> JA ---(2)--> X ---(2) --> JCE > > malicious JN JA <---(3)-- X <---(3) -- JCE > > where > (1) malicious join request message containing malicious COSE object > and processed at the MAC layer through K1 > (2) malicious join request message forwarded by JA or intermediate > node X towards JCE. It can be protected at the MAC layer through > network-wide keys or unicast layer-2 keys. > > --- in the middle time JCE verifies that the request is not legitimate > and stores somethings in its database and announces this to the JA --- > > (3) join response message forwarded by JCE to _only_ JA. It can be > protected at the MAC layer through network-wide keys or unicast > layer-2 keys. IMPORTANT: It contains details about the fail of the > join process. > > -- details stored in (3) are used by JA for avoid to accept any other > packets from that malicious JN --- > > > Now, what happens if you have many malicious JNs ? What happens if JS > moves and try to join from different JAs ? Therefore, PSK +COSE > reduces the number of messages... but makes the network vulnerable > against DoS and DDoS. > > > Does it make sense ? What do you think ? How do you suggest to handle > this aspect ? Probably I did not understand well what you have in > mind... so, please, clarify this aspect. > > > All the best, > Giuseppe > > > > > > > > > > On Fri, Sep 11, 2015 at 1:05 PM, Malisa Vucinic <[email protected]> > wrote: >> It seems that this would trigger the exchange of: >> >> (1) 6 packets between JN and JA, >> (2) 4 packets between JA and JCE on a multi hop path. >> >> Communication of (1) happens in the shared slot so collisions are likely. >> Communication of (2) happens over multiple hops so it affects the network. >> >> I am skeptical how this would look like in terms of delay for the initial >> formation of a large network and in your example bellow JA learns that JN is >> valid only in step (6) at the end of the exchange, when 4 packets have >> already traversed the whole network. In that sense, I don’t see any benefit >> from JA there, except that we can get rid of one packet, EAP identity >> request… Am I missing something? >> >> What do we loose in terms of security if JN simply uses its PSK to generate >> a MAC protected COSE object that can fit in one radio frame that JA forwards >> to JCE? We said that we can protect from replay either using ASN or a >> monotonic counter local to JN. In that case, it would suffice that JCE >> verifies the object and creates a new one that JN can accept, encapsulating >> whatever domain-specific keys are necessary… >> >> This would result in: >> >> (1) 2 packets between JN and JA, >> (2) 2 packets between JA and JCE on a multi hop path. >> >> This roughly reduces the latency by a factor of 3 for the most critical >> stochastic part, and by a factor of 2 for the deterministic part… >> I realize that we are not doing challenge-response there but I am not clear >> what do we really loose since JCE takes care of replay protection from a >> rogue JN, and JN can make sure that it does not use the PSK with the same IV >> more than once? > > -- > Giuseppe Piro, PhD > Post Doc Researcher > DEI, Politecnico di Bari > via Orabona 4 - 70125 (Bari), Italy. > email: [email protected] > phone: +39 080 5963301 > web: giuseppepiro.com -- Giuseppe Piro, PhD Post Doc Researcher DEI, Politecnico di Bari via Orabona 4 - 70125 (Bari), Italy. email: [email protected] phone: +39 080 5963301 web: telematics.poliba.it/piro _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
