Subject: [6tisch-security] Suggested agenda for 6tisch security call of *today*, Tue January 6, 2015, 5pm EST (dial-in info at bottom)

From: Rene Struik <[email-masked]>
Date: Tue, 06 Jan 2015 11:48:53 -0500

Dear colleagues:

Happy New Year!

According to the agreed-upon 6tisch security conf call schedule, we will 
resume the conference call series today, Tue Jan 6, 2015, 5pm EST.

I propose we continue the discussion where we left off prior to 
Christmas (essentially, item 3c below), except that we may have a short 
presentation first (item #2).

Agenda:
1) administrativia {agenda bashing/minutes}
2) {still to be confirmed} presentation Giuseppe Piro
3) join protocol details
-- a) (done) status update MAC behavior
-- b) (brief!) recap of routing/communication flow aspects
-- c) incremental deployment aspects
4) input 6tisch security to other 6tisch documents
-- a) terminology draft
-- b) architecture draft

Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. {The 
next call, on January 6, 2014) is also at 5pm EST (see schedule till 
half of January 2015)}.
Note: next week's call is on Wed Jan 14, 2015, 11am EST.

Dial-in info at end of this email.

Best regards,

Rene

-------- Forwarded Message --------
Subject: 	Suggested agenda for 6tisch security call of *today*, Tue 
December 16, 2014, 5pm EST (dial-in info at bottom)
Date: 	Tue, 16 Dec 2014 09:21:20 -0500
From: 	Rene Struik <[email-masked]>
To: 	tisch-security <[email-masked]>

Dear colleagues:

I propose we continue the discussion where we left off last week.

Agenda:
1) administrativia {agenda bashing/minutes}
2) join protocol details
-- a) (brief!) status update MAC behavior
-- b) continuation of routing/communication flow aspects {last week, we 
did not finish the only two slides on this
3) input 6tisch security to other 6tisch documents

Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. {The 
next call, on January 6, 2014) is also at 5pm EST (see schedule till 
half of January 2015)}.

Dial-in info at end of this email.

Best regards,

Rene

-------- Forwarded Message --------
Subject: 	suggested agenda for 6tisch security call of tomorrow, Tue 
December 9, 2014, 9am EST (dial-in info at bottom)
Date: 	Mon, 08 Dec 2014 17:16:40 -0500
From: 	Rene Struik <[email-masked]>
To: 	tisch-security <[email-masked]>

Dear colleagues:

For last week's Tue Dec 2, 2014, 9am EST conf call I prepared some 
material and posted prior to the call. During the call, we discussed all 
MAC-related aspects relevant for the join protocol and did not discuss 
higher-layer aspects I prepared material for yet. I suggest we continue 
the systematic discussion of last week and take that topic on now.

This leads to the following suggested agenda for this week (essentially 
a continuation of last week's one):

Same as last week's, except with
#1a-b) focus on routing/communication flow related aspects join protocol;
#2a): confirm concensus on MAC (as discussed last week) and 
routing/communication flow aspects
#2c) {as consequence of two items above} what to squeeze into 
architecture draft

The detailed agenda and dial-in info is below (#A, resp. #B).

Best regards, Rene

_A) Suggested agenda Tue Dec 9, 2014, 9am EST call_

Proposed agenda:

0) Agenda bashing

1) Join protocol details

    a) desired properties
    b) realizable properties

    #1a-b) focus on routing/communication flow related aspects join
    protocol (we discussed MAC-related join-relevant aspects during the
    conf call of Tue Dec 2, 2014, 9am EST).
    For slides, see
    https://drive.google.com/folderview?id=0B2a6Ilxu1XfCNF9JaXR1ZXlzZlU&usp=sharing
    (same slides as sent out prior to Dec 2, 2014, 9am EST call)
    Relevant slides: Slides 23-25 (contained in entire slide deck (ppt),
    but also in excerpt (pdf))

2) Next steps:
         a) consensus on 1#a and 1#b

    #2a): confirm consensus on MAC (as discussed last week) and
    routing/communication flow aspects
    #2c) {as consequence of two items above} what to squeeze into
    architecture draft

         b) form tiger team to work out details
             - project phases
             - communication of sub-results
         c) what to squeeze into architecture draft, etc.

I will prepare material to facilitate discussion on 1) and 2), to be 
discussed during the call.

_B) Dial-in information:_

English : New York Time 6tisch security
Tuesday, December 9, 2014 | 9:00 am Eastern Standard Time (GMT-05:00)
Meeting number:   641 709 118
Meeting password: joinjoin
Audio connection:
       1-877-668-4493 Call-in toll free number (US/Canada)
       1-650-479-3208 Call-in toll number (US/Canada)

Access code: 641 709 118
Meeting link:
         https://ietf.webex.com/ietf/j.php?MTID=m1aa12258a83109b4ae291fb0c2bd92d6

The etherpad we have used is at:
        http://etherpad.tools.ietf.org:9000/p/6tisch-security-6top-xml.txt

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

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 6 Jan 2015 23:03:33 +0100

Quick reminder about the dial in information:

Access code: 641 709 118
Meeting link:

On Tue, Jan 6, 2015 at 5:48 PM, Rene Struik <[email-masked]> wrote:

