Subject: [6tisch-security] agenda for 2014-05-05 6tisch security call

From: Michael Richardson <[email-masked]>
Date: Sun, 04 May 2014 22:06:27 -0400

Agenda.

1) notewell.
2) intros
3) pritikin-bootstrapping/autonomic vs EAP-TLS vs 6top/COAP/DTLS.
4) if possible, how is 802.1AR being used in the VoIP space.

-- remember that the call is recorded, and the NoteWell applies.

-- The URL to access the webex, which will we use for audio only:
  https://cisco.webex.com/cisco/j.php?MTID=m2fe139bf876cea3ec62750cd580b7908

-- we will resume with the etherpad at:
   http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-6tisch-security

I'm at +1 613 276-6809, IM: [email-masked] or [email-masked],
if you need more than that to get in, or are having difficulties.
Please make sure your audio works, and that you mute when not talking.

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

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 05 May 2014 09:31:59 -0400

>    https://cisco.webex.com/cisco/j.php?MTID=m2fe139bf876cea3ec62750cd580b7908

I will most likely not be talking.  As I have really not set up my corp 
system for miking.  And I have to go through the corp VPN for it.  My 
Fedora system has grief with WebEx.  There has been a discussion on how 
to get WebEx working on the Fedora list, but I just don't have the time.

---

From: Rene Struik <[email-masked]>
Date: Mon, 05 May 2014 11:26:57 -0400

Dear colleagues:

During the 6tisch security conf call today, discussion referenced the 
notion of "domain". Somewhat unfortunately, the diagrams referred to 
communications between a new entity and the domain, whereas in real life 
communications is between devices (i.e., between a new entity and 
another network node [who may be a representative of a domain]).

It seems to be useful to define the notion of domain somewhat more 
precisely. One can imagine various levels of granularity:
a) universe: in this case, the new entity would accept to become part of 
any network.
b) single PAN: in this case, the new entity would accept to become part 
of the specific PAN that is singled out here. {This also means that if a 
device moves from one PAN to another one, e.g., in the same 
manufacturing plant, it has to get another "domain cert"}.
c) bunch of PANs: in this case the new entity would accept to become 
part of any PAN that is in the "bunch of PANs" list.

In all cases, the "domain" notion captures an element that is used for 
authorization and not authentication.

Now for a thought experiment:
a) provisioning step. Suppose one has a single global CA for which the 
public key Q_{CA} is embedded with every device during manufacturing.
b) authentication step. Now, any successful execution of an 
authenticated key agreement scheme where devices present certs vouched 
for by that single CA will result in mutual authentication between the 
new entity and any network representative.
c) authorization step. More fine-grained access control could depend on 
new entity or network representative having configuration settings that 
allow further filtering (e.g., network representative has access control 
list where new entity shows up as a member (and may inquire with third 
party authorization device if new entity does not show up on this list, 
in which case third party could  trigger update of this access control 
list/configuration setting).

Some of this may be intertwined in message flows. However, 
authentication can be done locally (if devices have each others' root CA 
key) and only authorization may involve third party that my be somewhere 
many hops away in the cloud. Here, one should note that the 
authentication flows and authorization flows do not necessarily create 
hierarchical flow dependencies.

Wouldn't this be simpler?

As a final note: TLS does not have message elements that can carry 
authorization tokens (the protocol data elements are simply not there). 
So, any protocol that may rely on carrying "piggy-backed data" cannot 
possibly be mapped to TLS (or DTLS for that matter). Hence, my email 
question a few weeks ago (April 10, 2014, 11:37am EDT) on "TLS/DTLS 
piggy-backing".

On 5/4/2014 10:06 PM, 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: Michael Richardson <[email-masked]>
Date: Mon, 05 May 2014 14:12:40 -0400

Rene Struik <[email-masked]> wrote:
    > communications between a new entity and the domain, whereas in real
    > life communications is between devices (i.e., between a new entity and

please see section 1.3 at:
      http://tools.ietf.org/html/draft-richardson-6tisch-security-architecture-02#section-1.3

which refers to:
  http://tools.ietf.org/html/draft-irtf-nmrg-autonomic-network-definitions-00#section-2
and:
  http://tools.ietf.org/html/draft-pritikin-bootstrapping-keyinfrastructures-00#section-2

While it is true that communication is between two nodes, and while it is
possible that some members of an LLN may be sufficiently capable to run an
entire CA, but abstracting that role out elsewhere, we make it possible for
everyone to play.

802.1X and PANA uses of EAP-TLS have three parties that they identify:
  - supplicant    (new entity)
  - authenticator (second device, proxy)
  - authorization server (more capable, central device)

---

From: Rene Struik <[email-masked]>
Date: Mon, 05 May 2014 14:44:13 -0400

Hi Michael:

Some comments below.
> entire CA, but abstracting that role out elsewhere, we make it possible for
RS>>
I do not understand the para above, since in my email this morning after 
the 6tisch security conf call, I did not refer to devices playing their 
own CA at all. Besides, to my knowledge, there has been no conclusion 
yet that devices would not be capable of executing a public key protocol.
<<RS
>    - authorization server (more capable, central device)
RS>>
802.1x and PANA all seem to involve an inline third party, which is 
highly undesirable in spotty communication networks and, in particular, 
TSCH-based networks, due to communication time latencies. To my 
knowledge, we have not picked either of these schemes (in case I am 
missing something here, I would be curious about the quantified analysis 
that supports this pick, except to say that protocols "are out there").
<<RS

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 May 2014 08:26:23 -0400

To remind, we moved the call from the 19th to the 20th at 10am EDT.
That's 90 minutes from this email.

1) notewell.
2) intros
3) Rene had some material to present?  Did it happen last week,
   it seems not?
4) review of claim certificate process, vs EST with token.

---

From: Rene Struik <[email-masked]>
Date: Tue, 20 May 2014 09:45:27 -0400

Hi Michael:

At the previous conf call of May 12, 2014, we discussed message flows of 
w/HART join process, as also alluded to in my email below (the specs 
could not be distributed due to copyright restrictions).

In my mind, 6TiSCH protocol can use similar communication flows as 
w/HART where only non-local communication flows (between joining node 
and network manager) would be
i) passing join/authentication information from joining node to network 
manager (and back);
ii) passing configuration parms from network manager to joining node 
(keys, links, frame links) and neighbor report from joined node to 
network manager.

MAIN OUTSTANDING ISSUES (in my mind):
a) Packet sizes:
get more info on packet sizes configuration parms, as w/HART uses. Note 
RS: during call, Tom Phinney suggested contacting Wally Bratt from HART 
Comm. Foundation for this).  Note RS: Shouldn't, e.g., Dust Networks 
have info on packet sizes/structure?; ISA SP100.11a metrics would also 
help, as would ZigBee 2.0 config parms. Does, e.g., Cisco have useful 
data points here?
b) Device Ids:
With industrial control, network manager would look up "tag name" device 
in pre-configured database. Details on tag name syntax, how assigned, 
and how bound to, e.g., EUI-64 are missing. Note RS: Perhaps, Tom 
Phinney could point at tag name syntax and lifecycle aspects here?
c) Join process impact on network:
Pascal Thubert asked "when network would explode with join". Note RS: 
the following questions come to mind:
- how does joining  node find a time slot to send first join packet to 
neighbor node (presumably, this would require listening for Enhanced 
Beacon, but details on schedule in terms of time and channels seems 
incomplete [min-schedule suggests 101x15ms slotframe and "less than 10s 
repeat of EBs, but that leaves lots of dead time and does not suggest a 
schedule that would create a common time window where two devices would 
both be awake).
- how does joining node negotiate a local schedule with neighbor node 
for execution of join protocol (draft-watteyne-6tisch-tisch-00 refers to 
local schedule negotiation need, but unclear whether this has been 
looked into in detail).
- for local traffic (joining node/neighbor), it seems Pascal Thubert's 
"exploding network" may not happen easily. Nevertheless, unclear what 
impact of "join priority flag TSCH 802.15.4e frames is [that seems to 
have been designed with legacy w/HART in mind (centralized solution). 
With centralized tree-like solution, lots of traffic happens close to 
the root, thus potentially amplifying congestion around root node 
(=network manager?).
d) crypto protocol details of join protocol:
Note RS: I can solve this (close to optimal design already done 
[assuming I can do this "without hands tied behind the back"])
e) authorization/trust management:
it is here where binding of ids to public keys via certs and lifecycle 
aspects play a role, as well as syntax/semantics of authorization 
messages. Note RS: question is whether ACE could play a role here 
(current charter discussions seem to be endless, though). As has been 
brought up before, a potential instantiation of certs would be the use 
of 802.1ar certs, but this is certainly not the only way of doing things.

