Subject: [Roll] Unique shared key for the entire RPL network vs Privacy?

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 07 Sep 2010 08:52:21 +0200

RPL text often mentions a "shared key", which does not seem to depend on
the IP address of the devices to which it is dedicated - is it a single
"shared key" across the entire RPL network?

This may be an assumption about the keys which ignores privacy.  It
seems that all node in the RPL network to share the same key, proper to
a network; just as a Bluetooth PIN code is shared by all devices in a
piconet.

There are alternatives to this.  For example, a pair of IP communicating
nodes may share one key, and everybody else not able to listen to their
conversation.  This stems from a Privacy requirement.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Tue, 7 Sep 2010 08:57:43 +0200

> conversation.  This stems from a Privacy requirement.
This adds a LOT complexity to a security schema (and key generation) for a 
routing protocol and prevents using symmetric cryptography for broadcasts 
(unless you want to generate a unique "group key") for every broadcast group.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 07 Sep 2010 09:19:11 +0200

Le 07/09/2010 08:57, Henning Rogge a écrit :
>> RPL text often mentions a "shared key", which does not seem to
>> depend on the IP address of the devices to which it is dedicated -
>>  is it a single "shared key" across the entire RPL network?
>>
>> seems that all node in the RPL network to share the same key,
>> proper to a network; just as a Bluetooth PIN code is shared by all
>>  devices in a piconet.
>>
>> There are alternatives to this.  For example, a pair of IP
>> communicating nodes may share one key, and everybody else not able
>>  to listen to their conversation.  This stems from a Privacy
>> requirement.
>
> This adds a LOT complexity to a security schema (and key generation)
>  for a routing protocol and prevents using symmetric cryptography for
>  broadcasts (unless you want to generate a unique "group key") for
> every broadcast group.

Hmmm... it is relatively straightforward to use an IPsec
Security Association and each node to keep a shared per-destination key
(manually installed) (shared between two nodes only).

The only issue may be that of the memory size to keep a key per dst.  To
how many nodes would that scale.  Would this memory be worth theprivacy
it affords, and the numerous key generation messages it avoids.

Secure group communications with dynamically generated keys are indeed
harder to achieve - a LOT more complexity and more messages exchanged;
but shared key per-network as RPL puts it - symmetric crypto for
broadcast addresses as you put it - is a wrong solution.  It has many
security risks, including privacy.  This puts the entire network at
the mercy of a single malicious node.

This is hardly acceptable.

