Re: [6tisch] 6tisch join requirements for 6top

[Pat Kinney <[e-mail]>]

I find that I must disagree with Tero on his point 10 the well-known beacon key to use for the join network. (Defaulting to "6TISCHJOIN). This behavior is used in WirelessHART networks for a very practical reason.

Keys are not always used for security purposes, often they are used to prevent unintended occurrences, like using a lock and key to prevent a door from accidentally opening.  It is for this reasoning that WirelessHART used a "well-known" key (772E 6861 7274 636F 6D6D 2E6F 7267: ASCII value sequence of the 16 character string of the HART Foundation's web address: www.hartcomm.org) for nodes joining a network or broadcasting a network advertisement.  This mechanism allows for the 802.15.4 MAC to perform additional filtering on received packets.  It was noted in large conventions that using only the 2-octet FCS filter was not sufficient to prevent all undesired messages.  Using the well-known key allowed an additional filter of the 4-octet MIC.

In conclusion, I support the use of the well-known key and I further disagree with the comment that "Using well-known keys makes it bit harder for the upper layer to know whether the frame actually has some protection or not", if an upper layer finds this practice confusing then it shouldn't be an upper layer, perhaps it should try out as a PHY.

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[e-mail]






On 24, Nov2014, at 7:25, Tero Kivinen <[e-mail]> wrote:

Michael Richardson writes:
> joining node interface:
> 1) an enum (registry) saying what kind of network security is to be used.
>   a) NO_SECURITY = 0 
>   b) network-wide MIC/key, to be used directly.

As the key is AES-CCM key that means that every single device needs to
store their frame counters to stable storage. This sets quite high
requirements for the devices. In theory they should also store the
frame counters for all the peers they are talking to, but I don't know
if any device does that. Usually they only store their own frame
counter to flash every now and then, and then on the restart they load
it from the flash, and add big enough counter to it to make sure that
it is unique. 

>   c) a network-wide "PSK", to be used with 802.15.9 mode DTLS (DHE_PSK),
>      unclear to me how broadcast/multicasts are keyed,I hope to read
>      the 15.9 documents.

There is no TLS/DTLS key management defined in the 15.9. Nobody has
bothered to invest time or energy to add that, so thats why it is not
there.

>   d) a network-wide "PSK", to be used with 802.15.9 mode IKEv2
>       (Shared key message integrity code. ditto about broadcast)

How the broadcast/multicast keys are keyed is not really defined in
the 15.9, but it is left for the upper layer. I.e. 15.4 the keys are
identified with the two attributes, Key Source and Key Index. The
format of the Key Source depends on the Key Identifier Mode value.
There are 4 different values for the Key Identifier Mode:

0x00	Key is determined implictly from the originator and
	recipient(s) of the frame. I.e there is no  Key Source or Key
	Index, and pairwise keys between peers are used. Note, that
	there is no Key Index, thus there is only one such key at
	given time. 

0x01	Key is determined from the Key Index field in conjuction with
	macDefaultKeySource. I.e. each device can have one default
	sender, which allows compression of the security header, as
	this default key source can be left out from the header. I
	would expect that this macDefaultKeySource would be the PAN
	coordinator or similar. As the macDefaultKeySource needs to be
	global to the PAN, there can really be only one owner for the
	key. 

0x02	Key is determined explictly from the 4-octet Key Source field,
	and the Key Index field. The 4-octet Key Source consists of
	PAN Id and the short address. I.e there can be 255 keys from
	the same sender. 

0x03	Key is determined explictly from the 8-octet key source field,
	and the key index field. I.e. this gives the extended address
	of the sender and identifies which of the 255 keys from that
	sender is used.

The 15.9 allows creating those keys KMP-CREATE.request is given the
NewKeyIdMode, NewKeySource and NewKeyIndex which key management then
negotiates.

If the NewKeyIdMode is 0x00, then pairwise keys are negotiated, and
there can only be one key between the peers, so the Key Source and Key
Index are ignored.