> I propose we continue the discussion where we left off prior to Christmas
> (essentially, item 3c below), except that we may have a short presentation
> first (item #2).
>
> Agenda:
> Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. {The next
> call, on January 6, 2014) is also at 5pm EST (see schedule till half of
> January 2015)}.
> -------- Forwarded Message --------  Subject: Suggested agenda for 6tisch
> security call of *today*, Tue December 16, 2014, 5pm EST (dial-in info at
> bottom)  Date: Tue, 16 Dec 2014 09:21:20 -0500  From: Rene Struik
> <[email-masked]> <[email-masked]>  To: tisch-security
> <[email-masked]> <[email-masked]>
>
> Dear colleagues:
>
> Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. {The next
> call, on January 6, 2014) is also at 5pm EST (see schedule till half of
> January 2015)}.
>
> -------- Forwarded Message --------  Subject: suggested agenda for 6tisch
> security call of tomorrow, Tue December 9, 2014, 9am EST (dial-in info at
> bottom)  Date: Mon, 08 Dec 2014 17:16:40 -0500  From: Rene Struik
> <[email-masked]> <[email-masked]>  To: tisch-security
> <[email-masked]> <[email-masked]>
>
> Dear colleagues:
>
> higher-layer aspects I prepared material for yet. I suggest we continue the
> systematic discussion of last week and take that topic on now.
>
> This leads to the following suggested agenda for this week (essentially a
> continuation of last week's one):
>
> #2c) {as consequence of two items above} what to squeeze into architecture
> draft
>
> *A) Suggested agenda Tue Dec 9, 2014, 9am EST call*
>
> Proposed agenda:
>
> 0) Agenda bashing
>
> 1) Join protocol details
>
> a) desired properties
> b) realizable properties
>
> #1a-b) focus on routing/communication flow related aspects join protocol
> (we discussed MAC-related join-relevant aspects during the conf call of Tue
> Dec 2, 2014, 9am EST).
> For slides, see
> Relevant slides: Slides 23-25 (contained in entire slide deck (ppt), but
> also in excerpt (pdf))
>
> 2) Next steps:
> #2c) {as consequence of two items above} what to squeeze into architecture
> draft
>
> *B) Dial-in information:*
>
> email: [email-masked] | Skype: rstruik
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security
>
>

---

From: Rene Struik <[email-masked]>
Date: Tue, 13 Jan 2015 19:37:04 -0500

Dear colleagues:

Just a quick reminder that we *do* have a conf call tomorrow, Wed Jan 
14, 2015, 11am EST.

Currently, the main agenda item is item #4b of last week: input to the 
6tisch architecture draft. It would also be good to have some more 
comments on the draft I posted.

Minutes of calls later tonight (sorry - extremely busy). For conf call 
dial-in info, see bottom of email.

Best regards, Rene

==

