Subject: [6tisch-security] (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan

From: Rene Struik <[email-masked]>
Date: Mon, 01 Dec 2014 11:55:45 -0500

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<[email-masked]>  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 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

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 01 Dec 2014 13:37:16 -0500

> b) realizable properties

Please, where is the text and/or slides that go with this discussion?

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

---

From: Rene Struik <[email-masked]>
Date: Mon, 01 Dec 2014 20:07:52 -0500

Hi Michael:

As already said, I have material to be discussed during the 9am EST 
call, so as to make progress on the suggested agenda items.

As I am sure you understand, the reason to have a conference call is 
that often times actual conversations are more effective in making 
technical progress than having a long sequence of emails.

I am looking forward having the conf call tomorrow being an example 
illustrating this point.

I also welcome technical points brought up by an as wide set of people, 
where each gets the floor to bring their insight across.

Speak with you tomorrow.

Best regards, Rene

---

From: Michael Richardson <[email-masked]>
Date: Mon, 01 Dec 2014 21:59:29 -0500

>> > a) desired properties

Here are the requirements which the 6tisch-security group was given.
True, they were communicated orally, and perhaps my attempt to capture them
was poor, in which case, I hope that some people will post adjustments.

I pull the following text out, as a kind of executive summary:
   The ultimate goal of the join protocol is to provide a new node with
   a locally significant security credentials so that it is able to take
   part in the network directly.

====

Intro:

   A challenging part with constructing an LLN with nodes from multiple
   vendors is providing enough security context to each node such that
   the network communication can form and remain secure.  Most LLNs are
   small and have no operator interfaces at all, and even if they have
   debug interfaces (such as JTAG) with personnel trained to use that,
   doing any kind of interaction involving electrical connections in a
   dirty environment such as a factory or refinery is hopeless.

   It is necessary to have a way to introduce new nodes into a 6tisch
   network that does not involve any direct manipulation of the nodes
   themselves.  This act has been called "zero-touch" provisioning, and
   it does not occur by chance, but requires coordination between the
   manufacturer of the node, the service operator running the LLN, and
   the installers actually taking the devices out of the shipping boxes.

...

3.2.  Join Protocol deliverables

   This section works from the ultimate goal, and goes backwards to
   prerequisite actions.  (Section 6 presents the protocol from
   beginning to end order)

   The ultimate goal of the join protocol is to provide a new node with
   a locally significant security credentials so that it is able to take
   part in the network directly.  The credentials may vary by
   deployment.  They can be one of:

   1)  a network-wide shared symmetric key (this is the production
       network key, or MasterKey)

   2)  a locally significant (one-level only) 802.11AR type LDevID
       certificate (which allows it to negotiate a pair-wise keys)

   One of these two items is delivered by JCE to the joining node using
   the 6top protocol.  That is, the JCE provisions using a secure
   "northbound" interface.  The authentication of this interface the
   subject of the Join Protocol as explained below.

   The above credential are used for authentication to generate per-peer
   L2, using a key exchange protocol.  The choice of key exchange
   protocol, and what kind of link and multicast keying needs to be done
   is also provisioned by the JCE.  There are a number of options for
   doing this, such as:

   1)  Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment]
       (IMPORTANT, a good option.  Uses certificates from common CA)

   2)  work in 802.15.9 (uses certificates from common CA)

   3)  Security Framework and Key Management Protocol Requirements for
       6TiSCH [I-D.ohba-6tisch-security] (this document provides the
       phase 0 required, using the network-wide shared key)

   4)  Layer-2 security aspects for the IEEE 802.15.4e MAC
       [I-D.piro-6tisch-security-issues]: the MasterKey is used to
       derive per-peer L2 keys

   Per-peer L2 keying is critical when doing peer-2-peer schedule
   negotiation over 15.4 Information Elements.  Therefore a network-wide
   layer-2 key is inappropriate for the self-organizing networks, and a
   protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys.

   For networks where there is a PCE present and it will do all schedule
   computation, then the only trust relationship necessary is between
   the individual node and the PCE, and it MAY be acceptable to have a
   network-wide L2 key derived in ways such as
   [I-D.piro-6tisch-security-issues] describes in section ?.  The trust
   relationship between the PCE and the joining node flows from the
   LDevID certificate loaded by the JCE.  When the PCE and JCE are co-
   located, the existing 6top/DTLS security association could be reused.

3.3.  Join Protocol connection setup

   The intermediate level goal of the join protocol is to enable a Join
   Coordination Entity (JCE) to reach out to the new node, and install
   the credentials detailed above.  The JCE must authenticate itself to
   the joining node so that the joining node will know that it has
   joined the correct network, and the joining node must authenticate
   itself to the JCE so that the JCE will know that this node belongs in
   the network.  This two way authentication occurs in the 6top/CoAP/
   DTLS session that is established between the JCE and the joining
   node.

   [I-D.ietf-6tisch-6top-interface] presents a way to interface to a
   6top information model (defined in YANG).  [I-D.ietf-6tisch-coap]
   explains how to access that information model using CoAP.  This
   information model will include security attributes for the network.
   The JCE would therefore reach out to the joining node and simply
   provision appropriate security properties into the joining node, much
   like the PCE will provision schedules.

   This 6top-based secure join protocol has defined a push model for
   security provisioning by the JCE.  This has been done for three
   reasons:

   1)  6tisch nodes already have to have a 6top CoAP server for schedule
       provising

   2)  this permits the JCE to manage how many nodes are trying to join
       at the same time, and limit how much bandwidth/energy is used for
       the join operation, and also for the JCE to prioritize the join
       order for nodes.

   3)  making the JCE initiate the DTLS connection significantly
       simplies the certificate chains that must be exchanged as the
       most constrained side (the joining node) provides it's
       credentials first, and lets the less constrained JCE figure out
       what kind of certificate chain will be required to authenticate
       the JCE to the joining node.  In EAP-TLS/802.1x situations, the
       TLS channel is created in the opposite direction, and it would
       have to complete in a tentative way, and then further
       authorization occur in-band.

3.4.  End to End considerations for Join Protocol

   In order for a 6top/DTLS/CoAP connection to occur between the JCE and
   the joining node, there needs to be end-to-end IPv6 connectivity
   between those two entities.  The joining node will not participate in
   the route-over RPL mesh, but rather will be seen by the network as
   being a 6lowpan only leaf-node.

..

---

From: Michael Richardson <[email-masked]>
Date: Mon, 01 Dec 2014 22:03:57 -0500

Rene Struik <[email-masked]> wrote:
    > As already said, I have material to be discussed during the 9am EST call, so
    > as to make progress on the suggested agenda items.

I'm looking forward to receiving the material in a form that I can open 
prior to the call.  
gotomeeting fails on most platforms, so I will be on the telecon only.

---

From: Rene Struik <[email-masked]>
Date: Tue, 02 Dec 2014 08:56:25 -0500

Dear colleagues:

For those of you who somehow seem to have display problems with 
GoToMeetings, please find attached slides to be discussed during the 
call. This focuses on MAC behavior and Routing aspects of the join 
process. It is my strong desire that the group as a whole gains more 
understanding of how the MAC actually works and also considerations that 
may trigger routing questions, mostly from a security perspective.

The slides are pp. 17-25 (and the desired/realizable properties of the 
join process).

Agenda item 2) will be discussed without slide hand-out.

Slides will be discussed on the call.

Rene

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Dec 2014 10:52:22 -0500

Rene, you said in the "9am" call that you sent the slides out, but I didn't
find them in any email to the list.  If they are the same slides at in
Honolulu, then I guess they are in the proceedings.  I'm sorry I was unable
to turn on my mic in the coffee shop, you would have just have had muzak and
espresso machines and crying babies; I had just come from dropping son at
school, and I did not have time to either return to my home office or make it
to work in time. 

You have done an excellent job of explaining the layer-2 security processing
that the join assistant will need to be able to do.  

Will you commit to writing this processing up in a way that can be put into
the detailed 6top join processing?  

I see now that my mistake was in assuming that it was well understood that
a node could process both encrypted and unencrypted packets, and could
distinguish packets encrypted with one key from those encrypted with another
key.   I see that it was this detail that you wanted to discuss; I see no
controversy myself, but this may stem from having spent 20 years working on
layer-3 IPsec mechanisms (rfc2401 and rfc4301 speak at length about this kind
of thing).  

I see from your explanation that this is all possible with 802.15.4, and I
thank for this detailed explanation.  I can not disagree about any of it.

Are we done talking about layer-2 issues now?
You have my agreement.

Will you document the layer-2 attributes which must be configured for the 6top
YANG interface definition?   Which role do you think should own the multicast
key material?  The JCE? the PCE? the 6LBR?  

Tero has suggested a mechanism whereby the we could have a cycle of 16 keyIds
for the multicast key.  We will need to delineate which RPL messages can be
trusted when secured with the layer-2 multicast key, and which ones require
a peer to peer key.  
Clearly the Minimal IE-based 6top interface has to use peer to peer keys.

Given that we have introduced locally significant key pairs via the 6top
interface, do you think that there is value in using the assymmetrically
secured RPL messages that you defined in 6550?

---

From: Rene Struik <[email-masked]>
Date: Tue, 02 Dec 2014 11:01:47 -0500

Hi Michael:

