[wi-sun rlmmwg] [SPAM] Re: Security Features in RLMM Profile 1v01

Wed Jun 29 23:55:33 PDT 2016

Yamada-san, Verotiana and all,

I apologize that I joined the call late today and I couldn’t attend last conference call.

I've checked incoming frame procedure of IEEE802.15.4 and found following things.
A. There is two options to check frame counter
  1.  Per Device; Min frame counter is managed for neighbor devices
  2.  Per Key; Min frame counter is managed for pair of neighbor and key_id
I've found frame counter is incremented per device (and per key). That means that frame counter is not shared.
It depends on number of frames which the most frequent sender sends but it doesn’t depend on the number of neighbors.

Sorry that I may say wrong thing in last but one call.

B. Frame counter is defined as 4 bytes counter in IEEE802.15.4 security.
It has very large space.  If a frame is sent by one device per 100 (msec), The frame counter will expire 13.6 years later

Assuming that it is common key in network, key update needs to be done before the most frequent sender expires frame counter.

So, do we really need to consider about expiration of frame counter and cost of key update?
If the duty is 1%, it requires 1/100 times key update frequency as rich resource device.

Here is questions on the today's slides.

Questions:
1. There is necessity of receiving WK from R9 for Cons of [1] and there is unnecessity of receiving WK for Pros of [3]. However, [3]
requires R0 devices to send WK to R9. What is the difference? It looks that both methods requires secure transportation of key. Not
only [1] and [3] but [2] looks to require it.

2. Even if WK is common key in the network, R9 can kick out any device during key update period if they key transport mechanism is
used per device in [2].

I think we can summarize as following.

Do we use secured key transportation to share the key or do we use key derivation method with using password?
Former one is approach of ENET single hop HAN and latter is one of ENET B-route.

If we use key transportation, which do we use for it - password per device or common in network? This key is different from common
wk key.
 - if it is per device, R9 can kick R0/R1 during key update and R9 can provide either 'per link' WK key and 'common' WK key.
 - if it is common in NWK, R9 cannot choose R0/R1 to be kicked and R9 can provide 'common' WK key only.
If we use password to derivate key like ENET B-route, is it shared one or per devices?

Summarized into 4 methods
[1] Per Device Key Transport, Common WK key, Pro: Broadcast, Individual kickout
[2] Common Key Transport, Common WK key, Pro: Broadcast
[3] Derivation from per device password, Pro: key transport unnecessary, kickout 
[4] Derivation from common password, Pro: key transport unnecessary, easy handling

Questions and comments are welcomed.

Best regards,
Noriyuki Sato

> -----Original Message-----
> From: rlmmwg [mailto:rlmmwg-bounces at wi-sun.org] On Behalf Of rverotiana at nict.go.jp
> Sent: Wednesday, June 29, 2016 7:33 PM
> To: Ryota Yamada
> Cc: rlmmwg at wi-sun.org
> Subject: [SPAM] Re: [wi-sun rlmmwg] Security Features in RLMM Profile 1v01
> 
> Dear Yamada-san and all,
> 
> >From our last call I believe we are down to a choice between [2] and [3].
> 
> If my understanding is correct, here are the things we should consider in this discussion:
> 
> *The key update frequency depends on:
> 
> - the R1/R9 traffic (traffic to and from R0 is bound by their duty cycle and is less significant in the key update frequency)
> - the number of R1 devices in the network
> - others?
> 
> *The following implementation cases are possible:
> 
> - Many R1, low traffic (Key update frequency similar to the R0 wake-up frequency) ==> [2]
> - Many R1, high traffic ==> [3], but broadcast become costly (multiple unicasts).
>         o   If broadcast transmissions are frequent, [2] is better
>         o   Another option would be to have a common key for R1s and unique respective keys for R0
> - Low number of R1 (most devices are R0) or only R0 ==> [2] or [3].
>         o   If [3], broadcasts can be handled with multiple unicast transmissions synchronized with the duty cycle of
> R0.
> - Others?
> 
> So far, there is no strict definition or requirement on few/many R1 or high/low traffic.
> Therefore, one of the most feasible/preferable choice might be "to simply hold those two options."
> 
> This might help the discussion tomorrow.
> 
> Best regards,
> 
> Verotiana
> 
> 
> >Dear RLMM WG members,
> >
> >This is gentle reminder to members for providing feedback for
> >discussion on security features in RLMM Profile 1v01. We will discuss
> >about this in the call to be held tomorrow on Jun. 30th JST.
> >
> >If you could provide your feedback before the call, we can share it in
> >the call.
> >
> >Best regards,
> >Ryota
> >
> >
> >On 2016/06/24 16:14, Ryota Yamada wrote:
> >> Dear RLMM WG members,
> >>
> >> I have uploaded the updated version of the material which summarize
> >> current status of discussion regarding security feature for 1v01:
> >> https://dms.wi-sun.org/htcomnet/Handlers/Download.ashx?action=downloa
> >> d&file=M2MIG%2F20160624%20Security%20Features%20in%20RLMM%20Profile%2
> >> 01v01%200v01.pptx
> >>
> >>
> >> Please go through the material and give your feedback before next
> >> call to be held fromm 11:00 on Jun. 30th JST.
> >>
> >> There are two major questions:
> >> (1) Which option on page 3 of the material shall we choose?
> >> (2) Which option on page 7 shall we choose for how to manage key?
> >>
> >> If you have any comment or suggestion, please let me know.
> >>
> >> Best regards,
> >> Ryota
> >>
> >>
> >
> >様
> >
> >お世話になっております。オムロン株式会社の山田亮太です。
> >
> >さん
> >
> >おつかれさまです。(企画)オープンの山田亮太です。
> >
> >
> >
> >以上、よろしくお願いいたします。
> >
> >
> >--
> >+--------------------------------
> >| Ryota Yamada <ryamada at ari.ncl.omron.co.jp>
> >|
> >| OMRON Corporation
> >|  Technology and Intellectual Property H.Q.
> >|   Planning and CTO Support Division
> >|    Open Innovation Sec.
> >|
> >| Tel: +81-774-74-2158 (Ext: 7-232-6558)
> >
> >_______________________________________________
> >rlmmwg mailing list
> >rlmmwg at wi-sun.org
> >https://lists.wi-sun.org/listinfo/rlmmwg
> >
> >Copyright (C) 2016 Wi-SUN Alliance. The contents of this email are confidential and may not be disclosed to non-members
> without prior written consent of an authorised representative of Wi-SUN Alliance.
> >
> 
> 
> 
> _______________________________________________
> rlmmwg mailing list
> rlmmwg at wi-sun.org
> https://lists.wi-sun.org/listinfo/rlmmwg
> 
> Copyright (C) 2016 Wi-SUN Alliance. The contents of this email are confidential and may not be disclosed to non-members
> without prior written consent of an authorised representative of Wi-SUN Alliance.