On 1/6/2015 11:48 AM, Rene Struik wrote:
> Dear colleagues:
>
> Happy New Year!
>
> According to the agreed-upon 6tisch security conf call schedule, we 
> will resume the conference call series today, Tue Jan 6, 2015, 5pm EST.
>
> Christmas (essentially, item 3c below), except that we may have a 
> short presentation first (item #2).
>
> Agenda:
> -- b) continuation of routing/communication flow aspects {last week, 
> we did not finish the only two slides on this
> material and posted prior to the call. During the call, we discussed 
> all MAC-related aspects relevant for the join protocol and did not 
> discuss higher-layer aspects I prepared material for yet. I suggest we 
> continue the systematic discussion of last week and take that topic on 
> now.
>
> This leads to the following suggested agenda for this week 
> (essentially a continuation of last week's one):
>
>     protocol (we discussed MAC-related join-relevant aspects during
>     the conf call of Tue Dec 2, 2014, 9am EST).
>     For slides, see
>     Relevant slides: Slides 23-25 (contained in entire slide deck
>     (ppt), but also in excerpt (pdf))
>
> 2) Next steps:

---

From: Rene Struik <[email-masked]>
Date: Wed, 14 Jan 2015 00:04:13 -0500

Please find below the minutes of the 6TiSCH Security conf call as of 
January 6, 2015, 5pm EST.

Minutes 6TiSCH Security conf call, Tue January 5, 2015, 5-6pm EST
{note taker: Rene Struik}
{recording: see 6tisch bitbucket list}
{slides discussed (and referenced in minutes): no slides this time }

1. Attendance:
Michael Richardson, Malisa Vucinic, Yoshi Ohba, Thomas Watteyne, Kris 
Pister, Rene Struik

2. Agenda
The suggested agenda was approved, after removal of item #2 below 
(speaker not available)

3. Minutes
RS apologized for being late with sending out the minutes of the 
previous call.

4. Brief recap of routing/communication flow aspects (item #3b of agenda)
RS summarized some of the discussion at the previous call regarding 
communication flows between joining node, neighbor node (the join 
assistant), and server (JCE). Main discussion point was that the slides 
assumed a role for the router node (join assistant) that stretches 
further than just the role of relay station: it only forwards traffic to 
the server after first authenticating the joining node. Here, the idea 
was that while authentication does not offer fine-grained authorization 
control (without further filtering mechanisms on the router (join 
assistant)), it might help in limiting denial-of-service attacks 
targeting the long-haul communication channel between the router (join 
assistant) and the server (JCE). RS suggested that it would not be too 
hard to extend this mechanism to support both the relay and the 
authenticating role of the router (join assistant). Upon question by MV 
as to whether it was decided what to actually support, RS suggested this 
would depend on more detailed cost/benefit analysis (which is still to 
be done).

KP asked how the terminology of joining node, neighbor node, and server 
related to the notions JN, JA, and JCE. RS suggested that these would be 
the same notions, if each role would be implemented on a single device; 
he simply used notions in slides circulated during earlier calls and 
also presented at IETF-90 and -91 meetings.

RS mentioned that the protocol discussed would allow for a single 
communication flow between join assistant and server (JCE), in case 
JCE-related certificate information could be cached at the join 
assistant, which is optimal. He expected that this would cover ordinary 
operation; out-of-sync behavior would necessitate an additional 
communication flow, so as to recover from this anomaly. Upon question by 
TW, RS suggested that the initial sync operation could be used as 
bootstrap mechanism.

RS suggested that there are lots of details/minutiae that need to be 
worked out, once we have agreement that this approach has indeed 
sufficient merit.

5. Incremental deployment aspects (item #3c of agenda)
On the RoLL mailing list, so-called incremental deployment scenarios 
were brought up (e.g., by Peter van der Stok). With RPL, a joining node 
would only join a tree, where each node hereof would already be part of 
the network. For applications such as building control, one would prefer 
a more "random" network configuration approach. Here, the idea is that 
as long as the new node is able to find the root, it should be possible 
to enroll, no matter whether each node on the communication path to the 
root is already part of the network, as MR suggested is currently the 
case with RPL. An example scenario would be if the newbee node talks to 
the root via a configuration tool, where the latter two devices would 
communicate, e.g., via cellular traffic. Question is whether we can 
accommodate this scenario.

KP suggested that the only requirement is that there is indeed a 
communication path between the joining node and the server (JCE). MR 
suggested that there is no implicit assumption that communication 
between join assistant and PCE would be private. TW was curious why this 
topic was brought up. RS suggested that it would be good to limit 
interdependencies between routing protocol and join protocol, e.g., to 
support wider use case scenarios. Here, this would include "crazy" 
scenario where one would set up a large network, where one would 
sprinkle the room with unsecured nodes that only provide connectivity 
during set-up. This would allow use of any communication protocol during 
set-up and removal of "connectivity-assist" devices after configuration 
is finished and using RPL only once this step has finished. RS suggested 
that the so-called join priority parameter in 802.15.4e-2012 might be a 
potential hurdle (since it essentially encodes the length of the 
shortest path to the DODAG route, using historical tree-like set-up 
info). TW suggested that it would be possible to completely discard the 
join priority parameter in practice, so that this would not be a problem.

6. Input 6tisch security to other 6tisch drafts (item #4a, #4b of the 
agenda)
YO mentioned that he had provided some feedback on the email by Pascal 
Thubert on join process and had commented that this section should be 
less specific and that he had reservations about specific notions, such 
as ULA addresses. RS volunteered to provide input to the terminology 
draft and the architecture draft, so as to remove roadblocks by end of 
week.  The idea here would be that the level of detail would reflect 
consensus as reached to-date.

RS mentioned that there were some other inter-dependencies, e.g., with 
the minimal draft, but that Xavier Vilojasana had already responded to 
comments submitted just prior to Christmas (Dec 19, 2014).

7. AOB --- Conf call scheduling
Next week's conf call is Wed January 15, 2015, 11am EST. There is no 
schedule for subsequent weeks yet; not urgent, but to be discussed next 
week.

[end of call: 5.56pm EST]

---

From: Rene Struik <[email-masked]>
Date: Wed, 14 Jan 2015 09:48:13 -0500

Dear colleagues:

Please find below the (belated) formal minutes of the 6TiSCH Security 
conf call as of December 16, 2014, 5pm EST.

Minutes 6TiSCH Security conf call, Tue December 16, 2014, 5-6pm EST
{note taker: Rene Struik}
{recording: see 6tisch bitbucket list}
{slides discussed (and referenced in minutes): 
https://drive.google.com/file/d/0B2a6Ilxu1XfCOGxkbm05NlEwbms/view?usp=sharing}

1. Attendance:
Michael Richardson, Malisa Vucinic, Tero Kivinen, Yoshi Ohba, Subir Das, 
Jonathan Simon, Rene Struik

2. Agenda
The suggested agenda was approved.
Agenda:
1) administrativia {agenda bashing/minutes}
2) join protocol details
-- a) (brief!) status update MAC behavior
-- b) continuation of routing/communication flow aspects {last week, we 
did not finish the only two slides on this}
3) input 6tisch security to other 6tisch documents

3. Join process - brief status update MAC behavior (item #2a of agenda)
RS suggested he had sent out a preliminary MAC behavior write-up (that 
elaborated in much more detail the contents of Slides 5-8) to most 
6tisch stakeholders, so as to solicit offline feedback on accuracy and 
completeness. He expected that the write-up would help in streamlining 
discussions and not repeating technical discussions. He suggested that 
the topic re MAC behavior had run its course in the calls, with 
conclusion for now, and suggested that this only be brought up again 
after first giving appropriate attention to other (non-MAC related) join 
process aspects (to which participants at the call agreed).

4. Routing/Communication flow aspects
RS went over Slides 9-11 of the slides, which dealt with degrees of 
knowledge at various stages of the join protocol flows, its 
consequences, and with trade-offs re keeping temporary state on, e.g., 
the neighbor node (join assistant) during the join process. During the 
presentation, RS mentioned that on Slide #10, the term "link local 
address" should be read as "local address" (so, as to avoid unintended 
connotation of terms already in use with IETF). There was a discussion 
after conclusion of the presentation, captured below. {Editorial note 
minute taker: as convenience for readers, some terms used on slides are 
described using alternative lingo capturing similar meaning (e.g., join 
assistant and JCE).}

--Slide 9:
no discussion

--Slide 10:
JS elaborated on the join protocol flows with w/HART. Most salient 
aspects include the following:
a) the joining node communicates directly to the server (JCE), with the 
neighbor node (join assistant) acting only as relay station, without a 
security role.
b) communication between joining  node and server (multi-hop) is secured 
end-to-end. Security uses pre-shared keying material.
c) communication from server to joining node is directed via neighbor 
node/router (join assistant), where there is an indicator in the message 
to the neighbor node that the message is not intended for itself, but 
assumed to travel "downstream", to the joining node. This indication is 
included in a separate header of the routing header.
d) initial communication uses EUI-64 address, whereas short address 
would be assigned by server, after successful conclusion of security 
handshakes.
e) admittance to the network requires access to the short address and is 
realized at the same time as the security establishment.
f) message relay by the neighbor node (join assistant) would be 
contingent upon some policy filtering, since only control data is 
relayed ("quarantine procedure"). No MAC state or counters are strored 
by the relaying node. Potential DoS attacks are "countered" via rate 
limiting techniques.
g) initial communications from joining  node is secured (at MAC layer) 
using default key, with ASN-based nonce, with authentication-only mode 
of operation.
h) link layer (MAC) security is completely orthogonal to transport layer 
security, where the latter uses the CCM* mode of operation.

