[6tisch-security] minutes from call 2014-10-28

[Michael Richardson <[e-mail]>]

My appologies for taking so long to get these out.
The call this week is in 30 minutes at:
    > Meeting number: 645 146 419 Meeting password: timeslot Audio
    > connection: 1-877-668-4493 Call-in toll free number (US/Canada)
    > 1-650-479-3208 Call-in toll number (US/Canada)

    > https://ietf.webex.com/ietf/j.php?MTID=m026b87ec5a630ca1ec44f2e79329ba02

    > etherpad for meeting:
    > http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt

    > please note that google/browser-using-google-data might complain about it
    > being a phising site, it is likely a false positive, and I've let
    > ietf-action know about it.


2014-10-28 call started 11am EST.

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"







--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-