[6tisch-security] beacon discussion based on confusion between w/HART and 802.15.4e-2012? (Re: agenda for 2014-05-27 6tisch security call)

[Rene Struik <[e-mail]>]

Dear colleagues:

I may have missed something here, but this email thread seems to confuse 
what w/HART provides with what 6TiSCH could specify. Since 6TiSCH is to 
be defined on top of 802.15.4e-2012, it can secure frame types using 
policy-defined combinations of encryption and authenticity (including 
authentication-only). In particular, a newbee device, just out of the 
wrapping paper and with no network-specific keying material yet, may 
still be able to see most of an authenticated, but not secured frame, 
even if it cannot check authenticity.

So, no need to kill off functionality, come up with nested security 
constructs, two beacon types, etc; one should simply look at the correct 
standard one builds on {caveat: this assessment is modulo some errors in 
the 802.15.4e-2012 spec.}

BTW - As an interesting aside, this seems to illustrate that looking at 
specific details *does* matter...

Best regards, Rene


On 5/28/2014 7:43 PM, [e-mail] wrote:
>
> Yes.
>
> Yoshihiro Ohba
>
> *From:*Jonathan Simon [mailto:[e-mail]]
> *Sent:* Thursday, May 29, 2014 8:42 AM
> *To:* ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ)
> *Cc:* [e-mail]; [e-mail]; 
> [e-mail]
> *Subject:* Re: [6tisch-security] agenda for 2014-05-27 6tisch security 
> call
>
> Then as long as either
>
> a) Beacons are only used for advertising a network to unsychronized 
> devices, or
>
> b) Devices only take timing information (time of arrival) from beacons 
> coming from time parents and authenticated with the run-time key
>
> you are good.
>
> -- 
> Jonathan Simon, Ph. D
> Director of Systems Engineering
> Linear Technology, Dust Networks product group
> 30695 Huntwood Ave
> Hayward, CA 94544-7021
> [phone]
> [phone] FAX
> [e-mail] <mailto:[e-mail]>
>
> **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 [phone], and destroy the 
> original transmission and its attachments without reading or saving in 
> any manner. Thank you.
>
> On May 28, 2014, at 4:19 PM, <[e-mail] 
> <mailto:[e-mail]>> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>
>     Hi Jonathan,
>
>     I am not caring about an attacker to inject joining traffic, but
>     what I care is an attacker attempting to destruct basic TSCH
>     operation in the network by sending forged beacons protected with
>     the well-known key.
>
>     Yoshihiro Ohba
>
>     *From:*6tisch-security
>     [mailto:[e-mail]]*On Behalf Of*Jonathan Simon
>     *Sent:*Thursday, May 29, 2014 12:47 AM
>     *To:*ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ)
>     *Cc:*[e-mail]
>     <mailto:[e-mail]>;[e-mail]
>     <mailto:[e-mail]>;[e-mail]
>     <mailto:[e-mail]>
>     *Subject:*Re: [6tisch-security] agenda for 2014-05-27 6tisch
>     security call
>
>     Yoshihiro -
>
>     I don’t think this is a problem.  Nodes that are in the network
>     reject incoming frames secured with the well-known key. The
>     well-known key is only used to authenticate beacons, and
>     authenticate join requests (which don’t carry synchronization
>     information).  There is a DoS vector, in that an attacker can
>     inject joining traffic (destined for the network mananager) that
>     will ultimately be discarded, possibly preventing other nodes from
>     joining, and increasing the traffic in the network.
>
>     Jonathan Simon, Ph. D
>     Director of Systems Engineering
>     Linear Technology, Dust Networks product group
>     30695 Huntwood Ave
>     Hayward, CA 94544-7021
>     [phone]
>     [phone] FAX
>     [e-mail] <mailto:[e-mail]>
>
>     **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 [phone], and destroy the original transmission
>     and its attachments without reading or saving in any manner. Thank
>     you.
>
>     On May 28, 2014, at 8:01 AM, <[e-mail]
>     <mailto:[e-mail]>>
>     <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>
>
>
>         Hi Jonathan,
>
>         Thank you for your answer.
>
>         I think this can be an issue if already joined nodes also use
>         the beacons protected with the well-known key for maintaining
>         synchronization and slot allocations, as an attacker can send
>         forged beacons protected with the well-known key.
>
>         Yoshihiro Ohba
>
>         *From:*6tisch-security
>         [mailto:[e-mail]]*On Behalf
>         Of*Jonathan Simon
>         *Sent:*Wednesday, May 28, 2014 11:49 PM
>         *To:*ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ)
>         *Cc:*Michael Richardson; Rene Struik;[e-mail]
>         <mailto:[e-mail]>
>         *Subject:*Re: [6tisch-security] agenda for 2014-05-27 6tisch
>         security call
>
>         Yoshihiro -
>
>         Q.In w/HART, are all beacon frames authenticated with a
>         well-known key even after a joining node obtained the runtime
>         link layer key?
>
>         A. Yes. In WirelessHART the beacons (called "advertisements"
>         but they serve the same purpose and have similar content) are
>         intended for devices not yet in the network, so they always
>         use the well-known key.  To discover other nodes within the
>         network, they use frames secured with the runtime link-layer key.
>
>         Jonathan
>
>         On Tue, May 27, 2014 at 11:18 PM,
>         <[e-mail]
>         <mailto:[e-mail]>> wrote:
>
>             Hi Jonathan,
>
>             Thank you for sending the summary of w/HART joining.
>
>             I have question.
>
>             In w/HART, are all beacon frames authenticated with a
>             well-known key even after a joining node obtained the
>             runtime link layer key?
>
>             Regards,
>
>             Yoshihiro Ohba
>
>             *From:*6tisch-security
>             [mailto:[e-mail]
>             <mailto:[e-mail]>]*On Behalf
>             Of*Jonathan Simon
>             *Sent:*Tuesday, May 27, 2014 10:41 PM
>             *To:*Rene Struik
>             *Cc:*Michael Richardson;[e-mail]
>             <mailto:[e-mail]>
>             *Subject:*Re: [6tisch-security] agenda for 2014-05-27
>             6tisch security call
>
>             Rene had asked on a previous call for someone to summarize
>             WirelessHART joining - here you go.
>
>             * One or more devices are sending beacons to advertise the
>             presence of the network. In WirelessHART, this frame is
>             unencrypted, but authenticated with a well known key.  The
>             beacon contains the current ASN, which the joining device
>             uses to synchronize its clock.
>
>             * Once the joining node has heard a beacon, it continues
>             listening for additional beacons for a short specified
>             timeout.
>
>             * The joining node encrypts a frame containing some HART
>             specific content, including a list of beaconing neighbors
>             it heard in the previous steps. The size of the payload is
>             ~ 60 bytes.  The packet is routed by a "proxy" node - the
>             joining parent. The frame is authenticated using the
>             well-known key, and encrypted using a shared symmetric key
>             known only by the node and the manager.
>
>             * The manager responds with a frame containing the
>             run-time link-layer key, the node's new short address
>             (this takes the place of PAN coordinator association), and
>             a unicast session key and starting nonce for the manager.
>             This frame is encrypted with the symmetric key. The
>             payload is ~ 60 bytes, and is routed to the proxy for
>             delivery to the joining node - the proxy uses the
>             link-layer well known key on the frame.
>
>             * At this point the joining node transitions to using the
>             run-time link-layer key for all link-layer frames, and the
>             manager unicast session for end-to-end manager traffic.
>             This ends the initial security handshake.
>
>             * Over a number of additional frames, the manager assigns
>             additional sessions, including broadcast sessions, and a
>             unicast session to the Gateway (sink for all data
>             traffic), and additional communications resources, routing
>             information, etc.  There is no explicit transition from
>             joining to joined - the mote transitions when certain key
>             frames are received.
>
>             * Note that a WirelessHART link-layer frame contains and
>             additional frame type byte and a 4-byte link-layer MIC, on
>             top of the unsecured 15.4 frame.  A network frame contains
>             an additional 16-40 bytes of addressing, routing, security
>             and other information.
>
>             Hope this help!
>
>             Jonathan
>
>             On Mon, May 26, 2014 at 8:09 PM, Rene Struik
>             <[e-mail] <mailto:[e-mail]>> wrote:
>
>                 Hi Michael:
>
>                 I would like to discuss the outstanding issues I
>                 summarized in my email of Tue last week, May 20, 2014,
>                 9:45am EDT
>                 (seehttp://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html
>                 <http://cp.mcafee.com/d/5fHCMUp41ESyNt55OWtSjtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsTJQXIfcLZvC4TQTS6eLsKCO-PPXX3XUVzBHFShjlKepVkffGhBrwqrhdI6XYyMCY-ehojd79KVI05bVKY01MjbX6NehDY05zAVkIjbQ-PspjbppKcvxf5q4rTKYVMedKjBiNcLjXdNBcIn8lrxrW0GnPtU02rhhuhKr1vF6y0QJKjBiNcLjXdNBcIqnjh1F7U8qq87qNd42tQm2ZTOWoUQgejBiNcQgk-Pspjb6y2SDDCT63pO_o>).
>                 This was also one of the action items at the
>                 conclusion of last week's 6TiSCH security call.
>
>                 FYI - the w/HART communication flows were discussed
>                 during the 6TiSCH security conf call the week before,
>                 on Mon May 12, 2014. If one wishes to go over this
>                 again, that is fine, but I would prefer us giving
>                 preference to taking on already articulated issues
>                 (which were assigned as homework assignment to reflect
>                 upon) first (i.e., prior to item #4 of the proposed
>                 agenda).
>
>                 As another agenda point, I would like us to discuss
>                 the frequency of future calls (as part of EOB).
>
>                 Best regards, Rene
>
>
>                 On 5/26/2014 10:49 PM, Michael Richardson wrote:
>
>                     To remind, we moved the call from the 26th to the 27th at 10am EDT.
>
>                     That's 90 minutes from this email.
>
>                       
>
>                     1) notewell.
>
>                     2) intros
>
>                     3) recap of draft-piro-
>
>                     4) wirelesshart -way --- how does the communication work?
>
>                     5) how to summarize all of this to the working group
>
>                     6) how to close this process up?
>
>                       
>
>                     -- remember that the call is recorded, and the NoteWell applies.
>
>                       
>
>                     -- The URL to access the webex, which will we use for audio only:
>
>                        https://cisco.webex.com/cisco/j.php?MTID=m2fe139bf876cea3ec62750cd580b7908  <http://cp.mcafee.com/d/5fHCN0SyNt55OWtSjtPqbwVBcSyUepvdEK3zhOyCOqejrzPPPz5XCN6ABqM1hYEvIundDOx-NVsTJQXIfcLZvC4TQTS6eLsKCO-PPXX3XUVzBHFShjlKepVkffGhBrwqrjdI6XYyMCY-ehojd79KVIDeqR4IOQGmHM0L3-nOQGmHwzMh93o93gUVldTQmjhOgtu7em_mvIUCevLp1ZWV0sqerL6T9OFoCnFZCUOCmbAaJMJZ0lbVKY01dEEL8TdwLQzh0qmT9OFoCnFZCUOCmdbFEwQzY4dd43JoCy1eWb1uXVtcsq879OFoCq8avpKcFBzh1rjPPrz1LmTw7w17>
>
>                       
>
>                     -- we will resume with the etherpad at:
>
>                         http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-6tisch-security  <http://cp.mcafee.com/d/2DRPow71NJ5yWabBQXICXCQn1PapJ5MsO-rhs76zB5dAQsCT7DDD6bTdyd9aRw2zVg_oYKrfB3ZzOVLrFToupvW_c9LFLIctuVtdBZDDTS7TNP7bnjIyCHssPOEuvkzaT0QSOrodTV5xdVYsyMCqejtPo0fVA_yJG7jHk-Di-rL00kzhPuZYmO5p_gLbVKBTzhOnsDaBypuDSrzapoSVelb4OZfIT6kONsxlK5LE2FvdTw09J55V6VI5-Aq83iSVelb4OZfIT6kONFtd46AvwxFEwtH4Qg9ThobTvbFzzh0Velb4Ph1jXdNBcIq8bquursodJiZvpmK6GwY>
>
>                       
>
>                     I'm at+1 613 276-6809  <tel:%2B1%20613%20276-6809>, IM:[e-mail]  <mailto:[e-mail]>  [e-mail]  <mailto:[e-mail]>,
>
>                     if you need more than that to get in, or are having difficulties.
>
>                     Please make sure your audio works, and that you mute when not talking.
>
>                       
>
>                     --
>
>                     Michael Richardson<[e-mail]>  <mailto:[e-mail]>, Sandelman Software Works
>
>                       -= IPv6 IoT consulting =-
>
>                       
>
>                       
>
>                       
>
>                     _______________________________________________
>
>                     6tisch-security mailing list
>
>                     [e-mail]  <mailto:[e-mail]>
>
>                     https://www.ietf.org/mailman/listinfo/6tisch-security  <http://cp.mcafee.com/d/2DRPoO86QmbEEKnjKOrKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCZKDtxVB_HYMC-C-MNRXBQSnSuvvovv7csJteOaqJNPfaxVZicHs3jr1JwTvAm4TDNOb2pEVdTdAVPmEBC5eBYTu00U9GX33VkDa3JssDaBypuDSrzapoSVelb4OZfIT6kONsxlK5LE2FvdTw09J55V6VI5-Aq83iSVelb4OZfIT6kONFtd46AvwxFEwtH4Qg9ThobTvbFzzh0Velb4Ph1jXdNBcIq8bquursodLWbv>
>
>
>
>
>
>                 -- 
>
>                 email:[e-mail]  <mailto:[e-mail]>  | Skype: rstruik
>
>                 cell:[phone]  <tel:%2B1%20%28647%29%20867-5658>  | US:[phone]  <tel:%2B1%20%28415%29%20690-7363>
>
>
>                 _______________________________________________
>                 6tisch-security mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 http://cp.mcafee.com/d/avndzgQ93gArhoKyyVteX9KVJ5MsOCrhs7cLCQn1NEVhjpd79JNVVVNyZPoziiJo0E-kfSfbCPVg_oYKrSWtS7Cn-LP2rWrX37nKnjpvpVZZxZYsNORQX8FGT7cYG7DR8OJMddECQjt-hojuv78I9CzATsSjDdqymokWnPtU03wCHIcfBisEeRNOsGm9BWvpKcFBzrAVkIjbQ-Pspjb5O5mUm-waBYTu00CQknArCMnWhEwdbrAVkIjbQ-Pspjb6BQQgqh-26Cy1SIjh0Dt5wLtYKCed43AVkIjd45fIT6kONEwJFVVJNwSeVhsrLe-Fkd
>
>
>
>
>             --
>
>             -- 
>             Jonathan Simon, Ph. D
>             Director of Systems Engineering
>             Dust Networks at Linear Technology
>             30695 Huntwood Ave
>             Hayward, CA 94544-7021
>             [phone] <tel:%28510%29%20400-2936>
>             [phone] <tel:%28510%29%20489-3799>FAX
>             [e-mail] <mailto:[e-mail]>
>
>             **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
>             <tel:%28510%29%20400-2936>, and destroy the
>             original transmission and its attachments without reading
>             or saving in any manner. Thank you.
>
>
>             _______________________________________________
>             6tisch-security mailing list
>             [e-mail] <mailto:[e-mail]>
>             http://cp.mcafee.com/d/2DRPow76QmbEFLzzhOM-rKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCTA7hPXPb_nVNZNBVxzHTbEzHIYYepd7bz8XBHEShhlKM_OEuvkzaT0QSyrhdTV5xdVYsyMCqejtPpesRG9pxjFvdTw0e2qKMM-l9OwXn79OFoCnFZCUOCmdKjBiNcLjXdNBcIn8lrxrW0GnPtU02rojhKUr1vF6y0QJKjBiNcLjXdNBcIqnjh1F7U8qq87qNd42tQm2ZTOWoUQgejBiNcQgk-Pspjb6y2SDDCT63rt_U2SVUlVB0
>
>
>
>
>         --
>
>         -- 
>         Jonathan Simon, Ph. D
>         Director of Systems Engineering
>         Dust Networks at Linear Technology
>         30695 Huntwood Ave
>         Hayward, CA 94544-7021
>         [phone]
>         [phone] FAX
>         [e-mail] <mailto:[e-mail]>
>
>         **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 [phone], and destroy
>         the original transmission and its attachments without reading
>         or saving in any manner. Thank you.
>
>         _______________________________________________
>         6tisch-security mailing list
>         [e-mail] <mailto:[e-mail]>
>         http://cp.mcafee.com/d/1jWVIe3zqb5QkTzhOMC-rKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCO5JtvupvW_8CzBdBBfHTbECzBdzATC7xNEVVqWtAklrCzB7BgY-F6lK1FJ4SyrLOb2rPUV5xcQsCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04S-qem7T3obZ8Qg6BJOsGm9BWvpKcFBziWq8d8_13jh0Xm9EwjKyMnK-nj76y1OsGm9Cy2DSrzapoQgmQYYSUMrDrkr2pAaTam
>


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]