Re: [6tisch-security] agenda for 2014-05-27 6tisch security call

[Jonathan Simon <[e-mail]>]

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]

**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]> <[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]
> 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]> 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]] On Behalf Of Jonathan Simon
> Sent: Tuesday, May 27, 2014 10:41 PM
> To: Rene Struik
> Cc: Michael Richardson; [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]> 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 (see http://www.ietf.org/mail-archive/web/6tisch-security/current/msg00086.html). 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
>  
> -- we will resume with the etherpad at:
>    http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-6tisch-security
>  
> I'm at [phone], IM: [e-mail] or [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]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>  
>  
>  
>  
> 
> _______________________________________________
> 6tisch-security mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch-security
> 
> 
> 
> -- 
> email: [e-mail] | Skype: rstruik
> cell: [phone] | US: [phone]
> 
> _______________________________________________
> 6tisch-security mailing list
> [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]
> [phone] FAX
> [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]
> 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]
> 
> **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]
> http://cp.mcafee.com/d/1jWVIe3zqb5QkTzhOMC-rKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCO5JtvupvW_8CzBdBBfHTbECzBdzATC7xNEVVqWtAklrCzB7BgY-F6lK1FJ4SyrLOb2rPUV5xcQsCXCOsVHkiP2Di-rL00s4RtxxYGjB1SKejBiNcLjXdNBcIrsDaBypuDSrzapoKgGT2TQ1kLCXM04S-qem7T3obZ8Qg6BJOsGm9BWvpKcFBziWq8d8_13jh0Xm9EwjKyMnK-nj76y1OsGm9Cy2DSrzapoQgmQYYSUMrDrkr2pAaTam