[MSEC] Review of draft-ietf-msec-tesla-for-alc-norm-05.txt

[Ramu Panayappan <pramu at cmu.edu>]

Hi,

Brian had asked the security group at CMU, to have a quick look at the  
draft to check if there are any issues with the way TESLA is being used.

At the outset, there are no apparent issues with the way it has been  
used. However, I have a few comments (see below) in form of questions/ 
suggestions to ascertain that my conclusions are correct.  A couple of  
nits are also noted. Feel free to ignore those.

Thanks
Ramu


--------------


2.3.2 (Nit)
Use of GPS as secure time source is a issue almost always as GPS  
timings signals can be spoofed easily. Methods like "dead reckoning"  
may be used to circumvent spurious GPS signals to certain extent. It  
may be worthwhile to add a "caution" of not using this method for  
synchronization.

3.3.1 (Nit)
What is the F' function? (probably some reference to later section  
might help)

3.3.2 (Assumption)

Bootstrap Message signing:  Assumes that the receiver obtains the  
verifying key corresponding to the signing key K of the sender by some  
means. May be add this as a pre-requisite for receiver side in Section  
4.

3.3.3 (Question & suggestion)

What is the reasoning behind including  the digital signature (e.g.,  
of a bootstrap message) and the MAC fields (e.g., of an authentication  
tag) while computing the Weak group MAC Tag. Since this is just a  
preliminary check the group MAC tag can be computed devoid of it and  
thus helping the sender to parallize the computations of group MAC tag  
and computing authentication tags on the packet.

(As a side note given that groups change dynamically and the group  
keys are rekeyed periodically it might be a implementation hurdle to  
always tag the correct group MAC tag. This might require accepting  
group MAC based on older group keys too. May be it is worth cautioning  
this and cite it as "out of scope").


6. Security Considerations: (Suggestion)

In addition to the correct calculation of D-t the choice of time  
intervals is critical for TESLA to function correctly. It should be  
noted that (d * time interval) should b greater than the propagation  
delay to reach from sender to receiver. (Not sure whether this is  
already taken care of by the nuances of the existing protocols).


6.1 DoS (Suggestion)

In addition to those mentioned,
DoS is possible by bombarding with spurious bootstrap packets or  
bombarding with synchronization packets. Recommendations for these may  
also be helpful.

6.2.2 Impact of replay attacks on NORM (Question)

Does the sequence number check happen before the TELSA processing?




_______________________________________________
MSEC mailing list
MSEC at ietf.org
https://www.ietf.org/mailman/listinfo/msec