Rene, Kris, Tero,
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} }
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:
KeyIDLookupDescriptor_JA = { keyIDMode = IMPLICIT, KeySource = undefined,
KeyIndex = undefined, DeviceAddrMode = SHORT/EXTENDED, DeviceAddress =
SHORT_ADDRESS_JA/EXTENDED_ADDRESS_JA }
KeyUsageDescriptor_K1 = { FrameType = BEACON, CommandFrameIdentifier =
undefined }
KeyDescriptor_K1 = { KeyIDLookupList = KeyIDLookupDescriptor_JA, , KeyUsageList
= KeyUsageDescriptor_K1, Key = K1 }
DeviceDescriptor_JA = { PANId = PAN_ID_JA, Address = ShortAddress or ExtAddress
depending on JA’s addressing mode, FrameCounter = ASN, Exempt = False }
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.
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. JA would need to instantiate:
KeyIDLookupDescriptor_K1 = { keyIDMode = IMPLICIT, DeviceAddrMode = NO_ADDRESS,
DeviceAddress = macCoordExtendedAddress (JA's extended address) }
KeyUsageDescriptor_K1 = { FrameType = BEACON, CommandFrameIdentifier =
undefined }
KeyDescriptor_K1 = { KeyIDLookupList = KeyIDLookupDescriptor_K1, , KeyUsageList
= KeyUsageDescriptor_K1, Key = K1 }
Regards,
Mališa Vučinić
> On 24 May 2015, at 09:37, Kris Pister <[email protected]> wrote:
>
> Yes, 7.2.3 describes the incoming frame security procedure, which references
> the
> 7.2.2 keyDescriptor lookup procedure. 7.2.2 says that if the KeyIdMode is
> 0x00,
> then a.4 and a.5 say to find the keyDescriptor in the macKeyTable which has
> the
> same PAN ID and source device address.
> How the macKeyTable is populated is not described. In particular, we know
> that
> in many cases keyDescriptors will be added during network operation.
> The information contained in an EB is sufficient to allow a JN receiving that
> EB
> to create a deviceDescriptor and keyDescriptor entry for the JA, including
> the PAN ID, JA address, and all other information necessary to
> perform the procedure described in 7.2.3 in a standard-compliant way.
>
> Again, I'm confident that we can be compliant and use a key K1 with
> keyIdMode 00 and no extra header bytes.
>
> ksjp
>
> On 5/22/2015 8:54 PM, Rene Struik wrote:
>> Hi Kris:
>>
>> The appropriate clause in 802.15.4-2011 is clause 7.2.3 (which describes the
>> normative behavior of the incoming security frame processing procedure),
>> which includes the mechanism by which key look-up takes place.
>>
>> Rene
>>
>> On 5/22/2015 7:15 PM, Kris Pister wrote:
>>> Rene - just to make sure that I understand you, you are saying that:
>>>
>>> If I generate a secure random 128 bit number to use as K1, and I program
>>> that number
>>> into five motes sitting on my desktop, there is no standard-compliant way
>>> that those
>>> motes can use K1 to protect MAC frames without using a 9-octet key
>>> identifier?
>>>
>>> I'm pretty sure that there *is* a way. I'm pretty sure that I can set Key
>>> Identifier Mode to 00,
>>> and have 0 additional bytes in the security header, and determine the key
>>> implicitly
>>> ("use K1!"), as described in 7.4.1.2 of 802.15.4-2011 .
>>> Perhaps Tero can tell us if this is still true in -2015.
>>>
>>> ksjp
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
