Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 1 Aug 2012 16:10:01 +0000

I think this is probably the right thing to do, there are sufficient overlaps in how the security model suggested in 5444 and detailed in 6622 might be applied to different MANET protocols (NHDP, OLSRv2, SMF, potentially DYMO/AODVv2) that some common advice is I think appropriate. In particular note that 6622 is a functional document, not a rationale for use.

In particular this could consider the different characteristics of packet/message signatures/encryption and that there may be a place for either, or even both. There may be issues as to what extent to keep it abstract, and to what extent to give specific examples, but that's what the usual discussion process is for. To do a good job, this would need to consider some broader issues. For example with a single shared secret key, is there any gain in message over packet signatures? With separate keying (but what are the scalability issues? - some approaches are better than others) message signatures are probably  better, but still not without possible flaws. While 6622 retains the option to use quite differently key managed signature methods (in particular) neither packet nor message signature are the definitively right answer.

--
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]<mailto:[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

From: Rick Taylor [mailto:[email-masked]]
Sent: 31 July 2012 10:49
To: Teco Boot; Ulrich Herberg
Cc: Dearlove, Christopher (UK); manet; Thomas Heide Clausen
Subject: RE: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf> on how to deal with suspicious emails.
For those of us who missed the relevant parts of the mailing discussion, what was the consensus on general ICV verification for RFC5444 packets?

I am with Teco, a separate manet-rfc5444-sec document would be very useful.

Rick Taylor
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Teco Boot
Sent: 31 July 2012 07:00
To: Ulrich Herberg
Cc: Dearlove, Christopher (UK); manet; Thomas Heide Clausen
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

I provided feedback to authors before: I strongly prefer having a document on MANET packet security before we go into further details, such as manet-nhdp-sec. Another concern is that NHDP messages are extended by other protocols.

Teco

Op 13 jul. 2012, om 18:55 heeft Ulrich Herberg het volgende geschreven:

Chris,
On Fri, Jul 13, 2012 at 5:52 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
This partly depends on what your planned document structure is, Ulrich just mentioned the possibility of a generic 5444 document. I'm actually not sure that wouldn't be more relevant, as it is hard to actually separate these things.

My concern is, if you want to specify packet signing in the NHDP-sec document, that NHDP itself would never see the packet. The RFC5444 multiplexing would see a HELLO message in the packet and send it to NHDP (which can use the mechanisms specified in NHDP-sec to reject or accept the message). I think that a packet signer/verifier is tied to the RFC5444 parser itself, which would accept or reject the whole packet. So in my view, it would actually be much easier to separate it into an additional draft, rather than combining it with NHDP.
Moreover, protocols that do not use NHDP but use RFC5444 would probably like to use packet ICV verification as well, but they don't need all the NHDP part.

But I think this is jumping in with solutions before considering a threat model. Let's suppose that we have hardware that (a) stores key materials in secure tamperproof storage,  (b) doesn't make mistakes, and (c) we use a signature method that's cryptographically infeasible to break. Then in this case (not uniquely) packet signatures actually provide as much security as message signatures.

If you assume a transitive trust model. If a router receives a TC message (unsigned) in a correctly signed packet, the receiving router can be sure that the TC has not been modified after transmission by the previous hop. It has no information what happened before that. But I agree that for certain deployments that may be enough.

Of course I can also think of threat models that do favour message signatures. But this is exactly like the choice of signature methods, which is not mandated because different threats require different solutions.

Right. I am absolutely in favor of specifying packet ICV handling. The only question for me is where to do that.

The same is true of packet and message signatures. Each (and indeed the third option of both) should be allowed, we should not have a document that prefers one above the other

Correct.

except following a security analysis - which is not on offer.

Yes. There was some emails about the nhdp-sec-threats document by Jiazi several months ago, but there was not much activity on the mailing list.. Do you think that that document should contain such an analysis?

Best regards
Ulrich

--
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<tel:%2B44%201245%20242194> |  Fax: +44 1245 242124<tel:%2B44%201245%20242124>
[email-masked]<mailto:[email-masked]> | http://www.baesystems.com<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

From: Thomas Heide Clausen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 13 July 2012 13:36
To: Dearlove, Christopher (UK)
Cc: Ulrich Herberg; manet

Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf> on how to deal with suspicious emails.
Chris,

I figured that you wouldn't agree.

I agree, of course, with your observation that none of the signature models yields end-to-end security, but I don't think that that's the issue here.

Personally, I do not see packet ICVs as being appropriate for neither NHDP nor OLSRv2 - at least, not for the uses that I see/have, but I am not saying that they do not exist. I could make an argument that a packet ICV would have to be validated before knowing that a HELLO message was delivered to an NHDP instance, and that the validation might be based on different principles (or, even layers) for packet/messages.

I see what you say about protecting packet sequence numbers by way of a packet-level ICV, but I would argue that:

            o          As packet sequence numbers are generated "outside" NHDP, and are incremented for all
                        packets (not just those with HELLOs), specifying the validation of a packet-level ICV in NHDP would
                        be inappropriate (as in: potentially conflicting with another mechanism)

            o          Whatever mechanism would provide "packet sequence number statistics" to NHDP (such as the
                        demultiplexer) would want to be the entity doing that packet-level ICV validation, in part as
                        I would _suspect_ that inability to validate a packet-level ICV should cause the whole packet
                        with all contained messages to be dropped.

That said, with reference to the I-D, I think I speak for the authors when saying that we're welcoming a suggestion that would address the issue that you raise?

Best,

Thomas

On Jul 13, 2012, at 14:18 , Dearlove, Christopher (UK) wrote:

I don't agree. Note that if all you are running is NHDP, then signing packets is more secure than signing messages, as you get to cover the packet sequence number as well.
What I think is wrong is to suggest that the only correct way to protect NHDP is to sign HELLO messages. Whether by inclusion or external reference, signing packets should be also an option.

I'll take that further to OLSrv2 as well. Now there signing messages vs signing packets has advantages to the former. But signing packets also has advantages of simplicity and covering packet header. It is incidentally not correct to say that signing TC messages provides end to end security. It's actually last-bit-one-from-end to end, and still relies on a form of transitive trust. Packet based signatures rely on a greater degree of transitive trust. There is a difference in threat models and vulnerabilities, and that may matter, but it's not (unfortunately) as simple as one being end to end and thus avoiding transitivity issues.

--
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<tel:%2B44%201245%20242194> |  Fax: +44 1245 242124<tel:%2B44%201245%20242124>
[email-masked]<mailto:[email-masked]> | http://www.baesystems.com<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

From: Thomas Heide Clausen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 12 July 2012 23:09
To: Ulrich Herberg
Cc: Dearlove, Christopher (UK); manet
Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf> on how to deal with suspicious emails.
I agree with Ulrich.

Note that this is all about "messages" in as much as NHDP is concerned.

1) NHDP specifies something akin to "an implementation may recognize additional reasons for considering a HELLO message invalid for processing"; this I-D specifies such an additional reason, by way of a TLV in HELLO messages.

