Subject: [6tisch-security] Comments on “6-TiSCH Security - Some Notes and Thoughts on Security Properties; Date: 2014-03-24”

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 31 Mar 2014 11:17:16 +0000

René, team,

Up front, I haven’t had the time to catch up with the details of the WG, so may not be aware of context, previous decisions, etc. Please let me know where I’m missing the point and educate me.

Comments on “6-TiSCH Security - Some Notes and Thoughts on Security Properties; Date: 2014-03-24”

Slide 4: All statements are high level and not yet precise, but I guess the point is to move into the right direction at this point. (Which it does).

“Security-related”:
Third bullet: Are you trying to say “A device must automatically recover from DoS attacks”? (What else?)  Makes sense to me.
Fourth bullet: Can you give an example? Do you mean that the security protocols should not significantly increase the attack surface on comparison to a device without such protocols? I don’t understand the “network outage” point.

Can you expand on “homogenous trust models” please?

Some statements on this slide make me nervous, like the last line “Dependency on on-board trusted platforms and trusted I/O interfaces should be reduced”. ACE is defining 3 classes of devices with varying capabilities, and I think we should do the same, right? So the fact that low-end devices may not support trusted platform modules should not mean we don’t support it. In fact, I think those are a key element in a secure solution (for a certain device class, for sure).

I suggest we start introducing the concept of a “domain” in this deck. To me, a domain is a set of nodes with a common trust anchor. That could be a CA-type trust anchor, but it could also be done differently, for example by pre-staging domain-wide shared secrets. In the authentication step (slide 5), devices exchange and (probably) validate their identities. If we want to reduce dependencies on central resources (slide 4: “Security protocols should allow to be run locally, without third party involvement, if at all possible”) then each node needs to be able to authenticate and authorise each other node. The simplest form of authorization is “this node belongs to the same domain, I’ll route traffic through/from this device”. Thoughts?

Conversely, without the concept of a domain, I don’t really see how authentication can work?

Device enrolment (slide 5): in your model a device always enrols to an access point. I think we should make this model more flexible, and allow another client to proxy such procedures. In draft-pritikin-bootstrapping-keyinfrastructures we speak of a “proxy”, which could be in this model either another client or an access point.

I would prefer if we had a diagram that reflects that. Or, in case we cannot support that, we should state that enrolment MUST happen in the reach of an access point. (Because that would be the consequence, right?)

“Authorization decision may be delegated to server KDC or other 3rd-party device”: In my brain the KDC ALWAYS makes the authorization decisions. Other nodes may cache such information of course. I.e., a node or access point cannot make an authorization decision. Am I missing something?

Slide 5, bottom: If I read this correctly, we do NOT expect a new client to have an assigned IP address BEFORE this process starts? (in your flow, IP address assignment comes after authorization). To be clear, I fully support this, our model in draft-pritikin-bootstrapping-keyinfrastructures assumes only link local addresses. Are you thinking along the same lines?

Slide 6: “Access Point B decides on whether/how to authorize device A”: How can an access point make this decision? In my world, it can’t. (see above). Can you give an example here please?

Slide 7: Can you define “Third party” please? In my understanding, normally the KDC is part of the “domain” as I call it. So I wouldn’t call it “third party”. In our model there is the “MASA”, which is a vendor or integrator cloud service. That to me would be a third party. Are we saying the same?

Let me stop here for now, enough questions for one mail! ☺  Generally, it would be great if we could map our two worlds together, so that we’re talking the same language. Sorry if I’m the odd one out here, I’d really appreciate your patient help though! :-)

Talk later in the 6tisch security call.

Michael

---

From: Paul Duffy <[email-masked]>
Date: Mon, 31 Mar 2014 10:09:24 -0400

On 3/31/2014 7:17 AM, Michael Behringer (mbehring) wrote:
>
> Some statements on this slide make me nervous, like the last line 
> “Dependency on on-board trusted platforms and trusted I/O interfaces 
> should be reduced”. ACE is defining 3 classes of devices with varying 
> capabilities, and I think we should do the same, right?
>

Hi Michael

Can you clarify re: the three device classes ACE is defining? I want to 
be sure we're not confusing these with CORE device classifications.

> So the fact that low-end devices may not support trusted platform 
> modules should not mean we don’t support it. In fact, I think those 
> are a key element in a secure solution (for a certain device class, 
> for sure).
>
>

