> On 25 May 2015, at 05:38, Tero Kivinen <[email protected]> wrote:
>
> You cannot really do that. MAC will run the filttering rules for the
> frame, and then continue to the incoming frame security procedure and
> only after that willit pass the frame forward.
>
> In normal case it would discard the frame as the security processing
> fails, but because this is doing active/passive scanning now it will
> still store the information about the beacon even when the incoming
> frame security processing failed.
>
> I.e you will be able to see the EB even when the security processing
> failed, but you will not be able to get the well-known keys in place
> for the first EB so it would be checked by the MAC.
>
> 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? :)
> 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. 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? 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.
>
> I think it would be better to define so that when JA sends EBs out it
> configures its EBs as follows:
>
> It always sends them out using extended address as a source address,
> thus fills in secKeyIdLookupDescriptor for K1 with following values (I
> am using the 2015 naming, as they are bit clearer than 2011 versions,
> and I will leave undefined values out, or values which are not
> releveant for this dicussion):
>
> secKeyIdLookupDescriptor(K1)
> secKeyIdMode = 0b01
> secKeyIndex = 0b42 (value defined in minimal draft, or
> negotiated during bootstrap process).
>
> secKeyDescriptor(K1)
> secKeyUsageList = { (secFrameType = beacon) }
> secKey = <K2 key>
I believe you mean <K1 key>.
>
> For K2 it will use separate KeyIndex.
>
> When it sends beacon out it will send it having extended address as
> SourceAddressingMode and using Extended address in its Source Address.
> The Source PAN Identifier are filled in as normally.
>
> The JN will fill in the security tables as followS:
>
> secKeyIdLookupDescriptor(K1)
> secKeyIdMode = 0b01
> secKeyIndex = 0b42 (value defined in minimal draft, or
> negotiated during bootstrap process).
>
> secKeyDescriptor(K1)
> secKeyUsageList = { (secFrameType = beacon) }
> secKey = <K1 key>
>
> When it starts joining process the first EB is received, but cannot be
> verified by the MAC as the secDeviceDescriptor is not filled in and
> ASN is not known.
>
> When during the scanning it finds EB it could accept, it can take the
> ASN from TSCH Synchronization IE, configure it to the MAC (how it will
> set that properly to MAC is bit difficult, as setting the macASN by
> the upper layer might not work, as we might already be on the next
> timeslot by the time upper layer manages to set the ASN).
>
> Then it would also create secDeviceDescriptor for the coordinator
> sending beacons:
>
> secDeviceDescriptor(coordinator)
> secPanId = <pan id from EB frame>
> secShortAddress = 0xffff (== unknown)
> secExtAddress = <extended address from EB frame>
> secExempt = FALSE
>
> 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. Otherwise, we can consider using K1 with KeyIdMode 0b01
(one extra byte for Key Index) and K2 with KeyIdMode 0b00 (implicit, no extra
bytes).
> 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?
Regards,
Mališa Vučinić
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