I forwarded the slides prior to the call to the 6tisch security mailing 
list. This also included details on what to be discussed during the 
call. (see 
http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00295.html)

I did a partial write-up of all details, but my xml2rfc editor (I used 
the online version) did not seem to work yesterday. I will try and get 
this off my to-do list, since the devil is in the details.

I will have to reflect on some of the higher layer routing aspects you 
asked about. (I did have some slides about routing aspects, but we kept 
it to MAC behavior, both because of time issues and because you had to 
drop off the call and we really would like you to be there).

More later.

Rene

---

From: Subir Das <[email-masked]>
Date: Tue, 2 Dec 2014 16:57:08 -0500

Sorry for my late reply. Either you or Rene should do a doodle poll on this
and then schedule one call. I was also equally confused yesterday with two
call notices.

-Subir

On Fri, Nov 28, 2014 at 10:39 AM, Michael Richardson <[email-masked]>
wrote:

>
> Subir Das <[email-masked]> wrote:

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 2 Dec 2014 23:06:52 +0000

I too got confused on the meeting notices.  I am on PST and could do a 7amPST or late evening to accommodate Asian timezones….

Thanks, Nancy

From: Subir Das <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 2, 2014 at 1:57 PM
To: Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tisch-security] agenda for upcoming 6tisch security calls

Sorry for my late reply. Either you or Rene should do a doodle poll on this and then schedule one call. I was also equally confused yesterday with two call notices.

-Subir

On Fri, Nov 28, 2014 at 10:39 AM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

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

---

From: Rene Struik <[email-masked]>
Date: Mon, 08 Dec 2014 18:09:10 -0500

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

---

From: <[email-masked]>
Date: Tue, 9 Dec 2014 00:03:17 +0000

Hi Rene,

I would like to double check the meaning of “exempt status”.  I thought the “exempt status” is maintained by higher layer and is different from the “Exempt” flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes.

I am asking this because, while the “Exempt” flag of 802.15.4-2011 DeviceDescriptor of Security-related PIB attributes allows unsecured frames to be passed to higher layer, the flag solely does not help for joining node’s higher layer to process authenticated-only secured beacons.

Yoshihiro Ohba

From: 6tisch-security [mailto:[email-masked]] On Behalf Of Rene Struik
Sent: Tuesday, December 9, 2014 8:09 AM
Cc: [email-masked]
Subject: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan

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:

2. Agenda

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

0) Agenda bashing

1) Join protocol details
a) desired properties
b) realizable properties
2) Next steps:

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

Best regards, Rene

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.

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

GoToMeeting(r)
Online Meetings Made Easy(r)

Not at your computer? Click the link to join this meeting from your iPhone(r), iPad(r), Android(r) or Windows Phone(r) 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...}

or

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

--

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

--

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

--

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

---

From: Rene Struik <[email-masked]>
Date: Mon, 08 Dec 2014 20:48:55 -0500

Hi Yoshi:

Good point (and I remember we discussed this, while going over Slide 20, 
but I forgot to include this in the minutes [I will correct this]).

The idea is that if a joining device receives a secured beacon frame, it 
can still extract the visible portion of the frame, even if it cannot do 
proper incoming security processing (obviously, it cannot really rely on 
this data at this point, then).

With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active 
Channel Scan), of which the excerpt from p. 174 of the spec describes 
the corresponding behavior:

    If a protected beacon frame is received, i.e., the Security Enabled
    subfield in the Frame Control field is set to one, the device shall
    attempt to unsecure the beacon frame using the unsecuring process
    described in 7.5.8.2.3.
    The security-related elements of the PAN descriptor corresponding to
    the beacon (see Table 55) shall be set to the corresponding
    parameters returned by the unsecuring process. The SecurityFailure
    element of the PAN descriptor shall be set to SUCCESS if the status
    from the unsecuring process is SUCCESS and set to one of the other
    status codes indicating an error in the security processing
    otherwise. The information from the unsecured frame shall be
    recorded in the PAN descriptor even if the status from the
    unsecuring process indicated an error.

I did not check yet whether the later spec 802.15.4-2011 changed this 
behavior or whether 802.15.4e-2012 did, but if I remember correctly the 
802.15.4e spec did not modify any of this, so the remaining check would 
be 2006 --> 2011.

Best regards, Rene

On 12/8/2014 7:03 PM, [email-masked] wrote:
>
> Hi Rene,
>
> I would like to double check the meaning of “exempt status”.  I 
> thought the “exempt status” is maintained by higher layer and is 
> different from the “Exempt” flag of 802.15.4-2011 DeviceDescriptor of 
> Security-related PIB attributes.
>
> I am asking this because, while the “Exempt” flag of 802.15.4-2011 
> DeviceDescriptor of Security-related PIB attributes allows unsecured 
> frames to be passed to higher layer, the flag solely does not help for 
> joining node’s higher layer to process authenticated-only secured beacons.
>
> Yoshihiro Ohba
>
> *From:*6tisch-security [mailto:[email-masked]] *On 
> Behalf Of *Rene Struik
> *Sent:* Tuesday, December 9, 2014 8:09 AM
> *Cc:* [email-masked]
> *Subject:* [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST 
> call) Re: (now with agenda) Re: invite for 6tisch security call Tue 
> December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan
>
> Dear colleagues:
>
> 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.
>
> 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.
>
> 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.
>
> 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
>
>         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.
>
>
>         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
>
>         Not at your computer? Click the link to join this meeting from
>         your iPhone®, iPad®, Android® or Windows Phone® device via the
>         GoToMeeting app.
>
>
>
>
>         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...}
>
>
>             Subir Das<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>             [email-masked]  <mailto:[email-masked]>
>
>         email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik
>
>     email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik
>
> email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik

---

From: Rene Struik <[email-masked]>
Date: Mon, 08 Dec 2014 21:00:35 -0500

Dear colleagues:

Please find below the (corrected) minutes of the 6TiSCH Security conf 
call as of December 2, 2014, 9am EST. {Correction re active scan in italics}

1. Attendance:

2. Agenda

/RS also discussed incoming processing of secured beacon frames (Slide 
20), where a device without proper keying material can still extract 
visible portions of a secured beacon frame, even though it cannot rely 
on this. This feature is already supported in the 802.15.4-2006 spec as 
part of the "active scan" specification. {NOTE added (after the call): 
still to be checked whether this feature was not modified in the 
802.15.4-2011 spec or with 802.15.4e-2012}./

Best regards, Rene

---

From: Rene Struik <[email-masked]>
Date: Mon, 08 Dec 2014 21:21:34 -0500

Hi Yoshi:

The passive scan language in the 802.15.4-2011 spec is in Clause 
5.1.2.1.2. I think one should also look at the PAN descriptor and see 
which elements of the enhanced beacon that are in the PAN descriptor 
table are visible to a "newbee" device. Would you like to give this a look?

Best regards, Rene

On 12/8/2014 8:48 PM, Rene Struik wrote:
> Hi Yoshi:
>
> Good point (and I remember we discussed this, while going over Slide 
> 20, but I forgot to include this in the minutes [I will correct this]).
>
> The idea is that if a joining device receives a secured beacon frame, 
> it can still extract the visible portion of the frame, even if it 
> cannot do proper incoming security processing (obviously, it cannot 
> really rely on this data at this point, then).
>
>     If a protected beacon frame is received, i.e., the Security
>     Enabled subfield in the Frame Control field is set to one, the
>     device shall attempt to unsecure the beacon frame using the
>     unsecuring process described in 7.5.8.2.3.
>     The security-related elements of the PAN descriptor corresponding
>     to the beacon (see Table 55) shall be set to the corresponding
>     element of the PAN descriptor shall be set to SUCCESS if the
>     status from the unsecuring process is SUCCESS and set to one of
>     the other status codes indicating an error in the security
>     processing otherwise. The information from the unsecured frame
>     shall be recorded in the PAN descriptor even if the status from
>     the unsecuring process indicated an error.
>
> behavior or whether 802.15.4e-2012 did, but if I remember correctly 
> the 802.15.4e spec did not modify any of this, so the remaining check 
> would be 2006 --> 2011.
>
> Best regards, Rene
>
>
>> frames to be passed to higher layer, the flag solely does not help 
>> for joining node’s higher layer to process authenticated-only secured 
>> beacons.
>>
>> Yoshihiro Ohba
>>
>> 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.
>>
>> SD suggested that an important point in not using default keys is 
>> that all incoming processing with keys will be treated transparently, 
>>         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.
>>
>>
>>         Not at your computer? Click the link to join this meeting
>>         from your iPhone®, iPad®, Android® or Windows Phone® device
>>         via the GoToMeeting app.
>>
>>
>>
>>
>>         should allow people to have their private time in the
>>         12am-6am time window. {Other groups do a much better job at
>>         this...}
>>
>>

---

From: <[email-masked]>
Date: Tue, 9 Dec 2014 04:58:36 +0000

I think all PAN Descriptor fields are either contained in the visible part of Beacon frame or obtained as associated information of the frame.  Some TSCH-related IEs, such as TSCH Synchronization, TSCH Slotframe and Link, TSCH Timeslot, Channel Hopping
Sequence IEs, are contained as Payload IEs, and are not accessible from joining node if they are encrypted.

Of course, if the Beacon frame is authenticated-only and unencrypted, then all information is visible to joining node, but joining node has to process AES-CCM* encoded cleartext information even if key is not available (I am not sure if existing implementation supports this kind of processing).

