Subject: [Roll] Questions on draft-dvir-roll-security-extensions-00.txt

From: [email-masked]
Date: Mon, 21 Mar 2011 13:11:26 +0000

Dear BME colleagues,

I have two questions which are probably misinterpretations or otherwise 
have to do with some assumptions that I have not found explicit enough 
in the draft:

- 3.1 DIO Message Authentication
In step 3, the DODAG root authenticates the message. However, if this 
is not done using asymmetric crypto, any compromised node can propagate 
false DIO messages locally calculated based on a locally generated 
random number r2. I failed to understand how the nodes receiving these 
messages (which are in fact authenticated by the compromised node using 
a common key) can be sure that it was really the DODAG Root to generate 
them. For new nodes joining the network, we have the same problem.

- 3.2 Local Key Agreement
The definition of a time T, seems to imply that the network cannot 
accept new nodes after T. However, from the algorithm you present, I 
think that this is not the case, right? Although the nodes delete the 
preshared key after T, it is enough that each node 'u' retains Ku in 
order to derive more pairwise keys, right?

Best regards,
António

---

From: Tamás Holczer <[email-masked]>
Date: Fri, 25 Mar 2011 13:23:33 +0100

Dear Antonio,

thank you for commenting our draft. The answers can be found inline

On 2011.03.21. 14:11, [email-masked] wrote:
> In step 3, the DODAG root authenticates the message. However, if this is
> not done using asymmetric crypto, any compromised node can propagate

Possibly it is not clear from the text, that this key K is the same as
in section 3.2, meaning that it must be deleted after a small time. We
assume that it is not compromised before this safe time period. It can
be used to authenticate the first hash value received by the node. This
is not a suggested method, because it is impossible to reload the hash
chain after deleting K. This solution can be used for short or pregiven
lifetime networks. We will clarify this in the next version of the draft.

> order to derive more pairwise keys, right?

You are right, it is enough if the new (joining) node has the preshared
initial key K, and the neighbors own their key Ku.
>
> Best regards,
> António
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

Best regards,

Tamás
- -- 
Tamas Holczer
Assistant Research Fellow
Laboratory of Cryptography and System Security (CrySyS)
Budapest University of Technology and Economics (BME)
URL: http://www.crysys.hu/members/tholczer/

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Mar 2011 13:52:01 +0200

>>>>> "antonio" == antonio grilo <[email-masked]> writes:
    antonio> - 3.1 DIO Message Authentication In step 3, the DODAG root
    antonio> authenticates the message. However, if this is not done
    antonio> using asymmetric crypto, any compromised node can propagate
    antonio> false DIO messages locally calculated based on a locally
    antonio> generated random number r2. I failed to understand how the
    antonio> nodes receiving these messages (which are in fact
    antonio> authenticated by the compromised node using a common key)
    antonio> can be sure that it was really the DODAG Root to generate
    antonio> them. For new nodes joining the network, we have the same
    antonio> problem.

If there is symmetric authentication in use, then it is not possible for
a node to be sure that a real DODAG root sent out a hash chain root.

If the key K was known to be secure when the hash chain root was sent
out, then a node would continue to trust the real DODAG root, but new
ones could arrive.  More specifically, a compromise of K does not
compromise previously authenticated hash chain roots.

Asymmetric authentication solves this problem, and 3.1 reduces the
frequency that you have to do asymmetric operations quite significantly,
with the hope that this might make some use of assymetric authentication
more useful.

-- 
]       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.