Subject: Re: [6tisch-security] two 6TiSCH security working calls

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Oct 2014 09:52:05 -0400

I'm resending this, as it might not have made it off my tablet yesterday.
Or maybe it's a duplicate.

Michael Richardson <[email-masked]> wrote:
    > We will meet on *Tuesday* Oct 21 and 28 at 8am PDT.

    > Webex to be posted on Monday.  This is a WORKING MEETING, please read:
    > https://tools.ietf.org/html/draft-richardson-6tisch--security-6top-02

    > I will post it to etherpad, and the goal is to EDIT this, fill in
    > missing text such that it is complete.  Subsequently, we will rip the
    > document into two; one part to be patches into 6tisch-arch, and the
    > other for the 6top people.

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)

Show toll-free dialing restrictions
Access code: 645 146 419
Meeting link: https://ietf.webex.com/ietf/j.php?MTID=m026b87ec5a630ca1ec44f2e79329ba02

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Rene Struik <[email-masked]>
Date: Mon, 20 Oct 2014 10:43:12 -0400

Hi Michael:

I am surprised seeing your note below, given the notes on conf calls by 
the 6TiSCH Chairs in 
http://www.ietf.org/mail-archive/web/6tisch/current/msg02517.html.

Best regards, Rene

On 10/20/2014 9:52 AM, Michael Richardson wrote:
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 20 Oct 2014 11:35:21 -0700

Rene,

Thank you for keeping an eye on this. Please note that Michael's invitation
is targeted at the 6TiSCH security DT to very specifically discuss one
draft before this is presented to the 6TiSCH WG.

Per https://www.ietf.org/iesg/statement/interim-meetings.html, I believe
this working meeting falls under the following sentence "*This does not
apply to meetings, conference calls, or jabber sessions for small design
teams producing input to working groups.*".

I hope this helps clarifying things.

Thomas

On Mon, Oct 20, 2014 at 7:43 AM, Rene Struik <[email-masked]> wrote:

> Michael Richardson <[email-masked]> <[email-masked]> wrote:
> Michael Richardson <[email-masked]> <[email-masked]>, Sandelman Software Works
> 6tisch-security mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch-security
>
>
>
> --

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 21 Oct 2014 05:12:43 +0000

Hi Michael,

I did not see this in time for this week so will miss tomorrow¹s call but
will try to make next week¹s session.
I will try to review the draft and provide feedbackŠ.will look forward to
the notes from tomorrow¹s discussion.

Thanks, Nancy

On 10/20/14, 6:52 AM, "Michael Richardson" <[email-masked]> wrote:

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Oct 2014 10:13:50 -0400

Etherpad for working call today:
  http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt

base work today:
     - recap of plans for document (10minutes)

specific sections to review today: section 3.

specific sections to address today:

4.2.  implementation cost
   (storage of security material, computational cost)

4.3.  denial of service
   other communication impacts of security protocol mechanics

10.  slotframes to be used during join
   how is this communicated in the (extended) beacon.

14.  Posture Maintenance
   (SACM related work)

======

next week: section 5 extended, intended as specific text for architecture
document, going into a new section 6.6 of 6tisch-architecture, as
well as populating section 11 (Security Considerations) of
6tisch-architecture from section 4 of 6tisch-6top.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Oct 2014 14:56:28 -0400

Michael Richardson <[email-masked]> wrote:
    > base work today: - recap of plans for document (10minutes)

    > specific sections to review today: section 3.

Attending today's meeting was:
- Thomas Watteyne
- Michael Richardson
- Kris Pister
- Mike Seewald
- Pat Kinney
- Subir Das

1) we got started 10 minutes late, and reviewed what the purpose of
   the draft-richardson-6tisch-security-6top document was.

   There are two places for this text.
   a) into the 6tisch-architecture (or possibly a new document, as per the WG)
   b) into the 6tisch-6top document for the actual objects to adjust.
   c) into some other documents that might wind up in ANIMA.

2) we worked on section 3.
   we added some terms to the glossary and struggled with the
   "network-wide" shared symmetric key that many other details cryptographic
   key agreement protocols assume exists in order to authenticate exchanges.

3) we discussed whether or not we could use the 6top-over-15.4 Information
   Elements (IE) to do security bootstrapping, and concluded that we can not,
   as on the JOIN mac-key which authenticate that process would be well
   known.

4) we discussed the question of end-to-end, JCE<->JoiningNode communication,
   and the relative merits of the four possibilities outlined in section 3,
   page 6.  We agreed that option (1) [ipip] was a poor choice, and that
   while option (4) was a really good choice, it might not be possible.
   We were left with whether a new DODAG or the existing base DODAG was
   the right answer.

