Rene,
FYI, I have archived those minutes at
https://bitbucket.org/6tisch/meetings/wiki/141202a_webex_security.

All,
Note that all minutes, attendance, recordings and meeting material is
archived at https://bitbucket.org/6tisch/meetings/. Please speak up if you
see something is missing.

Thomas

On Tue, Dec 9, 2014 at 12:09 AM, Rene Struik <rstruik.ext@gmail.com> wrote:
>
>  Dear colleagues:
>
> Please find below the minutes of the 6TiSCH Security conf call as of
> December 2, 2014, 9am EST.
>
> Minutes 6TiSCH Security conf call, Tue December 2, 2014, 9-10am EST
> {note taker: Rene Struik}
> {recording:
> https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing
> }
> {slides discussed (and referenced in minutes):
> https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing
> }
>
> 1. Attendance:
> Michael Richardson, Yoshi Ohba, Subir Das, Piro Giuseppe, Rene Struik
>
> 2. Agenda
> The suggested agend was approved.
>
> 3. Join process - desirable vs. realizable properties
> RS went over the desirable properties of the join process (Slide 6). MR
> raised point that privacy of the device identity of the joining node might
> not be required. . SD suggested that it is fine to include privacy in list
> of "desiderata"; evaluation metrics might consider these in "grey tones"
> vs. as "black and white" requirement. RS suggested that merit of privacy
> might depend on deployment scenario, but is on the radar in lots of IETF
> groups (in terms of traceability/tracking); if privacy can be easily
> offered as additional feature, this  would be a plus. After asking, there
> was no further discussion on properties listed.
>
> 4. Join process - MAC behavior.
> RS went over some MAC security aspects of the 802.15.4-2011 and
> 802.15.4e-2012 specifications (Slides 19-22). The main premise here was
> that a recipient device that expects secured traffic, will reject all
> incoming unsecured traffic, unless this originates from a device with
> so-called "exempt status". This "exempt status" construct allows receipt of
> incoming unsecured data frames from a joining node that does not have
> network-specific keying material yet. How to switch on/off this "exempt
> status" parameter was also discussed (see Slide 20). Furthermore, there was
> some discussion on how this compares to the use of so-called "default keys"
> (aka "fake" keys) (see also Slide 22).
>
> PG mentioned that 802.15.4 does not allow the use of the default key. SD
> suggested that an important point in not using default keys is that all
> incoming processing with keys will be treated transparently, irrespective
> of exceptions. RS explained that even if default keys were to be used, this
> would mess up local security state (e.g., frame counters), which is not the
> case if one would send unsecured traffic and use the "exempt status"
> construct instead. PD summarized that using unsecured frames, rather than
> "fake" security with "default keys", should be adopted, which was consensus
> on the call.
>
> PG came back to the "exempt flag" topic and suggested that details hereof
> are in the "device descriptor lookup table". RS suggested that we all have
> a closer look at specification details, so that switching this feature
> on/off could be easily codified for 6TiSCH use.
>
> 5. Join process - non-MAC behavior.
> Given remaining time on the call would not allow full discussion of
> non-MAC aspects (Slides 23-25) and given that MR had to drop off the call,
> it was decided to revisit those topics at the next conf call.
>
> 6. AOB Conf call scheduling.
> SD suggested he was confused about having two call times in email traffic
> (one at 9am EST and one at 11am EST) and suggested that other groups, such
> as, e.g., IEEE, often use cyclic schedule, so as to accommodate
> participants from around the world and who may be at widely different time
> zones. RS volunteered to look into this topic and obtain feedback on such a
> schedule.
>
> Best regards, Rene
>
> On 12/1/2014 11:55 AM, Rene Struik wrote:
>
> Proposed agenda:
>
> 0) Agenda bashing
>
> 1) Join protocol details
>
> a) desired properties
> b) realizable properties
>
> 2) Next steps:
>         a) consensus on 1#a and 1#b
>         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.
>
> Best regards, Rene
>
>
> On 11/28/2014 11:02 AM, Rene Struik wrote:
>
>  Dear colleagues:
>
>
> I have set up a conf call for Tuesday December 2, 2014 at a time that
> tries and accommodate people in different time zones to the largest extent
> possible, without trying to discriminate against various parts of the world.
>
>
> Please see dial-in information below.
>
>
> Agenda to follow Monday around noon.
>
>
> Looking forward to a collaborative meeting, in good spirit.
>
>
>  Best regards, Rene
>
> ==
>
>
>  1.  Please join my meeting.
>
> https://global.gotomeeting.com/join/594299061
>
>
>
> 2.  Use your microphone and speakers (VoIP) - a headset is recommended.  Or,
> call in using your telephone.
>
>
>
> Dial +1 (647) 497-9351
>
> Access Code: 594-299-061
>
> Audio PIN: Shown after joining the meeting
>
>
>
> Meeting Password: collaborate
>
> Meeting ID: 594-299-061
>
>
>
> GoToMeeting®
>
> Online Meetings Made Easy®
>
>
>
> Not at your computer? Click the link to join this meeting from your
> iPhone®, iPad®, Android® or Windows Phone® device via the GoToMeeting app.
>
>
>
> [excerpt email as of Thu November 27, 2014, 9.42pm EST]
> I suggest 9am EST = 6am PST = 3pm Paris = 11pm Japan. This should allow
> people to have their private time in the 12am-6am time window. {Other
> groups do a much better job at this...}
>
>
> On 11/28/2014 10:39 AM, Michael Richardson wrote:
>
> Subir Das <subirdas21@gmail.com> <subirdas21@gmail.com> wrote:
>     > Thanks for arranging the calls. It would be good to accommodate Asian time
>     > zone for broader participation. I would suggest choosing a time that is
>
> I'm happy to do this at another time; the original choice of 11am Eastern was
> to accomodate Pacific Time Zone People who couldn't meet before 8am.
>
> >From long experience, our choices essentially are at 15:00 UTC or 03:00 UTC.
>     07:00 Pacific/10:00 Eastern / 17:00 Helsinki/22:00 Beijing
> or
>     19:00 Pacific/22:00 Eastern / 05:00 Helsinki/10:00 Beijing
>
> I am also happy to alternate.
> Shall I put up a doodle poll?
>
>
>
>
> _______________________________________________
> 6tisch-security mailing list6tisch-security@ietf.orghttps://www.ietf.org/mailman/listinfo/6tisch-security
>
>
>
> --
> 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
>
>
>
> --
> email: rstruik.ext@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>
>
> _______________________________________________
> 6tisch-security mailing list
> 6tisch-security@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch-security
>
>