Subject: [Roll] some brief comments on draft-qiu-roll-kemp-00

From: Rene Struik <[email-masked]>
Date: Wed, 30 Mar 2011 11:08:31 -0400

Dear Qiu:

Please find below some initial comments on your draft-qiu-roll-kemp-00.

I hope you have a good discussion at the roll meeting at IETF-80.

Best regards, Rene

==

[initial comments  on draft-qiu-roll-kemp-00]

Section 3:
This section referesto a probabilistic key pre-distribution scheme based
on secret keys.
a) Obviously, there are trade-offs between size of the key set and
probability that one is able to establish a shared key. It would be
helpful to have some insight in the number of keys that need to be
stored so that a shared key can be derived (e.g., with network of size
100, 1000, 10000).
b) It would be good to have some insight into how compromise of a few
nodes may impact the security of key establishment with two
non-compromised nodes.

Section 4.1:
This section describes a basic protocol where a base station B acts as
inline CA and assists a sensor node N and router R in establishing a
session key.
a) The protocol assumes that each sensor, router shares a secret key
with the base station. Thus, one seems to consider a single trust
domain. What about the scenario where on has multiple trust domains
(e.g., when one procures sensors from different vendors)?
b) How does the sensor N know which base station B to talk to?
c) The base station B checks revocation of sensor node N. It seems
useful to also check revocation of router R and arbitrage on whether
secure and authentic channel between node {N,R} should be established.
d) The message appv needs to be authenticated, since otherwise any
incoming message may trigger a key update with router R.
e) What prevents an adversary from replaying past (sensor node, request)
pairs and triggering traffic flows and key updates with routers this way?
f) The protocol does not provide for key confirmation, so state changes
on the router (triggered key update K_NR with purported sensor node N)
may not be temporary, but may linger for quite a while. This, in
conjunction with potential replay attacks, may trigger consumption of
keying material related storage.
g) The protocol's communication pattern is circular (sensor - base
station - router - sensor). Given the sleepy nature of networks and
desire to minimize having to keep status information, having the
communication flow between two nodes (sensor - base station) may be
preferred. This could then be followed by communication flow between two
nodes (sensor - router) based on successful completion of first
transaction. In other words, this corresponds with inline CA (base
station) interacting with one node (sensor) only, whereafter sensor
interacts with router based on distributed keying material by CA. This
may also minimize necessity to propagate state and prevent replay scenarios.

General remarks:
a) It may be useful to analyze the proper working of the protocol if the
underlying single-hop communications would be secured (e.g., using
802.15.4-2006 security with a network-wide key), so as to have potential
restrictions surfacing.
b) It seems that use of public-key based techniques may aleviate some of
the restrictions w.r.t. single trust domain and initial set-up. Anno
2011, implementation cost (code size, communication overhead,
computational latency, and energy consumption) does not seem to be a
roadblock for considering this for all but most mundane devices.

==

-------- Original Message --------
Subject: 	RE: [Roll] FW: New Version Notification
fordraft-qiu-6lowpan-secure-router-01
Date: 	Thu, 28 Oct 2010 19:46:15 +0800
From: 	QIU Ying <[email-masked]>
To: 	'Childress, Steve' <[email-masked]>, 'Rene Struik'
<[email-masked]>
CC: 	<[email-masked]>, <[email-masked]>, "'Zhou Jianying'"
<[email-masked]>, "'Bao Feng'" <[email-masked]>

Hi, Rene and Steve

Thanks for your comments.

First of all, one thing needs to clarify: each node shares a secret key with
its neighbour as well as the base station, respectively.

You are right that the current version does not describe the issue of
multiple trust domains.

If these multiple domains are managed by one base station (key centre), the
proposed protocol can simplify be employed on this scenario.
 
If these multiple domains have their own base station, there are 2
sub-scenarios:
1) if the sensor node know its destination base station, the current
protocol can be use without any change, but extend the node's cache table to
store the secret between node and these base stations.
2) if the sensor node cannot decide which base station is its destination,
we need to modify the req message. One possible solution could let the req
message carry a catenation of all of MACs with generated by the secret
between the node and the basestaion, respectively. But I do not think it is
a good solution because the req message would be longer and cost much more
transit energy.    

Since the node has different keys with its neighbours respectively, one
compromised router would not affect the entire system but its neighbour
nodes.

In the section 5, we briefed the security analysis. In fact, the protocol is
similar with the well-known Kerberos protocol. Our protocol tries to reduce
the handshake messages.

Steve, could you please provide more information on your project?

Regards and Thanks
Qiu Ying

> -----Original Message-----
> From: Childress, Steve [mailto:[email-masked]]
> Sent: Thursday, October 28, 2010 4:12 AM
> To: Rene Struik; QIU Ying
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Roll] FW: New Version Notification fordraft-qiu-6lowpan-
> secure-router-01
> 
> On: "What about the scenario where one has multiple trust domains (e.g.,
> when one procures sensors from
> different vendors)?"
> 
> This is the nature of our current project and implementation, using
> 802.15.4 sans full NWK layer.
> 
> Steve Childress
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rene Struik
> Sent: Wednesday, October 27, 2010 6:18 AM
> To: QIU Ying
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Roll] FW: New Version Notification
> fordraft-qiu-6lowpan-secure-router-01
> 
> Hi Qiu:
> 
> Thanks for your draft.
> 
> Your draft seems to suggest a single trust domain, where each node
> shares a secret key with the base station. What about the scenario where
> 
> one has multiple trust domains (e.g., when one procures sensors from
> different vendors)? Doesn't the security fall apart if a router gets
> compromised? What prevents an adversary from replaying past (sensor
> node, request) pairs and triggering traffic flows and key updates with
> routers this way?
> 
> Do you have a paper that provides a more formal analysis of the security
> 
> properties provided by the protocol you suggest?
> 
> Best regards, Rene
> 
> On 27/10/2010 6:22 AM, QIU Ying wrote:
> > http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt
> >
> > The title of the draft had been changed to "Lightweight Key
> Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)"
> instead of "Lightweight Secure Router Protocol" in order to make the
> work more clearly. It will be presented at ROLL WG.
> 
> >
> > Any comments are appreciated.
> >
> > Regards
> > QIU Ying

-- 
email: [email-masked]
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363