Re: [6tisch] comments on draft-piro-6tisch-security-issues

[Giuseppe Piro <[e-mail]>]

Hi Michael,



thank you very much for your mail and you precious comments. See my answers
below.


On Wed, May 14, 2014 at 2:41 AM, Michael Richardson
<[e-mail]>wrote:

>
> I found this document to be a useful overview of 802.15.4 physical/layer-2
> security options.
>
> I don't agree with your title! I don't see how this is a "security
> framework". It is something much more useful and important.
> The analysis in section 3 is very useful.
>

​As you understood, we are focusing on the layer-2 security. I agree with
you that the title should be modified. What do you think about “Layer-2
security aspects in IEEE 802.15.4(e) networks ” ? Do you have a better
proposal ?​


>
> I am not sure that I understand section 4.
>

Probably this issue arises from the concept of “domain” that we introduced
in this section. In our draft (written few months ago), the domain
identifies a portion of the network where the conceived procedures work.

I’ve realized that this definition is, now, no more useful because it goes
against the “concept of domain” recently discussed within the 6tisch
security task force (I read Rene’s comment on that topic).

As suggested by Thomas (see
http://www.ietf.org/mail-archive/web/6tisch/current/msg01741.html), we can
use the term “one-hop neighborhood” for indicating that the presented
approach just enable (for the moment) the establishment of a secured link
at the MAC layer.

What do you think ?
​


>
> Thank you for giving the network definitions in section 5.0.
> It would be worth making it clear in the definition of fully secure that
> all
> broadcasts are encrypted, including the beacon.
>
> The _Hybrid Secured network_ is likely the most common, and not because
> nodes
> are not capable of encryption, but because they don't have the key (yet!!).
>
>
​Ok, I've understood your point of view about the _Hybrid​ Secured_
configuration. We can modify the definition accordingly. However, according
to your comment, do you think that the _Fully Secured network_ still
identifies a realistic scenario ?

In that configuration, all packets, included the Beacon, are protected.
This means that all nodes needs to know the key before starting any
connections (included the join procedure).

To address this issue, we introduced the Default Key (I believe that it has
the same meaning of the "fake key" used by Rene in some mails few weeks
ago).

Do you think that this is still a useful and correct approach ?



> The Setting-up Phase seems to assume a provisioning process to distribute
> this MasterKey.  It could be that the MasterKey comes from something like
> 1x/PANA?
>

​In the current version of the draft, it is assumed that the MasterKey is
stored into the device by the manufacturer or by the network administrator
(like a certificate).

We can think to a more generic scheme that enables its distribution through
1x/PANA approaches. However, we have to understand how this scheme
maintains the compatibility with the _Fully Secured_ configuration.
​

>
> I like that the document uses 6top API to set things up.
> My understanding is that 6.3 describes a way to get fresh per-cluster
> keying.
> It appears that this is done over a layer-2 protocol.  Why not MLE?
>
>
I agree with you. Qin has already pointed out this issue in the past.

We have already re-designed the whole KMP by using only Information
Elements but we didn’t yet included this into the draft).
Please, can you confirm that the adoption of only IEs handled by the MLME
is the right approach ?​


>
> Some editorial nits:
> in section 6.1.1 the word "exploit"(ed) is technically correct, but perhaps
>    an unfortunate choice for many non-english/french speakers.
>    "exploiter" en francois is perhaps best translated as "leverage"
>    In IT circles, many understand an "exploit" to be a security flaw..
>
>
.... I I will delete this term from my dictionary, thanks :-)
​




Finally, I would remark that we are working for upgrading the draft by
considering comments provided within these discussions:

http://www.ietf.org/mail-archive/web/6tisch/current/msg01691.html
http://www.ietf.org/mail-archive/web/6tisch/current/msg01680.html
 http://www.ietf.org/mail-archive/web/6tisch/current/msg01685.html

and obviously, your comments will be also carefully taken into account.

Apart of these comments, can you provide further suggestions and highlight
in which direction this draft can be upgraded, thus being more useful for
the work conducted within the security task force ?

Thanks
Giuseppe





-- 
*Giuseppe Piro, PhD*
Post Doc Researcher
DEI, Politecnico di Bari
via Orabona 4 - 70125 (Bari), Italy.
email: [e-mail]
phone: [phone]
web: g <http://telematics.poliba.it/piro>iuseppepiro.com