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

Yoav Nir <ynir@checkpoint.com> Fri, 02 August 2013 10:57 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A103B11E828F; Fri, 2 Aug 2013 03:57:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.478
X-Spam-Level:
X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9KEDqEXjvT0; Fri, 2 Aug 2013 03:57:13 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3183911E8251; Fri, 2 Aug 2013 03:57:12 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r72Av8Q6023835; Fri, 2 Aug 2013 13:57:08 +0300
X-CheckPoint: {51FB9084-3-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Fri, 2 Aug 2013 13:57:07 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "<adrian@olddog.co.uk>" <adrian@olddog.co.uk>
Thread-Topic: SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03
Thread-Index: AQHOjkRzWPcMempN206ICOIpPpticZl/4aaAgAGrfgCAAAIWAA==
Date: Fri, 2 Aug 2013 10:57:06 +0000
Message-ID: <2696224D-F001-490D-8D37-381CCD199920@checkpoint.com>
References: <332E771E-87A4-4C9F-83B7-CB96AB41D5A3@checkpoint.com> <CAK=bVC805v8984f3S1rbeGjhJ2U169LKMou+AfM_uTh64jvBqA@mail.gmail.com> <005201ce8f6d$fcc8ac20$f65a0460$@olddog.co.uk>
In-Reply-To: <005201ce8f6d$fcc8ac20$f65a0460$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.96]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 114f3aae9f1ac07032ddcf217b6e2e1a042259464f
Content-Type: text/plain; charset="us-ascii"
Content-ID: <BF6532807F0CCA4794F5DB95CE3942F7@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<secdir@ietf.org>" <secdir@ietf.org>, IESG <iesg@ietf.org>, Ulrich Herberg <ulrich@herberg.name>, "<draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org>" <draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org>
Subject: Re: [secdir] SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Aug 2013 10:57:24 -0000

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 <adrian@olddog.co.uk>;
 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