SD asked about next steps: he referred to Tero Kivinen's review 
(informal Security Directorate) review and TK's role in championing 
ideas in IEEE 802.15.4 and 802.15.9. He suggested that (a) one should 
not assume a pre-shared key; (b) one does not use a well-known key for 
the join process. YO suggested that one might still be able to support 
two types of network, join network and production network. MR was just 
off the call, so no opportunity to poll his opinion. TK suggested that 
(a) w/HART was quite different; (b) certain ports were visible to 
joiners; (c) beacon only relevant to joining nodes; (d) one had only one 
network ("production network"), with a corner that would relate to the 
joining node - neighbor device/join assistant ("join network"); (e) it 
was better to use no security during MAC layer messaging and use the 
exempt flag construct instead; (f) using a "well-known key" for join 
security was a bad idea.

--Slide 11:
MV came back to the join architecture discussion presented on Slides 
9-11. He noted that the slides assumed a role for the router node (join 
assistant) that stretches further than just the role of relay station: 
it only forwards traffic to the server after first authenticating the 
joining node. Here, the idea was that while authentication does not 
offer fine-grained authorization control (without further filtering 
mechanisms on the router (join assistant)), it might help in limiting 
denial-of-service attacks targeting the long-haul communication channel 
between the router (join assistant) and the server (JCE). MV noted that 
more fine-grained authorization policies would still require 
communication with the server (for arbitrage), as would the 
configuration step in the join process. RS suggested that if credentials 
were handed out locally ("this node belongs to production facility 
XYZ"), then network authorization could indeed be done locally, without 
need for online arbitrage by server, but that credentialing details 
still needed more work. RS suggested that it would not be too hard to 
extend this mechanism to support both the relay and the authenticating 
role of the router (join assistant), where decision whether to support a 
relay-only mode as well would depend on more detailed cost/benefit 
analysis. He did suggest that relay-only modes had DoS issues with other 
IETF specs, such as DNS (hence, his emphasis on denial of service aspects).

5. AOB
The next conf call is scheduled for Tue January 5, 2015, 5pm EST, after 
a well-deserved Christmas/New Year's break.

Best regards, Rene

---

From: Rene Struik <[email-masked]>
Date: Wed, 14 Jan 2015 09:54:14 -0500

Dear colleagues:

Please find below the (corrected) minutes of the 6TiSCH Security conf 
call as of December 16, 2014, 5pm EST. {Correction re configuration 
(item #4, Slide 10, bullet #i) in italics}

-------- Forwarded Message --------
Subject: 	(minutes of Tue Dec 16, 2014, 5pm EST call) Re: Suggested 
agenda for 6tisch security call of *today*, Tue December 16, 2014, 5pm 
EST (dial-in info at bottom)
Date: 	Wed, 14 Jan 2015 09:48:13 -0500
From: 	Rene Struik <[email-masked]>
To: 	tisch-security <[email-masked]>

Dear colleagues:

1. Attendance:

2. Agenda

--Slide 9:
no discussion

--Slide 10:
/i)//server configures joining  nodes and neighbor nodes (join 
assistant) with common resources, dedicated set of links, application 
protocol related info (lots of other devices)./

--Slide 11:

5. AOB

Best regards, Rene

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 14 Jan 2015 17:03:33 +0100

Rene,

I'd like to converge on which text the security team is proposing for the
architecture draft. We currently have 3 proposals on the table:

http://www.ietf.org/mail-archive/web/6tisch/current/msg02690.html
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00328.html
https://tools.ietf.org/html/draft-struik-6tisch-security-considerations-01

Thomas

On Wed, Jan 14, 2015 at 1:37 AM, Rene Struik <[email-masked]> wrote:

>  Dear colleagues:
>
> Just a quick reminder that we *do* have a conf call tomorrow, Wed Jan 14,
> 2015, 11am EST.
>
> 6tisch architecture draft. It would also be good to have some more comments
> on the draft I posted.
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Jan 2015 19:04:15 -0500

I've read the minutes, and they reflect my memory too.

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

---

From: Rene Struik <[email-masked]>
Date: Fri, 16 Jan 2015 17:21:30 -0500

Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of 
January 14, 2015, 11am-12pm EST.

Minutes 6TiSCH Security conf call, Wed January 14, 2015, 11am-12pm EST
{note taker: Rene Struik}
{recording: see 6tisch bitbucket list}
{slides discussed (and referenced in minutes): no slides this time}

1. Attendance:
Michael Richardson, Malisa Vucinic, Mike Seewald, Thomas Watteyne, Rene 
Struik

2. Agenda
The suggested agenda was approved.
Agenda:
1) administrativia {agenda bashing/minutes}
2) (brief update) feedback on posted security draft
3) input 6tisch security to the 6tisch architecture draft
4) AOB

3. Minutes
The minutes of the previous 6TiSCH security conference calls will be 
first item of agenda for approval at the next 6tTiSCH security 
conference call. {Please review.}

