Subject: [manet] Security drafts

From: Ulrich Herberg <[email-masked]>
Date: Thu, 12 Nov 2009 14:43:32 +0900

Hi,

as mentioned during my presentation of security extensions to packetbb
and NHDP, here are my drafts:

http://tools.ietf.org/html/draft-herberg-manet-packetbb-sec-02
http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-threats-00.txt
http://tools.ietf.org/html/draft-herberg-manet-nhdp-sec-00

Feel free to read them and give me comments.

Thanks
Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 13 Nov 2009 09:45:12 +0900

There is a list of DYMO implementations on http://ianchak.com/dymo/
6 versions are public. EK-DYMO seems to be private or dead.

http://http//www7.informatik.uni-erlangen.de/~sommer/omnet/ 
  should be:
http://www7.informatik.uni-erlangen.de/~sommer/omnet/

Question: are these updated to recent I-D version?

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 16 Nov 2009 21:17:32 +0100

Hi Ulrich,

I'll comment on sec-threats first. This would line out what needs
to be done.

At first, I would like to distinguish networks that have L2 protection 
and those who have not. For the firsts, we could skip the whole thing.

Then, we want to know what to protect, and against who. Let's say we
have the good guys and the bad guys. The question is, do the bad guys
think the good guys are the bad guys? In other words, are there
multiple groups on the same medium? Do we want to separate those
with crypto? Or use some kind of identifier?

After more analysis of threats, I expect a demand for protecting packets,
not messages. Messages are updated along the path, only by the good guys.
For OLSR, there is only the hop-count and hop-limit being updated. For
DYMO, there is a lot more. Who knows what future brings.

Regards, Teco.

>-----Oorspronkelijk bericht-----
>Van: [email-masked] [mailto:[email-masked]] Namens
>Ulrich Herberg
>Verzonden: donderdag 12 november 2009 6:44
>Aan: [email-masked]
>Onderwerp: [manet] Security drafts
>
>Hi,
>
>_______________________________________________
>manet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/manet

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 16 Nov 2009 21:51:28 +0100

Hi Teco,

thanks for your comments.

> and those who have not. For the firsts, we could skip the whole thing.

I disagree. L2 protection does not guarantee end-to-end
authentication. Consider an example where a router A receives a
forwarded TC (originator is router C) message from router B. If only
L2 security is used, router  A has no means to be sure that the
message really originates from C (because e.g. it does not know
whether there is an L2 protection between B and C).
But I agree with you that it could be worth mentioning L2 protection
in the draft, possibly explaining why it does not solve all problems
(notably end-to-end security).

> with crypto? Or use some kind of identifier?

First, keep in mind that in my framework the assumption is:
good guy == has a valid key to sign/validate messages
bad guy == does not have such a key

So, if there are some routers in a MANET that do not possess the right
key ("bad guy"), they are not able to sign messages correctly. Thus,
all HELLO/TC messages they send will be ignored by the "good guys".
Another issue is that several signatures can be added to a message in
the current specification. One thing I need to think about more is
what happens if part of these signatures are correct, and another part
is incorrect (or cannot be validated because the receiving router of
such a message does not have a valid key or does not know the
signature algorithm). Do we want to to enforce that _all_ signatures
must be valid, or is it sufficient that at least one signature is
valid? Or should we limit the number of signatures to one?

> not messages.

That would be like an L2 protection. Indeed, as an additional measure
that could be interesting to provide.

> Messages are updated along the path, only by the good guys.

Yes, as mentioned in the slides, I will have a closer look into DYMO
in order to understand the necessities of protecting DYMO.

Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 16 Nov 2009 22:18:12 +0100

Hi Ulrich,

I ask for keeping things simple.

I don't believe in end-to-end security. Why are relayed messages
by bad guys interesting? Why a security mechanism, far more complex
than all what exists today, without a request for it?

One of the principles in security space is checking identity before
validating the authentication / integrity hash. Maybe the other node
is just member of another group. Is this principle history?

Teco.

>Van: Ulrich Herberg [mailto:[email-masked]]
>Verzonden: maandag 16 november 2009 21:51
>Aan: Teco Boot
>CC: [email-masked]
>Onderwerp: Re: [manet] Security drafts
>
>Hi Teco,
>

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 17 Nov 2009 09:59:54 +0100

Hi Teco,

> I ask for keeping things simple.

I think that my framework is very simple. But please, if you find any
possible simplifications in the framework (while preserving the same
security), point them out to me.

> I don't believe in end-to-end security.

What about IPsec, TLS, SSL, SSH? They are all end-to-end and widely
used. And coming back to your first comment, I believe that IPsec is
far more complicated than my proposed framework.

> Why are relayed messages
> by bad guys interesting?

Because if you do not have end-to-end security, you don't know whether
this message comes from a bad guy or not. The most you can say is that
the last hop (i.e. the router that relays a message) is a "good guy".

> Why a security mechanism, far more complex

Why is it far more complex? I assume that if you add up the number of
pages of all IPsec RFCs, you would agree that my framework is not very
complex. (I know, IPsec serves another purpose... just for showing you
that my framework is not that complex).
Talking about "a request for it". I have heard from several members of
the WG that they are interested in such security. As soon as MANET
routing protocols will be used outside of testbeds, I think that we
need some security.

> is just member of another group. Is this principle history?

No, it is not. This is exactly what my framework does. The identity of
a message originator is checked first, before the integrity of the
message is verified. Maybe I should that make clearer in the text,
though. I will soon release a new version of the drafts, including all
comments that I get from the mailing list.

Thanks
Ulrich

---

From: Henning Rogge <[email-masked]>
Date: Tue, 17 Nov 2009 10:12:33 +0100

> far more complicated than my proposed framework.
I think we must differentiate between "internal" and "external" attackers.

External attackers are much easier to defend against. They don't have access 
to a part of your cryptographic data and are not allowed to participate in 
your network. You can use a link-layer authentication and encryption to keep 
an external attacker out of your network.

Internal attackers are much more difficult to defend against. They are using a 
legal node of your network as a starting platform for their attacks. Because 
of this they are able to inject traffic into your network and read much of the 
internal state of the routing. You need mesh-wide authentication and end-to-
end encryption to have SOME defense against an internal attacker.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-263,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 17 Nov 2009 10:32:40 +0100

Let's start with the basic stuff, protection against external attackers,
where we are in an open network (no L2 security).
I think we shall use packet authentication only, this will work for all
packetBB protocols. Having this, we don't need more for 1-hop messages,
like NHDP and DYMO.
Before we work on more complex cases, I want to see the threat analysis
and need for protecting messages, I don't get it now.

I did not see practical end-to-end security for any routing protocol 
before. I can tell I've seen a lot of those. Do we accept a message from
a bad guy, when the message looks OK?

On IPsec: it is reasonably easy to deploy. This is very different for
protecting routing protocols. Key management is mostly pain in the ass.
This is for group key management in general. 
Let's see what happens with KARP.

Teco.

>Van: Henning Rogge [mailto:[email-masked]]
>Verzonden: dinsdag 17 november 2009 10:13
>Aan: [email-masked]
>CC: Ulrich Herberg; Teco Boot

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 17 Nov 2009 09:39:44 -0000

> and those who have not. For the firsts, we could skip the whole thing.

Not necessarily so.

