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

Yoav Nir <ynir@checkpoint.com> Wed, 31 July 2013 23:20 UTC

From: Yoav Nir <ynir@checkpoint.com>
To: "secdir@ietf.org" <secdir@ietf.org>, IESG IESG <iesg@ietf.org>, "draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org" <draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org>
Thread-Topic: SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03
Thread-Index: AQHOjkRzWPcMempN206ICOIpPpticQ==
Date: Wed, 31 Jul 2013 23:19:49 +0000
Message-ID: <332E771E-87A4-4C9F-83B7-CB96AB41D5A3@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <9C422FCAE932E2438969B53166558749@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03
Precedence: list

Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

Summary: Has issues. This document needs some more work, both on the security considerations section and general terminology.

This draft adds integrity protection and replay protection to the NHDP protocol and the OLSRv2 protocol. These protocols use the TLV format defined in RFC 5444. This draft specifies the use of the ICV and TIMESTAMP TLVs (both defined in draft-ietf-manet-rfc6622-bis), the former for integrity protection, and the latter for replay protection.

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.

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.

On to the security considerations section:
This section is generally well-written, although it might have been clearer to write the limitations along with the list of alleviated attacks. The section does cover the dependency on clock synchronization, the limited time in which replay is possible, the vulnerability to other routers who possess the same shared key, and the reliance on another key distribution and key revocation mechanism.

About the general writing:
This document contains some examples of sloppy language:
- Figure 1 shows messages being processed by "this specification". Specifications don't process messages. Hardware or software components do.
- Section 3 says that "[RFC6130] and [OLSRv2] enable extensions to recognize…". Extensions don't recognize, they're just a string of bytes. Implementations recognize things.
- Section 4 says something about "messages owned by [RFC6130] and [OLSRv2]". Again, RFCs define messages, they don't own them.
- TC is used multiple times, but never expanded.

Yoav

[secdir] SecDir Review of draft-ietf-manet-nhdp-o… Yoav Nir
Re: [secdir] SecDir Review of draft-ietf-manet-nh… Adrian Farrel
Re: [secdir] SecDir Review of draft-ietf-manet-nh… Yoav Nir