4. Feedback on posted security considerations draft 
(draft-struik-6tisch-security-architectural-considerations-01)
RS mentioned that he posted (on Fri January 9, 2015) a write-up on 
security considerations for 6tisch that provides lots of footnotes on 
behavior and security and implementation considerations re MAC, 
networking, and join protocol behavior. He also posted a slightly 
updated version (#01) that includes a high-level overview of the join 
protocol, including phases (authentication, authorization, 
configuration), device roles, and diagrams. He suggested that the draft 
tried to take into account technical discussions on 6TiSCH security 
calls since early December 2014, as well as offline feedback on 
pre-draft versions from several participants. While he acknowledged the 
draft still had some rough edges that needed polishing, he would welcome 
feedback from the group that would help in making the draft better. Kris 
Pister already kindly provided some preliminary feedback on the 6TiSCH 
mailing list, but more feedback would be much appreciated.

TW volunteered to provide feedback to the list.

5. Input 6tisch security to the architecture draft 
(draft-ietf-6tisch-architecture-04)
TW mentioned that there were currently three text proposals that could 
be used for inclusion with the architecture draft:
http://www.ietf.org/mail-archive/web/6tisch/current/msg02690.html
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00328.html
https://tools.ietf.org/html/draft-struik-6tisch-security-considerations-01

MV suggested that the verbiage of the three text proposals differed in 
level of detail provided, which made it hard to compare. RS suggested 
that at the previous 6TiSCH security conference call (Tue January 5, 
2015), everyone agreed that "the the level of detail would reflect 
consensus as reached to-date, so as to remove roadblocks by end of week" 
and that snippets that do (as yet) not carry this consensus would, 
therefore, have to be trimmed out. MR suggested that some of the 
language in section 1.3.1 of 
draft-struik-6tisch-security-considerations-01 was too high level and 
"does not align with what we were told". RS reminded the group that he 
simply provided text suitable for inclusion with the architecture draft 
that was known to reflect consensus to-date. Moreover, he suggested that 
the architecture draft does not have to carry all detailed information, 
if only because lots of work is still required to iron this out.

MR suggested that he would like to see inclusion of, e.g., details re 
trust relationships, certificate detail, and scalability properties. RS 
suggested that those could indeed be considered, but since some aspects 
hereof are still highly controversial at this time, this should be left 
out for now.

TW summarized some areas of consensus, including (a) identifying three 
device roles in the join process (joining node, join assistant, "JCE"); 
(b) aiming at minimization of long-haul communications between join 
assistant and JCE (ideally, only comprising one communication flow to 
and from the JCE, as, e.g., w/HART does).

MR suggested that it would be useful to add some verbiage re privacy 
aspects of addressing (e.g., that joined nodes would use short 
addresses). He further suggested that it would be useful to 
cross-reference some actual protocols that could be considered. As to 
the latter, RS suggested that it would certainly be possible to add some 
verbiage along the lines "the join protocol would consider authenticated 
key agreement protocols, such as, e.g., DTLS, and certificate schemes, 
such as, e.g., X509", etc., if referring to these acronyms would make 
people happy.

TW asked whether RS could review the three text proposals currently on 
the table and suggest a way forward that takes into account consensus 
and what was discussed during the call. RS agreed to take this on as 
homework assignment, with target to report back on this to the group by 
the end of Monday next week (January 19, 2015).

6. AOB
RS mentioned that there is no conference call schedule for next calls 
yet, but he would poll people re time preferences.

Best regards, Rene

-------- Forwarded Message --------
Subject: 	reminder -- 6tisch security call *tomorrow*, Wed Jan 14, 2015, 
11am EST (dial-in info at bottom)
Date: 	Tue, 13 Jan 2015 19:37:04 -0500
From: 	Rene Struik <[email-masked]>
To: 	tisch-security <[email-masked]>

Dear colleagues:

Best regards, Rene

==

---

From: Rene Struik <[email-masked]>
Date: Mon, 19 Jan 2015 14:20:21 -0500

Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, 
Tue January 20, 2015, 4.30-5.30pm EST.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) 6tisch security conf call schedule moving forward
3) input 6tisch security to architecture draft
-- RS to present result homework assignment of last call
4) prep for IETF-92 in Dallas
5) AOB

For dial-in info, please see bottom of this email.

As to item #2 above, if you wish to weigh-in, please do respond to the 
Doodle poll by end of *today*, see https://doodle.com/q63844gqd59urrae.

Best regards, Rene

-------- Forwarded Message --------

Dear colleagues:

Best regards, Rene

==

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Jan 2015 15:49:47 -0500

Rene Struik <[email-masked]> wrote:
    > Just a quick reminder that we have a 6TiSCH security conf call tomorrow, Tue
    > January 20, 2015, 4.30-5.30pm EST.

here again is the dial in info, I've adjusted the time to 4:30pm EST,21:30 UTC.

meeting number:   641 709 118
Meeting password: joinjoin
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: 641 709 118

---

From: Rene Struik <[email-masked]>
Date: Tue, 20 Jan 2015 01:13:03 -0500

Dear colleagues:

Please find attached my analysis of the three text proposals. I hope 
this helps in zooming in on consensus text.

I will present this in more detail as item #3 on the agenda for the 
6tisch security call of tomorrow, Tue Jan 20, 2015, 4.30pm EST.

We can discuss this in more detail during that call (I won't have much 
time beforehand).

Best regards, Rene

[excerpt of minutes of 6tisch security conf call as of January 14, 2015, 
11am-12pm EST]

On 1/19/2015 2:20 PM, Rene Struik wrote:
> Dear colleagues:
>
> Just a quick reminder that we have a 6TiSCH security conf call 
> tomorrow, Tue January 20, 2015, 4.30-5.30pm EST.
>
> Suggested agenda:
> Subject: 	reminder -- 6tisch security call *tomorrow*, Wed Jan 14, 
> 2015, 11am EST (dial-in info at bottom)
>> discuss higher-layer aspects I prepared material for yet. I suggest 
>> we continue the systematic discussion of last week and take that 
>> topic on now.
>>

