Minutes Webex 28 October 2014, 6TiSCH Security Task Force
Note: timestamps in PDT.
These minutes were announced at http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00232.html.
Attending - Thomas Watteyne - Michael Richardson - Jonathan Simon - Kris Pister - Mike Seewald - Nancy Cam-Winget We started the meeting by attempting to recap the discussion in the Mailing List. Michael asks Kris to do the recap. The thread starts at: http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00212.html The result of the discussion is that we have some terminology problems with the use of "join key" --- we agreed that we would use the following terms: join network - A 802.15.4e network whose well known global encryption and authentication key is "JOIN6TISCH". unique join key - a symmetric key shared between a newly joining node, and the JCE. This key supports smaller installations for which asymmetric methods are considered too large well known beacon key - this is the key "JOIN6TISCH" MR discussed that while the unique join key might in some situations not be unique (we can not prevent use of pin "0000" a la Bluetooth headsets), we should never make a protocol that depends upon the key being known by more than one node. We then had a discussion about the term "trust anchors". MCR said that the use of this term will cause some security people to assume that this is related to the set of trust anchors present in web browsers; that some interaction with the Verisign/Komodo/etc. is intended, when it really is about connection to some industry consortia, or perhaps only to the vendor's CA. We covered the problem of the node knowing if it is joining the right network, that "this is the JCE you are looking for" (Star Wars droids reference). The oil refinery situation was raised; where competitors have equipment within radio distance of each other, and often sell/lease it among themselves. MR: suggestion: certificate given by JCE to node, contains authorization with "I am your owner". there is a set of delegation in supply chain. node can authenticatie that. node need to go to its vendor KP: so go out to the Internet and contact the vendor? MR: don't suggest node or JCE do this online. Michael Belinger raised fraud and reselling. issue is that, when you purchase a node, you have to install. vendor could veto a resell market if was involved online. example with lightbulbs MR: opinion is that the way you get that certificate is out of scope. Here is your MAC id and certificate of who owns you We had a discussion about possible ways that this introduces a vendor-lockin DRM, and the negative press that might result. This is the reason for the 802.1AR installation of a LDevID after the join process, as this permits/supports resell and further econonic activity without permission of the vendor. We agreed that there would never be a requirement to go out to the Internet. MCR explained purpose of draft-richardson-6tisch-idevid-cert... tried to explain relative to SIDR, but SIDR work was not known. We discussed why we have a well-known-beacon key at all: mixing traffic from other sources users of that spectrum, and also concern that some MACs may be unable to deal with unencrypted and encrypted traffic being received at the same time. We had a discussion about the 10/11 flows which are summarized as follows: MR: DTLS session bnetwee JCE and join assistant, doubly encryped (L2 hop by hop and e2e DTLC/6top) MR: TLS session setup consists of 2 exchanges: . client hello (client presents his capabilities) . server helo (new node) responds his capabilities) . those packets re 100-150 bytes. possibly 60-70 bytes. suspect will be 2 frames . allow to agree on cipher, need crypto agility . would be ideal is JCE presents 2 options, AES-TCM and other . second exchange involves client certification, and response with server certificate and DH . packet ~1-2kB size. can be in smaller pieces . biggest pieces in this is supplier chain of certificate that proves own this node . upper part of chain COULD be cached by join assistant. but, most of statements will be mote-specific Agenda for next, second DODAG, how do we get that mode online: text in section 3 starting with: "The specific mechanism to enable end to end connectivity with the JCE"