(I do agree with what you seem to imply that the use of symmetric crypto
for a multicast group (not broadcast) would indeed be very good here.
But I don't think RPL security offers it.)

Alex

---

From: Andy Zhou <[email-masked]>
Date: Tue, 7 Sep 2010 20:44:22 +0800

It may depend on what level of security you want. In some case, the public
shared key is enough to provide the security  and privacy.
However, it will waste a lot of resource if every node shares a pair-key. It
also a big challenge  to build the pair wise key between the nodes.

On Tue, Sep 7, 2010 at 3:19 PM, Alexandru Petrescu <
[email-masked]> wrote:

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

-- 
Thanks & Best Wishes

Zhou, Yaowei (Andy)

MSN: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Sep 2010 08:37:00 +0200

Le 07/09/2010 14:44, Andy Zhou a écrit :
> It may depend on what level of security you want. In some case, the
> public shared key is enough to provide the security  and privacy.

Hi... would you please mention one such case, with an existing IP
protocol?  I am personally not aware of any IP protocol using a common
shared key between more than two communication ends.

> However, it will waste a lot of resource if every node shares a
> pair-key.

I agree using a key per pair of communicating nodes may need more memory
in a node than if only one key were used for the entire network.  One
particular node would store 1 key if there are two nodes in the network,
and n-1 keys if there are n nodes.

With a 64bit key and a 100 node network, this would be 800Kbyte memory
requirement to store keys.  I don't think it is very much.

> It also a big challenge  to build the pair wise key between the
> nodes.

I agree.  Dynamically generating keys on a per-pair basis may require
many messages exchanged - each node would have to develop a security
relationship with each other node.

However, I assume in a first step to manually configure keys, or to
hardcode keys in devices of a deployed network.

There is one additional point worth mentioning: it seems an RPL network
is relatively static, with devices not moving much.  It seems one
particular node would communicate directly with only a few other nodes
(DAG pictures show a max of 2 or 3).  This would involve only a few keys
stored.

Alex
>
>
> On Tue, Sep 7, 2010 at 3:19 PM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> RPL text often mentions a "shared key", which does not seem to depend
> on the IP address of the devices to which it is dedicated - is it a
> single "shared key" across the entire RPL network?
>
> seems that all node in the RPL network to share the same key, proper
> to a network; just as a Bluetooth PIN code is shared by all devices
> in a piconet.
>
> communicating nodes may share one key, and everybody else not able to
> listen to their conversation.  This stems from a Privacy
> requirement.
>
>
> Hmmm... it is relatively straightforward to use an IPsec Security
> Association and each node to keep a shared per-destination key
> The only issue may be that of the memory size to keep a key per dst.
> To how many nodes would that scale.  Would this memory be worth
> theprivacy it affords, and the numerous key generation messages it
> avoids.
>
> Secure group communications with dynamically generated keys are
> indeed harder to achieve - a LOT more complexity and more messages
> exchanged; but shared key per-network as RPL puts it - symmetric
> crypto for broadcast addresses as you put it - is a wrong solution.
> It has many security risks, including privacy.  This puts the entire
> network at the mercy of a single malicious node.
>
> (I do agree with what you seem to imply that the use of symmetric
> crypto for a multicast group (not broadcast) would indeed be very
> good here. But I don't think RPL security offers it.)
>
> Alex
>
>
> Henning Rogge
>
>
>
> _______________________________________________ Roll mailing list
> [email-masked] <mailto:[email-masked]>
> -- Thanks & Best Wishes
> MSN: [email-masked] <mailto:[email-masked]>

---

From: Henning Rogge <[email-masked]>
Date: Wed, 8 Sep 2010 08:46:29 +0200

> requirement to store keys.  I don't think it is very much.
You mean 800 bytes.

It's more a problem how to create the keys, especially when you extend an 
existing network and if you need to support rekeying and revokation of keys.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Sep 2010 09:01:03 +0200

Le 08/09/2010 08:46, Henning Rogge a écrit :
>> With a 64bit key and a 100 node network, this would be 800Kbyte
>> memory requirement to store keys.  I don't think it is very much.
>
> You mean 800 bytes.

Right, thanks.  800bytes is even less than 800kbyte, which is better news.

> It's more a problem how to create the keys, especially when you
> extend an existing network and if you need to support rekeying and
> revokation of keys.

I agree fully: dynamically generating these keys, rekeying upon network
expansion, key revocation - are all much harder to do when per-pair keys
are used (instead of a single per-network key).

The dynamic generation of a single key for the entire network, its
revocation and regeneration - is also difficult to do.

However, I think it is good to clarify whether we look at this in a
perspective where - now - the dynamic key generation is out of scope and
only manual configuration, administrative key provisioning, hardcoded
keys, preinstalled keys are in scope.

Alex

---

From: "Akyol, Bora A" <[email-masked]>
Date: Wed, 8 Sep 2010 08:57:55 -0700

Do you mean GDOI does not fit the bill?

http://www.ietf.org/rfc/rfc3547.txt

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Sep 2010 18:16:04 +0200

That GDOI is for group communications of Security Associations of IPsec,
right?  It could probably work for RPL.  It would need SAs to work,
which I could agree to.

I wonder which other protocol uses these group keys and SAs. (like for
example is DHCP protected by GDOI?  Or is some proprietary video
streaming protocol protected by GDOI?).

Alex

Le 08/09/2010 17:57, Akyol, Bora A a écrit :
>>> It may depend on what level of security you want. In some case,
>>> the public shared key is enough to provide the security  and
>>> privacy.
>>
>> protocol?  I am personally not aware of any IP protocol using a
>> common shared key between more than two communication ends.
>
>

---

From: "Akyol, Bora A" <[email-masked]>
Date: Wed, 8 Sep 2010 09:19:22 -0700

GDOI establishes group-wise keys that can be used for multi-party communication.
This way you will not need N^2 SAs in storage and the shared key can be rekeyed quickly.

I cc-d Brian Weis to comment further on this as he is the expert on this.

Regards

Bora

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Sep 2010 13:09:30 -0400

>>>>> "Alexandru" == Alexandru Petrescu <[email-masked]> writes:
    >> the public shared key is enough to provide the security and

    Alexandru> Hi... would you please mention one such case, with an
    Alexandru> existing IP protocol?  I am personally not aware of any
    Alexandru> IP protocol using a common shared key between more than
    Alexandru> two communication ends.

multicast IPsec.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 08 Sep 2010 22:43:51 +0200

Le 08/09/2010 19:09, Michael Richardson a écrit :
>
>>>>>> "Alexandru" == Alexandru
>>>>>> Petrescu<[email-masked]>  writes:

YEs that is good, as well as the GDOI RFC.  Reads IPsec and I agree with it.

(I could explain why people may think I don't understand IPsec: maybe
  the alea of email conversation, or anything you prefer; but the
  Security Considerations section being silent of IPsec really itches.)

Alex