Consider for example an 802.11 network with what is, in effect, a
shared secret key across the network. I may find that security worth
having (it's there, use it, and it has some other advantages) but not
sufficient. I want to add some L3 security that improves on it, with
individual keys.

>From an L3 point of view, yes, in some systems L3 security may not be
needed. But it's not as simple as that just being having L2 security.

> After more analysis of threats, I expect a demand for protecting
packets,

In OLSR, protecting messages gives end to end security, while protecting
packets gives hop by hop security. There can be some advantages in the
former.

********************************************************************
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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 17 Nov 2009 09:45:01 -0000

> I don't believe in end-to-end security.

But others do. And we want mechanisms for those that do.

> Why are relayed messages by bad guys interesting?

I would ask why relayed messages by bad guys could be harmful.
And I can do that.

> than all what exists today, without a request for it?

How do you know who's requested what? Maybe the people working
here have other people behind them who want such things but
don't go round discussing their specific needs. The intent of
the draft is a framework which can be used to do many things.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 17 Nov 2009 10:47:41 +0100

Thanks, we need such analysis in a threats draft.
Teco.

>Van: Dearlove, Christopher (UK) [mailto:[email-masked]]
>Verzonden: dinsdag 17 november 2009 10:40
>Aan: Teco Boot; Ulrich Herberg; [email-masked]
>Onderwerp: RE: [manet] Security drafts
>

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 17 Nov 2009 10:52:04 +0100

What to do when a bad guy strips authentication, manipulates and forward?
And adjust hop-count / hop-limit and forward?
I ask this, for being included in the threats draft.

We need a document on specific needs.

Teco.

>Verzonden: dinsdag 17 november 2009 10:45
>Aan: Teco Boot; Ulrich Herberg
>CC: [email-masked]

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 17 Nov 2009 09:53:00 -0000

> packetBB protocols.

OK, here's one specific example of the advantage of end to end security
over hop by hop security used for something like TC messages in OLSR.

I'm a bad guy. I capture node X and have access to its internals.

End to end, I can forge messages from node X. Not good.

Hop by hop, I can forge messages from any node, as forwarded by node X.
Even worse.

My point is not that that's the only reason, but it is an illustration
of how end to end and hop by hop are different. And some people want
the end to end.

Note that had you been arguing to keep end to end and not have hop by
hop I'd have disagreed with that too. As a "toolbox" draft, we want
hammers and screwdrivers.

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 17 Nov 2009 10:59:59 +0100

Teco,

> What to do when a bad guy strips authentication, manipulates and forward?

In that case, the bad guy is not able to sign the message again
(remember: "bad guy" == guy who does not possess a valid key). The
forwarded message will thus be ignored by routers receiving such a
forged message.

> We need a document on specific needs.

I will definitely rework the threats draft to include some more
explanations, such as an explanation why we need end-to-end security.
This will be particularly important for the upcoming
OLSRv2-sec-threats document.

Ulrich

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 17 Nov 2009 10:02:08 -0000

> What to do when a bad guy strips authentication, manipulates and
forward?

If we're running in a network with authentication, any unauthenticated
message will get dropped, so unless I'm missing the point of the
example,
that's OK.

> And adjust hop-count / hop-limit and forward?

That can be an issue. (I assume we're considering authentication that
excludes there, and an attacker that just adjusts these.) I can see
more than one attack that way.

One possible counter to that - I'm not recommending it, I'm just
noting it - is applying both end to end and hop by hop authentication,
as the latter will cover hop count and limit. There's another form of
counter discussed in the SMF draft I believe.

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 17 Nov 2009 11:08:57 +0100

Chris,

On Tue, Nov 17, 2009 at 11:02 AM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
>[...]

Yes, indeed, that can be an issue which needs to be discussed, since
hop-count and hop-limit fields are blanked (set to 0) before signing
the message (in the upcoming OLSRv2-sec draft)

Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 17 Nov 2009 11:25:34 +0100

>hammers and screwdrivers.

I am not against a tool-box.
I say: keep it simple, especially start with the simple case.
Agreed that protecting packets works OK for NHDP, DYMO and the
basics for OLSR?

I have my thoughts on signature checks, this needs some form of PKI.
Not really candidate for an ad hoc network.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 17 Nov 2009 11:30:18 +0100

>message will get dropped, so unless I'm missing the point of the

I didn't read unprotected packets are dropped on the floor. This could
be a mode of operation. 
I had the other mode in mind, then the bad guy injects false information
with unprotected messages.
Also to be included in the threats document.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 17 Nov 2009 10:35:57 -0000

> Agreed that protecting packets works OK for NHDP, DYMO and the

As end to end may be superior, I would not agree with excluding it.

> Not really candidate for an ad hoc network.

Various people, including the authors of this draft, and maybe
ourselves, have some ideas as to what one might do. Whether they
involve PKI may depend on how you define that term. (Actually if
the I stands for infrastructure then they may well not be PKI.)
But also maybe we aren't going to discuss our thoughts right now.
But they may well fit in a good general framework.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 17 Nov 2009 11:40:05 +0100

> As end to end may be superior, I would not agree with excluding it.
I agree to this, we must not exclude end to end security.

"End to end" and "link based" security have different goal, and there are not 
even  mutual exclusive !

So discussing BOTH of them is important in my oppinion.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 17 Nov 2009 10:40:35 -0000

> I didn't read unprotected packets are dropped on the floor.

There's no point in not giving unprotected packets a hard time.
The easiest hard time is just to drop them, and in systems I'd
be most interested in, that would be the right thing to do.

There could be possibilities in, for example, recording both
authenticated and unauthenticated messages and doing some sort
of "only use unauthenticated when no authenticated is known".
But that would be quite a bit of work to get to be safe (in the
sense of e.g. not looping in a routing protocol) and you'd have
to have a real use case to make that work worthwhile. In the
absence of such a case, dropping is the way to go.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 17 Nov 2009 10:42:05 -0000

I think I made the same point elsewhere. But just in case not,
to be clear, yes, we should have a framework that handles using
one, the other, or both together.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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: Henning Rogge [mailto:[email-masked]] 
Sent: 17 November 2009 10:40
To: Dearlove, Christopher (UK)
Cc: Teco Boot; Ulrich Herberg; [email-masked]
Subject: Re: [manet] Security drafts

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 17 Nov 2009 11:44:37 +0100

> absence of such a case, dropping is the way to go.
We could regard non-signed messages as "second class citizens" so that foreign 
nodes can join a secured network without disrupting it. This would be similar 
to having multiple routing tables, one for the secure network part and one for 
the rest of it.

Of course unsigned messages for nodes we know signing messages should be 
ignored.

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 17 Nov 2009 11:59:31 +0100

>one, the other, or both together.

I think the postings provide useful input for improving the security
drafts. This was my intention. I'm looking forward to updated versions.

Thanks, Teco

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 17 Nov 2009 12:02:55 +0100

> drafts. This was my intention. I'm looking forward to updated versions.

Indeed, thanks a lot for all the comments. I will work on updated
versions of the drafts.

Ulrich

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 17 Nov 2009 09:44:32 -0800

> > > I don't believe in end-to-end security.

End-end security is the ONLY long term solution to content security.
Infrastructure protection only protects infrastructure.  
> Internal attackers are much more difficult to defend against. 

This is the problem to focus on.  For all practical purposes, we have to
assume that everybody -- Bad Guys included -- is on the internet.
They're all insiders.  ... or will be in due time.  

> > What about IPsec, TLS, SSL, SSH? 

	- all are end-end as far as the internet is concerned.
	- IPsec's scope is single enclave, TLS/SSL scope is single TCP
connection.  The shortcomings here are that there's lots of untrusted OS
software out there that sees unprotected data.  SSH (and more elegantly,
S/MIME) are more completely end-end.  But.... all is outside of scope
for this group.  

End-end security is absolutely necessary.  But again, probably outside
scope for MANET.

-- 
Rex Buddenberg
Naval Postgraduate School
Code IS/Bu
Monterey, Ca 93943
831/656-3576

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 17 Nov 2009 19:00:52 +0100

Rex,

> Infrastructure protection only protects infrastructure.

Yes, end-to-end protection is very important.

> S/MIME) are more completely end-end.  But.... all is outside of scope

