> On 11 Sep 2015, at 14:20, Tero Kivinen <[email protected]> wrote: > > 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.
This scenario would correspond to ‘hijacking’ a JN and installing it in a different network than the one it was programmed to join, I suppose? > JA needs to know the result of the > exchange between JCE and JN so it can know whether JN is valid. Not sure I agree with this, why couldn’t JN and JA authenticate themselves once JCE has shared network keys/certificates to JN. Or you are considering DoS attack on JA by a rogue JN? Consider for instance K1 and K2 from minimal, where JCE shares K2 with JN as a result of the join. As soon as JN has K2, it can start exchanging securely with JA (or any other neighbor) through the knowledge of ASN. I don’t see the need to do anything else there, do you? Of course, JCE then needs to handle updates of K2 but that’s another story. > Doing > that all in messages that are less than 100 bytes is even harder. That, I agree :-). > > 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. Ok, I see your point. If you don’t think we should design a new one, is there something already specified that does not require 10+ exchanges that we could use? Regards, Mališa
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