5) we concluded that for self-organizing (no PCE) 6tisch networks, that
   per-pair L2 keys were very important due to the use of mac-layer IE
   to do schedule updates.   This has a code and energy impact on nodes
   in that they need to support one of the per-pair mechanisms listed on
   page 5 (section 3)[MLE,802.15.9,ohba-6tisch-security,piro-6tisch-secuirity].

   Not only is there a code space requirement, but there is also the need
   to have enough non-volatile storage to keep all of the (unique) keys to
   talk to each of one's neighbours.

   The upshot of this is that if you want to simplify the motes further,
   then having a PCE/JCE is an effective way as the motes need only maintain
   a single DTLS/CoAP/6top security association with the PCE, and the L2
   network key could be common across the entire network.

6) we did not finish discussion of section 3, and we will come back to
   that next week, and also talk about what is in the packets 10-13,
   and if we can cache anything that would reduce join traffic.

   we did dicuss intensitivity of join traffic, and how the JCE can
   control how many nodes (and in which order) they join.

7) I will provide an overview in the Oct. 24 group call, and I will
   revise the document slightly for next week.

---

From: Kris Pister <[email-masked]>
Date: Sun, 26 Oct 2014 13:05:28 -0700

Michael - I'm trying to get back up to speed on the security discussion, 
so forgive a few
possibly out-of-date questions.
--------------------------------------------
#1 Is this a correct statement of the start and end states?

The mote starts with some authentication material, either
1) a pre-shared join key
or
2) a certificate

The JCE starts with either
1) the same pre-shared join key as the mote (possibly tied to the 
joining mote
MAC ID, possibly unique, ...)
or
2) a certificate

The mote ends up with either
1) a single network-wide L2 key for the production network
or
2) multiple L2 keys for the production network, each associated with one 
or more neighbors
--------------------------------------------
#2 I'm a little confused on what's happening with flows in Figure 1. If 
I remember
Jonathan's presentation correctly, I think that he was hoping to use 
packets 2 and 3
as a short cut to minimize the time and effort required for a DTLS PKI 
based exchange.
If that's the case, then does it make sense to talk about a 
JCE-initiated session in
packets 10 and 11?  It seems like the joining mote has already said with 
packet 2
"hey, I speak short cut DTLS with secp256r1 - can you send me the JCE's 
public key?"
or something like that.  Yes?

ksjp

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 26 Oct 2014 14:20:03 -0700

Personally, I would greatly benefit from a detailed overview flows 10/11. I
believe this would also help answer Kris' remarks.

Michael,
I believe it would be helpful to dedicate a significant portion of
Tuesday's call on this. Thoughts?

Thomas

On Sun, Oct 26, 2014 at 1:05 PM, Kris Pister <[email-masked]> wrote:

> 1) the same pre-shared join key as the mote (possibly tied to the joining
> mote
> #2 I'm a little confused on what's happening with flows in Figure 1.  If I
> remember
> If that's the case, then does it make sense to talk about a JCE-initiated
> session in

---

From: Michael Richardson <[email-masked]>
Date: Sun, 26 Oct 2014 18:03:46 -0400

Kris Pister <[email-masked]> wrote:
    > Michael - I'm trying to get back up to speed on the security
    > discussion, so forgive a few possibly out-of-date questions.

    > The mote starts with some authentication material, either 1) a
    > pre-shared join key or 2) a certificate

No.  Neither.  That's sort of the closer to the end state, but not really.

The mote starts with a certificate from it's factory attesting to it's
identity.  The JCE starts with a certificate chain from the factory
attesting to it's ownership of the mote.

    > The mote ends up with either 1) a single network-wide L2 key for the
    > production network or 2) multiple L2 keys for the production network,
    > each associated with one or more neighbors

No, the mote winds up with a locally significant certificate or network-wide
master key, and it uses those to derive (1) and/or (2) using
one of MLE/802.15.9/piro/ohba documents.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 26 Oct 2014 18:09:56 -0400

Thomas Watteyne <[email-masked]> wrote:
    > Personally, I would greatly benefit from a detailed overview flows
    > 10/11. I believe this would also help answer Kris' remarks.

    > Michael, I believe it would be helpful to dedicate a significant
    > portion of Tuesday's call on this. Thoughts?

Yes, let's do that.