There are lots of other things we should consider, outside the join 
protocol realm.

------- Original Message --------
Subject: 	Re: [6tisch-security] agenda(?) for call today
Date: 	Mon, 12 May 2014 09:53:37 -0400
From: 	Rene Struik <[email-masked]>
To: 	Michael Richardson <[email-masked]>, [email-masked]

Hi Michael et al:

Another topic worth exploring more is the join protocol details.

(There are many other aspects, including certs, as you mentioned, more 
general security architecture, provisioning, etc., but below only deals 
with join.)

With w/HART, the join process only interacts with the network manager 
(62591, Annex A.3, Fig. A.1) for
-forwarded join from joining node to network manager;
-passing configuration parms from network manager to joining node (keys, 
links, frame links) and neighbor report from joined node to network manager.
All other communications are local, between joining device and neighbor 
(resp. with maintenance tool).

It may have merit if we could use similar communication flows with 
6tisch, i.e., keep most traffic local to the joining device, except for 
configuration parms exchange and authorization info passing.

Most important consideration (from communication perspective) would be 
that non-local traffic would be minimized, as also w/HART does. From a 
marketing perspective, mimicking the communication flows w/HART already 
has would keep all time scheduling considerations for w/HART as 
currently there and 6TiSCH as to be detailed roughly the same. This 
would longer term help in pushing 6tisch-style security scheme to 
w/HART, since from a distance it looks the same (although trying to 
scrap the maintenance tool).

Of course, this does not deal with the details of the joining protocol 
itself; only the flows.

What about we look at some of the flows, and enumerate all issues that 
need to be addressed here, both from a security perspective and 
otherwise. We can then assign people to find missing information (I am 
esp. curious about how devices know when to send/receive and 
contributions of cycling efforts to total time latency).

We could go over w/HART join flows during the call, to trigger these 
questions.

Best regards, Rene

---

From: Michael Richardson <[email-masked]>
Date: Tue, 20 May 2014 09:55:10 -0400

> https://cisco.webex.com/cisco/j.php?MTID=m2fe139bf876cea3ec62750cd580b7908

Pascal, this URL does not work for today.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 May 2014 22:49:57 -0400

To remind, we moved the call from the 26th to the 27th at 10am EDT.
That's 90 minutes from this email.

1) notewell.
2) intros
3) recap of draft-piro-
4) wirelesshart -way --- how does the communication work?
5) how to summarize all of this to the working group
6) how to close this process up?

---

From: Rene Struik <[email-masked]>
Date: Mon, 26 May 2014 23:09:57 -0400

Hi Michael:

I would like to discuss the outstanding issues I summarized in my email 
of Tue last week, May 20, 2014, 9:45am EDT (see 
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html). 
This was also one of the action items at the conclusion of last week's 
6TiSCH security call.

FYI - the w/HART communication flows were discussed during the 6TiSCH 
security conf call the week before, on Mon May 12, 2014. If one wishes 
to go over this again, that is fine, but I would prefer us giving 
preference to taking on already articulated issues (which were assigned 
as homework assignment to reflect upon) first (i.e., prior to item #4 of 
the proposed agenda).

As another agenda point, I would like us to discuss the frequency of 
future calls (as part of EOB).

Best regards, Rene

---

From: Rene Struik <[email-masked]>
Date: Mon, 26 May 2014 23:20:10 -0400

Dear colleagues:

I would like add one more topic to the mix: initialization and 
synchronization of ASN numbers. This relates to item c) "join process 
and impact on the network" of my outstanding topic last of Tue last week 
(referenced below).

Best regards, Rene

On 5/26/2014 11:09 PM, Rene Struik wrote:
> Hi Michael:
>
> I would like to discuss the outstanding issues I summarized in my 
> email of Tue last week, May 20, 2014, 9:45am EDT (see 
> preference to taking on already articulated issues (which were 
> assigned as homework assignment to reflect upon) first (i.e., prior to 
> item #4 of the proposed agenda).
>
>> I'm at +1 613 276-6809, IM:[email-masked]  [email-masked],
>> Michael Richardson<[email-masked]>, Sandelman Software Works
> email:[email-masked]  | Skype: rstruik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 27 May 2014 06:50:05 +0000

Hi René:

I'm interested in following up with the ND ARO thread (ARO and DTLS/CoAP) that Michael just launched. If that's what the wireless HART discussion is about then I think we're not done yet with it.

Still I agree we need to report on the homework. Could you please propose a list of specific items like the topic below and evaluate the time that is required at the call to present the issue and get initial feedback?

With this, we can work on spreading the time over the next calls.

I think we could have a wiki page on pending flows and issues on the repo or the IETF site, and I can help with that if you like.

Many thanks for all this!

Pascal

From: 6tisch-security [mailto:[email-masked]] On Behalf Of Rene Struik
Sent: mardi 27 mai 2014 05:20
To: Michael Richardson; [email-masked]
Subject: Re: [6tisch-security] agenda for 2014-05-27 6tisch security call

Dear colleagues:

I would like add one more topic to the mix: initialization and synchronization of ASN numbers. This relates to item c) "join process and impact on the network" of my outstanding topic last of Tue last week (referenced below).

Best regards, Rene

I would like to discuss the outstanding issues I summarized in my email of Tue last week, May 20, 2014, 9:45am EDT (see http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html). This was also one of the action items at the conclusion of last week's 6TiSCH security call.

FYI - the w/HART communication flows were discussed during the 6TiSCH security conf call the week before, on Mon May 12, 2014. If one wishes to go over this again, that is fine, but I would prefer us giving preference to taking on already articulated issues (which were assigned as homework assignment to reflect upon) first (i.e., prior to item #4 of the proposed agenda).

As another agenda point, I would like us to discuss the frequency of future calls (as part of EOB).

Best regards, Rene

1) notewell.

2) intros

3) recap of draft-piro-

I'm at +1 613 276-6809, IM: [email-masked]<mailto:[email-masked]> or [email-masked]<mailto:[email-masked]>,

--

Michael Richardson <[email-masked]><mailto:[email-masked]>, Sandelman Software Works

[email-masked]<mailto:[email-masked]>

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 May 2014 09:40:04 -0400

Rene Struik <[email-masked]> wrote:
    > http://www.ietf.org/mail-archive/web/
    > 6tisch-security/current/msg00086.html). This was also one of the action
    > items at the conclusion of last week's 6TiSCH security call.

Good, let's do that.

    > as homework assignment to reflect upon) first (i.e., prior to item #4
    > of the proposed agenda).