Yoshihiro Ohba

From: Rene Struik [mailto:[email-masked]]
Sent: Tuesday, December 9, 2014 11:22 AM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ)
Cc: tisch-security
Subject: Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan

Hi Yoshi:

The passive scan language in the 802.15.4-2011 spec is in Clause 5.1.2.1.2. I think one should also look at the PAN descriptor and see which elements of the enhanced beacon that are in the PAN descriptor table are visible to a "newbee" device. Would you like to give this a look?

Best regards, Rene

Good point (and I remember we discussed this, while going over Slide 20, but I forgot to include this in the minutes [I will correct this]).

The idea is that if a joining device receives a secured beacon frame, it can still extract the visible portion of the frame, even if it cannot do proper incoming security processing (obviously, it cannot really rely on this data at this point, then).

With 802.15.4-2006, this is described in Clause 7.5.2.1.2 (Active Channel Scan), of which the excerpt from p. 174 of the spec describes the corresponding behavior:
If a protected beacon frame is received, i.e., the Security Enabled subfield in the Frame Control field is set to one, the device shall attempt to unsecure the beacon frame using the unsecuring process described in 7.5.8.2.3.
The security-related elements of the PAN descriptor corresponding to the beacon (see Table 55) shall be set to the corresponding parameters returned by the unsecuring process. The SecurityFailure element of the PAN descriptor shall be set to SUCCESS if the status from the unsecuring process is SUCCESS and set to one of the other status codes indicating an error in the security processing otherwise. The information from the unsecured frame shall be recorded in the PAN descriptor even if the status from the unsecuring process indicated an error.
I did not check yet whether the later spec 802.15.4-2011 changed this behavior or whether 802.15.4e-2012 did, but if I remember correctly the 802.15.4e spec did not modify any of this, so the remaining check would be 2006 --> 2011.

Best regards, Rene

On 12/8/2014 7:03 PM, [email-masked]<mailto:[email-masked]> wrote:
Hi Rene,

Yoshihiro Ohba

From: 6tisch-security [mailto:[email-masked]] On Behalf Of Rene Struik
Sent: Tuesday, December 9, 2014 8:09 AM
Cc: [email-masked]<mailto:[email-masked]>
Subject: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris = 11pm Japan

Dear colleagues:

1. Attendance:

2. Agenda

Best regards, Rene

0) Agenda bashing

1) Join protocol details
a) desired properties
b) realizable properties
2) Next steps:

Best regards, Rene

Best regards, Rene
==

Dial +1 (647) 497-9351
Access Code: 594-299-061

GoToMeeting®

Not at your computer? Click the link to join this meeting from your iPhone®, iPad®, Android® or Windows Phone® device via the GoToMeeting app.

or

--

--

--

--

--

---

From: Kris Pister <[email-masked]>
Date: Tue, 09 Dec 2014 09:46:09 -0800

So the idea is that misinterpreting a frame from a completely different 
type of network
is not a problem?
I guess that it will just cause the joining node to try to initiate an 
authentication exchange
that won't go anywhere.  Maybe that's ok, but it leaves us open to 
*unintentional* denial
of service attacks.

I'd feel a little better about it if the proponents of "no fake keys" 
would acknowledge
the concerns of the "well-known key" gang.  We've said repeatedly that 
"well known"
is not about security, it's about avoiding unintentional 
misinterpretation of foreign packets.
We get that a well known key provides zero security.
Do you get that the aether is filled with packets that don't abide by 
6lowpan dispatch bytes,
or even IEEE MAC header conventions?

ksjp

On 12/8/2014 6:00 PM, Rene Struik wrote:
> PD summarized that using unsecured frames, rather than "fake" security 
> with "default keys", should be adopted, which was consensus on the call.

---

From: Jonathan Simon <[email-masked]>
Date: Tue, 9 Dec 2014 10:09:30 -0800

I am kind of baffled at the direction this group seems to have taken.

We all agreed that touchless operation is the goal.  So beacons need to be authenticated with a well-known key (yes, I know this does nothing for security - this provides for protocol separation only).  Mixing of unauthenticated and authenticated frames is a non-issue, since everything is authenticated.   I don’t understand the value of saving a beacon key configured at a higher layer, as a) the network has to send the beacons unencrypted for touchless operation, b) you don’t get any security benefit if a device is going to accept the beacon contents regardless, and c) a device has to be able to fall back to the well-known key any time, since the saved key may be stale (node moved, node slept while key was changing, node is allowed in multiple overlapping networks using different keys, etc.)

This is all distraction from the real problem we have to solve:  how do we agree on session keys that allow a device and a PCE to exchange MAC configuration messages in a minimal number of frames, and do so in a touchless way.  Everything else is either irrelevant, or application policy.

--
Jonathan Simon, Ph. D
[email-masked]

On Dec 9, 2014, at 9:46 AM, Kris Pister <[email-masked]> wrote:

> So the idea is that misinterpreting a frame from a completely different type of network
> is not a problem?
> I guess that it will just cause the joining node to try to initiate an authentication exchange
> that won't go anywhere.  Maybe that's ok, but it leaves us open to *unintentional* denial
> of service attacks.
> 
> I'd feel a little better about it if the proponents of "no fake keys" would acknowledge
> the concerns of the "well-known key" gang.  We've said repeatedly that "well known"
> is not about security, it's about avoiding unintentional misinterpretation of foreign packets.
> Do you get that the aether is filled with packets that don't abide by 6lowpan dispatch bytes,
>> PD summarized that using unsecured frames, rather than "fake" security with "default keys", should be adopted, which was consensus on the call.
> 
> http://cp.mcafee.com/d/2DRPos81NJ5x5V5wsyYedTdEK3CkPqbwVBYSyUed7aar9EVdKfffecnKr4qilH057Ox-NVsSva7X7BPr8VZAsYM_R-73Akn7KLsKCONvAm4NPXzfbnjIyCGztzBgY-F6lK1FJ4SyrLOb2rPUV5xcQsCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SVssyr1vF6y0QJKjBiNcLjXdNBcIqnjh0qa366y2xYy9epEwJmcvJelo6yAQg2Vx18Qg6yxmk6V_gQgltd409rYQg1TSd42o1Cy1eWb01Cy0QsWGq81Eo19EwJFVVEFd40bZ8Qg6yy5j1EwciCjd46AvwxFEFd40bZ8QgiwpBfPh0Xm9EwsDaBypEwFZCUOCmd45Jffd409rYQg1TSZkxYjh0C0pEwjKyM0pEwd7eGCy0q60iq83zh0VGFEw2MM2jh0sq86lBjh05JzaxEwed42aaOFEw0zlJwrjhvdBO7_

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Dec 2014 19:31:47 +0000

I agree Jonathan

I tried to propose text that is independent on that decision this morning but I strongly favor using a key to differentiate networks if at all possible.

The argument of faster rejoin I have a hard time accepting since I see the value of a join link that is not taken from the production schedule and uses a different prefix. So the rejoin works if you still have a key and ate still in sync, and in that case you can restart from the RS/RA in my flow.

Another aspect of the join link would be a slower hoping schedule to accommodate rejoin of a node with limited RTC capabilities after a day's sleep. This is something of deep interest in NAN applications and would make 6TiSCH a strong contender.

Can that be accommodated?

Pascal

Le 9 déc. 2014 à 12:09, Jonathan Simon <[email-masked]<mailto:[email-masked]>> a écrit :

--
Jonathan Simon, Ph. D
[email-masked]<mailto:[email-masked]>

On Dec 9, 2014, at 9:46 AM, Kris Pister <[email-masked]<mailto:[email-masked]>> wrote:

ksjp

---

From: Rene Struik <[email-masked]>
Date: Tue, 09 Dec 2014 18:19:37 -0500

Hi Yoshi:

According to Section 5.2.4.1, Payload Information Elements do not seem 
to be encrypted (cf. below). Curiously, though, this seems to be 
inconsistent with the incoming and outgoing security processing in 
802.15.4-2011 [see, e.g., Table 53 hereof], which procedure 
802.15.4-2012 did not redefine).

Best regards, Rene

[excerpt of 802.15.4e-2012, Clause 5.2.4.1]
IEs may be either part of the MAC Header or MAC payload. Header IEs are 
used by the MAC to process the
frame immediately, i.e., they cover security, addressing, etc., and are 
part of the MAC Header. Payload IEs
are destined for another layer or SAP and are part of the MAC payload 
(but like command IDs they may not
be encrypted). If IEs are contained in a frame, they always occur before 
other unstructured MAC payload
elements.