Agreed.

Cheers

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 31 Mar 2014 14:19:46 +0000

Paul, I’m referring to slide 8 of http://www.ietf.org/proceedings/89/slides/slides-89-ace-2.pdf.

Michael

From: Paul Duffy (paduffy)
Sent: 31 March 2014 16:09
To: Michael Behringer (mbehring); [email-masked]
Subject: Re: [6tisch-security] Comments on “6-TiSCH Security - Some Notes and Thoughts on Security Properties; Date: 2014-03-24”

Some statements on this slide make me nervous, like the last line “Dependency on on-board trusted platforms and trusted I/O interfaces should be reduced”. ACE is defining 3 classes of devices with varying capabilities, and I think we should do the same, right?

Hi Michael

Can you clarify re: the three device classes ACE is defining? I want to be sure we're not confusing these with CORE device classifications.

So the fact that low-end devices may not support trusted platform modules should not mean we don’t support it. In fact, I think those are a key element in a secure solution (for a certain device class, for sure).

Agreed.

Cheers

---

From: Paul Duffy <[email-masked]>
Date: Mon, 31 Mar 2014 10:21:33 -0400

OK, you were referring to the core designations.  Thanks

On 3/31/2014 10:19 AM, Michael Behringer (mbehring) wrote:
>
> Paul, I’m referring to slide 8 of 
> http://www.ietf.org/proceedings/89/slides/slides-89-ace-2.pdf.
>
> Michael
>
> *From:*Paul Duffy (paduffy)
> *Sent:* 31 March 2014 16:09
> *To:* Michael Behringer (mbehring); [email-masked]
> *Subject:* Re: [6tisch-security] Comments on “6-TiSCH Security - Some 
> Notes and Thoughts on Security Properties; Date: 2014-03-24”
>
>     “Dependency on on-board trusted platforms and trusted I/O
>     interfaces should be reduced”. ACE is defining 3 classes of
>     devices with varying capabilities, and I think we should do the
>     same, right?
>
>
> Hi Michael
>
> Can you clarify re: the three device classes ACE is defining? I want 
> to be sure we're not confusing these with CORE device classifications.
>
>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Mon, 31 Mar 2014 14:40:39 +0000

Sorry, still learning a lot here, I’m not a “small device” guy at all, so will need to be corrected from time to time ;-)

Michael

From: Paul Duffy (paduffy)
Sent: 31 March 2014 16:22
To: Michael Behringer (mbehring); [email-masked]
Subject: Re: [6tisch-security] Comments on “6-TiSCH Security - Some Notes and Thoughts on Security Properties; Date: 2014-03-24”

Michael

From: Paul Duffy (paduffy)
Sent: 31 March 2014 16:09
To: Michael Behringer (mbehring); [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch-security] Comments on “6-TiSCH Security - Some Notes and Thoughts on Security Properties; Date: 2014-03-24”

Hi Michael

Agreed.

Cheers

---

From: Paul Duffy <[email-masked]>
Date: Mon, 31 Mar 2014 10:43:28 -0400

No worries at all.

I'm in the process of reviewing several related IETF and IEEE 
constrained security efforts.  Just making sure I've got them lined up 
correctly.

On 3/31/2014 10:40 AM, Michael Behringer (mbehring) wrote:
>
> Sorry, still learning a lot here, I’m not a “small device” guy at all, 
> so will need to be corrected from time to time ;-)
>
> Michael
>
> *Sent:* 31 March 2014 16:22
>     <mailto:[email-masked]>
>     *Subject:* Re: [6tisch-security] Comments on “6-TiSCH Security -
>     Some Notes and Thoughts on Security Properties; Date: 2014-03-24”
>
>         Some statements on this slide make me nervous, like the last
>         line “Dependency on on-board trusted platforms and trusted I/O
>         devices with varying capabilities, and I think we should do
>         the same, right?
>
>
>     Hi Michael
>
>     Can you clarify re: the three device classes ACE is defining? I
>     want to be sure we're not confusing these with CORE device
>     classifications.
>
>
>
>     modules should not mean we don’t support it. In fact, I think
>     those are a key element in a secure solution (for a certain device
>     class, for sure).
>
>
>     Agreed.
>
>     Cheers
>
>
>