Subject: [secdir] secdir re-review of draft-ietf-manet-olsrv2-16

From: Tom Yu <[email-masked]>
Date: Wed, 10 Oct 2012 18:57:59 -0400

I have re-reviewed this document, primarily by examining the changes
from the -15 version.  The authors have added references to RFC 6622,
which specifies some protocol elements that could in principle provide
any needed security properties.  These changes relegate most of my
previous concerns to RFC 6622.

Unfortunately, most of my concerns still apply to RFC 6622, which has
already been approved as Standards Track.  I am undecided as to
whether the Area Directors should treat my concerns with RFC 6622 as
reasons to block this document.  It does appear to me that a number of
security aspects of this protocol suite are deferred to possible
future work.  This may even be appropriate, depending on the risk
profile of the likely deployments.

It is not clear to me that RFC 6622 is implementable as written (are
there multiple existing implementations?), because it seems that it
leaves a number of things underspecified.  As an example, although
future specifications that register ICV (integrity check value)
algorithms might resolve these ambiguities, RFC 6622 appears to make
an underlying assumption that it is possible to decompose ICVs as:

      ICV-value = cryptographic-function(hash-function(content))

which is not in general possible.  (HMAC is but one example of how
this assumption is invalid.)  In some cases where it is possible to
make such a decomposition, such as encrypting a hash value using a
symmetric cipher, RFC 6622 does not specify necessary parameters such
as the cipher mode.  (Also, producing a message authentication code by
encrypting a hash value using a symmetric cipher can lead to
forgeries.)

RFC 6622 leaves key management issues unresolved.

In the next to last paragraph of Section 23.2, the word "valid" should
probably be "invalid":

   Failure to
   verify an ICV included can be used as a reason to reject an incoming
   message or packet as "valid", according to Section 12.1 of [RFC6130]

should be

   Failure to
   verify an ICV included can be used as a reason to reject an incoming
   message or packet as "invalid", according to Section 12.1 of [RFC6130]

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 11 Oct 2012 09:02:14 +0000

Note, this is a personal comment, not the collected opinions of the authors.

Thanks you for re-reviewing.

With regard to the final correction, I think neither version is good. I think the original meant to say reject it as having the status valid, the replacement is saying reject it, it has the status invalid. I think a third wording (I'm not proposing a candidate here) would be better.

With regard to RFC 6622, I should note that I'm not an author of it. But from the perspective of OLSRv2, I can only comment that it was accepted by the IESG. Stressing the speaking personally, I would be happy to reference, or not reference, it.

There are good reasons why security functionality is separated out, essentially because (as is commented on in the security considerations section) there are a wide range of circumstances that ad hoc networks are used in. To name but two, there are obviously different requirements (including key management approaches) in a community Wi-Fi network, and a military application such as a group of soldiers. It would be, for the people who will use the protocol, wrong to even consider putting a "one size fits all" mechanism for signatures, timestamps, or (probably especially) key management into the routing protocol.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Tom Yu [mailto:[email-masked]] 
Sent: 10 October 2012 23:58
To: [email-masked]; [email-masked]; [email-masked]
Subject: secdir re-review of draft-ietf-manet-olsrv2-16

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

   Failure to

should be

   Failure to

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Tom Yu <[email-masked]>
Date: Thu, 11 Oct 2012 11:13:59 -0400

> With regard to the final correction, I think neither version is good. I think the original meant to say reject it as having the status valid, the replacement is saying reject it, it has the status…

RFC 6130 Section 12.1 (which this document references) describes when
a message is invalid, so I think "invalid" is the correct word to use
in that sentence in Section 23.2 of this document.

> With regard to RFC 6622, I should note that I'm not an author of it. But from the perspective of OLSRv2, I can only comment that it was accepted by the IESG. Stressing the speaking personally, I wo…

RFC 6622 basically provides building blocks for authenticating MANET
messages.  I think it is not feasible to implement RFC 6622 in an
interoperable way, but even if it were, I think it remains the
responsibility of a document referencing RFC 6622 to describe how to
use those building blocks to construct an appropriate authentication
scheme.

I find that this document doesn't provide enough specification detail
to build a plausible interoperable authentication scheme for the
OLSRv2 protocol out of RFC 6622 building blocks.  If anything, it
seems to defer such specification of such authentication schemes to
future work ("security extensions"), but it refers to no specific work
in progress.  Is any such work in progress or planned?  If there are
no such plans, perhaps it is best to explicitly state that (with
justifications), and let the IESG decide on those grounds.

> There are good reasons why security functionality is separated out, essentially because (as is commented on in the security considerations section) there are a wide range of circumstances that ad h…

I agree that there can be good reasons to separate out the security
capabilities of a protocol, but it should be possible to implement
something that provides a reasonable level of security.  For a routing
protocol, strong authentication seems desirable for most reasonable
deployment scenarios.  Confidentiality seems likely to be less
important for a routing protocol, except for specialized situations.
(I imagine that a combat deployment would be one situation where
revealing topology information about a wireless network could put
personnel at an elevated risk of physical attack by leaking
information about their physical locations.)

This document appears to recommend message authentication in Section
23.2, but it doesn't specify how to determine which cryptographic key
protects what message, or how protocol participants manage those keys.
It also doesn't specify which messages should be authenticated using
public key versus shared key cryptography.

Do you envision that an entire MANET shares a single symmetric key?
If so, how would operators provision this key to routers?  Is this a
reasonable risk in envisioned deployment scenarios?  What if one
router is compromised?  etc.

Although allowing alternative security mechanisms can be beneficial, I
think it's important to specify at least one, so that it is clear that
the architecture can support at least one mechanism that has the
desired security properties for the protocol.  The specification of
such a "proof of concept" security mechanism need not be in this
document, but it should be somewhere.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 11 Oct 2012 16:16:40 +0000

Tom

I should again note that this is personal, not the collective view of the authors.

Is there work, yes. Is it all public, no.

A single shared secret key is, as you indicate, a possibility. It is that used in (not OLSRv2) IEEE 802.11s I believe. Key management would however have to be out of band, typically before deployment. (Whatever you do, something has to be done before deployment.) I can point to a non-shared secret key approach outlined in
http://ftp.rta.nato.int/public/PubFullText/RTO/MP/RTO-MP-IST-092/MP-IST-092-21.doc (which pre-dates RFC 6622). I am not suggesting that as more than an example.

I remain of the opinion that the approach separating the two is the correct one. I can assure you that does not mean I - or anyone else I know doing serious work - will be ignoring the subject.

Christopher