Subject: Re: [manet] Re: Re Security considerations in MANET

From: "Claude Castelluccia" <[email-masked]>
Date: Wed, 24 Apr 2002 16:08:26 +0200

-----Message d'origine-----
De : Claude Castelluccia <[email-masked]>
À : Phil Neumiller <[email-masked]>; Manel Guerrero Zapata
<[email-masked]>; ext Casey Carter <[email-masked]>
Cc : [email-masked] <[email-masked]>; Seung Yi <[email-masked]>
Date : mercredi 24 avril 2002 14:38
Objet : [manet] Re: Re Security considerations in MANET

>
>-----Message d'origine-----
>>D).  In the case that the network has no fixed infrastructure, i.e. a pure
>ad hoc network
>>       a good solution for key management does not yet exist.  Please find
>one.
>
>
>Hello Phil,
>
>We've actually found one;-)
>
>Our proposal focuses on AODV but
>actually could be used with any other MANET protocol. It is
>basically a scheme to establish an authenticated secret key between two
>hosts that does not have access to an infrastructure (PKI, or others...).
>
>
>Protecting AODV against Impersonation attacks (or how
>to establish a secure tunnel between 2 hosts on a MANET)
>=============================================
>Claude Castelluccia and Gabriel Montenegro.
>April 2002.

oups, i have just realized that i've sent an old (very drafty)
version of the draft.
Please ignore my previous email and consider the draft attached to
this email...sorry about that...
regards,
Claude.

PS: FYI i'll be travelling for the next 10 days and not sure whether i'll
have an Internet access...but Gabriel (my co-author) will reply to
your comments (or  i'll reply when i'll be back...)

PS: BTW we plan to submit this draft to the AODV workshop in Lausanne
(after MobiHoc)
the submission deadline is April 30th...it would be great to have your
comments
before this deadline to possibly integrate them in the draft...thanks in
advance.

Claude.

----------8><---------------------------8><--------------------------------

Protecting AODV against Impersonation attacks (or how
to establish a secure tunnel between 2 hosts on a MANET)
======================================================
Claude Castelluccia and Gabriel Montenegro.
April 2002.

1 *Problem statement:
--------------------
- How to protect AODV from the impersonation attack: i.e.
how can a host H1 that is communicating with a host H2 over an
insecure Adhoc network that uses AODV has the assurance that when
it receives packets from H2 they actually come from H2 and not from
an impersonator even if the routing insfracture/protocol is insecure...

In current AODV [AODV,AODV6], H1 establishes a route to H2 by sending
a RREQ message to H2 that will then replies with a RREP. But actually anyone
(ecen a malicious host, on the path or not) can reply to the RREQ and
redirect the packets addressed to H2 to him (eventhough H1 thinks
it is communicating with H2). Furthermore if H1 receives several RREP,
how can it select the right one?

The basic solution is:
- the node H2 uses a CGA (Crypto Generated Address) or CGI
(Crypto. Generated Identifier) [SUCV,CAM]  as address (a CGI is
an identifier that is defined as the hash of a public key).
- whenever a H2 sends packets to H1, it must disclosed its public key
and sign its packets (by setting
the mutable fields (ie hop counts) to zero or as specified in sAODV [SAODV])
with its CGA private key...

As a result, the destination, H1, can verify that the packets have
actually been sent by H2 . This is achieved by verifying that the CGA
or CGI was generated from the public key and that the signatures
are valid.

This solution solves the problem but is not very efficient because
it requires one signature generation/verification per packets.
This is not acceptable.

A Better solution is:
- H1 and H2 establish a secure channel (tunnel) and then encrypt or
authenticate (with a HMAC) their packets with the symetric key that
was generated.

Therefore the problem can now be stated as follows:
- how can two hosts H1 and H2, identified by their address,
establish a secure (IPSec) tunnel over an insecure adhoc network
that uses AODV.

2 * Proposal description:
---------------------------------
2.1 + requirements:

Both H1 and H2 define a CGA or CGI, respectively CGI_H1 and
CGI_H2 as follows:
 -CGI_H1 =  hashx(PublicKey_H1, counter_H1) x=64 (for CGA)
or 128 (for CGI).
 -CGI_H2 =  hashx(PublicKey_H2, counter_H2)

where PublicKey_H1 (resp. PublicKey_H2) is a public key
associated with H1 (resp. H2).

Note: it is not clear today if a IPv6 address is really needed in
MANET.
If this is the case then CGA must be used otherwise CGI
(128 bit identifier) is better since they are cryptographically
 stronger.

2.2 + protocol description:

- H1 initiates a RREQ, includes in it its PublicKey_H1, counter_H1,
g^x.modp (i.e. a DH exponentiation value) and an nonce N1 (RREQ id
could be used instead), and signs the whole message with its
PrivateKey_H1.
The RREQ must have the newly defined D flag (see Section 2.3).
set. This flag specifies that only H2  is allowed to reply to this
RREQ.

