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

["Dearlove, Christopher (UK)" <[e-mail]>]

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

-- 
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: [phone] |  Fax: [phone]
[e-mail] | 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:[e-mail]] 
Sent: 11 October 2012 16:14
To: Dearlove, Christopher (UK)
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: 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.
--------------------------------------------------------

"Dearlove, Christopher (UK)" <[e-mail]> writes:

> 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.

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 would be happy to reference, or not reference, it.

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 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.

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.


********************************************************************
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.
********************************************************************