Mališa Vučinić writes:
> For pairwise (KeyIdeMode 0) things are bit different, for example
> sending beacons using pairwise keys is not really useful. So for
> pairwise keys key usages like 6TiSCH-K2-* are something that are
> usuful.
>
> I see what you mean. Essentially, key usage will in this case signal
> to the node that it should use this pairwise key to send DATA and
> ACKs.
Yes.
> But my question is related to the signaling of the destination peer.
>
> You say:
>
> For KeyIdMode 0 (pairwise keys), the key_index is set to 0, and
> key_source is omitted. The key_index 0 is invalid for other modes, and
> KeyIdMode 0 do not have key_index, so this will allow us to transmit
> pairwise keys between the peers (the addresses needs to be taken from
> the MAC header).
>
> I don't understand the part where "addresses need to be taken from
> the MAC header". Node A has neighbors B, C, D, and it receives a
> pairwise Link_Layer_Key from the JRC.
It might not want to receive it from JRC. Pairwise keys are just that,
they are meant to be between pair of nodes, and not shared with
anybody else. I.e., they would NOT be sent by JRC, but instead the
node A and B runs some unspecified protocol between them and the end
result of that would be the pairwise key. If this unspecified protocol
is sharing code with initial joining processing, it could use same
Link_Layer_Key structure to send that key. In that case the outer MAC
header of the packets doing this exchange already have the needed
addresses.
Another option is that JRC is used as trusted 3rd party to create the
key, as it does share crypto context with both peers. Then again you
need another unspecified protocol where node A would send message to
JRC asking it to create pairwise key between A and B, and JRC would
then reply with packet which has for example two parts, one meant for
node A, which contains the Link_Layer_Key structure encrypted with key
node A knows, and another one that is opaque blob for A, that is
encrypted with key known by B, and node A, would simply forward that
blob to B, and B can then decrypt it and get the Link_Layer_Key
structure out from there. In this case the addresses of A and B would
need to be somewhere outside, i.e., in message going to JRC.
Third option is that node A sends request to JRC to create keys
between A and B and then JRC creates two key update messages one
encrypted with key known by A and send that to A, and another
encrypted with key known by B, and sends that to B. Both of those
messages needs to contain the pairwise keys addresses (i.e., the fact
that this key is for between A and B).
> It needs to know to what node it will use that key to transmit to:
> B, C, or D. The JRC should in this case, I suppose, send 3 different
> keys, each with a different "destination". I am missing this
> destination part.
Yes, 3 keys for A, and of course also the one keys transmitted to B,
C, and D (where the destination address would be A).
>
> Similar when node A receives a frame, if it comes from B, it
> decrypts it with the corresponding key that the JRC indicated for
> node B. Is my understanding correct? If no, discard the text below
> :-)
Yes.
> If so, we would just need to use "key_source" in this case as well,
> renamed perhaps, to carry the address of the destination peer.
We could.
Anyways this information needs to be already in request where the node
A asking JRC creating keys between A and B. If this information is
there in the wrapper, we could reuse that for other direction too.
I.e., now we are talking about the COnfiguration object, but in this
key negotation protocol we could have PairWise_Keys object:
PairWise_Keys = {
[ +Link_Layer_Key ],
address bstr ; length will tell whether this is pan + short
; or extendedaddress
}
In message from A to JRC the Link_Layer_Key can be empty, or it could
include the key A created, and wants JRC to re-encrypt and transmit to
B, and the address contains the of B. The JRC will then create same
structure, replace address part A and send to B (if A sent key), or
create two similar structures, one for A and one for B, each having
same key, but different addresses.
> All the other modes that you proposed seem still to work.
>
> The proposed change for KeyIdMode 0 is : "key_index" is set to
> 0, "key_source" is present. Can you confirm this works?
Hmm... true, the key_index cannot be zero for KeyIdMode 2 and 3, so
only case where key_index can be zero is with KeyIdMode 0...
So in that case we do NOT need to address outside, so you can ignore
what I wrote above :-)
--
[email protected]
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
