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

[Thomas Watteyne <[e-mail]>]

[adding the 6TiSCH ML]

On Tue, Nov 4, 2014 at 7:30 AM, Michael Richardson <[e-mail]>
wrote:

>
> 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 =-
>
>
>
>
> _______________________________________________
> 6tisch-security mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch-security
>
>