I agree; it was my goal to bring closure to that part.

    > future calls (as part of EOB).

Good idea.

---

From: Jonathan Simon <[email-masked]>
Date: Tue, 27 May 2014 06:40:35 -0700

Rene had asked on a previous call for someone to summarize WirelessHART
joining - here you go.

* One or more devices are sending beacons to advertise the presence of the
network. In WirelessHART, this frame is unencrypted, but authenticated with
a well known key.  The beacon contains the current ASN, which the joining
device uses to synchronize its clock.

* Once the joining node has heard a beacon, it continues listening for
additional beacons for a short specified timeout.

* The joining node encrypts a frame containing some HART specific content,
including a list of beaconing neighbors it heard in the previous steps. The
size of the payload is ~ 60 bytes.  The packet is routed by a "proxy" node
- the joining parent. The frame is authenticated using the well-known key,
and encrypted using a shared symmetric key known only by the node and the
manager.

* The manager responds with a frame containing the run-time link-layer key,
the node's new short address (this takes the place of PAN coordinator
association), and a unicast session key and starting nonce for the manager.
This frame is encrypted with the symmetric key. The payload is ~ 60 bytes,
and is routed to the proxy for delivery to the joining node - the proxy
uses the link-layer well known key on the frame.

* At this point the joining node transitions to using the run-time
link-layer key for all link-layer frames, and the manager unicast session
for end-to-end manager traffic. This ends the initial security handshake.

* Over a number of additional frames, the manager assigns additional
sessions, including broadcast sessions, and a unicast session to the
Gateway (sink for all data traffic), and additional communications
resources, routing information, etc.  There is no explicit transition from
joining to joined - the mote transitions when certain key frames are
received.

* Note that a WirelessHART link-layer frame contains and additional frame
type byte and a 4-byte link-layer MIC, on top of the unsecured 15.4 frame.
A network frame contains an additional 16-40 bytes of addressing, routing,
security and other information.

Hope this help!

Jonathan

On Mon, May 26, 2014 at 8:09 PM, Rene Struik <[email-masked]> wrote:

>  Hi Michael:
>
> I would like to discuss the outstanding issues I summarized in my email of
> Tue last week, May 20, 2014, 9:45am EDT (see
> http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html<http://cp.mcafee.com/d/5fHCMUp41ESyNt55OWtSjtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsTJQXIfcLZvC4TQTS6eLsKCO-PPXX3XUVzBHFShjlKepVkffGhBrwqrhdI6XYyMCY-ehojd79KVI05bVKY01MjbX6NehDY05zAVkIjbQ-PspjbppKcvxf5q4rTKYVMedKjBiNcLjXdNBcIn8lrxrW0GnPtU02rhhuhKr1vF6y0QJKjBiNcLjXdNBcIqnjh1F7U8qq87qNd42tQm2ZTOWoUQgejBiNcQgk-Pspjb6y2SDDCT63pO_o>).
> security conf call the week before, on Mon May 12, 2014. If one wishes to
> go over this again, that is fine, but I would prefer us giving preference
> to taking on already articulated issues (which were assigned as homework
> assignment to reflect upon) first (i.e., prior to item #4 of the proposed
> agenda).
>
>   https://cisco.webex.com/cisco/j.php?MTID=m2fe139bf876cea3ec62750cd580b7908 <http://cp.mcafee.com/d/5fHCN0SyNt55OWtSjtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsTJQXIfcLZvC4TQTS6eLsKCO-PPXX3XUVzBHFShjlKepVkffGhBrwqrjdI6XYyMCY-ehojd79KVIDeqR4IOQGmHM0L3-nOQGmHwzMh93o93gUVldTQmjhOgtu7em_mvIUCevLp1ZWV0sqerL6T9OFoCnFZCUOCmbAaJMJZ0lbVKY01dEEL8TdwLQzh0qmT9OFoCnFZCUOCmdbFEwQzY4dd43JoCy1eWb1uXVtcsq879OFoCq8avpKcFBzh1rjPPrz1LmTw7w17>
>
>    http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-6tisch-security <http://cp.mcafee.com/d/2DRPow71NJ5yWabBQXICXCQn1PapJ5MsO-rhs76zB5dAQsCT7DDD6bTdyd9aRw2zVg_oYKrfB3ZzOVLrFToupvW_c9LFLIctuVtdBZDDTS7TNP7bnjIyCHssPOEuvkzaT0QSOrodTV5xdVYsyMCqejtPo0fVA_yJG7jHk-Di-rL00kzhPuZYmO5p_gLbVKBTzhOnsDaBypuDSrzapoSVelb4OZfIT6kONsxlK5LE2FvdTw09J55V6VI5-Aq83iSVelb4OZfIT6kONFtd46AvwxFEwtH4Qg9ThobTvbFzzh0Velb4Ph1jXdNBcIq8bquursodJiZvpmK6GwY>
>
> Michael Richardson <[email-masked]> <[email-masked]>, Sandelman Software Works
> 6tisch-security mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch-security <http://cp.mcafee.com/d/2DRPoO86QmbEEKnjKOrKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCZKDtxVB_HYMC-C-MNRXBQSnSuvvovv7csJteOaqJNPfaxVZicHs3jr1JwTvAm4TDNOb2pEVdTdAVPmEBC5eBYTu00U9GX33VkDa3JssDaBypuDSrzapoSVelb4OZfIT6kONsxlK5LE2FvdTw09J55V6VI5-Aq83iSVelb4OZfIT6kONFtd46AvwxFEwtH4Qg9ThobTvbFzzh0Velb4Ph1jXdNBcIq8bquursodLWbv>
>
>
>
> --
> http://cp.mcafee.com/d/avndzgQ93gArhoKyyVteX9KVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrSWtS7Cn-LP2rWrX37nKnjpvpVZZxZYsNORQX8FGT7cYG7DR8OJMddECQjt-hojuv78I9CzATsSjDdqymokWnPtU03wCHIcfBisEeRNOsGm9BWvpKcFBzrAVkIjbQ-Pspjb5O5mUm-waBYTu00CQknArCMnWhEwdbrAVkIjbQ-Pspjb6BQQgqh-26Cy1SIjh0Dt5wLtYKCed43AVkIjd45fIT6kONEwJFVVJNwSeVhsrLe-Fkd
>
>

-- 
-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Dust Networks at Linear Technology
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
[email-masked]

**LINEAR TECHNOLOGY CORPORATION**
*****Internet Email Confidentiality Notice*****
 This e-mail transmission, and any documents, files or previous
e-mail messages attached to it may contain confidential information that
is legally privileged. If you are not the intended recipient, or a
person responsible for delivering it to the intended recipient, you are
hereby notified that any disclosure, copying, distribution or use of any of
the information contained in or attached to this transmission is
STRICTLY PROHIBITED. If you have received this transmission in error,
please immediately notify me by reply e-mail, or by telephone at (510)
400-2936, and destroy the original transmission and its attachments without
reading or saving in any manner. Thank you.

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 27 May 2014 06:42:44 -0700

The IETF Etherpad instance is down. I propose we use
https://beta.etherpad.org/6tisch this week until it gets resolved.

In case this instance doesn't work well (we had some problems on Friday), I
can take notes locally.

Thomas

On Tue, May 27, 2014 at 6:40 AM, Michael Richardson <[email-masked]>
wrote:

> email
> assigned

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 May 2014 09:44:58 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > I?m interested in following up with the ND ARO thread (ARO and
    > DTLS/CoAP) that Michael just launched. If that?s what the wireless HART
    > discussion is about then I think we?re not done yet with it.

so, we are all in violent in agreement: we have all found an elephant,
we are just on different sides of things.
(cf: http://en.wikipedia.org/wiki/Blind_men_and_an_elephant )

    > I think we could have a wiki page on pending flows and issues on the
    > repo or the IETF site, and I can help with that if you like.

When you say "pending flows", I think you mean people conversations,
not packet sequences?

---

From: Rene Struik <[email-masked]>
Date: Tue, 27 May 2014 09:50:57 -0400

Can I read up on ARO and DTLS/CoAP in preparation for the call?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 May 2014 10:02:44 -0400

Thomas Watteyne <[email-masked]> wrote:
    > The IETF Etherpad instance is down. I propose we
    > use https://beta.etherpad.org/ 6tisch this week until it gets resolved.

I couldn't connect to that one either... (I removed the space)
https://etherpad.mozilla.org/wJimt3mv1c

seems to work.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 May 2014 11:31:20 -0400

Jonathan Simon <[email-masked]> wrote:
    > * One or more devices are sending beacons to advertise the presence of
    > the network. In WirelessHART, this frame is unencrypted, but
    > authenticated with a well known key.  The beacon contains the current
    > ASN, which the joining device uses to synchronize its clock.

I think that this step won't change at all.
draft-piro-6tisch-security-issues-01 calls this a Partial and Hybrid Secure
Network.

    > additional beacons for a short specified timeout.

You don't explain this part, but one assumes one does this in order to:
  1) perhaps obtain a better (louder) beacon.
  2) in order to hear the correct (non-malicious beacon) as well.