- When H2 receives the RREQ,  it verifies that H1 owns its address
(i.e. CGI_H2 was generated from PublicKey_H2 and the signature is valid).
It then replies with a RREP that contains PublicKey_H2, counter_H2,
g^y. modp, N1 (i.e. RREQid), and signs the whole message with its
PrivateKey_H2. H2 also derives the secret key, Ke that would
be used to establish a secure channel between CGI_H1 and CGI_H2.
For example, Ke  could be defined as follows:
Ke = hash_x(g^xy mod p)  (where x is the size of the generated key).

- When H1 receives RREP, it verifies that H2 owns its address and
derives the secret Key, Ke.

From then on, the "standard" AODV protocol is used until the SA
needs to be refreshed.

As a result of this exchange, CGI_H1 (resp. CGI_2) has the assurance
that it is talking to CGI_H2 (resp. CGI_H1) and a secure tunnel
(i.e. an authenticated symetric key) is established between
CGI_H1 and CGI_H2 that can be used to secure (authenticate + encrypt)
control or data traffic.

2.3 + the "D" flag

-The D (Destination) flag has been added to the RREQ packet format
because in our proposal, when H1 sends a RREQ it wants to make sure
that it gets a reply from H2 itself and not from an intermediate host
that may have an active route to H2 (as this is possible in current
AODV draft). In fact, RREQ and RREP carry information (DH
exponentiation value) that are used to establish the symetric key
between H1 and H2. If an intermediate node replies, H2 won't be able
to derive the symetric key and the protocol will fail.

             Route Request (RREQ) Message Format
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |J|R|G|D|     Reserved          |   Hop Count   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   32-bit Flooded Packet ID                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              32-bit Destination Sequence Number               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 32-bit Source Sequence Number                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                128-bit Destination IP Address                 :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                   128-bit Source IP Address                   :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3 + Conclusion
--------------
We propose a protocol that allows two random hosts H1 and H2 to
establish a secure tunnel over an insecure Adhoc network that uses
AODV.  Our solution relies on CGI and the definition of a new flag
(the D flag) in the RREQ packet format.

Our proposal does not use any certificate (and therefore PKI) and
does not require any TTP support. It is therefore well adapted to
adhoc environments and very scalable.

Note that since the routing infrasstructure is insecure, our proposol
does not protect H1 and H2 against DoS attacks. In fact, in our
proposal, as in AODV, an attacker can easily redirect/hijacked the
packets from H1 or H2. Protecting from these DoS attacks  is a
different (or very complex) issue that can potentially solved by
securing the routing infrastructure or by using schemes that use
redundancy (i.e several paths).
However, even under DoS attacks,  whenever H1 (and resp. H2)
receives a packet from H2 (resp. H1) it has the assurance that it
was not sent by an impersonator. That is the goal of our proposal.

References:
----------

[AODV] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc
On Demand Distance Vector (AODV) Routing, draft-ietf-manet-aodv-10.txt,
March 2002.

[AODV6] Charles Perkins, Elisabeth Belding-Royer and Samir Das, Ad Hoc
On Demand Distance Vector (AODV) Routing for IPv6,
draft-ietf-manet-aodv6-01.txt, March 2002.

[CAM] Greg O'Shea and Michael Roe, "Child-proof Authentication for MIPv6
(CAM)", ACM Computer Communication Review, April 2001.

[SAODV] Manel Zapata, Secure Ad hoc On-Demand Vector (SAODV) Routing,
draft-guerrero-manet-saodv-00.txt, August 2001.

[SUCV] Gabriel Montenegro and Claude Castelluccia, "Statistical Unique and
Cryptographically Verifiable (SUCV) Identifiers and Addresses", in NDSS02,
February 2002.

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Philippe Jacquet" <[email-masked]>
Date: Wed, 24 Apr 2002 18:15:40 +0200

Claude,

Nice stuff. I am relatively new in security considerations, sorry if I ask
naive questions. Why H1 and H2 must exchange their public keys and
signatures in RREQ and RREP messages. It cannot be done in simple data
packets after route discovery? I don't see the plus of involving the routing
protocol.

Philippe
----- Original Message -----
From: Claude Castelluccia <[email-masked]>
To: Claude Castelluccia <[email-masked]>; Phil Neumiller
<[email-masked]>; Manel Guerrero Zapata
<[email-masked]>; ext Casey Carter <[email-masked]>
Cc: <[email-masked]>; Seung Yi <[email-masked]>
Sent: Wednesday, April 24, 2002 4:08 PM
Subject: Re: [manet] Re: Re Security considerations in MANET

---

From: "Philippe Jacquet" <[email-masked]>
Date: Wed, 24 Apr 2002 18:15:40 +0200

Claude,

Philippe