2) NHDP "owns" HELLO messages, and therefore gets first dip on an incoming HELLO message post-demultiplication. Including the ICV Message TLV in HELLO messages therefore makes sense.

Ad 1), I note that this I-D is intended to exactly plug in at that place in 6130.

Thomas

--
Thomas Heide Clausen
http://www.thomasclausen.org/

"Any simple problem can be made insoluble if enough meetings are held to
 discuss it."
   -- Mitchell's Law of Committees

On 12 Jul 2012, at 22:54, Ulrich Herberg <[email-masked]<mailto:[email-masked]>> wrote:
The document specifies signing/verifying NHDP messages. RFC5444 packets are not specific to NHDP, and therefore should IMO not be discussed in a document entitled "Using Integrity Check Values and Timestamps For Router Admittance in NHDP". That's why I suggested to handle this in an additional document for RFC5444 packets.

Regards
Ulrich
On Thu, Jul 12, 2012 at 1:39 PM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ulrich,

I am not expert in security issues, but IMHO, I agree with Chris to
recommend to include in draft-02 both securing messages and packets
(in general for packets), so the document should specify NHDP messages
and MANET packets [AB]. The reasons are first, because NHDP is a MANET
Interface protocol between neighbor routers. secondly it uses RFC5444
format that the future MANET routers will use. Third, NHDP uses
RFC5444 which was specified for information exchange between MANET
routers.