On 12/8/2014 11:58 PM, [email-masked] wrote:
>
> I think all PAN Descriptor fields are either contained in the visible 
> part of Beacon frame or obtained as associated information of the 
> frame.  Some TSCH-related IEs, such as TSCH Synchronization, TSCH 
> Slotframe and Link, TSCH Timeslot, Channel Hopping
>
> Of course, if the Beacon frame is authenticated-only and unencrypted, 
> then all information is visible to joining node, but joining node has 
> to process AES-CCM* encoded cleartext information even if key is not 
> available (I am not sure if existing implementation supports this kind 
> of processing).
>
> Yoshihiro Ohba
>
> *From:*Rene Struik [mailto:[email-masked]]
> *Sent:* Tuesday, December 9, 2014 11:22 AM
> *To:* ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ)
> *Cc:* tisch-security
> *Subject:* Re: [6tisch-security] (minutes of Tue Dec 2, 2014, 9am EST 
>     Good point (and I remember we discussed this, while going over
>     Slide 20, but I forgot to include this in the minutes [I will
>     correct this]).
>
>     The idea is that if a joining device receives a secured beacon
>     frame, it can still extract the visible portion of the frame, even
>     if it cannot do proper incoming security processing (obviously, it
>     cannot really rely on this data at this point, then).
>
>     Channel Scan), of which the excerpt from p. 174 of the spec
>     describes the corresponding behavior:
>
>         The security-related elements of the PAN descriptor
>         corresponding to the beacon (see Table 55) shall be set to the
>         corresponding parameters returned by the unsecuring process.
>         The SecurityFailure element of the PAN descriptor shall be set
>         to SUCCESS if the status from the unsecuring process is
>         SUCCESS and set to one of the other status codes indicating an
>         error in the security processing otherwise. The information
>         from the unsecured frame shall be recorded in the PAN
>         descriptor even if the status from the unsecuring process
>         indicated an error.
>
>     I did not check yet whether the later spec 802.15.4-2011 changed
>     this behavior or whether 802.15.4e-2012 did, but if I remember
>     correctly the 802.15.4e spec did not modify any of this, so the
>     remaining check would be 2006 --> 2011.
>
>     Best regards, Rene
>
>
>     On 12/8/2014 7:03 PM, [email-masked]
>     <mailto:[email-masked]> wrote:
>
>         Hi Rene,
>
>         I would like to double check the meaning of “exempt status”. 
>         I thought the “exempt status” is maintained by higher layer
>         and is different from the “Exempt” flag of 802.15.4-2011
>         DeviceDescriptor of Security-related PIB attributes.
>
>         I am asking this because, while the “Exempt” flag of
>         802.15.4-2011 DeviceDescriptor of Security-related PIB
>         attributes allows unsecured frames to be passed to higher
>         layer, the flag solely does not help for joining node’s higher
>         layer to process authenticated-only secured beacons.
>
>         Yoshihiro Ohba
>
>         *From:*6tisch-security
>         [mailto:[email-masked]] *On Behalf Of *Rene
>         Struik
>         *Cc:* [email-masked] <mailto:[email-masked]>
>         *Subject:* [6tisch-security] (minutes of Tue Dec 2, 2014, 9am
>         EST call) Re: (now with agenda) Re: invite for 6tisch security
>         call Tue December 2, 2014, 9am EST = 6am PST = 3pm Paris =
>         11pm Japan
>
>         Dear colleagues:
>
>         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
>         additional feature, this  would be a plus. After asking, there
>         was no further discussion on properties listed.
>
>         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.
>
>         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.
>
>         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
>
>                 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.
>
>
>                 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
>
>                 Not at your computer? Click the link to join this
>                 meeting from your iPhone®, iPad®, Android® or Windows
>                 Phone® device via the GoToMeeting app.
>
>
>
>
>                 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...}
>
>

---

From: Pat Kinney <[email-masked]>
Date: Tue, 9 Dec 2014 17:28:14 -0600

The Payload IEs are indeed encrypted if the frame is encrypted, that was part of the intent of having two types of IEs.

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, TG chair
ISA100.11a WG chair
O: +1.847.960.3715
[email-masked] <mailto:[email-masked]>

On 9, Dec2014, at 17:19, Rene Struik <[email-masked]> wrote:

Hi Yoshi:

According to Section 5.2.4.1, Payload Information Elements do not seem to be encrypted (cf. below). Curiously, though, this seems to be inconsistent with the incoming and outgoing security processing in 802.15.4-2011 [see, e.g., Table 53 hereof], which procedure 802.15.4-2012 did not redefine).

Best regards, Rene

[excerpt of 802.15.4e-2012, Clause 5.2.4.1]
IEs may be either part of the MAC Header or MAC payload. Header IEs are used by the MAC to process the
frame immediately, i.e., they cover security, addressing, etc., and are part of the MAC Header. Payload IEs
are destined for another layer or SAP and are part of the MAC payload (but like command IDs they may not
be encrypted). If IEs are contained in a frame, they always occur before other unstructured MAC payload
elements.

