Michael - (2) is permitted. EBs and even regular beacons can be theoretically sent with different keys - in Zigbee you can solicit a beacon using one key, and have the receiver send you a beacon on a different key - as long as the aux security header tells each receiver what key is used (or they know what key to use implicitly because it’s specified in the protocol), it works.
That said, I don’t see a good reason to use EBs for anything other than join in 6TiSCH. -- Jonathan On May 20, 2015, at 6:06 AM, Michael Richardson <[email protected]> wrote: > > Tero Kivinen <[email protected]> wrote: >> If the device looses syncronization or gets dropped out of the network >> for some reason, and wants to come back, if the EBs are protected with >> secure K1 then it can trust information in the EBs and do faster >> reconnect. > >> I.e it will get the ASN etc from the EB, and as the K1 is unique for >> this network it can trust this information to be correct. It cannot >> verify that it is not replay, as attacker could have stored the EBs >> and replay them back to node so it would think the ASN is what it used >> to be when EBs were sent. > > 1) But, also, the attacker has to race the coordinator who will send a new > EB with a larger ASN. The node should accept the largest ASN it sees. > > 2) I had originally envisioned that there would be two sets of EBs, one > for joining that might be "protected" with a well-known K1, and one > for production that is protected with a derived key. > > I learnt that (2) was not permitted in 15.4. I still don't quite > understand why, as I originally thought it was a just a question of having > two active PANs. I'm told that this is frequently not possible with MAC > firmware; I can't speculate much about what non-open source stacks do, > but the open source stacks don't seem to have seperate firmware for the MAC > engine. > > I want to say that all of this is outside of the scope of minimal, > so I've changed the subject. > > -- > Michael Richardson <[email protected]>, Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > 6tisch mailing list > [email protected] > http://cp.mcafee.com/d/avndz8OcCQm6kQkNO8UsrKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCTHefmvvvW_8Tud79EVpKDRXBQQT7ejjsusKyNORQr8EGTd7afaxVZicHs3jq9J4TvAm4TDNOb2pEVdTdAVPmEBC5eBYTu00U9GX33VkDa3JssDaBypJOsGm9BO5mUm-waBYTu00CT1RSjpFrsDaBypFtd41EyFZCUOCmd4hEwGWq81EpErjsdN3w1fqZa
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
