Subject: [6tisch-security] summary of discussions on Tuesday

From: Michael Richardson <[email-masked]>
Date: Thu, 04 Dec 2014 16:31:08 -0500

I can not speak to the call at 9am.
At 11am, we had Tero Kivinen join:
   Attending:
    - Thomas (TW)
    - Michael (MR)
    - Kivinen (TK)
    - Malisa 
    - Rene (joined :30) (RS)
    - Pascal (joined :50) (PT)

Tero composed a summary of his views, which he sent to secdir and to me
privately.  is it at:
     https://mailarchive.ietf.org/arch/msg/secdir/xqPZrSNhkXyD8n4Y5yerG2BmSVc
and I will likely reply to that message into this list.

The discussion started from a need to understand if we had one or two beacons
coming from the join assistant.  I assumed that there would be two, and that
one would be secured with the production network key, and the other with the
well known beacon key.  There was various amount of discussion as whether or
not this was even possible to do with available MAC implementations.

I took an action to research how much of the MAC implementation is in
software in the "main" CPU, and how much is logic in the MAC (whether it's
hard logic, or immutable firmware doesn't matter).  I hope to post that
summary on Monday.  Associated with this discussion was some details about
the current 802.15.4 receiver state machine, and changes that TK is making 
in the -2015 revision.

A suggestion was made to have one beacon, just the production beacon. This
made a number of us unhappy, as if you can trick someone to use lower ASN,
you cause them to send more data with a previous key, and due to the replay
issue with stream ciphers, you may be able to guess what sent the previous
time.

We transitioned to the idea of having one beacon, authenticating it only.
Nodes which have the production network key will be able to authenticate the
beacon and pull the correct ASN.  Joining nodes won't be able to authenticate
the traffic, but will be able to use the beacon to synchronize to the network
and find the Aloha slot.

We talked about the use of a virtual extended address for sending beacons,
as the L2-keys are per-extended (source) address, and since multiple nodes
will need to send the beacon (for radio coverage in the mesh), it needs to be
done right.  

We discussed whether or not the join traffic itself should be encrypted with
some well known key (different from the production network key, which the
joining node does not yet know). Opinions were expressed that it wasn't
necessary, and the situation from the Zigbee interop were recounted again.
TK suggested that older receiver state machine implementation would have
difficulty with encrypted traffic that was differently trusted.

- TK: points to "In the P802.15.4-REVc-DF2 section 6.3.1.2 Active and passive
  channel scan we say: 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"

We discussed what to do with the architecture document, and some text was
promised prior to Friday's 6tisch meeting.

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

---

From: Subir Das <[email-masked]>
Date: Thu, 4 Dec 2014 17:22:49 -0500

Thanks for posting the call minutes and sharing Tero's review. I tried to
join the call but failed and then thought that there is no other call.  I
was on the 9 am call where number of participants were less. Having two
calls in a single day is very bad and confusing. I noticed that both chairs
joined to this call but they were not in 9 am call. Does this mean they
didn't know or endorse the 9 am call?   Whatever it may be, Chairs must
bring some order here.  I understand that these are ad hoc calls but if the
WG needs to involve more participants, we need to have one call and decide
the call time that is acceptable by majority of the participants.

-Subir

On Thu, Dec 4, 2014 at 4:31 PM, Michael Richardson <[email-masked]>
wrote:

> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security
>
>

---

From: <[email-masked]>
Date: Fri, 5 Dec 2014 04:58:20 +0000

Michael and all,

Thank you for the minutes.  I could not attend this one due to difficulty in time difference while I was able to attend the 9am EST one.  As I mentioned before, I can always comment on the minutes even if I am not able to attend a call.  So everyone please do not much mind about time differences.  Actually I like email discussions.

Let me comment on several things.

[1] If my understanding is correct the following scheme is most likely the way for beacons.

- Use of a single, not-well-known key for protecting beacons.
- Use authentication-only (no-encryption) for protecting the beacons.

If so, I agree with this scheme.

[2] Regarding a virtual extended address, I think macDefaultKeySource in IEEE 802.15.4-2011 is such an address.

[3] I almost agree with Tero's review, except for the following paragraph:

"As I described earlier, this does not protect the nodes who has lost
sync with network (i.e. who has been sleeping so long that they do not
know the current schedule and current ASN) against replays of the
beacons by attacker. On the other hand as the AES-CCM nonce also has
the extended address of the sender there, it is enough for the node to
make sure he will never go backwards for ASN when sending packets
using current network key. If he is tricked to send frames using wrong
ASN, then other real nodes in the network will not be able to read
those, but that is just DoS, not real security vulnerability, which
would happen if he would generate frame with old ASN he has already
used, which would generate same AES-CCM nonce."

As I mentioned in other email, nonce re-use in AES-CCM is much more than just a DoS, as it gives hints about the key. 

Best Regards,
Yoshihiro Ohba

-----Original Message-----
From: 6tisch-security [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: Friday, December 5, 2014 6:31 AM
To: [email-masked]
Subject: [6tisch-security] summary of discussions on Tuesday

Tero composed a summary of his views, which he sent to secdir and to me privately.  is it at:
     https://mailarchive.ietf.org/arch/msg/secdir/xqPZrSNhkXyD8n4Y5yerG2BmSVc
and I will likely reply to that message into this list.

The discussion started from a need to understand if we had one or two beacons coming from the join assistant.  I assumed that there would be two, and that one would be secured with the production network key, and the other with the well known beacon key.  There was various amount of discussion as whether or not this was even possible to do with available MAC implementations.

I took an action to research how much of the MAC implementation is in software in the "main" CPU, and how much is logic in the MAC (whether it's hard logic, or immutable firmware doesn't matter).  I hope to post that summary on Monday.  Associated with this discussion was some details about the current 802.15.4 receiver state machine, and changes that TK is making in the -2015 revision.

A suggestion was made to have one beacon, just the production beacon. This made a number of us unhappy, as if you can trick someone to use lower ASN, you cause them to send more data with a previous key, and due to the replay issue with stream ciphers, you may be able to guess what sent the previous time.

We transitioned to the idea of having one beacon, authenticating it only.
Nodes which have the production network key will be able to authenticate the beacon and pull the correct ASN.  Joining nodes won't be able to authenticate the traffic, but will be able to use the beacon to synchronize to the network and find the Aloha slot.

We talked about the use of a virtual extended address for sending beacons, as the L2-keys are per-extended (source) address, and since multiple nodes will need to send the beacon (for radio coverage in the mesh), it needs to be done right.  

We discussed whether or not the join traffic itself should be encrypted with some well known key (different from the production network key, which the joining node does not yet know). Opinions were expressed that it wasn't necessary, and the situation from the Zigbee interop were recounted again.
TK suggested that older receiver state machine implementation would have difficulty with encrypted traffic that was differently trusted.

We discussed what to do with the architecture document, and some text was promised prior to Friday's 6tisch meeting.

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 5 Dec 2014 02:06:08 -0800

Minutes archived at
https://bitbucket.org/6tisch/meetings/wiki/141202b_webex_security.

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 5 Dec 2014 02:16:18 -0800

Subir, all,

Having two security calls is NOT something the chairs endorse. We have had
extensive private exchanges to understand what happened, and have converged
on steps to better coordinate for this situation not to repeat.

Thomas & Pascal

---

From: <[email-masked]>
Date: Tue, 9 Dec 2014 02:40:15 +0000

Correction in my words: "as it gives hints about the key" should read "as it can reveal cleartext".

Thanks Kris and Rene for correcting this.

Regards,
Yoshihiro Ohba

-----Original Message-----
From: 6tisch-security [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, December 5, 2014 1:58 PM
To: [email-masked]; [email-masked]
Subject: Re: [6tisch-security] summary of discussions on Tuesday

Michael and all,

"As I described earlier, this does not protect the nodes who has lost sync with network (i.e. who has been sleeping so long that they do not know the current schedule and current ASN) against replays of the beacons by attacker. On the other hand as the AES-CCM nonce also has the extended address of the sender there, it is enough for the node to make sure he will never go backwards for ASN when sending packets using current network key. If he is tricked to send frames using wrong ASN, then other real nodes in the network will not be able to read those, but that is just DoS, not real security vulnerability, which would happen if he would generate frame with old ASN he has already used, which would generate same AES-CCM nonce."

Best Regards,
Yoshihiro Ohba