---

From: Rene Struik <[email-masked]>
Date: Tue, 20 Jan 2015 16:35:00 -0500

I posted the document on Google drive, see weblink below.

https://drive.google.com/file/d/0B2a6Ilxu1XfCa3RyZzlZb3RRREk/view?usp=sharing

On 1/20/2015 1:13 AM, Rene Struik wrote:
> [excerpt of minutes of 6tisch security conf call as of January 14, 
> 2015, 11am-12pm EST]
> homework assignment, with target to report back on this to the group 
> by the end of Monday next week (January 19, 2015).
>
>> As to item #2 above, if you wish to weigh-in, please do respond to 
>> the Doodle poll by end of *today*, see 
>> https://doodle.com/q63844gqd59urrae.
>>
>> Best regards, Rene
>>
>> Currently, the main agenda item is item #4b of last week: input to 
>> the 6tisch architecture draft. It would also be good to have some 
>> more comments on the draft I posted.
>>
>> Minutes of calls later tonight (sorry - extremely busy). For conf 
>> call dial-in info, see bottom of email.
>>
>> Best regards, Rene
>>
>> ==
>>> Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. 
>>> {The next call, on January 6, 2014) is also at 5pm EST (see schedule 
>>> till half of January 2015)}.
>>> Conf call time: 5pm EST = 7am Japan = 2pm PST = 11pm Paris time. 
>>> {The next call, on January 6, 2014) is also at 5pm EST (see schedule 
>>> till half of January 2015)}.
>>>
>>> protocol;

---

From: Rene Struik <[email-masked]>
Date: Tue, 20 Jan 2015 16:54:48 -0500

Dear colleagues:

Due to connectivity problems, those on the 6tisch security call today 
concluded that it was best to reschedule the call.

The rescheduled 6tisch security call will take place this Thursday, 
January 22, 2015, 1-2pm EST.
(Please note that this is only once; schedule moving forward will 
otherwise remain the same)

Agenda and dial-in info remain the same (please scroll down).

Best regards, Rene

On 1/20/2015 4:35 PM, Rene Struik wrote:
>> We can discuss this in more detail during that call (I won't have 
>> much time beforehand).
>>
>> Best regards, Rene
>>
>> TW asked whether RS could review the three text proposals currently 
>> on the table and suggest a way forward that takes into account 
>> consensus and what was discussed during the call. RS agreed to take 
>> this on as homework assignment, with target to report back on this to 
>> the group by the end of Monday next week (January 19, 2015).
>>
>>> Just a quick reminder that we *do* have a conf call tomorrow, Wed 
>>> Jan 14, 2015, 11am EST.
>>>
>>>> {The next call, on January 6, 2014) is also at 5pm EST (see 
>>>> schedule till half of January 2015)}.
>>>> -- b) continuation of routing/communication flow aspects {last 
>>>> week, we did not finish the only two slides on this
>>>> {The next call, on January 6, 2014) is also at 5pm EST (see 
>>>> schedule till half of January 2015)}.
>>>>
>>>> Subject: 	suggested agenda for 6tisch security call of tomorrow, 
>>>> Tue December 9, 2014, 9am EST (dial-in info at bottom)
>>>> material and posted prior to the call. During the call, we 
>>>> discussed all MAC-related aspects relevant for the join protocol 
>>>> and did not discuss higher-layer aspects I prepared material for 
>>>> yet. I suggest we continue the systematic discussion of last week 
>>>> and take that topic on now.
>>>>
>>>> I will prepare material to facilitate discussion on 1) and 2), to 
>>>> be discussed during the call.
>>>>

---

From: Rene Struik <[email-masked]>
Date: Wed, 21 Jan 2015 10:30:35 -0500

Dear colleagues:

Giuseppe Piro offered to give a presentation on MAC security aspects, 
resulting in the updated agenda below. Dial-in info at bottom of email.

Remember: 6tisch security call is now tomorrow, Thu Jan 21, 2015, 1pm 
EST, with duration not to exceed one hour. Please call-in on time and 
test your speaker/mike beforehand.

Suggested updated agenda:
1) administrativia {agenda bashing/minutes} [4 min]
2) 6tisch security conf call schedule moving forward [1 min]
3) input 6tisch security to architecture draft [15 min]
-- RS to present result homework assignment of last call
4) presentation Giuseppe Piro re MAC security [30 min]
5) prep for IETF-92 in Dallas [10 min]
5) AOB