Yes, I agree they are out of scope for MANET WG.

> End-end security is absolutely necessary.  But again, probably outside

But do you think that the proposed framework is in scope for MANET?

Ulrich

---

From: Henning Rogge <[email-masked]>
Date: Wed, 18 Nov 2009 07:45:43 +0100

> But do you think that the proposed framework is in scope for MANET?
Could we maybe agree that "mesh-wide" routing security (and not only hop-by-
hop) is in scope for MANET ?

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 18 Nov 2009 08:05:13 +0100

>hop) is in scope for MANET ?

Yes, I agree the scope is limited to mesh or better: MANET protocol.
Question is: handling security hop by hop, with for example shared key?
I think: this perfectly fits NHDP, DYMO (all DV protocols) and the basics
of OLSR. Then the question is: do we need more? Some say so, so we can go
for it. But this can be a huge effort to deploy, especially in MANETs.
That is the reason I am conservative on this. One important principle
in security is: minimize (keep it simple and robust).

Teco.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 18 Nov 2009 09:02:21 +0100

> Question is: handling security hop by hop, with for example shared key?
Working with a shared key does not do routing security. Defending against an 
externel attacker can be done with Layer-2 security (link encryption).

> of OLSR. Then the question is: do we need more?
Routing attacks on NHDP from inside the network are based on forged NHDP 
messages. You cannot prevent an attack like this with a shared group key.

> Some say so, so we can go
Yes, finding a good tradeoff between security and performance in not easy.

> in security is: minimize (keep it simple and robust).
Simple and robust, yes... minimize ? Hmm...

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 18 Nov 2009 09:08:11 +0100

Teco

> in security is: minimize (keep it simple and robust).

I agree with you that we should keep it simple. However, in order to
achieve robustness of the security solution, we need end-to-end
protection. Otherwise, many security attacks will still be possible,
and we would not gain much. Just to give to an example: How would you
avoid identity spoofing and link spoofing of TC messages when not
using end-to-end protection? A router that receives a TC message has
no means of telling whether that message is "good" or "bad". That
router only knows that it is forwarded from a "good" relay, but
nothing about the originator.

Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 18 Nov 2009 15:59:06 +0100

Hi,

>Verzonden: woensdag 18 november 2009 9:08
>Aan: Teco Boot
>CC: Henning Rogge; Rex Buddenberg; [email-masked]
>protection. 

Please use other wording. Maybe you meant multi-hop router to router.
This is not (always) end-to-end.

>    Otherwise, many security attacks will still be possible,
>using end-to-end protection?

The bad guy cannot spoof, if not having the pre-shared key.
Protecting the pre-shared key could be problematic. Group-key
updates in a MANET is also difficult. Black list distribution 
is another problem.
Because you left out key management, we can't discuss this in
detail.

> A router that receives a TC message has

It is all about trust. If the TC has traveled only trusted neighbors,
what is the problem? Yes, how do we know a node somewhat far away
did not invalidate the TC, but the TC was malformed? But what is
the problem here, the network is affected by this misbehaving node
already?
You may come up with a scenario, where invalidating such messages
is important. But I think the costs for this is extremely high and
the benefit is low. I say: shoot down this invalid TC near to the
place where it was get corrupted. Every hop it took after that is
a hop too far.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 18 Nov 2009 17:25:17 -0000

> This is not (always) end-to-end.

If an OLSR router creates a TC message, which travels (as a TC
message, but in different packets) multiple hops to another
OLSR router, and the receiving OLSR router verifies that the
originating OLSR router did create that message (assuming no
failure of the security mechanism) then that is end to end
with regard to that message. It's not end to end with regard
to host applications attached to those routers of course. But
within the RFC 5444 context, end to end is a reasonable way
to view it. It's not my document, so what wording it should
use I'm not fussed by, whether it uses end to end (but could
note what that means - basically RFC 5444 message generating
end to RFC 5444 message processing end) or something else.

> The bad guy cannot spoof, if not having the pre-shared key.

Pre-shared key is an assumption that we do not all share. But
the point of the framework is that pre-shared key is an option.
But only an option.

> Because you left out key management, we can't discuss this in

The point is to make this independent of that. If A and B have
a security association such that if A signs a message then B
will be able to tell that the signature is valid, one part of
the problem is to enable that signature to be attached to that
message and delivered with it. How the security association is
set up is (as far as concerned here) Somebody Else's Problem.

> what is the problem?

Is trust transitive? I know in my early days at the IETF I sat in
a meeting, of I now know not what WG, where two people were arguing
past each other, and that was because one would have answered that
question no and the other would have said partly.

> place where it was get corrupted. Every hop it took after that is

That may stop me getting some messages. And that may be a good idea.
But it still leaves me with a chain of verifications I may choose not
to accept, I'd rather have it from the horse's mouth.

Here's just one reason why. Suppose a bad guy (TM) manages to spoof
being node A. (Note that I'm not using a single shared key - and
yes, I can do that - so the bad guy can't directly pretend to be
anyone without information I'm not even going to put in the MANET.)
Then with end to end signatures all he can do is create messages
claiming to be from node A. But with hop by hop signatures he can
create and inject message claiming to be from nodes B to Z. Even if
I work out that A is not to be trusted, I'm left with a mess of I
don't know what is trustworthy or not. With the end to end I know
what came from or about A, and I can bin that, and the rest of
the stuff is still good.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 18 Nov 2009 18:38:02 +0100

> end to RFC 5444 message processing end) or something else.

I think you are both right here, Teco, Chris - this is a matter which  
we need to be clear on in the document(s). Thanks for bringing it to  
our attention.

> the point of the framework is that pre-shared key is an option.

It is *an* option that  provides something different than e.g.  
asymmetric keys - e.g. identity verification. The point is, that these  
I-Ds shall not make a position (at this juncture) on which is "the  
way" but rather try to frame as much as possible as common ground for  
both.

> set up is (as far as concerned here) Somebody Else's Problem.

I agree. As far as these I-Ds are concerned, this is a SEP. I know of  
deployments where there is a long tradition of out-of-band key  
distribution (ever bought a car? what did the dealer hand you when you  
handed him the cheque? :) )-- and others where this is unacceptable.

I believe that it is recognized that both the choice of cryptographic  
system and key management is very deployment specific. What we should  
be trying to do in these I-Ds is to discuss the common set of things  
that can be accomplished, assuming that the SEP is indeed handled by  
Somebody Else ;)

<SNIP>

But all good, and thanks for the discussions on these matters - keep  
'em coming.

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 19 Nov 2009 08:18:32 +0100

>Is trust transitive? 

More thoughts on this, with TC in mind.
All nodes shall have synced LSDB, otherwise the network is loopy.
So all nodes shall accept or reject an invalid message.
So the neighbors of the node that corrupted the message shall
drop it on the floor. There is no olsr-sec draft yet, but I assume
such behavior written down.
Now we have some options what to do. Just drop the invalid messages?
Drop the whole packets? Invalidate the node that forwarded such 
messages, and tear down the links to such? Forever or hold-down 
period? Publish entries for revocation list?
I say the bad guy shall be isolated at least.

Now I see a benefit of signed messages. A node that is taken over
by the bad guys gang, and is transformed into an assassin, is to be 
isolated. Meanwhile, it can only cause some local damage.

Teco.

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 19 Nov 2009 10:24:57 +0100

Teco,

> such behavior written down.

As for the NHDP-sec draft, the plan for the OLSR-sec draft is to
provide another cause for TC messages to be rejected (as allowed by
the NHDP/OLSRv2 specs) (cf section 12.1 of the OLSRv2-draft). This
will be very similar to the NHDP-sec draft.

> Drop the whole packets?

