Tom: This standard is correctly written, please note that the excerpt has a footnote [12] that states what you stated.
In this case, the note is indeed informative, giving the reader insight as to why implicit key identification should not be used for broadcast frames, however their use is not prohibited. NOTE—For broadcast frames, the KeyDescriptor lookup procedure will result in Status set to FAILED if implicit key identification is used. Hence, explicit key identification should be used for broadcast frames.12 12 Notes in text, tables, and figures are given for information only and do not contain requirements needed to implement the standard. Pat Kinney Kinney Consulting LLC IEEE 802.15 WG vice chair, TG chair ISA100.11a WG chair O: +1.847.960.3715 [email protected] On 26, May2015, at 9:07, Tom Phinney <[email protected]> wrote: From the thread recorded below: > We are talking about source addresses here, not destination. Source > address should not be broadcast... > > And KeyIdMode 0b00 cannot be used with broadcast addresses for > non-beacon frames. See the note at the end of KeyDescriptor lookup > procedure which says: > > NOTE—For broadcast frames, the KeyDescriptor lookup procedure > will result in Status set to FAILED if implicit key > identification is used. Hence, explicit key identification > should be used for broadcast frames. Unless this apparent requirement appears in the normative text of the quoted IEEE 802.15.4 standard, and not just in this putatively informative (i.e., not normative) note, then it is not actually relevant to conformance to IEEE 802.15.4. This example demonstrates precisely why ISO and IEC are adamant that NOTEs be written in such a way that no reader can presume them to be adding to the requirements of the containing standard. Notes ARE strictly informative. === On 2015.05.26 03:20, Tero Kivinen wrote: > Malisa Vucinic writes: >>> Lets assume you could run this process inside the MAC, and check the >>> rest of the stuff here. >> Right, so in the worst case the join-specific routine can be invoked >> after we have discarded one EB and for the subsequent one everything >> should be in place. Otherwise, one will have an upper-layer callback >> within MAC, as this part of the spec is usually implemented in >> software i.e. firmware, that invokes the join-specific routine and >> prepares everything for the first received EB. Would that be non >> standard compliant? :) > Such implementation might not be against standard, but to get some > existing implementation to do that, might be really hard. > > Of course if your implementation does everything on software, then you > can do that, but if you have hardware doing the security processing > for frames, it might be really hard to be able to hook into that. > >>> Now you of course have the problem how to identify the K2 key for the >>> network... You cannot use KeyIdMode 0b00, as you can only have one of >>> them. >> Well, consider that beacons can also be sent with short Destination >> Addressing Mode and 0xffff Destination Address field. > We are talking about source addresses here, not destination. Source > address should not be broadcast... > > And KeyIdMode 0b00 cannot be used with broadcast addresses for > non-beacon frames. See the note at the end of KeyDescriptor lookup > procedure which says: > > NOTE—For broadcast frames, the KeyDescriptor lookup procedure > will result in Status set to FAILED if implicit key > identification is used. Hence, explicit key identification > should be used for broadcast frames. > >> Given that KeyDescriptor Lookup in case of KeyIdMode 0b00 (implicit) >> differentiates among different keys based on device address, PAN and >> addressing mode, you could use the short broadcast address (0xffff) >> to instantiate the KeyDescriptor, no? > The keys are identified by the source address. Destination address > does not matter when finding the key (of course it will matter who > will actually do the incoming frame security procedure, i.e. which > device receives the frame). > > It is possible in the sending end to have multiple KeyIdMode 0b00 keys > for different addresses. but for receiving end will just use the > source address of the frame to find the key. So if the device A has > KeyIdMode 0b00 key for coordinator B the device A will find the same > key always for same address. > >> Each EB would be secured using the KeyDescriptor that corresponds to >> the 0xffff address. The question then is if there is a way to >> differentiate between DATA broadcast frames and beacons for K1 >> during the outgoing security procedure. Since the incoming procedure >> checks the key usage policy (7.2.7) I don’t see a problem on the >> receiving side. > Key Usage Policy is done after we have found the key. It does not > affect the key lookup. I.e. the incoming frame security policy will > find the key using the KeyDescriptor lookup procedure, and then it > will later check whether that key was ok to be used for those frames. > >>> secKeyDescriptor(K1) >>> secKeyUsageList = { (secFrameType = beacon) } >>> secKey = <K2 key> >> I believe you mean <K1 key>. > Yes. >>> Now, if the ASN is right, it will be able to authenticate the next EB >>> that comes in (or if it has ability to push old received EB back to >>> mac for security check after filling in the tables). >>> >>> The K2 would use same KeyIdMode 0b01 but with different KeyIndex. >> KeyIdMode 0b01 for both K1 and K2 is more flexible but I am not sure >> if this is necessary for minimal. > I think it is mandatory if you want to use two different keys. > >> Otherwise, we can consider using K1 with KeyIdMode 0b01 (one extra >> byte for Key Index) and K2 with KeyIdMode 0b00 (implicit, no extra >> bytes). > That is fine as long as K2 key is never used with broadcast keys... > KeyIdMode is not supposed be used with broadcast keys (or actually any > group keys). > > Also this makes it impossible for K2 to be rekeyed. With KeyIdMode > 0b01 you can rekey by installing new key with new index, and > distribute the new key to all devices. When that is done, you can > switch the network to use new key, and then remove the old key. > > With KeyIdMode 0b00 this is not possible, as there you need to do this > atomically for the whole network. > >>> The bad thing here is that devices would try to do this for all >>> possible networks using KeyIdMode 0b01 and same KeyIndex, thus >>> this will not provide full network separation… >> Device will try to authenticate the EB (whichever EB the >> implementation-specifics allow it to authenticate) with K1 it has >> preinstalled. Wrong network and this will fail, no? > Yes, but people were concerned that we try to connect to wrong > networks, and if you need to wait for EB, install keys etc, wait for > next EB, and then notice that the network is wrong, this is quite slow > process... > > Having random KeyIndex for minimal would provide additional filter > when selecting network, but it is weaker than what can be done with > well-known extended address in KeySource or vendor specific IE > containing network id in EB... _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