The required reading is:
    1) draft-pritikin-bootstrapping-keyinfrastructures-00
    2) https://mailarchive.ietf.org/arch/msg/6tisch-security/DT-K0_qd_wd-GmqB4YVqQtbhC6Q

Suggested reading:
    3) draft-richardson-6tisch-idevid-cert-00

---

From: Kris Pister <[email-masked]>
Date: Mon, 27 Oct 2014 08:26:43 -0700

Hmm.

 >   > The mote starts with [...] a certificate
 > No.  Neither. [...] The mote starts with a certificate

My understanding is that you're excluding the use of a PSK.  Why?

I'm completely confused about the word "Neither" applied
to the set that includes "certificate", followed by "The mote starts 
with a certificate".

 > one of MLE/802.15.9/piro/ohba documents.

It seems that the end state is (1) and/or (2), and that we must specify the
complete mechanism to get there.

ksjp

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Oct 2014 17:01:03 -0400

Kris Pister <[email-masked]> wrote:
    >> > The mote starts with [...] a certificate No.  Neither. [...] The
    >> mote starts with a certificate

    > My understanding is that you're excluding the use of a PSK.  Why?

1) PSK is easy.  PSK authenticated DTLS is defined, just use it rather
   than certificates, if you have an environment that can deal with it.

2) PSK fails a number of use cases and threats that many have said are
   important.

    > I'm completely confused about the word "Neither" applied to the set
    > that includes "certificate", followed by "The mote starts with a
    > certificate".

The mote does not start with a locally significant/root certificate.
It starts with a certificate from the vendor.

    >> > production network or 2) multiple L2 keys for the production
    >> network, No, the mote winds up with a locally significant certificate
    >> or
    > network-wide
    >> master key, and it uses those to derive (1) and/or (2) using one of
    >> MLE/802.15.9/piro/ohba documents.

    > It seems that the end state is (1) and/or (2), and that we must specify
    > the complete mechanism to get there.

Yes, we have to decide how to specify the exact key derivation mechanism; but
once the DTLS-secured 6top session is up we have the full expressive power of
YANG in which to do it.

---

From: Kris Pister <[email-masked]>
Date: Mon, 27 Oct 2014 20:07:31 -0700

OK, this seems like the beginnings of convergence.  I agree with you 
that PSK fails
a number of use cases and threats.  I'm very much in favor of being able 
to use
certificates to solve those problems.  I'm also in favor of allowing 
less-demanding
applications to use PSK, because as you say, PSK is easy.

I do think that its important to define a security framework that is 
both flexible and
complete.  In that vein, and trying to be cognizant of your terminology, 
I'll try again.
The mote starts with some authentication material, either
1) a pre-shared join key
or
2) a vendor certificate

The JCE starts with either
1) the same PSK as the mote (possibly tied to the joining mote MAC ID, 
possibly unique, ...)
or
2) a vendor certificate, and the public keys of one or more trust anchors

The mote ends up with either
1) a network wide master key
or
2) a locally significant certificate
from which it derives either
1) a single network-wide L2 key for the production network
or
2) multiple L2 keys for the production network, each associated with one 
or more neighbors

ksjp

---

From: Michael Richardson <[email-masked]>
Date: Tue, 28 Oct 2014 10:37:23 -0400

> The mote starts with some authentication material, either

I'm gonna be picky here again, because I don't want to confuse anyone.
Let's not call it a "join key", because that sounds like the L2 well-known
JOIN KEY.  Let's call it a "symmetric authenticator"

    > 1) the same PSK as the mote (possibly tied to the joining mote MAC ID,

I'm pretty sure that it needs to be completely unique per node MAC ID.
(Over in 6tisch, we agreed to say "node" rather than "mote"...)

    > 2) a vendor certificate, and the public keys of one or more trust anchors

I don't like saying "trust anchors" here because for many this will imply
talking to Versign or Komodo or something.  I think you mean: one or more
supply chain certificate chains in the trusted store.

    > 2) multiple L2 keys for the production network, each associated with one or
    > more neighbors

Exactly.
Let's talk today about giving better terminology to these things, and making
the expectations of this clear.  What you have just done is clearly
articulated the architectural requirements... we need to tighten up the
terminology, even if we have to make up abstract names like: Bob and Phil or Orange and Purple.

We agreed to talk today about how the 6top DTLS session will be authenticated
when dealing with certificates;  for me this has become core ANIMA stuff,
although I'm not sure the ANIMA people yet agree.

ps: it seems I'm coming to gogo6live Nov.19/20 in Bay area, after IETF91;
    got a couple of days free beforehand.