The key identifier mode 0x01 can be used for the broadcast key for the
traffic originating from the pan coordinator. I.e. instead of storing
the pan coordinator address in the header, it can be left out, but as
one common frame counter is used for all traffic, only the pan
coordinator (or actually the macDefaultKeySource, i.e. the owner of
the key) can send data out using this key.

The key identifier modes 0x02 and 0x03 can be used for the broadcast
or multicast traffic from any peer to any peer. Each originator has
its own frame counters and each recipient stores last frame counter
seen from the other enad compares that there is no replay.

All of those keys can be negotiated by the upper layer, by calling the
KMP-CREATE.request with suitable paramaters. How the actual key
management protocol then maps those calls to actual operations on the
key management is left outside the 15.9. I.e. we most likely need IETF
draft explaining how to map the KeyIdMode, KeySource and KeyIndex to
actual IKEv2/HIP etc payloads.

For pairwise keys this is usually quite easy, i.e. we just derive
those keys from the KEYMAT. This is actually defined in the 15.9. For
the broadcast / multicast key destribition it says that such features
needs to be added to the IKEv2, i.e. sending key material over IKEv2
channel using Notify payloads inside INFORMATIONAL exchanges.

I.e. we need to write draft saying that 15.9 broadcast/multicast key
distribution is done by sending Notify Payload with notify message
status type of xxx, and having content of:

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |KIM|  RESERVED |            Key Source (0/4/8 octets)          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               | Key Index     | Key Material (16 octets)      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where the KIM is the Key Id Mode, and the Key Source is either 0, 4,
or 8 octects depeding on the KIM value (0x01 = 0, 0x02 = 4, 0x03 = 8
octets). The Key Index is always 1 octet. This is never used if the
Key Id Mode is 0, as then pairwise keys are used. The Key material
used for the key is the last 16 octets of the notify payload. 

This specification is not yet written.

Or instead of that we can use the GDOI IKEv2 specification to
distribute the keying material. 


>   f) a PK method: to be used with 802.15.9 mode DTLS (ECDSA),

As I said no DTLS/TLS key management method in 15.9. If that is
needed, then someone needs to start working on it, i.e. write the
appendix for it.

>   g) a PK method: to be used with 802.15.9 mode IKEv2 (ECDSA)
>      I thought that 7296 would have rolled in the signature-auth work.
>      I want to specify the ECDSA authentication methods.

The 7296 didn't include signature auth method draft, as there was not
yet proven interoperability with it. There are not even
implementations out there using it yet, so to make that full internet
standard in the first step would have been bit premature. It should
come out as RFC soon. 

>   h) ditto above, s/IKEv2/HIP/
>   i) perhaps a code for using draft-piro-6tisch-security-issues-02 
>   -- I'm unclear how MLE works at this point.
> 
> 2) a space for an ECDSA PKIX certificate.  from 6top's point of view, this is
>   around 300 opaque bytes.  We should be transfering DER, not base64 encoded
>   certificates!

802.15.9 allows transmitting 9 kB payloads inside the 15.4, so 300
bytes should not be problem. Also 15.9 defines multipurpose layer,
which can be used by others than KMP, i.e. 6tisch can use it do its
own protocols if needed. 

> 10) the well-known beacon key to use for the join network. (Defaulting to
>   "6TISCHJOIN") 

Why is this? What key Source it would use? What Key Id Mode? In 15.9
we specify that the key management packets are sent with security
level of 0, and I did hear someone complaining that you cannot mix
security level 0 and other security level frames in the 15.4, but that
is wrong. The 15.4 do allow receiving packets with any security level,
and upper layer is told about the security level of the received frame
in the DATA.indication call.

Using well-known keys makes it bit harder for the upper layer to know
whether the frame actually has some protection or not. I.e. instead of
checking whether the security level is 0, it needs to check the
KeyIdMode, KeySource and KeyIndex to know if this key was one of the
well know keys, which would indicate there is no protection for the
frames.

If there is no protection for the frames, it is better to indicate it
using security level 0, and not hide that fact to some well know key.
Also if you define such key you also need to defined the KeyIdMode,
KeyIndex and KeySource for it. 
-- 
[e-mail]

_______________________________________________
6tisch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6tisch