Attending:
    - Thomas Watteyne (TW)
    - Michael Richarson (MR)
    - Tero Kivinen (TK)
    - Malisa Vucinic (MV)
    - Rene Struik (joined :30) (RS)
    - Pascal Thubert (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.