We also need to listen for an RA during some slotted-Aloha period,
which the beacon(s) would tell us about.

    > * The joining node encrypts a frame containing some HART specific
    > content, including a list of beaconing neighbors it heard in the
    > previous steps. The size of the payload is ~ 60 bytes.  The packet is
    > routed by a "proxy" node - the joining parent. The frame is
    > authenticated using the well-known key, and encrypted using a shared
    > symmetric key known only by the node and the manager.

The name for this message is the ND+ARO... That's how things map.
And the ND+ARO is "routed by a proxy node", exactly the same.
The frame is authenticated using a public key rather than a well known
symmetric key.  The message is probably not encrypted.

What is the purpose of including the list of beaconing neighbours?

    > * The manager responds with a frame containing the run-time link-layer
    > key, the node's new short address (this takes the place of PAN
    > coordinator association), and a unicast session key and starting nonce
    > for the manager. This frame is encrypted with the symmetric key. The
    > payload is ~ 60 bytes, and is routed to the proxy for delivery to the
    > joining node - the proxy uses the link-layer well known key on the
    > frame.

ND+ARO reply, but possibly not including all of this information.
My understanding is that in the WirelessHart case, that the format of this
frame is in the same sensor/acutator format as application layer traffic.

In the 6tisch situation, this is where we would like to insteed start
the DTLS/CoAP session.  Ideally, we'd like like it to be end-to-end, but the
node is not completely on the network, and so it might still require a
proxy.  That *could* be trivially in the form an IPIP header, or it could
more complex.

    > link-layer key for all link-layer frames, and the manager unicast
    > session for end-to-end manager traffic. This ends the initial security
    > handshake.

Agreed --- one can imagine that the node might remove the JOIN key from its
MAC, and replaces it with the run-time key, and that might even involve
resetting that chip or something.

    > resources, routing information, etc.  There is no explicit transition
    > from joining to joined - the mote transitions when certain key frames
    > are received.

This is akin to the 6top schedule distribution.

    > * Note that a WirelessHART link-layer frame contains and additional
    > frame type byte and a 4-byte link-layer MIC, on top of the unsecured
    > 15.4 frame.  A network frame contains an additional 16-40 bytes of
    > addressing, routing, security and other information.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Jonathan Simon <[email-masked]>
Date: Tue, 27 May 2014 09:41:12 -0700

Responses inline

> draft-piro-6tisch-security-issues-01 calls this a Partial and Hybrid Secure

JS - How the joining node trusts the beacon appears to be one of Rene’s questions.  A well-known key allows you to distinguish it from another protocol, but it doesn’t protect you against an attacker. One option is generating the key based on one of the preconfigured certs. 
> which the beacon(s) would tell us about.

JS - it’s to hear louder beacons, or beacons from devices closer to the manager (coordinator).
> What is the purpose of including the list of beaconing neighbours?

JS - WirelessHART is centrally managed, so the additional connnectivity information is there for mesh management.  There is a separate discovery process (analogous to ND) in the running network to gather the same information, but it is typically slow.  
> ]     [email-masked]  http://cp.mcafee.com/d/5fHCMUe6wUqdEInhjKMUqekjtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsSCwXH3Pb_nVWZPhPRXBQSn7-hjjujVqWtAkRrCzAtOEuvkzaT0QSyrhdTV5xdVYsyMCqejtPo0aCMgYZnotrsdKjBiNcLjXdNBcIn8lrxrW0GnPtU02rd79EVjhdCBJOsGm9BWvpKcFBziWq834E-vZa1sg1o9NOsGm9Cy0hHa1EwmzmTQErvKr1ZiF        |   ruby on rails    [
> 
> 
> --
> http://cp.mcafee.com/d/1jWVIpdEInhjKMUqekjtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsSCwXH3Pb_nVWZPhPRXBQSn7-hjjujVqWtAkRrCzAtOEuvkzaT0QSyrhdTV5xdVYsyMCqejtPpesRG9pxjFvdTw0e2qKMM-l9OwXn79OFoCnFZCUOCmdKjBiNcLjXdNBcIn8lrxrW0GnPtU02rd79EVjhdCBJOsGm9BWvpKcFBziWq834E-vZa1sg1o9NOsGm9Cy0hHa1EwmzmTQErvKrU8X-yrFc

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 May 2014 15:58:50 -0400

> Can I read up on ARO and DTLS/CoAP in preparation for the call?

1) ARO is described in rfc6775.  It is an LLN extension to ND (including DAD),
   only without a requirement to multicast, or for all nodes to be listening.

2) draft-sarikaya-ace-cga-nd-01 describes adapting SEND to be more LLN
   happy.  Basically, ECDSA signatures on the ARO.

3) DTLS is described in rfc4347 and DTLS 1.2 [RFC6347], but really,
   you'll want to read some of the DICE drafts at:
   http://datatracker.ietf.org/wg/dice/
   the draft-ietf-dice-profile, but you may want to go deeper.
   We don't need to design any new cryptographic protocols or operations;
   we have a wealth of them already, we just need to explain how to use them.

4) CoAP is http://datatracker.ietf.org/doc/draft-ietf-core-coap/
   but, really, what is important is that the 6top API will use it:
   http://datatracker.ietf.org/doc/draft-ietf-6tisch-coap/

So regardless of what we might do, we can assume that the following
things will already be required, and code space will be allocated:
  1) IPv6 with 6lowpan-ND (ARO, etc.)
  2) DTLS + CoAP with some kind of authentication system.

That means the code space for DTLS and CoAP is free.  Anything else we
do will come with a code space impact.  Clearly, we may have a ram usage
impact as well, if we create many new DTLS sessions, and perhaps a custom
solution could use less ram, at least in principal.

If we specify a series of security objects, then it will map directly into
the /6t space that 6tisch-coap is creating and managing.  This is what
WirelessHART does.

---

From: Rene Struik <[email-masked]>
Date: Tue, 27 May 2014 17:15:47 -0400

Hi Michael:

Thanks for the references. Sorry - I have seen most of this stuff, but 
get easily confused by alphabet soup acronyms (which I have problems 
remembering).

Best regards, Rene

---

From: <[email-masked]>
Date: Wed, 28 May 2014 06:18:43 +0000

