Re: [secdir] SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03

[Yoav Nir <[e-mail]>]

With the proposed changes, including a statement that someone is working on key distribution, I'm fine.

On Aug 2, 2013, at 12:49 PM, Adrian Farrel <[e-mail]>
 wrote:

> Hello all,
> 
>>> I am not convinced by the suitability of a POSIX timestamp (32-bits with 1-
>>> second resolution) to protect in general against replay. Within the same
> second, a
>>> packet can be replayed. I don't know enough about the NHDP and OLSRv2
>>> protocols to say whether this is a problem. Its usefulness depends on
>>> synchronized clocks, but this is well explained in the document, both in the
>>> security considerations, and in the regular sections where timestamp is
>>> mentioned.
>> 
>> UH> In the majority of MANET use cases that we are aware of, time
>> synchronization much below one second is not possible. Also, keep in
>> mind that the MANET routers are not the typical huge backbone router,
>> but rather very constrained devices with CPUs of only a few Megahertz
>> and memory of megabytes or even just kilobytes. The precision of the
>> clocks on such devices will consequently not be of the same
>> granularity as on the big Internet routers. Note that, as we explained
>> in the previous comment, only the *implementation* of this framework
>> is mandatory, not the *usage*. In use cases with higher requirements
>> (and with routers of appropriate capability), higher granularity
>> timestamps may be used (e.g., for military use cases).
>> UH> In addition, when looking at the default message intervals and
>> validity times (minimum 2 seconds) anyone repeating the message within
>> a second is (bandwidth occupation aside) doing you a favor, not a
>> harm. If going into details, the use of RFC5148 jitter can cause a
>> message to take that long or more to traverse the network. In fact
>> even in a perfectly synchronized network, with fine granularity times,
>> the TC maximum delay would probably be greater than 1 second. (Shorter
>> for HELLO messages.)
> 
> Yes, this seems right.
> 
> This is good text and helps explain a lot about the operation of the protocols
> in environments that need to be secured. It also can be used to highlight the
> small vulnerability of replay within the timestamp granularity.
> 
> Could you polish it and add it to the draft?
> 
>>> The biggest hole in this specification is that it is silent about key
> distribution
>>> ("This framework does not...Specify how to distribute cryptographic material
>>> (shared secret key(s))." This is the real hard problem, and the draft doesn't
> even
>>> reference some other specification that does have a suitable key distribution
>>> protocol. You can't do HMAC without key distribution being in place.
>> 
>> UH> We have intensely discussed this with Stephen Farrel, who agreed
>> with this approach (and which actually triggered this particular
>> draft). The relevant text why we do not specify a key management
>> mechanism, can be found in the "Security Considerations" section in
>> OLSRv2. We can add a pointer to that text in the nhdp-olsrv2-sec
>> draft.
> 
> That pointer would be a great idea.
> 
> I suspect that we must take small steps towards the complete security picture.
> That the key distribution is still an open issue  is at last exposed here.
> 
> Is there enough text describing how deployed systems handle this issue? I
> suspect that, since many MANETs are military, there is an operational solution
> to this problem (probably involving men with guns and RSA tokens :-)
> 
>>> On to the security considerations section:
> [snip]
>> UH> Very good catches. We will fix them.
> 
> Ulrich and authors...
> Last call expires on 8/14 and the document is currently set for IESG review on
> 8/15
> If the resolution of these comments can be agreed with Yoav, no more substantive
> comments come in, and a new version is ready to post on 8/14 we can go ahead on
> the current schedule.
> If you think you need more time, I will move the document out to a later IESG
> telechat.
> 
> Adrian
> 
> 
> Email secured by Check Point