[AB] http://tools.ietf.org/id/draft-baryun-manet-terminology-00.txt

Regards
Abdussalam
=======

On Thu, Jul 12, 2012 at 9:08 PM, Ulrich Herberg <ulrich at herberg.name<http://herberg.name/>> wrote:
> Dear Chris,
>
> I agree that we need to provide similar mechanisms as in NHDP-sec for TC
> messages as well. I don't think that signing the packet is enough, since
> that does not provide end-to-end security. Instead, I suggest to submit a
> draft OLSRv2-sec that specifies how to calculate ICVs for TC messages, and
> how to handle these messages in OLSRv2.
>
> However, I believe that it would be beneficial for certain applications to
> also be able to sign/verify packets. But I don't think that the NHDP-sec
> document is the right place for this, since other applications (e.g. DYMO)
> may not use HELLO messages at all, but would still like to sign/verify
> packets.
> Maybe it would be better to have an extra document "packet-sec" which
> specifies how to sign/verify packets?
>
> Best
> Ulrich
>
>
> On Wed, May 30, 2012 at 6:21 AM, Dearlove, Christopher (UK)
> <Chris.Dearlove at baesystems.com<http://baesystems.com/>> wrote:
>>
>> (Sending again, to sort out the formatting problem with the last attempt.)
>>
>> As I read it, this draft is proposing using the RFC 6622 mechanism to sign
>> HELLO messages. RFC 6622 actually allows for signing packets as well as
>> signing messages (both, either, or neither to be used as required). There
>> isn't a major difference when considering HELLO messages, as few if any
>> packets will contain more than one HELLO message, and the packet and the
>> message will be signed by the same party.
>>
>> However NHDP doesn't exist in a vacuum, in particular it is used by
>> OLSRv2. Any security mechanism that is described in what will be an RFC for
>> NHDP must also be what's right for NHDP as used by OLSRv2. OLSRv2 also has
>> TC messages to consider, and they don't satisfy the points noted above (on
>> number or on who signs them). And one option for OLSRv2 is to sign all
>> packets, not messages. This can be a sensible decision there, for several
>> reasons, in some real circumstances.
>>
>> Consequently, I don't believe that this draft should describe only signing
>> HELLO messages as the correct thing to do, that it should also allow signing
>> packets as an equal status option. If someone wants to raise the possibility
>> of signing (possibly by methods with different properties) both at the
>> message and packet level, that may have its use cases too.
>>
>> Incidentally, even within the limited framework of just NHDP, it is
>> possible that packets need protection. If an NHDP implementation chooses to
>> use packet sequence number as part of its link quality mechanism, as it may,
>> then an unprotected packet header is a vulnerability.
>>
>> (For the sake of completeness, RFC 6622 also allows address block
>> signatures. I don't have a reason to suggest using this within NHDP or
>> OLSRv2.)
>>
>> --
>> 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<tel:%2B44%201245%20242194> |  Fax: +44 1245 242124<tel:%2B44%201245%20242124>
>> chris.dearlove at baesystems.com<http://baesystems.com/> | http://www.baesystems.com<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
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Mobile Ad-hoc Networks Working
>> Group of the IETF.
>>
>>         Title           : Using Integrity Check Values and Timestamps For
>> Router Admittance in NHDP
>>         Author(s)       : Ulrich Herberg
>>                           Thomas Heide Clausen
>>         Filename        : draft-ietf-manet-nhdp-sec-02.txt
>>         Pages           : 12
>>         Date            : 2012-05-29
>>
>>    This document specifies a security extension to the MANET
>>    Neighborhood Discovery Protocol (NHDP).  The extension introduces the
>>    use of Integrity Check Values (ICVs) and Timestamps in HELLO messages
>>    in order to provide a router admittance mechanism, and therefore to
>>    counter a selection of security threats to NHDP.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-02.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-02.txt
>>
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/
>>
>> _______________________________________________
>> manet mailing list
>> manet at ietf.org<http://ietf.org/>
>> https://www.ietf.org/mailman/listinfo/manet
>>
>>
>> ********************************************************************
>> 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.
>> ********************************************************************
>>
>

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet