Malisa Vucinic writes: > 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?
After this exchange we have following things set up: 1) JN and JA share unique link key that can be used to encrypt and aute authenticate traffic between them. 2) JN has received group key information from the JA. 3) JA has received authorization from the JCE, that JN can join the network, and that his credentials match. 4) JN will know that network he is joining is authenticated. 5) JN, JA, and JCE are sure the exchange is fresh, and cannot be replayed. 6) JN and JA also share KMP connection that can be used to add, delete or modify existing keys between them, i.e. do rekey etc. > 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… It depends what kind of authentication protocol you are going to create to run between JN, JA and JCE. You are talking about creating new protocol, and claiming that it would be just "simply using PSK to generate MAC protected COSE object", and that we somehow use ASN or monotonic counter to protect replays. And then just sending some encapsulated keys back... This is not as easy as it sounds. The devil is in the details, i.e. actually specifying this new authentication protocol so it is actually secure and offers the features we need is not that simple. You most likely need some kind of challenge response system so JN can know that JCE really answered to the request he send, and attacker cannot use old reply from JCE. JA needs to know the result of the exchange between JCE and JN so it can know whether JN is valid. Doing that all in messages that are less than 100 bytes is even harder. This is the reason why 802.15.9 decided AGAINST making their own key management protocols. All key management protocols in 802.15.9 are already specified somewhere else. I think it would be bad idea to start designing this kind of protocol here in this WG. > 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? To be able to see what we loose and what kind of attacks are possible, we would first need to see the actual protocol between JN and JA, and between JA and JCE. Before we see the protocol we do not know what we loose... -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
