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

On 12/16/2014 9:21 AM, Rene Struik wrote:
> 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 <rstruik.ext@gmail.com>
> To: 	tisch-security <6tisch-security@ietf.org>
>
>
>
> 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:rstruik.ext@gmail.com  | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>
>


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363