[wi-sun rlmmwg] Security Features in RLMM Profile 1v01
Ryota Yamada
ryamada at ari.ncl.omron.co.jp
Wed Jul 6 16:49:44 PDT 2016
Dear Sato-san,
I am sorry for missing to reply to your e-mail. I will put my response
between lines below in this e-mail.
On 2016/06/30 15:55, Noriyuki SATO wrote:
> 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.
Thank you very much for your input.
> 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.
Thank you very much for the calculation. I confirm that it will take
very long time until key expires and it seems that the key expiration
will not happen in most of application. However, I am not sure whether
we can just skip the description on how to update keys in RLMM Profile.
I would like to ask members opinion in the RLMM WG call today.
> 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.
As you mentioned, secure transportation of key is required in [1], [2]
and [3]. In [1] and [2], R0 is required to receive key through secure
transportation while R9 is required to receive key in [3]. As R9 is
connected to stable power source, it will be easy for R9 to receive key.
On the other hand, as the power source of R0 does not always provide
power, it will be difficult to receive key.
> 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 derivation and we consider about key update, I assume that
we need exchange of some information, such as random value, to be used
for derivation of updated key. Is my understanding correct?
In the case of ENET B-route, is the expiration of frame counter us
considered and Working Key updated?
> 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
Thank you very much for the summary.
In my understanding, if we require key update before expiration of frame
counter, some information such as random value is required to be
exchanged between R0/R1 and R9. In this case, both [3] and [4] will
require transportation of some information such as random value instead
of key. Is this understanding correct?
> Questions and comments are welcomed.
I hope we can have discussion in the call today.
Best regards,
Ryota
> 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.
>
>
様
お世話になっております。オムロン株式会社の山田亮太です。
さん
おつかれさまです。(企画)オープンの山田亮太です。
以上、よろしくお願いいたします。
--
+--------------------------------
| 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)
More information about the rlmmwg
mailing list