On 12/8/2014 11:58 PM, [email-masked] <mailto:[email-masked]> wrote:
> From: Rene Struik [mailto:[email-masked] <mailto:[email-masked]>] 
> On 12/8/2014 7:03 PM, [email-masked] <mailto:[email-masked]> wrote:
> Hi Rene,
>  
> From: 6tisch-security [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Rene Struik
> Cc: [email-masked] <mailto:[email-masked]>
> {recording: https://drive.google.com/file/d/0B2a6Ilxu1XfCUmU4RWFfb1FJSHc/view?usp=sharing <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 <https://drive.google.com/file/d/0B2a6Ilxu1XfCZnZzdlQ5V1hkNEk/view?usp=sharing>}
> 
> 1. Attendance:
> https://global.gotomeeting.com/join/594299061 <https://global.gotomeeting.com/join/594299061>
>  
> Subir Das <[email-masked]> <mailto:[email-masked]> wrote:
> https://www.ietf.org/mailman/listinfo/6tisch-security <https://www.ietf.org/mailman/listinfo/6tisch-security>
> 
> 
> 
> 
> -- 
> email: [email-masked] <mailto:[email-masked]> | Skype: rstruik
> email: [email-masked] <mailto:[email-masked]> | Skype: rstruik
> email: [email-masked] <mailto:[email-masked]> | Skype: rstruik
> email: [email-masked] <mailto:[email-masked]> | Skype: rstruik
> email: [email-masked] <mailto:[email-masked]> | Skype: rstruik

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

---

From: Rene Struik <[email-masked]>
Date: Tue, 09 Dec 2014 18:31:13 -0500

The current language is not entirely clear; hence, my note.

Rene

On 12/9/2014 6:28 PM, Pat Kinney wrote:
> The Payload IEs are indeed encrypted if the frame is encrypted, that 
> was part of the intent of having two types of IEs.
>
> Pat
>
> Pat Kinney
> */Kinney Consulting LLC/*
> [email-masked] 
> <mailto:[email-masked]>
>
>
>
>
>
>
> On 9, Dec2014, at 17:19, Rene Struik <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Hi Yoshi:
>
>> available (I am not sure if existing implementation supports this 
>> kind of processing).
>>
>> Yoshihiro Ohba
>>
>>     frame, it can still extract the visible portion of the frame,
>>     even if it cannot do proper incoming security processing
>>     (obviously, it cannot really rely on this data at this point, then).
>>
>>         Enabled subfield in the Frame Control field is set to one,
>>         the device shall attempt to unsecure the beacon frame using
>>         the unsecuring process described in 7.5.8.2.3.
>>         corresponding to the beacon (see Table 55) shall be set to
>>         the corresponding parameters returned by the unsecuring
>>         process. The SecurityFailure element of the PAN descriptor
>>         shall be set to SUCCESS if the status from the unsecuring
>>         process is SUCCESS and set to one of the other status codes
>>         indicating an error in the security processing otherwise. The
>>         information from the unsecured frame shall be recorded in the
>>         PAN descriptor even if the status from the unsecuring process
>>         indicated an error.
>>
>>         layer, the flag solely does not help for joining node’s
>>         higher layer to process authenticated-only secured beacons.
>>
>>         Yoshihiro Ohba
>>
>>         *From:*6tisch-security
>>         EST call) Re: (now with agenda) Re: invite for 6tisch
>>         security call Tue December 2, 2014, 9am EST = 6am PST = 3pm
>>         Paris = 11pm Japan
>>
>>         Dear colleagues:
>>
>>         (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.
>>
>>         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
>>         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.
>>
>>         discussion of non-MAC aspects (Slides 23-25) and given that
>>         MR had to drop off the call, it was decided to revisit those
>>         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
>>                 I have set up a conf call for Tuesday December 2,
>>                 2014 at a time that tries and accommodate people in
>>                 This should allow people to have their private time
>>                 in the 12am-6am time window. {Other groups do a much
>>                 better job at this...}
>>
>>

---

From: Pat Kinney <[email-masked]>
Date: Tue, 9 Dec 2014 17:50:02 -0600

To help clarify the procedure, Tero Kivinen is drawing state diagrams for the 802.15.4 revision

Pat Kinney
Kinney Consulting LLC

On 9, Dec2014, at 17:31, Rene Struik <[email-masked]> wrote:

Rene

On 12/9/2014 6:28 PM, Pat Kinney wrote:
> On 9, Dec2014, at 17:19, Rene Struik <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Yoshi:
>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Dec 2014 14:52:54 +0200

[email-masked] writes:
> DeviceDescriptor of Security-related PIB attributes allows unsecured frames to
> be passed to higher layer, the flag solely does not help for joining node’s

Beacons are special cases, and during the scanning process security
processing failures for them are ignored and all data from the beacon
is stored regardless whether security processing was successfull or
not.

In P802.15.4-REVc-DF2 the section "6.3.1.2 Active and passive scan"
has text which says:

	If a protected Beacon frame is received, i.e., the Security
	Enabled field is set to one, the device shall attempt to
	unsecure the Beacon frame using the unsecuring process
	described in 9.2.3.

	The security-related elements of the PAN descriptor
	corresponding to the beacon, as defined in Table 68, shall be
	set to the corresponding parameters returned by the unsecuring
	process. The SecurityStatus element of the PAN descriptor
	shall be set to SUCCESS if the Status from the unsecuring
	process is SUCCESS and set to one of the other Status codes
	indicating an error in the security processing otherwise.

	The information from the frame to be unsecured shall be
	recorded in the PAN descriptor even if the Status from the
	unsecuring process indicated an error.

Same text was also presented in the -2011 version in section
5.1.2.1.2.

Only difference is that in -DF2 we changed the "from the unsecured
frame" to "from the frame to be unsecured" in the last paragraph, so
it will match the terms used in the security section.

So beacons during the active or passive scan are processed regradless
their security level and information from there are stored to the PAN
Descriptor table regardless whether the bacon was secured or not, and
whether we actually managed to verify the security of the beacon frame
or not.

So for beacons you do not need exempt flag, it is needed only for
other frame types where you still want to enforce the security on the
MAC layer. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Dec 2014 15:07:59 +0200

Kris Pister writes:
> So the idea is that misinterpreting a frame from a completely
> different type of network is not a problem? I guess that it will
> just cause the joining node to try to initiate an authentication
> exchange that won't go anywhere. Maybe that's ok, but it leaves us
> open to *unintentional* denial of service attacks.

I think it is much better to leave joining process open for attacks,
than leave the whole production network completely open to all kind of
attacks. 

> I'd feel a little better about it if the proponents of "no fake
> keys" would acknowledge the concerns of the "well-known key" gang.
> We've said repeatedly that "well known" is not about security, it's
> about avoiding unintentional misinterpretation of foreign packets.
> We get that a well known key provides zero security. Do you get that
> the aether is filled with packets that don't abide by 6lowpan
> dispatch bytes, or even IEEE MAC header conventions?

The problem with using well known keys with beacons is that then
beacons do not have any security at all for anybody. I.e. attacker who
is not part of the network can easily fake beacons and mess up the
whole network for everybody. If beacons use real network key (not well
known, but group key distributed to valid members of the network),
then network users can actually verify that beacons are coming from
the network members, not from attackers. The joining nodes cannot
verify this yet, as they do not have the key, but I think it is much
more important to protect the production network, than to try to
protect joining nodes for accidents.

The TSCH beacons have several IEs already, and if you are really
concerned about mixing random radio interference with real beacon, it
might be better to just add one more IE that has network magic cookie
or something that joining nodes can verify...

If you could create completely separate another joining network with
their own set of beacons and schedules and most likely radio channels,
then joining network having well-known keys would work, but I do not
think that is what is done here. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Dec 2014 15:18:05 +0200

Jonathan Simon writes:
> We all agreed that touchless operation is the goal.  So beacons need to be
> authenticated with a well-known key (yes, I know this does nothing for
> security - this provides for protocol separation only).  Mixing of
> unauthenticated and authenticated frames is a non-issue, since everything is
> authenticated.   I don’t understand the value of saving a beacon key
> configured at a higher layer, as a) the network has to send the beacons
> unencrypted for touchless operation,

True.

> b) you don’t get any security benefit if a device is going to accept
> the beacon contents regardless, and

False. Joining node needs to ccept beacon contents regardless. Nodes
already part of the network DO want to verify that the ASN and other
parameters inside the beacon are accepted only from valid sources.
They can verify that if the beacon content is authenticated (not
encrypted) using the key which is not well-known.

> c) a device has to be able to fall back to the well-known key any
> time, since the saved key may be stale (node moved, node slept while
> key was changing, node is allowed in multiple overlapping networks
> using different keys, etc.)

In which case it is again joining node, and start joining process from
the beginning. Note, that even then node needs to remember last ASN it
has uesd for each key it has, and it needs to make sure ASN never goes
backwards even if he rejoins the networks. Most likely it will want to
remove all old keys before evn starting to rejoin. Also the joining
protocol needs to be so that it make sure it cannot be replayed in
such way that even if attacker do not know the contents of the frames,
the exchange cannot result in same keys to be group keys to be
transmitted to the joining peer.

For example protocol that would send group keys to the peer by
encrypting them with the public key of the peer would be unsafe, as
then attacker could trick the node to rejoin attackers network and
replay the joining frames from the real network to the node, and then
node would have the real group key (after decrypting the key object
sent to it). Attacker could do all this even when it does not know the
contents of the objetcs.

The attacker could have also stored the old beacons from the real
coordinators and replay them to the node, so node would think he is
part of the real network, and would start trasnmitting using the old
ASN. Immediately when it does this the attacker now have two packets
encrypted with same key (which attacker does not know) and with same
ASN + source address == same CCM nonce, and then it would be able to
get information out from the packets. 

-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Dec 2014 15:22:50 +0200

> The current language is not entirely clear; hence, my note.

This will be fixed during the maintenance work. We had several
comments about this during the balloting and 15-14-0704-02 already
propses fix for that (see page 5, CID 1026, 1145, 1146, 1148, 1147 for
more information). Also the outbound statemachine step f and inbound
statemachine step i have been modified to match (those state machines
are also in the same document).

https://mentor.ieee.org/802.15/dcn/14/15-14-0704-02-0mag-lb97-resolutions-kivinen.pdf

-- 
[email-masked]

---

From: Jonathan Simon <[email-masked]>
Date: Thu, 11 Dec 2014 08:03:31 -0800

Tero - I think my point got missed.  I'm not trying to say that if you
could use an instance-specific key to secure beacons that it would have no
value. Clearly that is preferable. But I think it costs us touchless
behavior, at least in some cases.

Imagine a sleepy node. It first joins with the well-known key.  It gets
assigned a new Beacon key #1 as you describe. It goes to sleep, and
meanwhile, the Beacon key is changed to key #2.  The node wakes up and
hears the Beacon.  It tries key #1 and fails, and tries the WKK and fails.
The proposal has been that the node should accept the Beacon contents, but
now we don't even know if it is a Beacon, or some other protocol that looks
like a Beacon.

A touchless node in general doesn't know how it will be deployed, so once
you start changing Beacon keys, you may wind up worse off than if you use
always a well known key. If your key rotation schedule cycled through a
list of keys, you could restrict the node to the configured key for a
period of time before falling back, but then we wind up a) describing
policy that is best left to the vendor, and b) ensuring that the node may
remain unavailable until the network returned to the configured key.  I see
a lot of complexity, and little upside.

Jonathan

-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(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.

-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(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: Kris Pister <[email-masked]>
Date: Fri, 12 Dec 2014 02:36:01 -0800

> than leave the whole production network completely open to all kind of

Tero - you and I are clearly talking about different things.  If using a 
well-known key
for the MIC on a beacon opened the production network to any attacks,
then there is no way that WiHART would have passed repeated security reviews
over a period of many years.

 > beacons do not have any security at all for anybody.

I'm pretty sure that everyone on this list agrees that a well-known key 
provides
no security.  Many would disagree that it is a problem.

 > attacker [...] can easily fake beacons and mess up the whole network 
for everybody

An attacker can easily fake beacons: yes.
and mess up the whole network: no.

Can you explain why you think that it will mess up the whole network for 
everybody?

ksjp

---

From: Kris Pister <[email-masked]>
Date: Fri, 12 Dec 2014 02:50:35 -0800

Tero - again I feel like we have a different understanding of what is 
going on.
Nodes in the network will keep track of ASN.  They will not in general 
be listening
to beacons, because beacons are not, and can not be, protected with 
symmetric
means.

ksjp

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 12 Dec 2014 14:57:44 +0200

> over a period of many years.

I have no idea how WiHART is doing things, but on the other hand most
of the security reviews are not really that through.

Using well-known key for beacons allows attackers to fake beacons,
which will allow them to modify the ASN. AES-CCM security needs ASN to
be global for the network, and if it can be faked to be different in
different parts of the network there is problems.

Also there used to be text in the 15.4e which used short addresses
instead of extended addresses for the nonce generation (we did get rid
of that in the maintenance), and if that is used that allows another
set of security vulnerabilitys. Someone claimed me that, the
requirement for short addresses to be used in nonce generation came
from somewhere outside, and I have assumed WiHART might have been one
of those sources, but as I have no idea what WiHART does and how it
works (I have never seen any of its specifications), I do not know if
they use it or not.

So I have no idea whether WiHART is secure or not, and having it
passing security reviews does not mean anything. It means those
reviews didn't find any obvious holes, it does not mean there isn't
any security holes there.

Seeing how many other protocols have gone through repeated security
reviews, and still have all kind of problems found later, does just
point out how little you can trust to security reviews.

There are ways to try to limit the damage caused by someone able to
fake beacons. For example each device can always remember the last ASN
they have seen / used and store that to stable storage every time they
go to sleep. That will make it sure the device will not get tricked to
smaller ASN than before.

Another kind of attack for network is to advance the ASN forward a
lot. I.e. if you have attacker in the network sending out beacons
having much bigger ASN than the real ASN is, that will cause all nodes
trusting that beacon to jump forward. Now even when the attacker goes
away the network will NOT recover from that. Those nodes things the
ASN is high and will send packets out which others cannot decrypt
because ASN is wrong. Those nodes having wrong ASN cannot decrypt /
verify frames sent by the real noeds, as they have wrong ASN.

Even when those frames realize they have been tricked to use wrong
ASN, they cannot go back down to real ASN, as that would mean that
they would violate the nonce uniqueness later when the real ASN
reaches the value of the wrong ASN, and then if they would send
packets out with same ASN twice, that would break the security.

Again there is ways for devices to be security against that, i.e. they
can keep their own count of ASN, and make sure it will never jump
forward or backwards at all, i.e. if they have accurate enough clock
they can calculate what value ASN should be for any given moment even
if they have been sleeping, thus they will make sure they will not
trust beacons with wrong ASN. This again sets up another requirement
for devices which is not needed if ASN from the beacon can be trusted
because it is authenticated.

> I'm pretty sure that everyone on this list agrees that a well-known
> key provides no security. Many would disagree that it is a problem.

Good.

I also claim that if the beacons in the network is protected with
well-known key it will lower the security a lot. This is because that
will mean that the beacons are not protected.

When beacons are not proteced this will cause problems. 

> Can you explain why you think that it will mess up the whole network for 

I gave just few examples with ASN above. With ASN it is possible to
break the security of the network.

Another thing attackers can do they can give out different schedule
for the TSCH causing nodes to talk over each other, or be out of sync,
thus they cannot hear each other as they are not receiving /
transmitting right time on right channel. This allows all kind of
denial of service attacks.

Can you explain how do you plan to protect against faking ASNs if the
beacons are protected with key that attacker knows (i.e. well-known
key)? If it requires devices to keep accurate enough clocks and verify
that ASN has right value, then that requirement needs to be mentioned
somewhere. 
-- 
[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 12 Dec 2014 13:05:13 +0000

Hello Tero:

The one thing I disagree upon is your assumption the actual production information is present in the join beacon. Your derive your model from that assumption and that is certainly a source of disagreement.

The key is that TSCH allows us to have a chunk of cells for join that is distinct from the chunks of cells used in production, e.g. for multicast or minimal RPL. If we leak production information then an attacker can much easier perform very discrete PHY attacks, and/or DoS production time slots.

The way I see it, since the join information is (as good as)  in the clear, it should leak as little information as possible about the real network operation. No global prefix, no actual data schedule. It should just give the minimal schedule information to allow the JN to talk to the JA and through that get the keys if it can, and that could be bandwidth that varies over time, a lot at the network bring up and a lot less in run time. 

After the keys are obtained, whether the node joins for the first time or rejoins later, it can use that crypto material to obtain or revalidate the real production information, both at MAC layer and IP layer. Typically, the node that obtained key material will send a protected multicast RS over the join schedule, and a router will answer with a unicast RA. This is the appropriate time to provide production schedule information, as well as the real production prefix, all encrypted. From there, the node can use 6LoWPAN ND and RPL to participate to the production network.

In that scenario, your contradiction to point B does not apply.

Makes sense?

Pascal

> -----Original Message-----
> From: 6tisch-security [mailto:[email-masked]] On Behalf Of
> Tero Kivinen
> Sent: jeudi 11 décembre 2014 07:18
> To: Jonathan Simon
> Cc: tisch-security
> Subject: Re: [6tisch-security] (w/ slight correction) Fwd: (minutes of Tue Dec 2,
> 2014, 9am EST call) Re: (now with agenda) Re: invite for 6tisch security call Tue
> > We all agreed that touchless operation is the goal.  So beacons need
> > to be authenticated with a well-known key (yes, I know this does
> > nothing for security - this provides for protocol separation only).
> > Mixing of unauthenticated and authenticated frames is a non-issue, since
> everything is
> > configured at a higher layer, as a) the network has to send the
> > beacons unencrypted for touchless operation,
> 
> True.
> 
> False. Joining node needs to ccept beacon contents regardless. Nodes already
> part of the network DO want to verify that the ASN and other parameters inside
> the beacon are accepted only from valid sources.
> In which case it is again joining node, and start joining process from the
> beginning. Note, that even then node needs to remember last ASN it has uesd
> for each key it has, and it needs to make sure ASN never goes backwards even if
> he rejoins the networks. Most likely it will want to remove all old keys before
> evn starting to rejoin. Also the joining protocol needs to be so that it make sure
> it cannot be replayed in such way that even if attacker do not know the contents
> of the frames, the exchange cannot result in same keys to be group keys to be
> For example protocol that would send group keys to the peer by encrypting
> them with the public key of the peer would be unsafe, as then attacker could
> trick the node to rejoin attackers network and replay the joining frames from the
> real network to the node, and then node would have the real group key (after
> decrypting the key object sent to it). Attacker could do all this even when it does
> not know the contents of the objetcs.
> 
> The attacker could have also stored the old beacons from the real coordinators
> and replay them to the node, so node would think he is part of the real network,
> and would start trasnmitting using the old ASN. Immediately when it does this
> the attacker now have two packets encrypted with same key (which attacker
> does not know) and with same ASN + source address == same CCM nonce, and
> then it would be able to get information out from the packets.
> 
> --
> [email-masked]
>

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 12 Dec 2014 15:11:50 +0200

Kris Pister writes:
> Tero - again I feel like we have a different understanding of what
> is going on. Nodes in the network will keep track of ASN. They will
> not in general be listening to beacons, because beacons are not, and
> can not be, protected with symmetric means.

There is way to authenticate that the sender of the beacon is part of
the network, and because of that there can be somewhat trusted what it
says.

When I have been reading the 802.15.4 I have not understood that TSCH
do require accurate clock to keep the ASN up to date even over
sleeping for long periods time and that only new joining devices care
about ASN sent in the beacon.

If all TSCH nodes do require accurate clock, then that will solve the
ASN problem, but I have understood that there are other parameters in
the beacon too which affect the network.

As far as I know those parameters can also be changed during the
runtime of the network, or is that also some of those false
assumptions I have made by just reading the 802.15.4 and not vendors
specifications (i.e. of course if vendors make their products so that
they will ignore beacons completely after the initial join to the
network, then protecting beacons have no value).
-- 
[email-masked]

---

From: Kris Pister <[email-masked]>
Date: Fri, 12 Dec 2014 08:54:14 -0800

> If it requires devices to keep accurate enough clocks and verify
somewhere.

Tero - indeed, that is the key piece of information that differs in our 
understanding.
Now I understand your concern.  You are absolutely correct that if nodes 
*in* the
network use beacons to get the ASN, then the beacons must be protected.
That is not how *existing* TSCH networks work - maybe it should be in 
the future.

Looking through the 6TiSCH documents, I can see that it is not at all 
clear that
in a secure network the use of beacons for synchronization is not 
allowed.  Indeed,
in at least one document it says
   "[...]  take into account whether EBs are used as the only mechanism to
    synchronize devices, or whether a Keep-Alive (KA) mechanism is also 
used."

So it's not surprising that you came to the conclusion that we need 
secure beacons.
I still have concerns about going that way, but it's certainly a 
reasonable assumption
for you to have made.

ksjp

On 12/12/2014 4:57 AM, Tero Kivinen wrote:
> If it requires devices to keep accurate enough clocks and verify

---

From: Kris Pister <[email-masked]>
Date: Fri, 12 Dec 2014 09:18:02 -0800

> the network, and because of that there can be somewhat trusted what 
it says.
Agree.

If I understand correctly, your point is that
1) we should authenticate EBs with the network key, thereby enabling nodes
already in the network to trust EBs for
  a) synchronization
  b) DIO and other "piggybacks" (not sure if you are suggesting this, or 
if its a good idea,
but we've discussed the possibility and its in the architecture draft)

2) Joining nodes which hear an EB will not be able to authenticate it, but
  a) authentication would not be secure for a joining node in any case 
(as we all
exhaustively agree), and
  b) as Rene pointed out in a private email, there is probably enough 
structure in the
enhanced beacon packet that it is extremely unlikely that random packets 
sent by
other networks will be misinterpreted as EBs by our network, and the 
consequences
of that misinterpretation are not fatal in any case.

Regarding 2b, I think that Rene is probably right.  The EB for Minimal MUST
* be a beacon
* contain a sync IE, with 2 header bytes that must be exactly 0x1a06
* contain a Timeslot IE, with 2 header bytes that must be 0x1c01
* contain a channel hopping IE, header bytes 0x1d01
* contain some frame and link IEs with more specific byte values

ksjp

---

From: Jonathan Simon <[email-masked]>
Date: Fri, 12 Dec 2014 10:16:05 -0800

I see the disconnect now too.  We’re talking about 2 different beacons.

Enhanced Beacons used to advertise a network: For an unsynchronized node, the content of the beacon tells it what ASN it is, when it can send a frame to the beaconer, and when it can expect a response from the beaconer.  There was a suggestion to add DAG rank to the contents.  This is the frame that I was suggesting be authenticated with a well known key to provide protocol separation.  

Frames used for synchronization in-network:  There are 2 mechanisms for maintaining synchronization. All frames in this context are assumed to be authenticated and or encrypted with a mutable link-layer key assigned by a PCE.
1) node sends a frame to a time parent and gets a time correction in the enhanced acknowledgement.  Contents of the outgoing frame are not used for timekeeping.
2) node gets a frame from a time parent, and uses the time of arrival relative to when expected to trim its clock. The contents of the frame are not used for timekeeping. Frame type isn’t important, so this could be an Enhanced Beacon, but since TSCH is generally described as a non-beaconing PAN, this isn’t the mechanism I’d assume.

**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. 

On Dec 12, 2014, at 8:54 AM, Kris Pister <[email-masked]> wrote:

> > that ASN has right value, then that requirement needs to be mentioned somewhere.
> 
> Tero - indeed, that is the key piece of information that differs in our understanding.
> Now I understand your concern.  You are absolutely correct that if nodes *in* the
> That is not how *existing* TSCH networks work - maybe it should be in the future.
> 
> Looking through the 6TiSCH documents, I can see that it is not at all clear that
> in a secure network the use of beacons for synchronization is not allowed.  Indeed,
>   synchronize devices, or whether a Keep-Alive (KA) mechanism is also used."
> 
> So it's not surprising that you came to the conclusion that we need secure beacons.
> I still have concerns about going that way, but it's certainly a reasonable assumption
> for you to have made.
> 
> ksjp
> 
> http://cp.mcafee.com/d/1jWVIidEI8Lcnpjpd79KVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrsR14wYM_R-j7cKnpLRXBQSkkuvKej73DemKzp5dl55DBgY-F6lK1FJ4SyrLOb2rPUV5xcQsCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04SU-MCr1vF6y0QJKjBiNcLjXdNBcIqnjh0qa366y2xYy9epEwJmcvJelo6yAQg2Vx18Qg6yxmk6V_gQgltd409rYQg1TSd42o1Cy1eWb01Cy0QsWGq81Eo19EwJFVVEFd40bZ8Qg6yy5j1EwciCjd46AvwxFEFd40bZ8QgiwpBfPh0Xm9EwsDaBypEwFZCUOCmd45Jffd409rYQg1TSZkxYjh0C0pEwjKyM0pEwd7eGCy0q60iq83zh0VGFEw2MM2jh0sq86lBjh05JzaxEwed42aaOFEw0zlJwrjhvdFLAR

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Dec 2014 14:31:01 -0500

> sent to it). Attacker could do all this even when it does not know the

I think public-key (chain) authenticated DTLS (probably with PFS) is good
enough to keep the key secure.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Dec 2014 14:49:40 -0500

> Imagine a sleepy node. It first joins with the well-known key.  It gets

I think it's more the sleepy; I think it's in a coma. That's okay.

    > now we don't even know if it is a Beacon, or some other protocol that looks

First, I would claim once enrolled, the node never goes back to unenrolled
state.  If it would do that, then when fake-beacon-that-pretends-to-have-key#2
is heard, that the node would fall off the network.

Second, if the beacon key changed, and do in a time such that not all nodes
got the new key (in advance), then the network is broken, period.  Tero
suggested that we have up to 16 key identifiers for this, to give us lots of
time/space to get new keys out.

How often would we change the beacon key? I think we have to change the
beacon key when the ASN threatens to roll-over. the ASN is...5 bytes.. and I
think we have 100 slottimes per ASN? And slottimes are on the order of 10s, I
think?  So that means we have 1,099,511,627,776,000s between needing to roll the
beacon key due to ASN?  Probably my inputs are wrong here.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Dec 2014 14:54:21 -0500

> the concerns of the "well-known key" gang.  We've said repeatedly that "well

Kris,  this has not been about no fake keys.  The debate has not been about that.
Rather the question has been:  can we actually support well-known keys?

Can the join assistant, for instance, which has to participate in both
networks, actually do that?

I had assumed that the join network would have a completely different
schedule, and it's own set of beacons seperate from the production network.
I was told that this was essentially impossible.  Can you tell us what
WirelessHART does?  Does it have a beacon?

---

From: Jonathan Simon <[email-masked]>
Date: Fri, 12 Dec 2014 11:58:22 -0800

10 ms but yeah it’s 100’s of years.

The point was they key rotation is policy, not mechanism.  We shouldn't have a mechanism that requires a particular policy.  
-- 
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
(510) 400-2936
(510) 489-3799 FAX
[email-masked]

On Dec 12, 2014, at 11:49 AM, Michael Richardson <[email-masked]> wrote:

> http://cp.mcafee.com/d/FZsS71MQ839J5x5Vx5AsYMrKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCTA7623P3_nV6X31EVjWZOWrbb79Tov7nVqWtAklrEIYG7DR8OJMddECQjt-hojuv78I9CzATsSjDdqymokWnPtU03wCHIcfBisEeRNOsGm9BWvpKcFBzrAVkIjbQ-Pspjb5O5mUm-waBYTu00CNObRPobZ8Qg6BJOsGm9BWvpKcFBziWq81sMwAq83hgoMQgkfAh9Pd45GNzZFOH0QkCy0nc896y0QkaOwTfW6y2HFEw1bvCy0e-NEwj0cQg9Tho0cQg6zDljh0d309d45Jffd59Ew1vF6y0QkgGod41ykOpEwQzY4dd59Ew1vF6y2k3cF-q87qNd43AVkIjd45fIT6kONEwJFVVEw1bvCy0e-TGAfyq84M3d42tQm03d41EVRkQg3gM2jh0sq87dld40m60iq83zh0OIGq80JIpkd41NEwhhmld404qJI3qqtPrzfH

---

From: Michael Richardson <[email-masked]>
Date: Fri, 12 Dec 2014 14:59:16 -0500

Jonathan Simon <[email-masked]> wrote:
    > We all agreed that touchless operation is the goal.  So beacons need to
    > be authenticated with a well-known key (yes, I know this does nothing
    > for security - this provides for protocol separation only).  Mixing of

In the model we were discussing, a single set of beacons go out.
They go out in the "clear" --- whether that means unencrypted or with a well
known key, we can leave aside for a moment.

The beacons are authenticated with MIC (authentication header in
IPsec-speak).  This lets the nodes which are already part of the production
network authenticate them, and facilities the sleepy node which comes back to
life, and needs to catch up on the ASN.

Joining nodes see the beacon, can look inside since it is in the "clear",
but can not validate the MIC.  There was a discussion about whether or not
this was possible in the specification.  As such, joining nodes can
synchronize to the timeslot schedule and can find the Aloha part, and do
their work at that point.

    > This is all distraction from the real problem we have to solve:  how do
    > we agree on session keys that allow a device and a PCE to exchange MAC
    > configuration messages in a minimal number of frames, and do so in a
    > touchless way.  Everything else is either irrelevant, or application
    > policy.

I think that this part is easy; but I don't have running code to prove that,
at least not yet.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 12 Dec 2014 23:56:38 +0000

Hello Kris:

Regarding René's point 2b, it is not only about differentiating protocols but also instances IOW different networks like different SSIDs tell you which network, all of them Wi-Fi. 

For that purpose, I buy Tero's point that we could also get a new 'SSID' IE, and should we favor that path, we can see with the interest group whether there is space and time in the 2015 edit for this.

About the PSK operation, we still need to support the case were the network secret key is provisioned and the device starts from there. This is hardly differentiable from the case where that PSK is a weak secret used to differentiate networks as a well-known SSID. So at the end of the day, it is an operational issue, not a protocol one. I see how we could recommend operations, but not how we could bar the use as SSID. Do I miss something?

Also, with classical implementations, the operational schedule comes from the network manager or system manager, so it does not leak anyway. With our distributed operation, some of the operational schedule may be passed in the clear and that troubles me. I think that another operational recommendation should be to keep the join cell separate from the data ones, as LTE does for instance.

Cheers,

Pascal

> Kris Pister
> Sent: vendredi 12 décembre 2014 11:18
> To: Tero Kivinen
> Cc: tisch-security
>  > There is way to authenticate that the sender of the beacon is part of  > the
> network, and because of that there can be somewhat trusted what it says.
> Agree.
> 
>   b) DIO and other "piggybacks" (not sure if you are suggesting this, or if its a
> good idea, but we've discussed the possibility and its in the architecture draft)
> 
>   a) authentication would not be secure for a joining node in any case (as we all
> exhaustively agree), and
>   b) as Rene pointed out in a private email, there is probably enough structure in
> the enhanced beacon packet that it is extremely unlikely that random packets
> sent by other networks will be misinterpreted as EBs by our network, and the
> consequences of that misinterpretation are not fatal in any case.
> 
> >> going on. Nodes in the network will keep track of ASN. They will not
> >> in general be listening to beacons, because beacons are not, and can
> >> not be, protected with symmetric means.

---

From: Kris Pister <[email-masked]>
Date: Fri, 12 Dec 2014 17:55:00 -0800

Good to hear.  Not sure if everyone will agree with you.

If the question is "can we actually support well-known keys?" the answer
is of course yes, the hardware will happily do that.

Wireless HART does roughly what we're talking about.  (The terminology 
in HART
is a little different, so I have converted HART terms to ours.)  The 
Join Assistant
is a part of a production network where there are no beacons.  All nodes are
synchronized using ACKs on packets to time parents.  Sometimes the packets
are just Keepalives, sent for the sole purpose of getting that 
synchronizing ACK.

The Join Assistant gets its schedule from the PCE via an end-to-end 
management-layer
security session with a high-entropy unique key.  All such packets are 
encrypted and
authenticated (4B MIC).
All MAC layer messages in the production network are authenticated with 
a single
network-wide high-entropy key (4B MIC).  All keys are 128 bit.

The Join Assistant has a completely different schedule for sending Enhanced
Beacons.  The Join Assistant calculates a MIC for those beacons using a 
well-known,
fake, bogus, entirely non-secure, zero entropy key.  When it receives a 
response
from a joining node, it checks the MIC to make sure that it was 
calculated with
the W-KFBEN-SZE key.  If the MIC is incorrect, the packet is thrown 
away.  (This
actually happens, and it gets logged, and reported.)  If the MIC is 
correct, and the
*type* of the packet is correct (join request) then
the packet from the joining node is forwarded over the production network to
the JCE, which makes its own determinations.  If a packet comes back 
from the
JCE to the Join Assistant for delivery to the joining node, this packet 
comes over
the production network.  The Join Assistant transfers it to its local 
join network,
puts a MAC MIC on it with the W-KFBEN-SZE key, and sends it down to the 
joining
node.  The ACK that the Join Assistant receives from the Joining Node 
does not
affect its timing at all - the joining node is not a time parent of the 
Join Assistant.
The ACK from the Join Assistant to the joining node is used to keep the 
joining
node synchronized.  The joining node may even send keepalives over the local
joining network until such time as it has left quarantine and gotten the 
production
network MAC key, at which point any packets that it sends will be on the 
production
network (until such time as it may become a Joining Assistant itself).

Between sending Enhanced Beacons and receiving join request responses, the
Joining Assistant may send or receive many packets on the production 
network.

ksjp

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 15 Dec 2014 15:36:07 +0200

> I see the disconnect now too.  We’re talking about 2 different beacons.

Ah, and the other is not beacon at all. I.e. the beacons are only used
for joining and other timekeeping is done on other frames.

This is not very clear in the 6tisch document, and of course the
802.15.4 does not give any details of this level, so it is impossible
to know that from there... 

> Enhanced Beacons used to advertise a network: For an unsynchronized
> node, the content of the beacon tells it what ASN it is, when it can
> send a frame to the beaconer, and when it can expect a response from
> the beaconer. There was a suggestion to add DAG rank to the
> contents. This is the frame that I was suggesting be authenticated
> with a well known key to provide protocol separation.

So enhanced beacons do not have any security critical information in
them, thus they can be allowed to be received without security, right? 

> Frames used for synchronization in-network:  There are 2 mechanisms for
> maintaining synchronization. All frames in this context are assumed to be
> authenticated and or encrypted with a mutable link-layer key assigned by a
> PCE.

The question I have here how do you configure the security PIB of the
802.15.4 to only allow certain information elements from the certain
nodes, and ignore them from others. For data and multipurpose frames I
could see that MAC could simply not process the information elements
at all, and they will be passed to the upper layer in the
MCPS-DATA.indication and then upper layer can do the filtering, but
how do you do that filtering on the Enh-Acks or beacons?

In those frames I think the MAC parses the information elements
directly and acts based on those. So if the frame type and key is
allowed by the inbound security state machine, then those information
elements are processed.

> 1) node sends a frame to a time parent and gets a time correction in the
> enhanced acknowledgement.  Contents of the outgoing frame are not used for
> timekeeping.
> 2) node gets a frame from a time parent, and uses the time of arrival relative
> to when expected to trim its clock. The contents of the frame are not used for
> timekeeping. Frame type isn’t important, so this could be an Enhanced Beacon,
> but since TSCH is generally described as a non-beaconing PAN, this isn’t the
> mechanism I’d assume.

So how do you filter out Time Correlation IEs from frames which come
from other nodes than your time parent? Or how you even filter out
Time Correlation IEs from frames which do not have valid network group
key?

We had short discussion about this (i.e. how we filter based on the
information elements) in the sc-maintenance BRC and I would like to
know how this is supposedly done?

Note that Exempt flag does not help there, as if you make Exempt for
the joining node, and allow it to send joining request, how do you
filter out which information elements in that joining request are
acted upon, and which are ignored.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 15 Dec 2014 15:41:49 +0200

> 10 ms but yeah it’s 100’s of years.

With 10 ms timeslot that would be 348 years, but macTsTimeslotLength
is configurable from 1 µs increments. If someone defines network where
the macTsTimeslotLength would be 1 µs then ASN would wrap around in 12
days. Of course I do not think there is any PHYs that could actually
use such short timeslot length yet, but that does not mean that there
would not be one in the future...

Anyways rekeying the network key every now and then would also be
needed if you ever want to remove any devices from the network, for
eaxmple beacuse you have replaced them with new ones and sold old ones
forward. In that case the old devices could still remember the network
key in their stable memory, thus changing the key would be useful
feature. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 15 Dec 2014 15:51:59 +0200

> is of course yes, the hardware will happily do that.

I think the confusion there was that people were talking about having
two sets of beacons, one with well-known keys and another for the
production network. I.e. one device would be sending two sets of
enhanced-beacons out and their difference would be the key used.

As far as I have understood the devices only support sending one set
of beacons at one time. Now when it was clarified, that there is only
one set of enhanced beacons sent by devices, and those are only used
by the joining nodes, and the production network does not use enhanced
beacons at all, but instead use other frames for their syncronization
then that is much clearer... 

> Wireless HART does roughly what we're talking about. (The
> terminology in HART is a little different, so I have converted HART
> terms to ours.) The Join Assistant is a part of a production network
> where there are no beacons. All nodes are synchronized using ACKs on
> packets to time parents. Sometimes the packets are just Keepalives,
> sent for the sole purpose of getting that synchronizing ACK.
>
> management-layer security session with a high-entropy unique key.
> All such packets are encrypted and authenticated (4B MIC). All MAC
> layer messages in the production network are authenticated with a
> single network-wide high-entropy key (4B MIC). All keys are 128 bit.

Are that schedule etc delivered from the PCE to the Join Assistant
over information elements, or some data / multipurpose frames (i.e.
upper layer protocol)?

> The Join Assistant has a completely different schedule for sending
> Enhanced Beacons. The Join Assistant calculates a MIC for those
> beacons using a well-known, fake, bogus, entirely non-secure, zero
> entropy key. When it receives a response from a joining node, it
> checks the MIC to make sure that it was calculated with the
> W-KFBEN-SZE key. If the MIC is incorrect, the packet is thrown away.
> (This actually happens, and it gets logged, and reported.) If the
> MIC is correct, and the *type* of the packet is correct (join
> request) then the packet from the joining node is forwarded over the
> production network to the JCE, which makes its own determinations.
> If a packet comes back from the JCE to the Join Assistant for
> delivery to the joining node, this packet comes over the production
> network. The Join Assistant transfers it to its local join network,
> puts a MAC MIC on it with the W-KFBEN-SZE key, and sends it down to
> the joining node. The ACK that the Join Assistant receives from the
> Joining Node does not affect its timing at all - the joining node is
> not a time parent of the Join Assistant.

Again, how do you filter that enh-ack so that IEs in there are not
processed or not trusted, as it is still using valid key configured to
the security PIB (i.e. the well-known key)?

This filtering needs to be done by the MAC (I think), but there is not
a feature in 802.15.4 security (that I know of) that would allow you
do that...
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Dec 2014 11:42:25 -0500

Tero Kivinen <[email-masked]> wrote:
    >> management-layer security session with a high-entropy unique key.  All
    >> such packets are encrypted and authenticated (4B MIC). All MAC layer
    >> messages in the production network are authenticated with a single

    > Are that schedule etc delivered from the PCE to the Join Assistant over
    > information elements, or some data / multipurpose frames (i.e.  upper
    > layer protocol)?

When there is a PCE, the schedule is delivered via the 6top protocol, which
runs over CoAP/DTLS.  This uses the locally significant (LDevID) certificates
and anchors that the JCE installed.

When there is no PCE, then the minimal schedule is used, and updates to the 
may be schedule may be delivered over Information Elements.  In this
situation, the layer-2 security MUST be node to node.  It has been observed
that the minimal situation while conceptually simpler, requires more
(code/ram) resources from each node, while the PCE situation permits somewhat
simpler firmware.   Perhaps this should be unsurprising: the PCE is
offloading work from the constrained nodes, they can can be slightly more
constrained.

---

From: Kris Pister <[email-masked]>
Date: Mon, 15 Dec 2014 11:21:40 -0800

Just in case Tero was asking specifically about WiHART:
  In HART we didn't have information elements to work with since they 
didn't exist yet
(HART 7.0 came out in 2007), so HART uses an upper layer protocol.

ksjp

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 16 Dec 2014 16:19:34 +0200

> (HART 7.0 came out in 2007), so HART uses an upper layer protocol.

Ok, thanks.

As future versions might be using information elements for
transmitting all kind of information, I think we are going to need
some security policy mechanisms for them, i.e. some kind of security
PIB that will say which key and which security level is needed for
information element to be trusted from given node. This is something
we are going to be discussing during the 802.15.4 maintenance work.
-- 
[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 19 Dec 2014 13:48:03 +0100

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 <[email-masked]> wrote:
> 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
> so-called "exempt status". This "exempt status" construct allows receipt of
> incoming unsecured data frames from a joining node that does not have
> 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).
>
> 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.
>
> 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.
>
> 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
>
> tries and accommodate people in different time zones to the largest extent
> possible, without trying to discriminate against various parts of the world.
>
>
> 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...}
>
>
> Subir Das <[email-masked]> <[email-masked]> wrote:
> 6tisch-security mailing [email-masked]://www.ietf.org/mailman/listinfo/6tisch-security
>
>
>
> --