I think that this decision is rather to be placed into the NHDP draft,
since the NHDP-sec draft only hooks into NHDP and provides a reason
for rejecting messages (as in section 12.1 of NHDP). In that section,
NHDP says:

"An invalid message MUST be silently discarded, without updating the
router's Information Bases."

So if we want to allow the whole packet to be dropped if a message is
invalid, we should put it in the NHDP draft, and not in the NHDP-sec
draft. I let the authors of NHDP express their opinion...

> Invalidate the node that forwarded such

This is an interesting point. I fear, however, that allowing to block
an originator forever leads to another attack. A malicious router
simply sends a few unsigned (or badly signed) messages claiming to
originate from another router. Thus, this router will be removed from
the Routing Set. So an attacker could easily disturb the topology.
Keep in mind that the only gain for tearing down a link (and thus to
reject incoming messages of a given source address without checking
the signature) is to save time for processing signatures.
What could be done is to enforce a minimum interval for incoming
messages (similar to MIN_INTERVAL for outgoing messages). If messages
from a source arrive more frequently, they are ignored. Are there any
opinions on such a mechanism?

> isolated. Meanwhile, it can only cause some local damage.

It depends, what you mean by "taken over". If an attacker gains access
to the key chain and is thus able to correctly sign messages, the
framework will not help in any way -- the "bad guy" would appear as a
"good guy" and cannot be isolated as all messages it signs are valid.

Ulrich

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 19 Nov 2009 10:49:19 +0100

Teco,

All good comments. I won't pretend to answer to your questions, as I  
don't know that I know the ultimate answers ;) I'd just bounce a  
couple of thoughts out and off you for discussion

I do know that there are uses for situations where a given network may  
maintain two topologies: one "secured" and one "not secured". Thus,  
one topology may reject a given entry in the LSDB while another  
topology in the same router may accept and use it, depending on the  
validation of signatures.

A blanket "throw away a message which doesn't validate, also without  
forwarding" would, I think, disable this functioning. Consequently,  
this holds also for "throw away a packet which contains a message  
where the signature doesn't validate".

On the latter (looking beyond simply OLSRv2/NHDP), throwing away a  
whole packet because a signature in any contained message doesn't  
validate wouldn't work, I think: it would assume that all routers  
would be equipped to parse (at least, to the point of verifying  
signatures) all possible message types. I would not expect that to  
hold true with various extensions and their new message types. Even if  
the packetbb-sec signature TLV was used for all messages, an  
intermediate might not have the necessary keys for validation (e.g. if  
the extension assumed endrouter-to-endrouter only, and therefore  
didn't share keys around to all intermediaries).

I'd like that whatever we do be flexible enough to accommodate at  
least the deployments/requirements that we can identify for current  
system -- and, preferably, those which we can reasonably project will  
emerge.

Cheers,

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Nov 2009 09:50:18 -0000

> draft. I let the authors of NHDP express their opinion...

It's not as simple as that. The multiplexing method in RFC 5444
means that NHDP doesn't even see non-HELLO messages in a packet,
and by the time it sees a message the packet has been distributed
to the appropriate protocols. So if you wanted this behaviour
- which is inappropriate in many cases, but may be appropriate in
some - then it needs to be in a security for RFC 5444 draft, not
a security for NHDP/OLSRv2 draft. In fact I think that's what we
need, with specific comments for NHDP/OLSRv2 in separate drafts,
but the bulk in a protocol agnostic document.

> the Routing Set.

All revocation mechanisms are a security threat, and any simple
"I've seen a bad message apparently from X, so X is bad" is a
very poor revocation mechanism, and not one to be used. Any
decision to blacklist a node needs more than that. I think this
is an area that needs more expertise than I'm aware of here.

> "good guy" and cannot be isolated as all messages it signs are valid.

There are however different cases of this as I noted in an earlier
email.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 19 Nov 2009 11:02:37 +0100

On Thu November 19 2009 10:24:57 Ulrich Herberg wrote:
> originate from another router.
Unsigned or badly signed messages/packets should NEVER be used to block a node 
if the capability exists to forge your own MAC/Source-IP. You simply don't 
have any information where the message is coming from, the only thing you can 
do is to call a higher layer (Help, I'm getting lot's of forged messages !).

The only exception I see is if you receive a message with a bad signature but 
the package was signed correctly. In this case it's clear that the forwarding 
node is either a stupid attacker or malfunctioning, so you could remove it.

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 19 Nov 2009 11:03:12 +0100

> but the bulk in a protocol agnostic document.

Incidentally, you are right - this was the reason that we started by  
publishing the packetbb-sec I-D. Initially, this contains almost only  
the TLV specifications; however I agree that it is natural to extend  
this to cover other "protocol-agnostic" matters. Incidentally, I  
suspect that these (in my opinion) will be relatively few: I can think  
of no situation where dropping a whole packet if a contained message  
doesn't validate would make sense - or rather, I can think of many  
counter-examples where it definitely wouldn't....

In terms of the way forward, it appears clear to me that discussing  
things in the context of protocols (NHDP/OLSRv2/DYMO) may be easier -  
and allow us to extract the general/agnostic matters. Which means, we  
have to accelerate getting the olsrv2-sec I-D polished and out, and  
preferably also a dymo-sec I-D (is there a DYMO expert in the house  
who'd like to chip in on that?)

> is an area that needs more expertise than I'm aware of here.

I second this. Not only are revocation mechanisms scary, I think that  
they also are (as with key distribution) very deployment specific too.

Thomas

---

From: Henning Rogge <[email-masked]>
Date: Thu, 19 Nov 2009 11:04:57 +0100

> validation of signatures.
Yes, we could do this, as long as unsigned messages cannot change the state 
delivered by signed messages.
 
> forwarding" would, I think, disable this functioning.
Yes.

> Consequently,
A packet should be only thrown away completely if the packet signature is 
wrong (if it contains a packet signature).
 
Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 19 Nov 2009 11:07:42 +0100

> node is either a stupid attacker or malfunctioning, so you could  

Or, maybe, that the forwarding node was not equipped to validate the  
signature. E.g. a protocol extension using a message type unknown to  
the forwarder, and where the "key-space" is proper to the extension  
(i.e. disjoint from that of NHDP/OLSRv2). I know of extensions (to  
OLSRv1, though) where this is the case.

I'd not even consider "good packet signature, bad message signature"  
as a reason to remove the sender of the packet.

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Nov 2009 10:13:01 -0000

> I can think  
> doesn't validate would make sense

There are always two cases of "doesn't validate" to consider
- Has signature, signature is bad.
- Doesn't have signature.

You can afford to be harsher in the former case than the latter.
Whether that extends to dropping a whole packet is another matter.

> and allow us to extract the general/agnostic matters.

Agreed. In fact it may make sense to say in NHDP/OLSRv2 specific drafts
that an aim is exactly that, given the RFC 5444 multiplexing framework.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 19 Nov 2009 11:14:34 +0100

> as a reason to remove the sender of the packet.
I think this would depend on the policy of the network.

Maybe you drop the node at once (because you have mandatory signature checking 
on all nodes), maybe you just drop the message and inform your IDS "got bad 
message signature from node X forwarded by node Y".

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 19 Nov 2009 11:16:25 +0100

> message signature from node X forwarded by node Y".

Right, I agree. This is rather deployment/policy dependent. We just  
need to make sure that we not enforce a behavior that excludes useful  
behaviors.

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 19 Nov 2009 11:18:01 +0100

> Whether that extends to dropping a whole packet is another matter.

Actually, I made a comment to this effect to Henning and on the list  
just now - not even in that case is it (always) reasonable to drop the  
packet, as the forwarder might just be an innocent bystander not able  
to validate the contained messages that it forwards.

> that an aim is exactly that, given the RFC 5444 multiplexing  

I could live with that, Ulrich?

---

From: Henning Rogge <[email-masked]>
Date: Thu, 19 Nov 2009 11:28:09 +0100

> to validate the contained messages that it forwards.

I think the signatures will get even more important in combination with the 
state-machine-drafts mentioned at IETF. Together they would allow to check for 
misbehaving nodes and trigger alerts to an IDS infrastructure (or a local 
response daemon).

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Nov 2009 10:28:26 -0000

> on all nodes)

The parenthesis is the key comment here - everything
(not just this) depends on your situation.

This makes it, in a generic document and even in an NHDP
or OLSRv2 specific document pretty much impossible to say
"you must always do this" and hard or worse to list all
possible options. Some possible options, and possibly the
most obvious ones, can be listed.

An OLSRv2 issue when using message signatures is: if
a node gets a message which it should forward, but not
process (there are at least two ways that can happen)
should it check the signature? I think the answer to
that one isn't obvious, there are arguments both ways.
Which means there might be circumstances for either
answer.

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 19 Nov 2009 11:32:22 +0100

Thomas,

On Thu, Nov 19, 2009 at 11:18 AM, Thomas Heide Clausen
<[email-masked]> wrote:
> Actually, I made a comment to this effect to Henning and on the list just
> now - not even in that case is it (always) reasonable to drop the packet, as
> the forwarder might just be an innocent bystander not able to validate the
> contained messages that it forwards.

Yes, I second this.

> I could live with that, Ulrich?

Yes, me too.

Ulrich

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Nov 2009 10:33:24 -0000

> to validate the contained messages that it forwards.

That's a third case. My first case is that the message has a signature,
I can validate signatures, and that signature is wrong. But if A sends
to B sends to C then C can get the first case because B was the third
case. Or due to one of the behaviours in my last email.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 19 Nov 2009 11:33:59 +0100

On Nov 19, 2009, at 11:28 AM, Henning Rogge wrote:

> state-machine-drafts mentioned at IETF.

Working on it, should not be long - but glad that you think they will  
be useful ;)