Hi Jonathan,

Thank you for sending the summary of w/HART joining.

I have question.

In w/HART, are all beacon frames authenticated with a well-known key even after a joining node obtained the runtime link layer key?

Regards,
Yoshihiro Ohba

From: 6tisch-security [mailto:[email-masked]] On Behalf Of Jonathan Simon
Sent: Tuesday, May 27, 2014 10:41 PM
To: Rene Struik
Cc: Michael Richardson; [email-masked]
Subject: Re: [6tisch-security] agenda for 2014-05-27 6tisch security call

Rene had asked on a previous call for someone to summarize WirelessHART joining - here you go.

* One or more devices are sending beacons to advertise the presence of the network. In WirelessHART, this frame is unencrypted, but authenticated with a well known key.  The beacon contains the current ASN, which the joining device uses to synchronize its clock.
* Once the joining node has heard a beacon, it continues listening for additional beacons for a short specified timeout.
* The joining node encrypts a frame containing some HART specific content, including a list of beaconing neighbors it heard in the previous steps. The size of the payload is ~ 60 bytes.  The packet is routed by a "proxy" node - the joining parent. The frame is authenticated using the well-known key, and encrypted using a shared symmetric key known only by the node and the manager.

* The manager responds with a frame containing the run-time link-layer key, the node's new short address (this takes the place of PAN coordinator association), and a unicast session key and starting nonce for the manager. This frame is encrypted with the symmetric key. The payload is ~ 60 bytes, and is routed to the proxy for delivery to the joining node - the proxy uses the link-layer well known key on the frame.
* At this point the joining node transitions to using the run-time link-layer key for all link-layer frames, and the manager unicast session for end-to-end manager traffic. This ends the initial security handshake.
* Over a number of additional frames, the manager assigns additional sessions, including broadcast sessions, and a unicast session to the Gateway (sink for all data traffic), and additional communications resources, routing information, etc.  There is no explicit transition from joining to joined - the mote transitions when certain key frames are received.
* Note that a WirelessHART link-layer frame contains and additional frame type byte and a 4-byte link-layer MIC, on top of the unsecured 15.4 frame.  A network frame contains an additional 16-40 bytes of addressing, routing, security and other information.
Hope this help!
Jonathan

On Mon, May 26, 2014 at 8:09 PM, Rene Struik <[email-masked]<mailto:[email-masked]>> wrote:
Hi Michael:

I would like to discuss the outstanding issues I summarized in my email of Tue last week, May 20, 2014, 9:45am EDT (see http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html<http://cp.mcafee.com/d/5fHCMUp41ESyNt55OWtSjtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsTJQXIfcLZvC4TQTS6eLsKCO-PPXX3XUVzBHFShjlKepVkffGhBrwqrhdI6XYyMCY-ehojd79KVI05bVKY01MjbX6NehDY05zAVkIjbQ-PspjbppKcvxf5q4rTKYVMedKjBiNcLjXdNBcIn8lrxrW0GnPtU02rhhuhKr1vF6y0QJKjBiNcLjXdNBcIqnjh1F7U8qq87qNd42tQm2ZTOWoUQgejBiNcQgk-Pspjb6y2SDDCT63pO_o>). This was also one of the action items at the conclusion of last week's 6TiSCH security call.

Best regards, Rene

1) notewell.

2) intros

3) recap of draft-piro-

  https://cisco.webex.com/cisco/j.php?MTID=m2fe139bf876cea3ec62750cd580b7908<http://cp.mcafee.com/d/5fHCN0SyNt55OWtSjtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsTJQXIfcLZvC4TQTS6eLsKCO-PPXX3XUVzBHFShjlKepVkffGhBrwqrjdI6XYyMCY-ehojd79KVIDeqR4IOQGmHM0L3-nOQGmHwzMh93o93gUVldTQmjhOgtu7em_mvIUCevLp1ZWV0sqerL6T9OFoCnFZCUOCmbAaJMJZ0lbVKY01dEEL8TdwLQzh0qmT9OFoCnFZCUOCmdbFEwQzY4dd43JoCy1eWb1uXVtcsq879OFoCq8avpKcFBzh1rjPPrz1LmTw7w17>

   http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-6tisch-security<http://cp.mcafee.com/d/2DRPow71NJ5yWabBQXICXCQn1PapJ5MsO-rhs76zB5dAQsCT7DDD6bTdyd9aRw2zVg_oYKrfB3ZzOVLrFToupvW_c9LFLIctuVtdBZDDTS7TNP7bnjIyCHssPOEuvkzaT0QSOrodTV5xdVYsyMCqejtPo0fVA_yJG7jHk-Di-rL00kzhPuZYmO5p_gLbVKBTzhOnsDaBypuDSrzapoSVelb4OZfIT6kONsxlK5LE2FvdTw09J55V6VI5-Aq83iSVelb4OZfIT6kONFtd46AvwxFEwtH4Qg9ThobTvbFzzh0Velb4Ph1jXdNBcIq8bquursodJiZvpmK6GwY>

I'm at +1 613 276-6809<tel:%2B1%20613%20276-6809>, IM: [email-masked]<mailto:[email-masked]> or [email-masked]<mailto:[email-masked]>,

--

https://www.ietf.org/mailman/listinfo/6tisch-security<http://cp.mcafee.com/d/2DRPoO86QmbEEKnjKOrKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCZKDtxVB_HYMC-C-MNRXBQSnSuvvovv7csJteOaqJNPfaxVZicHs3jr1JwTvAm4TDNOb2pEVdTdAVPmEBC5eBYTu00U9GX33VkDa3JssDaBypuDSrzapoSVelb4OZfIT6kONsxlK5LE2FvdTw09J55V6VI5-Aq83iSVelb4OZfIT6kONFtd46AvwxFEwtH4Qg9ThobTvbFzzh0Velb4Ph1jXdNBcIq8bquursodLWbv>

--

cell: +1 (647) 867-5658<tel:%2B1%20%28647%29%20867-5658> | US: +1 (415) 690-7363<tel:%2B1%20%28415%29%20690-7363>

--
--
Jonathan Simon, Ph. D
Director of Systems Engineering
Dust Networks at Linear Technology
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
[email-masked]<mailto:[email-masked]>

**LINEAR TECHNOLOGY CORPORATION**
*****Internet Email Confidentiality Notice*****
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

---

From: Jonathan Simon <[email-masked]>
Date: Wed, 28 May 2014 07:49:22 -0700

Yoshihiro -

Q. In w/HART, are all beacon frames authenticated with a well-known key
even after a joining node obtained the runtime link layer key?

A. Yes. In WirelessHART the beacons (called "advertisements" but they serve
the same purpose and have similar content) are intended for devices not yet
in the network, so they always use the well-known key.  To discover other
nodes within the network, they use frames secured with the runtime
link-layer key.

Jonathan

On Tue, May 27, 2014 at 11:18 PM, <[email-masked]> wrote:

