Malisa Vucinic writes:
> I tried to do a little exercise and here is the flow with implicit,
> pre-shared keys I see as standard compliant. Please correct me if I
> have misunderstood something.
>
> Step 0 - JN instantiates:
>
> SecurityLevelDescriptor_EB = {FrameType = BEACON,
> CommandFrameIdentifier = undefined, SecurityMinimum = MIC_32,
> DeviceOverrideSecurityMinimum = FALSE, AllowedSecurityLevel =
> {MIC_32, MIC_64, MIC_128} }
As you have specified the AllowedSecurityLevel there is no point of
listing SecurityMinimum. SecurityMinimum is only used if
AllowedSecurityLevel is empty.
> Step 1 - JN receives a frame (EB) from JA. JN parses the header and
> learns that it is an EB, JA’s addressing mode which is
> SHORT/EXTENDED, address SHORT_ADDRESS_JA/EXTENDED_ADDRESS_JA,
> PAN_ID_JA, ASN. JN knows that the join process is ongoing so it
> invokes a join-specific routine *before* checking steps from the
> incoming frame security procedure (Sec. 7.2.3). The join-specific
> routine instantiates:
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.
> KeyIDLookupDescriptor_JA = { keyIDMode = IMPLICIT, KeySource =
> undefined, KeyIndex = undefined, DeviceAddrMode = SHORT/EXTENDED,
> DeviceAddress = SHORT_ADDRESS_JA/EXTENDED_ADDRESS_JA }
I assume KeyIdMode = IMPLICIT means KeyIdMode = 0b00? There is no
IMPLICIT in 802.15.4 or 802.15.4e.
If you use KeyIdMode of 0b00 you would also need to set the
DevicePANId.
> KeyUsageDescriptor_K1 = { FrameType = BEACON, CommandFrameIdentifier
> = undefined }
>
> KeyDescriptor_K1 = { KeyIDLookupList = KeyIDLookupDescriptor_JA, ,
> KeyUsageList = KeyUsageDescriptor_K1, Key = K1 }
In this you also need to fill in the DeviceDescriptorHandleList which
will point to the DeviceDescriptor of the other end. For that you need
to know the PANId and ExtAddress of the other end, and you may also
fill in the ShortAddress if you know it.
To be able to fill those values in, the beacon needs to be sent out
using the extended address of the coordinator.
I.e. if the beacons used Extended addresses then you can fill all this
information in, but as there can be only one KeyIdMode 0b00 key
between pairs, this means you cannot use KeyIdMode 0b00 for K2, so for
that you need to use something else.
Also this will limit the usability of pairwise keys, as they would
normally use KeyIdMode 0b00, i.e. later when device wants to create
pairwise key between the coordinator and device, they could not fill
it in as there is already this K1 key in place (and if you remove the
K1 key before installing the pairwise key, you would get security
errors for each EB the device is trying to process after that point).
> DeviceDescriptor_JA = { PANId = PAN_ID_JA, Address = ShortAddress or
> ExtAddress depending on JA’s addressing mode, FrameCounter = ASN,
> Exempt = False }
For DeviceDescriptor you must fill in the ExtAddress, and PANId. They
are not optional regardless of the JA's addressing mode. The
ShortAddress can be left out (or filled up with 0xfffe if device is
only using extended address, or 0xffff if it is unknown).
Note, that you do not know ASN at this point. This is way before the
Payload IEs are parsed, so you cannot get the ASN from the TSCH
Synchronization IE. On the other hand it does not matter really, as
the FrameCounter is not used for Nonce generation, ASN is used
directly.
> Step 3 - JN checks steps from 7.2.3, i.e. the incoming frame
> security procedure. During the steps from 7.2.3, JN invokes
> KeyLookup Procedure from 7.2.2 with device PAN ID = PAN_ID_JA,
> device addressing mode = JA’s addressing mode, device address =
> SHORT_ADDRESS_JA/EXTENDED_ADDRESS_JA, KeyIdMode = IMPLICIT, KeyIndex
> = undefined, KeySource = undefined. In terms of the logic flow,
> procedure in 7.2.2 ends up in a.4 and a.5.
Yes.
> On the JA side, JA needs to follow the outgoing security procedure
> in 7.2.1 to secure EBs. I am not clear if macCoordExtendedAddress
> attribute is still valid in TSCH which seems to be necessary for the
> Key Lookup procedure to pass with beacons.
Yes, for KeyIdMode 0b00 with beacons, the macCoordExtendedAddress is
always used.
> JA would need to
> instantiate:
>
> KeyIDLookupDescriptor_K1 = { keyIDMode = IMPLICIT, DeviceAddrMode =
> NO_ADDRESS, DeviceAddress = macCoordExtendedAddress (JA's extended
> address) }
Yes.
> KeyUsageDescriptor_K1 = { FrameType = BEACON, CommandFrameIdentifier
> = undefined }
>
> KeyDescriptor_K1 = { KeyIDLookupList = KeyIDLookupDescriptor_K1, ,
> KeyUsageList = KeyUsageDescriptor_K1, Key = K1 }
Yep.
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.
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>
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. 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...
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