Thomas

> Together they would allow to check for

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 19 Nov 2009 11:35:19 +0100

> case. Or due to one of the behaviours in my last email.

We probably should enumerate these cases explicitly in the OLSRv2-sec  
I-D?

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Nov 2009 10:37:22 -0000

> misbehaving nodes and trigger alerts to an IDS infrastructure (or a
local 

If you have any infrastructure. But it's never enough
to know that there appear to be mis-signed messages
from node X, you need more. However every possibility
for what that more might be that I've thought of (though
I haven't thought too much about it) has a problem that
I've also thought of, so I'm not in a position to suggest
what that more might be (except, as always, it depends on
other things).

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 19 Nov 2009 11:37:45 +0100

Thomas,

On Thu, Nov 19, 2009 at 11:35 AM, Thomas Heide Clausen
<[email-masked]> wrote:
> We probably should enumerate these cases explicitly in the OLSRv2-sec I-D?

Yes, thanks for pointing out these three cases. They should be
explained in the OLSRv2-sec ID.

Ulrich

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Nov 2009 10:47:06 -0000

There are some more, including
- It has a signature and the signature is good (not all
  cases are failures!).
- It has a signature, but all I needed to do was forward
  it, so I didn't bother checking the signature, though
  I could have done.

-----Original Message-----
From: Thomas Heide Clausen [mailto:[email-masked]] 
Sent: 19 November 2009 10:35
To: Dearlove, Christopher (UK)
Cc: Rex Buddenberg; [email-masked]
Subject: Re: [manet] Security drafts

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Nov 2009 11:37:03 -0000

I'll make one more point that I think matters before trying
to move on from this discussion, at least for this morning.

OLSRv2 has a processing/forwarding engine that decides whether
a message should be processed, forwarded, both, or neither.

Messages that are to be processed need to be verified (if
possible, which I'm assuming is the case here). Messages that
are to be forwarded but not processed may or may not be
verified, but here I'll assume that they are if it matters.

That leaves messages to be neither processed nor forwarded.
There's actually no need to verify them cryptographically,
they are going to be discarded with no effect anyway. So
why waste the effort doing so?

OK, that's OLSRv2. But that says that even if we have a
generic RFC 5444 approach, with a packet demultiplexer
and message distributor, the right place for signature
verification isn't necessarily in that.

Now possibly an architecture including OLSRv2 might want
to reuse that message processing/forwarding engine from
OLSRv2 (it includes message type in it for at least a
specialised case thereof, of extensions to OLSRv2, but
could apply to other protocols with similar rquirements).
That might be the place for message signature checking.
Packet signature checking probably (almost certainly)
belongs in the RFC 5444 demultiplexer.

Note however that I'm not suggesting mandating that
processing/forwarding engine for all MANET protocols.
I think DYMO could be specified in such a way as to
use it, but that might necessitate considering some
DYMO messages as one hop then processing may generate
a very similar message (obviously created from it for
efficiency) rather than multi-hop modified before
forwarding (which also necessitates a signature change
- or if considered a new message, a new signature).
But note that I'm not 100% certain of everything about
DYMO I've just said - but that's my point, I'm not
suggesting mandating the OLSRv2 engine.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 19 Nov 2009 12:48:15 +0100

> verified, but here I'll assume that they are if it matters.
I think it matters that forwarded messages are checked for signatures too. If 
not the attacker will have the ability to poison the forwarding duplicate 
check, so that correct signed messages will not be forwarded anymore.
 
> why waste the effort doing so?
That's right, as long as we know that we do not need to forward/process them 
because we checked that message that lead to this.
 
> suggesting mandating the OLSRv2 engine.
I think we should (if possible) check all messages that change any kind of 
internal database in any way... even the duplicate/processing set.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Nov 2009 11:58:09 -0000

> check, so that correct signed messages will not be forwarded anymore.

Good point.
 
> internal database in any way... even the duplicate/processing set.

OK, I can buy that.

That is however an aside to the main point I was making, on the
architectural relationship of
- The RFC 5444 demultiplexer (which can incorporate
  packet signature verification).
- OLSRv2's processing and forwarding mechanism.
- The rest of OLSRv2, and any extensions to OLSRv2.
- Other MANET protocols, which may or may not want
  to use OLSRv2's processing and forwarding mechanism
  (or a copy thereof, or an adaption thereof).
- Message signature verification.

One point I didn't make was that NHDP does not need
to use the OLSRv2 mechanism, HELLO messages aren't
forwarded and are just processed when received
(or not if a signature fails).

---

From: Henning Rogge <[email-masked]>
Date: Thu, 19 Nov 2009 13:09:09 +0100

On Thu November 19 2009 12:58:09 Dearlove, Christopher (UK) wrote:
> > I think we should (if possible) check all messages that change any
> > kind of internal database in any way... even the
> > duplicate/processing set.
> 
> OK, I can buy that.
> 
If we put the packet signature verification there (which would be a good 
place), we need a mechanism to tell the packetbb-dependant protocolls if a 
message was in a signed packet or if it was badly signed. This might lead 
NHDP, DYMO or OLSRv2 to use another set of databases (or to flag the entries).

> - Message signature verification.
Yes, in terms of security (and depending on the security policy) this 
components could be tightly connected. We need some information channel 
between them.

> (or not if a signature fails).
Right, but it still needs to check incoming message signatures if the packet 
was not/badly signed or the packet signature does not belong to the originator 
of the message.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 19 Nov 2009 12:14:59 -0000

> message was in a signed packet or if it was badly signed.

If the packet badly signed, we dump it and the protocols never see
any of its messages. In some cases we may also dump the packet if
unsigned, but if not then the protocols can, in principle, deduce
this for themselves by that they (according to RFC 5444) get a copy
of the packet header.

Of course it might instead be preferable to remove the signature
from the packet header as copied and flag that fact separately.
Or that could be an implementation issue.

---

From: Tony <[email-masked]>
Date: Thu, 19 Nov 2009 14:10:00 -0500

Hello,
I would like to add a few points for consideration to the security 
discussion

First, when ever you add new behavior to a system, you bring in new 
security concerns. I always like to think of Manet as an addition to an 
existing wireless system’s communication stack. A wireless communication 
system can still work without Manet (or Mesh, etc); the communication 
node will not have the multi hop, discovery, etc capabilities. Thus, 
Manet’s scope should be limited to only the new functionality added to 
the system.

Is there a definition of Manet that defines its domain/scope within a 
system? I know there is an RFP at the OMG for a platform independent 
model for Manet providing such a description (I was part of the group 
who submitted it).

If the domain/scope is not clear, then you cannot understand the assets 
that are specific to Manet (as apposed to a point to point communication 
network). If you cannot understand what the assets are then you cannot 
understand what vulnerabilities and threats are specific to Manet and 
what what vulnerabilities and threat are against other communication 
mechanisms and services within a system. Example, jamming is not an 
attack against Manet but is an attack on a nodes RF broadcast. While it 
affects Manet and multi hop networking can be used to route around it 
ultimately does not stop the jamming’s effect if the end node is the 
target. Manet cannot provide any mitigation against such an attack. A 
jamming attack can still take place and the mitigation against such an 
attack must come from layer 1.

End to End security is not a concern for Manet because it is outside of 
scope. I can provide end to end security with or without Manet because 
such security services are outside of Manet’s scope. For example: IPSec 
does not care if a system is Manet enabled or not. While this does help 
enhance the security of a system, it does not address the security 
concerns that are specific to Manet. End to end security is address at 
layer 3 or higher in the network stack. (be it IP end to end 
communication or application to application). Unless manet replaces one 
or more of these layers, then end to end security should not be a 
concern for manet security and should be handled by other security 
mechanisms and services.

Point to Point security may even be in Manet scope because there are 
many examples of point to point security without Manet. So the question 
is, is p2p within the domain / scope of what Manet brings to a system. 
Point to point security is address at layer 2 in the network stack. 
Unless manet replaces layer 2, then point to point security should not 
be a concern for manet security and should be handled by other security 
mechanisms and services at layer 2.

If a manet design implementation replaces either point to point or end 
to end communication in existing network stacks, then it must address 
the security concerns for each.

The multi hop route security concerns are clearly within the 
scope/domain of Manet because this is what is it brings to a system. 
Multihop is neither point to point nor end to end communication but 
exists someplace in between.

Security engineering requires a series of steps to be able to more 
accurately identify the needed security architecture, mechanisms and 
services.  The assets that are specific to the components (Manet) need 
to be identified, then identify the vulnerabilities for these assets and 
then find the attacks and their associated threats which leverage the 
various vulnerabilities. Once this is done, one can properly begin to 
identify the needed security architecture, design, services and 
mechanisms to mitigate the threats and attacks. If this is not done, 
your security requirements/recommendations will not be traceable, 
incomplete or improperly over reaching.

Tony Martin

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 19 Nov 2009 21:04:38 +0100

I don't get why we sign nhdp msgs and not the packets. This would
protect for all protocols. I think Chris and Henning said this before.
Can [ Thomas | Ulrich ] explain?

Teco.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 19 Nov 2009 21:06:24 +0100

> Can [ Thomas | Ulrich ] explain?

It would not solve the problem for TC messages, or any other messages  
that are relayed beyond 1 hop - so it wouldn't protect for all  
protocols.

Thomas

---

From: Henning Rogge <[email-masked]>
Date: Thu, 19 Nov 2009 21:09:16 +0100

> Can [ Thomas | Ulrich ] explain?
Signing packets ist to protect the link, signing messages the end-2-end data 
transfer.

for NHDP signing packets could be enough, but signing messages would do the 
job too.

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 19 Nov 2009 21:17:05 +0100

> Signing packets ist to protect the link, signing messages the end-2- 

Agree.

> for NHDP signing packets could be enough, but signing messages would  

Actually, one might want to have a link advertised in a HELLO message  
with "both ends of the link signing for its existence", and so I would  
say that even NHDP would not (universally) be sufficiently supported  
by "just packet signatures".

Besides, each protocol with messages carried inside the same RFC5444  
packet might just use very different keys, signing processes, .....

Thomas

---

From: Henning Rogge <[email-masked]>
Date: Thu, 19 Nov 2009 21:25:46 +0100

Am Donnerstag 19 November 2009 21:17:05 schrieb Thomas Heide Clausen:
> > Signing packets ist to protect the link, signing messages the end-2-
> > end data transfer.
> 
> Agree.
> 
This "co-signing" of links would be a very expensive operation, especially in 
dense networks. Both expensive in terms of network load and cpu-power.
 
Yes.

Henning Rogge

---

From: "Justin Dean" <[email-masked]>
Date: Thu, 19 Nov 2009 15:25:53 -0500

It also has to do with the way RFC5444 delegates protocols to message types.
Having it at the packet level is okay but limited as it would have to work
correctly for all protocols.  A simple drop it if it doesn't have a
(correct) key works and is what I believe either Chris or Thomas mentioned
they might have a draft or are working on.  It doesn't however support
multiple hop signing to take advantage of possible heterogeneous situations
where not all routers (for whatever reason) understand signatures.  To me
there is value in having both.

Justin
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Henning Rogge
> Sent: Thursday, November 19, 2009 3:09 PM
> To: [email-masked]
> Cc: 'Dearlove, Christopher (UK)'; 'Thomas Heide Clausen'
> Signing packets ist to protect the link, signing messages the end-2-end
> data transfer.
> 
> for NHDP signing packets could be enough, but signing messages would do
> the job too.
> 
> Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 19 Nov 2009 21:32:34 +0100

Henning

> dense networks. Both expensive in terms of network load and cpu-power.

Yes, and as such it should not be mandatory. But for some deployments
that can be okay, so I think we should consider it as an additional
means of protection.

>> packet might just use very different keys, signing processes, .....

I second that. We definitely need signatures of messages in the
NHDP/OLSR-sec drafts. The question is, do we additionally allow to
sign packets?

Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 20 Nov 2009 08:17:47 +0100

Thanks for the replies on signing NHDP msgs or packets.
However, I did not see an answer. The replies were for
other protocols, or IMHO special cases.
I'm getting worried on having std track mechanism for
MANET protocol security. I think we should define
the basics first, that MUST be supported. After that
we could define other mechanisms, but as I see it now
this is experimental.

Teco.

>Van: Thomas Heide Clausen [mailto:[email-masked]]
>Verzonden: donderdag 19 november 2009 21:17
>Aan: Henning Rogge
>CC: [email-masked]; Teco Boot; 'Ulrich Herberg'; 'Dearlove, Christopher
>(UK)'
>> end data

---

From: Henning Rogge <[email-masked]>
Date: Fri, 20 Nov 2009 10:12:56 +0100

> we could define other mechanisms, but as I see it now
Signing packets helps to achive link-layer security for packetbb. If you have 
signed packets and don't want to sign the neighbor entries in the HELLOs, you 
might just skip signing NHDP messages.

But I think the NHDP security draft should only work on signatures/encryption 
of the NHDP messages. Packet signatures can be handled in a packetbb security 
draft.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 20 Nov 2009 09:19:33 -0000

> I don't get why we sign nhdp msgs and not the packets.

Without looking at the draft, I see no reason why a
particular deployment can't choose one, and another
deployment the other.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 20 Nov 2009 10:22:26 +0100

>of the NHDP messages. Packet signatures can be handled in a packetbb

This is what I don't get. Having packetbb-sec in std track,
we don't need something for 1-hop messages. Securing packets
will do.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 20 Nov 2009 09:24:22 -0000

> NHDP/OLSR-sec drafts. The question is, do we additionally allow to

Yes. While message signatures offer advantages, packet signatures
also have their uses. For example if you are prepared to assume
that no node is ever compromised, and the signature process is
flawless (I'm not, but a system offering a basic level of security
might) then packet signatures might suffice. Packet signatures
used in addition to message signatures might also offer some
advantages in some cases.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 20 Nov 2009 10:26:14 +0100

>particular deployment can't choose one, and another

Unless our goal is publishing lots of RFCs, I don't see
the benefit. Remember, we want to define some standards.
Having multiple options is contra-productive.

Teco.

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 20 Nov 2009 10:29:10 +0100

> advantages in some cases.

Okay, I think that we can indeed suggest a packet signature mechanism.
But as Henning pointed out before, I do not think that this would be
part of the NHDP-sec draft, since it is a lower layer mechanism. I
suggest that we include it in the packetbb-sec draft. If in a
deployment of NHDP/OLSRv2 no message signatures are required, the
NHDP-/OLSRv2-sec drafts can be ignored then. Rejected packets would
simply be never delivered to the NHDP/OLSRv2/otherprotocol instances.

Ulrich

---

From: Henning Rogge <[email-masked]>
Date: Fri, 20 Nov 2009 10:32:06 +0100

> Having multiple options is contra-productive.
Signing all packets have a huge overhead compared to signing only your own 
messages, because you have to sign packages that only contain forwarded 
messages.

So signing NHDP messages, even if you don't sign the links of NHDP, have it's 
use cases.

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 20 Nov 2009 10:33:47 +0100

> Having multiple options is contra-productive.

No, I don't think so. A major principle of this security work bases on
the principle no "one-size-fits-all". As Chris and Thomas pointed out,
there are many cases where message signatures are required. However, I
also understand that in some cases, packet signatures are sufficient.
For the latter, a modification of the packetbb-sec draft (or a new
draft for packet based signatures?) can be provided.

Ulrich

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 20 Nov 2009 09:38:27 -0000

> MANET protocol security.

Has anyone suggested standards track now?

> I think we should define
> the basics first, that MUST be supported.

I don't believe we can actually define what must be
supported. If someone is working in an environment
requiring high grade military security, and someone
else is working in an environment where authentication
is basically there to prevent accidental network
joining, they aren't going to have much in common in
their implementations, beyond working in the same
framework.

> After that
> we could define other mechanisms,

I'm not sure what you are considering now and later.
I would consider all of the framework proposed (message
and packet, timestamps and signatures, a space for a
range of algorithms, a few basic ones defined now) as
for now.

> but as I see it now

I would have to be persuaded that was not the case if
that is proposed.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 20 Nov 2009 09:41:11 -0000

> of the NHDP messages. Packet signatures can be handled in a packetbb
security 

The NHDP draft should refer to the RFC 5444 security
draft and note that packet signatures may be appropriate,
especially if not also running any other protocol that
requires more than one hop messages. But the details can
be left in the general RFC 5444 security draft, I agree.

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 20 Nov 2009 10:43:21 +0100

Teco,

> Has anyone suggested standards track now?

The intended status is Experimental.

> their implementations, beyond working in the same

Yes, again: no "one-size-fits-all".

Ulrich

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 20 Nov 2009 09:43:57 -0000

> Having multiple options is contra-productive.

Different people have seriously different security
requirements. You only need to look at the affiliations
of some people in this WG, from one of the chairs on
down, to consider why.

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 20 Nov 2009 10:44:20 +0100

> be left in the general RFC 5444 security draft, I agree.

Yes, I agree with that.

Ulrich

---

From: Paul Lambert <[email-masked]>
Date: Wed, 25 Nov 2009 16:10:08 -0800

Please excuss the out-of sync comments on the security drafts ... I'm an infrequent lurket on this list ....             
On draft-herberg-manet-packetbb-sec-02

The Hash functions can be usefully truncated to smaller sizes than the block size.  Are all 256 bits of SHA256 intended to be used (table 3)?  If not - Ids should be made for each size to prevent a hash truncation attack.

   |      3      |   SHA256  |    The hash function as specified in    |
   |             |           |                 [SHA256]                |

On 
       9.2.3. Cryptographic Algorithm Registry

Please remove 3DES it's a deprecated algorithm and should not be used.
AES is not fully defined - are you intending to use a AES-CBC MIC?

   |        4        |    3DES   |     3DES as specified in [3DES]     |
   |        5        |    AES    |      AES as specified in [AES]      |

It's also odd having the mix of public and symmetric key algorithms in the same table.  The properties are different.  Not indicating the key distribution methods leaves a big hole wrt PK usage.  

Event the symmetric algorithm typically could use a "security association identifier".  If there is no identifier, the mapping of keys to addresses should be better defined.  

Paul

Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Teco Boot
> Sent: Monday, November 16, 2009 12:18 PM
> To: 'Ulrich Herberg'; [email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Nov 2009 07:25:49 +0100

On Thu November 26 2009 01:10:08 Paul Lambert wrote:
> Please excuss the out-of sync comments on the security drafts ... I'm an
>  infrequent lurket on this list .... On draft-herberg-manet-packetbb-sec-02
> 
> The Hash functions can be usefully truncated to smaller sizes than the
>  block size.  Are all 256 bits of SHA256 intended to be used (table 3)?  If
>  not - Ids should be made for each size to prevent a hash truncation
>  attack.
> 
>    |
I agree to this, the length of the truncated string would be in the length 
field of the TLV anyways. We only have to define that we store a prefix of the 
hash.

> Please remove 3DES it's a deprecated algorithm and should not be used.
3DES should be nearly useless today, SHA1 should be faster.

> It's also odd having the mix of public and symmetric key algorithms in the
>  same table.  The properties are different.  Not indicating the key
>  distribution methods leaves a big hole wrt PK usage.
Key distribution is out of scope for the MANET WG I think.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 26 Nov 2009 09:43:02 -0000

> The Hash functions can be usefully truncated
> to smaller sizes than the block size.

If there's a well-defined way to truncate, then this could
be done with no additional overhead if the type extension
fully defines the untruncated size. Then the TLV length
(of value) field could define the truncated size.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 26 Nov 2009 13:17:27 +0100

> (of value) field could define the truncated size.
In a good hash every byte should contain the same amount of information. So 
just using the prefix should be okay. It does not change the strength of the 
hash function but increase the chance of random collisions.

Henning Rogge

---

From: Tony <[email-masked]>
Date: Sun, 29 Nov 2009 22:13:33 -0500

> 3DES should be nearly useless today, SHA1 should be faster.
SHA1, as of 2010, is no longer recommended by NIST; collisions were
found reducing complexity. Md5 is no longer secure either.

Tony Martin

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 30 Nov 2009 10:15:35 +0100

That's the advantage of the code point in the draft: signature
algorithms can be easily removed or added. Thanks Tony for that
information, we will consider that when updating the draft.

Ulrich

---

From: Paul Lambert <[email-masked]>
Date: Mon, 30 Nov 2009 09:40:39 -0800

So, imagine a message is sent with a hash of length 256.  It could be intercepted, and easily truncated to a length of 8.  Both the hash and the length value could be changed.  Hash truncation is not so much the issue as the reduction in size - which would greatly reduce the search space for valid hash values.

The definition requires at least a notion of the enforcement of a minimum acceptable hash size. 

Paul

> From: Dearlove, Christopher (UK) [mailto:[email-masked]]
> Sent: Thursday, November 26, 2009 1:43 AM
> To: Paul Lambert; Ulrich Herberg; [email-masked]; [email-masked]
> Subject: RE: [manet] Security drafts
>

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 30 Nov 2009 18:57:57 +0100

I had similar thoughts. Add type and length in hashed text?
Teco.

>Van: [email-masked] [mailto:[email-masked]] Namens Paul
>Lambert
>Verzonden: maandag 30 november 2009 18:41
>Aan: Dearlove, Christopher (UK); Ulrich Herberg; [email-masked];
>[email-masked]
>So, imagine a message is sent with a hash of length 256.  It could be
>intercepted, and easily truncated to a length of 8.  Both the hash and
>the length value could be changed.  Hash truncation is not so much the
>issue as the reduction in size - which would greatly reduce the search
>space for valid hash values.
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 30 Nov 2009 17:59:00 -0000

There's a key issue here of how much is agreed between sender
and recipient (and more widely, all the nodes in the MANET).
In the applications I'm thinking of, which are about signing,
not simply attaching a hash, the nodes will have pre-arranged
some things (how is an issue I'm not getting into now) and
that will actually probably make the specification of which
algorithm, and what length, redundant in that it's pre-agreed.
That's not to say those things shouldn't be included - but see
my next paragraph - and the TLV value length is mandatory
(RFC 5444, needed to parse). But there's no issue in those
cases of the attacker doing what you suggest as that would
fail the pre-arrangement, and hence be a (cheap) authentication
failure. But other systems may be different (that's the whole
point here) and so this might be an issue. But is the solution
in this draft to specify limitations, or to specify that
limitations will be needed, but those are administrative?

A thought that arose typing the above. I think (meaning I don't
have time to check right now) that type extension zero (which
is the most efficient type) is allocated to "none". The above
suggests to me that a possible type extension might be for
"if this is for you, you know what it is". Should that have
type extension 0? Or does type extension 255 (private use)
allow this?

-----Original Message-----
From: Paul Lambert [mailto:[email-masked]] 
Sent: 30 November 2009 17:41
To: Dearlove, Christopher (UK); Ulrich Herberg; [email-masked];
[email-masked]

                    *** WARNING ***

The definition requires at least a notion of the enforcement of a
minimum acceptable hash size. 

Paul

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 30 Nov 2009 18:03:47 -0000

Adding type and length in hashed text doesn't work. Or
rather it does, but only if you add them in a separate
TLV just for this purpose, and that's getting horrible, 
or if you do some sort of really nasty process that
involves something like a TLV that you add with a length
field, duplicating that in the TLV value length, and
otherwise zeros in the value field, then you hash etc.,
then you modify the TLV in situ. Reception is the opposite
and even uglier. This is not the model in RFC 5444, or
this draft.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Teco Boot
Sent: 30 November 2009 17:58
To: 'Paul Lambert'; Dearlove, Christopher (UK); 'Ulrich Herberg';
[email-masked]; [email-masked]
Subject: Re: [manet] Security drafts

                    *** WARNING ***

---

From: Paul Lambert <[email-masked]>
Date: Mon, 30 Nov 2009 10:04:47 -0800

I believe simply changing SHA-256 to be SHA-256-64 (truncated to 64 bits) would solve the problem.  There is no need to have variable hash sizes.  Adding the type and length into the has does  not help if the length is reduced to 8.  

There's a issue here also that some notion of the acceptable cipher suite is needed.  It's normally part of the key management or "security association" setup.  There's some type of negotiation that determines what algorithms are acceptable.  If the negotiation selects SHA-256 ... it should be of a known hash size and not subject to variations.  So, pinning down the hash lenth as part of the "type" would hopefully eliminate this issue.

Paul

> From: Teco Boot [mailto:[email-masked]]
> Sent: Monday, November 30, 2009 9:58 AM
> To: Paul Lambert; 'Dearlove, Christopher (UK)'; 'Ulrich Herberg';

---

From: Paul Lambert <[email-masked]>
Date: Mon, 30 Nov 2009 10:10:04 -0800

> type extension 0? Or does type extension 255 (private use)

Hummm ... this is actually a better process than having an explicit algorithm.  It's a little confusing in this specification - but it better represents how this would interact with any form of key management.  Basically - the signatures, hashes and all algorithms are determine before hand ... and each side should know what is expected.  Ideally there would only be a identifier providing the context of this pre-agreement (akin to the an SAID or SPI in IPsec).

Paul

---

From: Henning Rogge <[email-masked]>
Date: Mon, 30 Nov 2009 19:10:59 +0100

Am Montag 30 November 2009 19:04:47 schrieb Paul Lambert:
> I believe simply changing SHA-256 to be SHA-256-64 (truncated to 64 bits)
>  would solve the problem.  There is no need to have variable hash sizes. 
>  Adding the type and length into the has does  not help if the length is
>  reduced to 8.
Yes, there is a reason.

Sometimes it can be better to have a short has if you need lot's of them. 
Taking the first FOUR bytes from a SHA-256 will protect you against all 
attacks better than guessing (1 to 2^32), so it could be more than enough for 
shortlived routing packages.
 
> There's a issue here also that some notion of the acceptable cipher suite
>  is needed.  It's normally part of the key management or "security
>  association" setup.  There's some type of negotiation that determines what
>  algorithms are acceptable.  If the negotiation selects SHA-256 ... it
>  should be of a known hash size and not subject to variations.  So, pinning
>  down the hash lenth as part of the "type" would hopefully eliminate this
>  issue.
I think what algorithm you use and what length of it you use it in the scope 
of the protocol... if we define that we always take the has prefix, even 
different implementations can talk with each other. And you can always add a 
"check if hash is long enough for my security policy" if you need it.

Henning

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 30 Nov 2009 18:11:46 -0000

Actually there's another issue, to do with that the TLV 
value length isn't the hash length, it's the signature
length, and the hash length and signature length don't
have to be equal. So - possibly in contradiction to an
earlier email of mine - you need to include the hash
length, probably in the type extension specifying the
hash.

It is clear that a proper specification of a good set
of algorithms, pinning down their options, is needed.

-----Original Message-----
From: Paul Lambert [mailto:[email-masked]] 
Sent: 30 November 2009 18:05
To: Teco Boot; Dearlove, Christopher (UK); 'Ulrich Herberg';

                    *** WARNING ***

I believe simply changing SHA-256 to be SHA-256-64 (truncated to 64
bits) would solve the problem.  There is no need to have variable hash
sizes.  Adding the type and length into the has does  not help if the
length is reduced to 8.  

There's a issue here also that some notion of the acceptable cipher
suite is needed.  It's normally part of the key management or "security
association" setup.  There's some type of negotiation that determines
what algorithms are acceptable.  If the negotiation selects SHA-256 ...
it should be of a known hash size and not subject to variations.  So,
pinning down the hash lenth as part of the "type" would hopefully
eliminate this issue.

Paul

Paul

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 30 Nov 2009 19:14:28 +0100

Paul Lambert wrote:
> Hummm ... this is actually a better process than having an explicit algorithm.  It's a little confusing in this specification - but it better represents how this would interact with any form of key management.  Basically - the signatures, hashes and all algorithms are determine before hand ... and each side should know what is expected. 
> [...]
>   

Yes, exactly. All parameters have to be exchanged or set before (e.g.
hash length, keys, etc.). We will work on the text of the draft to make
that clearer.

Ulrich

---

From: Henning Rogge <[email-masked]>
Date: Tue, 1 Dec 2009 07:26:18 +0100

> of algorithms, pinning down their options, is needed.
So maybe a TLV extension type should specify a hash algorithm and the hash 
output length ?

It can be even worse, because we combine a hash function and an encryption 
function. So we need to know the length of the hash output, must define if it's 
padded or shortened before it's pushed into the encryption function, then we 
have to know the output size of the encryption function and again do have to 
decide if we shorten or pad the final TLV data.

Henning Rogge