> In w/HART, are all beacon frames authenticated with a well-known key even
> after a joining node obtained the runtime link layer key?
>
>
>
> Regards,
>
> Yoshihiro Ohba
>
>
>
>
>
>
>
>
>
> *From:* 6tisch-security [mailto:[email-masked]] *On
> Behalf Of *Jonathan Simon
> *Sent:* Tuesday, May 27, 2014 10:41 PM
> *To:* Rene Struik
> *Cc:* Michael Richardson; [email-masked]
> *Subject:* Re: [6tisch-security] agenda for 2014-05-27 6tisch security
> call
>
>
>
> key, the node's new short address (this takes the place of PAN coordinator
> https://www.ietf.org/mailman/listinfo/6tisch-security <http://cp.mcafee.com/d/2DRPoO86QmbEEKnjKOrKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCZKDtxVB_HYMC-C-MNRXBQSnSuvvovv7csJteOaqJNPfaxVZicHs3jr1JwTvAm4TDNOb2pEVdTdAVPmEBC5eBYTu00U9GX33VkDa3JssDaBypuDSrzapoSVelb4OZfIT6kONsxlK5LE2FvdTw09J55V6VI5-Aq83iSVelb4OZfIT6kONFtd46AvwxFEwtH4Qg9ThobTvbFzzh0Velb4Ph1jXdNBcIq8bquursodLWbv>
>
>
>
>
>  --
>
> 400-2936, and destroy the original transmission and its
> attachments without reading or saving in any manner. Thank you.
>
> http://cp.mcafee.com/d/2DRPow76QmbEFLzzhOM-rKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCTA7hPXPb_nVNZNBVxzHTbEzHIYYepd7bz8XBHEShhlKM_OEuvkzaT0QSyrhdTV5xdVYsyMCqejtPpesRG9pxjFvdTw0e2qKMM-l9OwXn79OFoCnFZCUOCmdKjBiNcLjXdNBcIn8lrxrW0GnPtU02rojhKUr1vF6y0QJKjBiNcLjXdNBcIqnjh1F7U8qq87qNd42tQm2ZTOWoUQgejBiNcQgk-Pspjb6y2SDDCT63rt_U2SVUlVB0
>
>

---

From: <[email-masked]>
Date: Wed, 28 May 2014 15:01:56 +0000

Hi Jonathan,

Thank you for your answer.

I think this can be an issue if already joined nodes also use the beacons protected with the well-known key for maintaining synchronization and slot allocations, as an attacker can send forged beacons protected with the well-known key.

Yoshihiro Ohba

From: 6tisch-security [mailto:[email-masked]] On Behalf Of Jonathan Simon
Sent: Wednesday, May 28, 2014 11:49 PM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: Michael Richardson; Rene Struik; [email-masked]
Subject: Re: [6tisch-security] agenda for 2014-05-27 6tisch security call

Yoshihiro -

Q. In w/HART, are all beacon frames authenticated with a well-known key even after a joining node obtained the runtime link layer key?
A. Yes. In WirelessHART the beacons (called "advertisements" but they serve the same purpose and have similar content) are intended for devices not yet in the network, so they always use the well-known key.  To discover other nodes within the network, they use frames secured with the runtime link-layer key.
Jonathan

On Tue, May 27, 2014 at 11:18 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jonathan,

I have question.

Regards,
Yoshihiro Ohba

From: 6tisch-security [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jonathan Simon
Sent: Tuesday, May 27, 2014 10:41 PM
To: Rene Struik
Cc: Michael Richardson; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch-security] agenda for 2014-05-27 6tisch security call

Best regards, Rene

1) notewell.

2) intros

3) recap of draft-piro-

--

--

--
--
Jonathan Simon, Ph. D
Director of Systems Engineering
Dust Networks at Linear Technology
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936<tel:%28510%29%20400-2936>
(510) 489-3799<tel:%28510%29%20489-3799> FAX
[email-masked]<mailto:[email-masked]>

**LINEAR TECHNOLOGY CORPORATION**
*****Internet Email Confidentiality Notice*****
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2936<tel:%28510%29%20400-2936>, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 May 2014 11:44:55 -0400

Jonathan wrote:
    > A. Yes. In WirelessHART the beacons (called "advertisements" but they serve the
    > same purpose and have similar content) are intended for devices not yet in the
    > network, so they always use the well-known key.  To discover other nodes within
    > the network, they use frames secured with the runtime link-layer key.

    > I think this can be an issue if already joined nodes also use the beacons
    > protected with the well-known key for maintaining synchronization and slot
    > allocations, as an attacker can send forged beacons protected with the
    > well-known key.

So, beacons are not also sent using the runtime link-layer key?
I was envisioning that to be the case for 6tisch.

---

From: Jonathan Simon <[email-masked]>
Date: Wed, 28 May 2014 08:47:12 -0700

Yoshihiro -

I don’t think this is a problem.  Nodes that are in the network reject incoming frames secured with the well-known key. The well-known key is only used to authenticate beacons, and authenticate join requests (which don’t carry synchronization information).  There is a DoS vector, in that an attacker can inject joining traffic (destined for the network mananager) that will ultimately be discarded, possibly preventing other nodes from joining, and increasing the traffic in the network. 

Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
[email-masked]

On May 28, 2014, at 8:01 AM, <[email-masked]> <[email-masked]> wrote:

> http://cp.mcafee.com/d/1jWVIe3zqb5QkTzhOMC-rKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCO5JtvupvW_8CzBdBBfHTbECzBdzATC7xNEVVqWtAklrCzB7BgY-F6lK1FJ4SyrLOb2rPUV5xcQsCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04S-qem7T3obZ8Qg6BJOsGm9BWvpKcFBziWq8d8_13jh0Xm9EwjKyMnK-nj76y1OsGm9Cy2DSrzapoQgmQYYSUMrDrkr2pAaTam

---

From: Jonathan Simon <[email-masked]>
Date: Wed, 28 May 2014 09:54:18 -0700

Michael - 

6TiSCH is free to use beacons any way they like.  In WH, they are only used to advertise the presence of a network, so they always use the well-known key. 15.4e allows you to use them to poll for information (using an enhanced beacon request).  They could be used for discovery, i.e. DIO or ND frames (with the runtime key) but this is out of scope for 4e.  
-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
30695 Huntwood Ave
Hayward, CA 94544-7021
(510) 400-2936
(510) 489-3799 FAX
[email-masked]

On May 28, 2014, at 8:44 AM, Michael Richardson <[email-masked]> wrote:

> http://cp.mcafee.com/d/2DRPos76QmbEFCzB4QsThdTdEK3CkPqbwVBYSyUed7aar9EVdKfffecnKr4qilH057Ox-NVsSva7X7BPtxP5T7Cn-LObzXzbP_nKnhuj7sCPtx55XBHFShjlhKVOEuvkzaT0QSyrhdTV5xdVYsyMCqejtPpesRG9pxjFvdTw0e2qKMM-l9OwXn79OFoCnFZCUOCmdKjBiNcLjXdNBcIn8lrxrW0GnPtU02rsuKqejobZ8Qg6BJOsGm9BWvpKcFBziWq8d8_13jh0Xm9EwjKyMnK-nj76y1OsGm9Cy2DSrzapoQgmQYYSUMrCr5n

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 May 2014 14:57:15 -0400

To remind the calls will return to Monday mornings at:
    7am PDT, 10am EDT, 1400 UTC.

The plan is to come up with a table of contents for two
documents on the details of the packet flow/sizes/etc. for
the two possible mechanisms.   That will be item #1.

Thomas/Jonathan will be providing some additional background
slides on WirelessHART, as that will provide some of the context
for the table of contents.   I hope the slides will be ready by
EOB Friday, so that they can get distributed before Monday.

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 28 May 2014 12:27:34 -0700

+1

I believe this is a good action plan.

Thomas

---

From: Rene Struik <[email-masked]>
Date: Wed, 28 May 2014 15:34:55 -0400

Hi Michael:

Fine with me, as long as we dive into more detail of how things 
could/should work as well.

Just curious, though: what are the "two possible mechanisms"???

Rene

On 5/28/2014 3:27 PM, Thomas Watteyne wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Michael Richardson <[email-masked]
>     <mailto:[email-masked]>>, Sandelman Software Works
>     [email-masked] <mailto:[email-masked]>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 May 2014 16:59:03 -0400

Rene Struik <[email-masked]> wrote:
    > Fine with me, as long as we dive into more detail of how things could/should
    > work as well.

The goal of this group is presently to create an architecture; it needs to
speak to top-down design in the architecture document.

As such, the deep technical dive is appropriate to the extent that it reveals
exchanges or components that need to exist but that we would otherwise have missed.

    > Just curious, though: what are the "two possible mechanisms"???

1) ZigbeeIP-like {1x,PANA} transported EAP-TLS resulting in a MSK being "pulled"
   by the new 6LN.

2) WirelessHART-like JOIN-network (partial?) connectivity resulting in a MSK being
   "pushed" to the new 6LN using 6top over CoAP/DTLS.

Both methods probably involve a 6lowpan-ND ARO step before you start,
possibly including initialization of the 6lowpan compression contexts
(possibly; because that may present a leak of information!), and both methods
can be made to work with 802.1AR certificates in the 6LN, and the network
trusted by TBD authorization token/certificate.

Those elements are, I think common.

---

From: Rene Struik <[email-masked]>
Date: Wed, 28 May 2014 17:09:12 -0400

Well, let us discuss at next Monday's call...

Rene

---

From: <[email-masked]>
Date: Wed, 28 May 2014 23:19:40 +0000

Hi Jonathan,

I am not caring about an attacker to inject joining traffic, but what I care is an attacker attempting to destruct basic TSCH operation in the network by sending forged beacons protected with the well-known key.

Yoshihiro Ohba

From: 6tisch-security [mailto:[email-masked]] On Behalf Of Jonathan Simon
Sent: Thursday, May 29, 2014 12:47 AM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [6tisch-security] agenda for 2014-05-27 6tisch security call

Yoshihiro -

Jonathan Simon, Ph. D

On May 28, 2014, at 8:01 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jonathan,

Yoshihiro Ohba

Cc: Michael Richardson; Rene Struik; [email-masked]<mailto:[email-masked]>

Yoshihiro -

I have question.

Regards,
Yoshihiro Ohba

Best regards, Rene

1) notewell.

2) intros

3) recap of draft-piro-

--

--

---

From: Jonathan Simon <[email-masked]>
Date: Wed, 28 May 2014 16:41:49 -0700

Then as long as either
a) Beacons are only used for advertising a network to unsychronized devices, or
b) Devices only take timing information (time of arrival) from beacons coming from time parents and authenticated with the run-time key
you are good.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 May 2014 19:43:23 -0400

<[email-masked]> wrote:
    > I am not caring about an attacker to inject joining traffic, but what I
    > care is
    > an attacker attempting to destruct basic TSCH operation in the network by
    > sending forged beacons protected with the well-known key.

I think therefore, that we ought to define either:

1) that 6tisch will two sets of beacons.
   JOIN beacons might be less frequent, less capable, etc.

2) a second authentication of the extended beacon, under the runtime-key,
   could be done.  It can't be verified by nodes that don't have the
   runtime-key, but as it would be authentication only, that's okay.

---

From: <[email-masked]>
Date: Wed, 28 May 2014 23:43:31 +0000

Yes.

Yoshihiro Ohba

From: Jonathan Simon [mailto:[email-masked]]
Sent: Thursday, May 29, 2014 8:42 AM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [6tisch-security] agenda for 2014-05-27 6tisch security call

Then as long as either

On May 28, 2014, at 4:19 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jonathan,

Yoshihiro Ohba

Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Yoshihiro -

Jonathan Simon, Ph. D

Hi Jonathan,

Yoshihiro Ohba

Yoshihiro -

I have question.

Regards,
Yoshihiro Ohba

Best regards, Rene

1) notewell.

2) intros

3) recap of draft-piro-

--

--

---

From: Rene Struik <[email-masked]>
Date: Wed, 28 May 2014 21:39:44 -0400

Dear colleagues:

I may have missed something here, but this email thread seems to confuse 
what w/HART provides with what 6TiSCH could specify. Since 6TiSCH is to 
be defined on top of 802.15.4e-2012, it can secure frame types using 
policy-defined combinations of encryption and authenticity (including 
authentication-only). In particular, a newbee device, just out of the 
wrapping paper and with no network-specific keying material yet, may 
still be able to see most of an authenticated, but not secured frame, 
even if it cannot check authenticity.

So, no need to kill off functionality, come up with nested security 
constructs, two beacon types, etc; one should simply look at the correct 
standard one builds on {caveat: this assessment is modulo some errors in 
the 802.15.4e-2012 spec.}

BTW - As an interesting aside, this seems to illustrate that looking at 
specific details *does* matter...

Best regards, Rene

On 5/28/2014 7:43 PM, [email-masked] wrote:
>
> Yes.
>
> Yoshihiro Ohba
>
> *From:*Jonathan Simon [mailto:[email-masked]]
> *Sent:* Thursday, May 29, 2014 8:42 AM
> *To:* ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ)
> *Cc:* [email-masked]; [email-masked]; 
> [email-masked]
> b) Devices only take timing information (time of arrival) from beacons 
> coming from time parents and authenticated with the run-time key
>
> you are good.
>
> -- 
> Jonathan Simon, Ph. D
> [email-masked] <mailto:[email-masked]>
>
> e-mail messages attached to it may contain confidential information 
> that is legally privileged. If you are not the intended recipient, or 
> a person responsible for delivering it to the intended recipient, you 
> are hereby notified that any disclosure, copying, distribution or use 
> of any of the information contained in or attached to this 
> transmission is STRICTLY PROHIBITED. If you have received 
> this transmission in error, please immediately notify me by reply 
> e-mail, or by telephone at (510) 400-2936, and destroy the 
> original transmission and its attachments without reading or saving in 
> any manner. Thank you.
>
> On May 28, 2014, at 4:19 PM, <[email-masked] 
> <mailto:[email-masked]>> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     Hi Jonathan,
>
>     I am not caring about an attacker to inject joining traffic, but
>     what I care is an attacker attempting to destruct basic TSCH
>     operation in the network by sending forged beacons protected with
>     the well-known key.
>
>     Yoshihiro Ohba
>
>     *From:*6tisch-security
>     [mailto:[email-masked]]*On Behalf Of*Jonathan Simon
>     *Sent:*Thursday, May 29, 2014 12:47 AM
>     *To:*ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ)
>     *Cc:[email-masked]
>     <mailto:[email-masked]>;[email-masked]
>     <mailto:[email-masked]>;[email-masked]
>     <mailto:[email-masked]>
>     *Subject:*Re: [6tisch-security] agenda for 2014-05-27 6tisch
>     security call
>
>     Yoshihiro -
>
>     I don’t think this is a problem.  Nodes that are in the network
>     reject incoming frames secured with the well-known key. The
>     well-known key is only used to authenticate beacons, and
>     authenticate join requests (which don’t carry synchronization
>     information).  There is a DoS vector, in that an attacker can
>     inject joining traffic (destined for the network mananager) that
>     will ultimately be discarded, possibly preventing other nodes from
>     joining, and increasing the traffic in the network.
>
>     Jonathan Simon, Ph. D
>     [email-masked] <mailto:[email-masked]>
>
>     e-mail messages attached to it may contain confidential
>     information that is legally privileged. If you are not
>     the intended recipient, or a person responsible for delivering it
>     to the intended recipient, you are hereby notified that any
>     disclosure, copying, distribution or use of any of the information
>     contained in or attached to this transmission is
>     STRICTLY PROHIBITED. If you have received this transmission in
>     error, please immediately notify me by reply e-mail, or by
>     telephone at (510) 400-2936, and destroy the original transmission
>     and its attachments without reading or saving in any manner. Thank
>     you.
>
>     On May 28, 2014, at 8:01 AM, <[email-masked]
>     <mailto:[email-masked]>>
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>
>
>         Hi Jonathan,
>
>         I think this can be an issue if already joined nodes also use
>         the beacons protected with the well-known key for maintaining
>         synchronization and slot allocations, as an attacker can send
>         forged beacons protected with the well-known key.
>
>         Yoshihiro Ohba
>
>         *From:*6tisch-security
>         [mailto:[email-masked]]*On Behalf
>         Of*Jonathan Simon
>         *Sent:*Wednesday, May 28, 2014 11:49 PM
>         *To:*ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ)
>         *Cc:*Michael Richardson; Rene Struik;[email-masked]
>         <mailto:[email-masked]>
>         *Subject:*Re: [6tisch-security] agenda for 2014-05-27 6tisch
>         security call
>
>         Yoshihiro -
>
>         Q.In w/HART, are all beacon frames authenticated with a
>         well-known key even after a joining node obtained the runtime
>         link layer key?
>
>         A. Yes. In WirelessHART the beacons (called "advertisements"
>         but they serve the same purpose and have similar content) are
>         intended for devices not yet in the network, so they always
>         use the well-known key.  To discover other nodes within the
>         network, they use frames secured with the runtime link-layer key.
>
>         Jonathan
>
>         On Tue, May 27, 2014 at 11:18 PM,
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>             Hi Jonathan,
>
>             In w/HART, are all beacon frames authenticated with a
>             well-known key even after a joining node obtained the
>             runtime link layer key?
>
>             Regards,
>
>             Yoshihiro Ohba
>
>             *From:*6tisch-security
>             [mailto:[email-masked]
>             <mailto:[email-masked]>]*On Behalf
>             Of*Jonathan Simon
>             *Sent:*Tuesday, May 27, 2014 10:41 PM
>             *To:*Rene Struik
>             *Cc:*Michael Richardson;[email-masked]
>             <mailto:[email-masked]>
>             *Subject:*Re: [6tisch-security] agenda for 2014-05-27
>             6tisch security call
>
>             * One or more devices are sending beacons to advertise the
>             presence of the network. In WirelessHART, this frame is
>             unencrypted, but authenticated with a well known key.  The
>             beacon contains the current ASN, which the joining device
>             uses to synchronize its clock.
>
>             * Once the joining node has heard a beacon, it continues
>             listening for additional beacons for a short specified
>             timeout.
>
>             * The joining node encrypts a frame containing some HART
>             specific content, including a list of beaconing neighbors
>             it heard in the previous steps. The size of the payload is
>             ~ 60 bytes.  The packet is routed by a "proxy" node - the
>             joining parent. The frame is authenticated using the
>             well-known key, and encrypted using a shared symmetric key
>             known only by the node and the manager.
>
>             * The manager responds with a frame containing the
>             run-time link-layer key, the node's new short address
>             (this takes the place of PAN coordinator association), and
>             a unicast session key and starting nonce for the manager.
>             This frame is encrypted with the symmetric key. The
>             payload is ~ 60 bytes, and is routed to the proxy for
>             delivery to the joining node - the proxy uses the
>             link-layer well known key on the frame.
>
>             * At this point the joining node transitions to using the
>             run-time link-layer key for all link-layer frames, and the
>             manager unicast session for end-to-end manager traffic.
>             This ends the initial security handshake.
>
>             * Over a number of additional frames, the manager assigns
>             additional sessions, including broadcast sessions, and a
>             unicast session to the Gateway (sink for all data
>             traffic), and additional communications resources, routing
>             information, etc.  There is no explicit transition from
>             joining to joined - the mote transitions when certain key
>             frames are received.
>
>             * Note that a WirelessHART link-layer frame contains and
>             additional frame type byte and a 4-byte link-layer MIC, on
>             top of the unsecured 15.4 frame.  A network frame contains
>             an additional 16-40 bytes of addressing, routing, security
>             and other information.
>
>             Hope this help!
>
>             Jonathan
>
>             On Mon, May 26, 2014 at 8:09 PM, Rene Struik
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 Hi Michael:
>
>                 I would like to discuss the outstanding issues I
>                 summarized in my email of Tue last week, May 20, 2014,
>                 9:45am EDT
>                 (seehttp://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html
>                 <http://cp.mcafee.com/d/5fHCMUp41ESyNt55OWtSjtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsTJQXIfcLZvC4TQTS6eLsKCO-PPXX3XUVzBHFShjlKepVkffGhBrwqrhdI6XYyMCY-ehojd79KVI05bVKY01MjbX6NehDY05zAVkIjbQ-PspjbppKcvxf5q4rTKYVMedKjBiNcLjXdNBcIn8lrxrW0GnPtU02rhhuhKr1vF6y0QJKjBiNcLjXdNBcIqnjh1F7U8qq87qNd42tQm2ZTOWoUQgejBiNcQgk-Pspjb6y2SDDCT63pO_o>).
>                 This was also one of the action items at the
>                 conclusion of last week's 6TiSCH security call.
>
>                 FYI - the w/HART communication flows were discussed
>                 during the 6TiSCH security conf call the week before,
>                 on Mon May 12, 2014. If one wishes to go over this
>                 again, that is fine, but I would prefer us giving
>                 preference to taking on already articulated issues
>                 (which were assigned as homework assignment to reflect
>                 upon) first (i.e., prior to item #4 of the proposed
>                 agenda).
>
>                 As another agenda point, I would like us to discuss
>                 the frequency of future calls (as part of EOB).
>
>                 Best regards, Rene
>
>
>                     I'm at+1 613 276-6809  <tel:%2B1%20613%20276-6809>, IM:[email-masked]  <mailto:[email-masked]>  [email-masked]  <mailto:[email-masked]>,
>
>                     Michael Richardson<[email-masked]>  <mailto:[email-masked]>, Sandelman Software Works
>
>                 email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik
>
>                 cell:+1 (647) 867-5658  <tel:%2B1%20%28647%29%20867-5658>  | US:+1 (415) 690-7363  <tel:%2B1%20%28415%29%20690-7363>
>
>
>             (510) 400-2936 <tel:%28510%29%20400-2936>
>             (510) 489-3799 <tel:%28510%29%20489-3799>FAX
>             [email-masked] <mailto:[email-masked]>
>
>              This e-mail transmission, and any documents, files or
>             previous e-mail messages attached to it may
>             contain confidential information that is legally
>             privileged. If you are not the intended recipient, or a
>             person responsible for delivering it to the intended
>             recipient, you are hereby notified that any disclosure,
>             copying, distribution or use of any of the information
>             contained in or attached to this transmission is
>             STRICTLY PROHIBITED. If you have received
>             this transmission in error, please immediately notify me
>             by reply e-mail, or by telephone at(510) 400-2936
>             <tel:%28510%29%20400-2936>, and destroy the
>             original transmission and its attachments without reading
>             or saving in any manner. Thank you.
>
>
>         [email-masked] <mailto:[email-masked]>
>
>          This e-mail transmission, and any documents, files or
>         previous e-mail messages attached to it may
>         contain confidential information that is legally privileged.
>         If you are not the intended recipient, or a person responsible
>         for delivering it to the intended recipient, you are
>         hereby notified that any disclosure, copying, distribution or
>         use of any of the information contained in or attached to this
>         transmission is STRICTLY PROHIBITED. If you have received
>         this transmission in error, please immediately notify me by
>         reply e-mail, or by telephone at (510) 400-2936, and destroy
>         the original transmission and its attachments without reading
>         or saving in any manner. Thank you.
>