Link to suggested text (item #3 above):
https://drive.google.com/file/d/0B2a6Ilxu1XfCbVhfd0ZONXoxc00/view?usp=sharing

On 1/20/2015 4:54 PM, Rene Struik wrote:
>>> this on as homework assignment, with target to report back on this 
>>> to the group by the end of Monday next week (January 19, 2015).
>>>
>>>>> According to the agreed-upon 6tisch security conf call schedule, 
>>>>> we will resume the conference call series today, Tue Jan 6, 2015, 
>>>>> 5pm EST.
>>>>>
>>>>> Subject: 	Suggested agenda for 6tisch security call of *today*, 
>>>>> Tue December 16, 2014, 5pm EST (dial-in info at bottom)
>>>>>     #1a-b) focus on routing/communication flow related aspects
>>>>>     join protocol (we discussed MAC-related join-relevant aspects
>>>>>     during the conf call of Tue Dec 2, 2014, 9am EST).
>>>>>     For slides, see

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Jan 2015 12:51:52 -0500

Rene Struik <[email-masked]> wrote:
    > The rescheduled 6tisch security call will take place this Thursday, January
    > 22, 2015, 1-2pm EST.
    > (Please note that this is only once; schedule moving forward will otherwise
    > remain the same)

I've moved the webex to that time, same codes.

---

From: Rene Struik <[email-masked]>
Date: Fri, 23 Jan 2015 17:24:33 -0500

Dear colleagues:

Minutes 6TiSCH Security conf call, Wed January 22, 2015, 1-2pm EST
{note taker: Rene Struik}
{recording: see 6tisch bitbucket list}
{discussion material (referenced in minutes): see Google Drive weblink 
https://drive.google.com/?tab=co&authuser=0#folders/0B2a6Ilxu1XfCNF9JaXR1ZXlzZlU}

1. Attendance:
Michael Richardson, Subir Das, Tero Kivinen, Giuseppe Piro, Pascal 
Thubert, Rene Struik

2. Agenda
The suggested updated agenda was approved.

3. Minutes
The minutes of all previous 6TiSCH security conference calls in the time 
window Dec 2, 2015 till Jan 14, 2015 that had not been formally approved 
yet were all approved.

4. 6tisch security call schedule moving forward
RS suggested he had posted the conf call schedule through March 9th, 
after polling preferences via a Doodle poll.
For details, see 
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00397.html

5. Input 6tisch security to the architecture draft 
(draft-ietf-6tisch-architecture-04)
RS reported on the outcome of the homework assignment of the 6tisch 
security call of the previous week (Jan 14, 2015). He had scrutinized 
the three text proposals that were on the table and had reviewed those 
with aim of establishing which elements reflected consensus of the 
6tisch security group and also suggested "consensus text" the text in 
the document titled "join process text - suggested text for architecture 
document, v2 (Rene Struik, January 21, 2015)" (available via the Google 
Drive link). He suggested to go over the (hopefully) consensus text, 
identity areas where this could be improved on the call, and then post a 
revision reflecting this as input to the architecture document prior to 
the 6tisch call of the next day (Friday January 23, 2015, 11am EST). 
Further comments, if any, could then be made as part of the review 
process of the architecture doc, rather than rehashing this more now, 
thus allowing Pascal Thubert to move forward with the architecture 
document and the 6tisch security group to focus on drilling down on more 
detail of the join protocol itself. MR suggested he was happy with this 
process.

RS briefly went over the document, identifying some feedback received 
from Subir Das and Yoshi Ohba by email. He also highlighted that he had 
incorporated the suggestion by MR on the previous call to 
cross-reference some actual protocols that could be considered. A brief 
discussion ensued.

PTh suggested that it would be good to add some language to the effect 
that the actual decision of the joining node to become part of the 
network may depend on authorization of the network itself. It was 
decided to leave out further minutiae, such as "authorization of the 
root of the RPL network", etc., so as to focus on the join process 
itself, without adding too much routing protocol baggage for now. RS 
suggested that this would also avoid issues that could arise in case 
distributed JCE's would be considered, which would not correspond to a 
single, fixed node. SD suggested to swap the order in which the join 
protocol phases and the device roles were presented in the text. He 
further on noted that some of the terminology re joining node, join 
assistant, and JCE was not entirely in with what was depicted in Fig. 1. 
Finally, he suggested a few small edits, such as clarifying that a 
"one-hop neighbor" would be one "radio hop" away and not one IP hop, etc.

RS agreed to try and incorporate this feedback and post a revised text 
document, aimed to be ready for inclusion with the architecture 
document. {Everybody hereby earned drink credits for reaching this mile 
stone and getting this topic off our chest (violins, harps, and trumpet 
sounds could be heard on the background)...!}

6. Presentation Giuseppe Piro re MAC security
GP gave a presentation on some issues with 802.15.4-2011 security in the 
context of the join protocol (see document "l2-sec-issues-join - v2 
(Giuseppe Piro, January 22, 2015), available via Google Drive link). The 
context (Slide #7) was that of a joining node that tries to become part 
of a fully secure network (i.e., the join assistant and the path towards 
the JCE is secured). The main problem identified was that, in 
802.15.4-2011, it is not possible to mix secured and unsecured traffic 
(due to some details in the incoming frame security procedure (clause 
7.2.3, Step f)). GP described a potential work-around, where one would 
install a random key (termed "fake_l2"key" on Slide #11), which only 
purpose was to jump the specification hurdle (so, it would never be 
reallly used). He also described how one could end up in the exempt 
status stage (by constructing a device descriptor for the joining node 
on the fly and setting the exempt flag). After the presentation, a brief 
discussion followed.

TK suggested that mixing of secured and unsecured traffic was possible, 
since "nobody would implement Step f) if one had an incoming frame 
without security". RS noted that GP's presentation assumed an 
implementation compliant with the 802.15.4-2011 specification, not one 
that deviated from this. TK suggested that the work-around in the 
presentation would fail, since it relied on KeyIDMode 0x00, which he 
thought would be undefined. Since the conference call was living on 
borrowed time (65 minutes into the call), there was no time to verify 
this claim on-the-fly.

Upon TK mentioning that the draft 802.15.4 revision text on security 
should be used, RS asked whether this draft was available to the 6tisch 
audience. TK mentioned that he would send a request to Bob Heile (Chair 
of IEEE 802.15) to request drafts (normally only available to 802.15 
voters) to be made available to interested 6tisch stakeholders.

[call concluded at 2.15pm EST]

Best regards, Rene

On 1/21/2015 10:30 AM, Rene Struik wrote:
>>>> Please find attached my analysis of the three text proposals. I 
>>>> hope this helps in zooming in on consensus text.
>>>>
>>>>>> For last week's Tue Dec 2, 2014, 9am EST conf call I prepared 
>>>>>> some material and posted prior to the call. During the call, we

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 24 Jan 2015 16:31:32 +0200

Rene Struik writes:
> should be used, RS asked whether this draft was available to the
> 6tisch audience. TK mentioned that he would send a request to Bob
> Heile (Chair of IEEE 802.15) to request drafts (normally only
> available to 802.15 voters) to be made available to interested
> 6tisch stakeholders.

And as the draft can only be given to named individuals, if you want
to see the draft send me an email, so I can include you in the list.
-- 
[email-masked]

---

From: Rene Struik <[email-masked]>
Date: Mon, 26 Jan 2015 12:15:39 -0500

Dear colleagues:

Just a quick reminder that we have a 6TiSCH security conf call tomorrow, 
Tue January 27, 2015, 9am EST. I expect this to be a short call.

Suggested agenda:
1) administrativia {agenda bashing/minutes}
2) prep for IETF-92 in Dallas
3) AOB

The dial-in info is below.

Best regards, Rene

Access code: 641 709 118
Meeting link:

---

From: Rene Struik <[email-masked]>
Date: Wed, 28 Jan 2015 10:16:04 -0500

Dear colleagues:

Please find below the minutes of the 6TiSCH Security conf call as of 
January 27, 2015, 9-10am EST.

Minutes 6TiSCH Security conf call, Wed January 27, 2015, 9-10am EST
{note taker: Rene Struik}
{recording: not available (Michael Richardson had control, but was not 
on the call}
{discussion material (referenced in minutes): this time, no posted 
collatoral}

1. Attendance:
Tero Kivinen, Yoshi Ohba, Rene Struik

2. Agenda

3. Minutes
The minutes of the previous 6TiSCH security conference call (Thu January 
22, 2015) were approved.

4. Prep for IETF-92 in Dallas {more of a 6tisch security various "varia" 
discussion really}
YO asked what happened with the output of the join process overview text 
discussed during last week's call. RS mentioned that Pascal Thubert 
included this in the 6tisch architecture draft (Section 13 - Security 
Considerations) and would issue draft-ietf-6tisch-architecture-05 for 
WGLC some time this week.

RS mentioned that at the IETF-92 meeting in Dallas in March, the 6tisch 
group would presumably recharter and include more security-related 
milestones into the revised charter. He thought it would be useful to 
have a 6tisch security draft by that meeting that could serve as baseline.

TK provided some more insight into the 802.15.4rev effort. He suggested 
that there would be 1-2 more letter ballots, followed by the start of 
sponsor ballot around end of March 2015, with anticipated conclusion of 
the work around July-August this year. RS commented that this schedule 
seemed quite aggressive, considering historical timelines of IEEE 802.15 
efforts. TK mentioned that according to Bob Heile (Chair IEEE 802.15) 
the 802.15rev draft would only be available in the 802.15 private member 
area or to those people participating in person in an actual IEEE 802 
meeting. Therefore, it does not seem possible to make a draft available 
to interested parties in the 6tisch community who did not meet those 
criteria (as previously suggested).

5. AOB
RS suggested to cancel the 6tisch security call of next week and 
reconvene two weeks from now, which was agreed upon. _Next call will 
take place Tue Feb 10, 2015, 4.30pm EST._

RS mentioned he had received feedback from Kris Pister and Yoshi Ohba on 
draft-struik-6tisch-security-architectural-considerations-01 (posted 
January 9, 2015). Before updating the draft, he would like to see more 
people give this a look. He invited people to use the now cancelled slot 
of next week's call to review this draft...

[call ended @9.23am EST]

On 1/26/2015 12:15 PM, Rene Struik wrote:
> tomorrow, Tue January 27, 2015, 9am EST. I expect this to be a short call.
>
> Suggested agenda:
>>> Due to connectivity problems, those on the 6tisch security call 
>>> today concluded that it was best to reschedule the call.
>>>
>>>>> I will present this in more detail as item #3 on the agenda for 
>>>>> the 6tisch security call of tomorrow, Tue Jan 20, 2015, 4.30pm EST.
>>>>>
>>>>> TW asked whether RS could review the three text proposals 
>>>>> currently on the table and suggest a way forward that takes into 
>>>>> account consensus and what was discussed during the call. RS 
>>>>> agreed to take this on as homework assignment, with target to 
>>>>> report back on this to the group by the end of Monday next week 
>>>>> (January 19, 2015).
>>>>>
>>>>>> As to item #2 above, if you wish to weigh-in, please do respond 
>>>>>> to the Doodle poll by end of *today*, see 
>>>>>> Subject: 	reminder -- 6tisch security call *tomorrow*, Wed Jan 
>>>>>> 14, 2015, 11am EST (dial-in info at bottom)
>>>>>> Currently, the main agenda item is item #4b of last week: input 
>>>>>> to the 6tisch architecture draft. It would also be good to have 
>>>>>> some more comments on the draft I posted.
>>>>>>
>>>>>>> we will resume the conference call series today, Tue Jan 6, 
>>>>>>> 2015, 5pm EST.
>>>>>>>
>>>>>>> Christmas (essentially, item 3c below), except that we may have 
>>>>>>> a short presentation first (item #2).
>>>>>>>
>>>>>>> Agenda:
>>>>>>> yet. I suggest we continue the systematic discussion of last 
>>>>>>> week and take that topic on now.
>>>>>>>
>>>>>>>     join protocol (we discussed MAC-related join-relevant
>>>>>>>     aspects during the conf call of Tue Dec 2, 2014, 9am EST).
>>>>>>>     For slides, see
>>>>>>>     Relevant slides: Slides 23-25 (contained in entire slide
>>>>>>>     deck (ppt), but also in excerpt (pdf))
>>>>>>>
>>>>>>> 2) Next steps:
>>>>>>>     #2c) {as consequence of two items above} what to squeeze
>>>>>>>     into architecture draft
>>>>>>>
>>>>>>> I will prepare material to facilitate discussion on 1) and 2), 
>>>>>>> to be discussed during the call.
>>>>>>>