Subject: [mobile-ip] IESG security concerns with MIPv6

From: Thomas Narten <[email-masked]>
Date: Mon, 19 Mar 2001 15:35:30 -0500

This is a note to summarize some security-related concerns that the
IESG has with the Mobile IP v6 Draft
(draft-ietf-mobileip-ipv6-13.txt). The concerns can be summarized as
follows:

The IESG has concerns about the draft's dependency on IPSEC AH to
authenticate Binding Updates. There are several issues here.

   a) There is significant overhead associated with building and
      maintaining AH/IPsec SAs (both in terms of state that needs to
      be maintained, but also in terms of required message flows, and
      the processing required to implement those flows). This has
      negative implications for larger servers that process many 100s
      of thousands of connections at a time.

   b) The processing rules for authenticating a Binding Update with AH
      are complex and are apparently not readily supported by the
      current generation of IPsec/IKE implementations (e.g., the IPsec
      policies are needed that specify sufficient granularity about
      IPv6 packets containing binding updates). There is a concern
      that this will not be rectified in the short term or that
      providing this level of granularity is even approriate for
      IPsec, leading to a possible result that the Binding Update
      won't be implemented/supported at all, (or even worse) that it
      will be used without proper authentication.

The IESG strongly recommends that the WG find an alternate approach
that is not tied to IPsec/AH. Our recommendation is to consider
approaches that are Binding Update specific, so that a solution can be
tailored to meet the actual requirement at hand. The main requirement
that needs to be met is that the use of MIPv6 with Binding Updates be
no less secure than the level of security one currently has with IPv4
(without mobility). That does not mean that the protocol needs to be
immune to *all* types of vulnerabilities. Rather, it means that a
solution should not introduce significant new vulnerabilities that are
not present in IPv4 today. (Of course, reducing vulnerabilities
compared to IPv4 is a very desireable goal.)

The WG is encouraged to look at the ID
http://search.ietf.org/internet-drafts/draft-bradner-pbk-frame-00.txt.
It was developed specifically as an alternate approach to addressing
the problems discussed in this note.

Jeff Schiller will give a brief presentation on the approach discussed
in the ID during the Mobile IP session at Minneapolis. The WG chairs
will likely be forming a design team to work on a specific solution to
the identified problems. This also will be discussed at the Thursday
session.

Thomas

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 20 Mar 2001 00:03:41 +0200

> the problems discussed in this note.

I'd like to point out an additional draft,

http://search.ietf.org/internet-drafts/draft-nikander-ipng-address-ownership-00.txt

which attempts to take one security view the very problem in 
a larger context.  It is our conviction that the problem mentioned
is just a specific example of a larger problem present in many 
IPv6 signalling mechanisms.  Mobile IPv6 BUs just seem to be the
one that gets most affected.  However, if things like SCTP Dynamic
Addition of IP addresses (draft-ietf-sigtran-addip-sctp-01.txt)
gets accepted, we will see probably worse examples of this problem.

> the identified problems. This also will be discussed at the Thursday

In addition to the PBK approach, a number of alternative approaches
are being emerged.  Based on some discussions that I've had with some
people looking at the solutions, even the various attack models seem
to be somewhat unclear.  I'd suggest that before advancing to select
between the proposed and to-be-proposed solutions, or desiging a new
solution, the design team focuses on trying to fully understand the
extent of the problem.

--Pekka

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 19 Mar 2001 14:26:30 -0800 (PST)

>       will be used without proper authentication.
These are not all the issues...

> compared to IPv4 is a very desireable goal.)
I think one of the most important issues is the authorization problem
that was raised at the last ietf.  Binding update contains two
important things. One is the home address and the other is the
care of address. If i can forge any of this two then there is no
use of having a binding update. Note that it is possible to use
IPsec and solve the authorization problem associated with
the home address and if we send binding updates *only*
to the home agent. Yes, this will kill route optimization. 
But i feel that this problem is unique to mobility i.e a
node moves to a new place and wants to direct all traffic
destined to the home address to a care of address. If i
can use any address, then the potential application of
Mobile IPv6 e.g. cell phones will suffer severe security
problem.

> the problems discussed in this note.
But this does not address the above problem which is important.
draft-snoeren-tcp-migrate-00.txt tries to solve this for TCP
which if can be generalized looks like a good solution for the
same problem that pbk-frame is solving. At least, pbk-frame
seems to have problems if somebody can spoof somebody elses
IP address and send the EID.

-mohan

---

From: Thomas Narten <[email-masked]>
Date: Mon, 19 Mar 2001 18:19:49 -0500

> These are not all the issues...

There may be others, but these seem to be the major ones, so that was
the focus of the message.

> use of having a binding update.

In order to produce a solution that is not more vulnerable than IPv4,
it is likely that one will want the equivalent of a 3-way
handshake. That is:

1) Mobile Node (MN) sends something to Correspondent (CN)
2) CN sends something back to MN
3) MN then sends something back of the CN that includes information
   that is only knowable if the MN receives the message in 2)

Once step 3) completes, the CN knows that packets it is sending to the
MN are reaching the MN (or at least to the node that it *thinks* is
the MN). I.e., this is what you get in IPv4 today, when communicating
with some node.

> Note that it is possible to use IPsec and solve the authorization
> problem associated with the home address

Yes. If the goal is simply to establish a set of keys between two
communicating nodes (i.e., to verify that packets are flowing in both
directions), you can probably do that with IPsec. I.e, negotiating
some sort of keys between two nodes, allows one to force a
re-authentication later, to verify that one is still talking with who
they were earlier. But mobile IPv6 as specfied today doesn't include
the details about doing this within the context of IPsec. Having said
that, there is still the overall concern that using IPsec to do this
is not ideal.

> IP address and send the EID.

Note that the pbk draft is not necessarily the *only* or even *best*
way to solve the issues at hand. It was developed, however, so that
there would at least be one approach to consider as a possible
starting point.

Thomas

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 Mar 2001 01:46:02 +0100

The IESG has concerns about the draft's dependency on IPSEC AH to
   authenticate Binding Updates.

=> I'll be politically incorrect but it seems the real issue is
Mobile IPv6 relies on a mandatory mechanism (IPsec AH) which is
expensive to implement, ..., ie. many people want to kill it...
If this is the case why not to say it (oh! this would be politically
incorrect :-).

    There are several issues here.

=> I assume that large servers stand for correspondent nodes. I don't
believe a good security level will be very cheap... The issue here seems
to be the price of IKE in terms of CPU cycles and message exchanges
(phase 1 in aggressive mode is 3 messages, phase 2 again 3 messages).
There are three obvious ways to fix this:
 - don't optimize routing (of course we don't want this solution)
 - define a little brother of IKE which will be able to build
   a pair of SAs in a minimal number of messages (it seems that
   3 messages are the minimal number and the BU can be piggybacked in
   the third one... If we merge aggressive and quick modes this can
   be done but we'll loose almost all negociation capabilities).
 - define an ad hoc mechanism... This will give the same result than
   the second solution but as a special mechanism we'll get special
   new bugs.

         IPv6 packets containing binding updates).

=> if this is true I can't explain why there are different working
implementations of secure Mobile IPv6... If the issue is identities
work only for UDP and TCP because of ports this is easy to fix and
will be fixed for other protocols too (the case of ICMPv6 is far
harder because ICMPv6 is used for many things and some can funny fail
when ICMPv6 is blindly secure, the neighbor discovery is a well known
example of this).

         There is a concern that this will not be rectified in the
         short term or that providing this level of granularity is
         even approriate for IPsec

=> I apologize because I'll be again politically incorrect:
if IPsec should be restricted to its current market (VPNs)
of course this is a real issue...

         leading to a possible result that the Binding Update
         won't be implemented/supported at all, (or even worse) that it
         will be used without proper authentication.
   
=> of course nobody wants this.

   The IESG strongly recommends that the WG find an alternate approach
   that is not tied to IPsec/AH. Our recommendation is to consider
   approaches that are Binding Update specific, so that a solution can be
   tailored to meet the actual requirement at hand.

=> so the IESG recommendation is an ad hoc mechanism.

=> I am not convinced by this proposal... IKE with self-signed/unverified
certificates gives a better security (because of the DH shared secret
and the symetrical authentication).

=> rendez-vous at the Thursday session!

Regards

[email-masked]

PS: for a standard correspondent the mobile node can use its care-of address
or its home address (the MUST for the care-of address is for the first
home registration from a visited network: the home address can be used only
after this home registration). The care-of address seems a bit better for
security (direct path) but has an authorization issue for the usage of
the home address in SAs. The home address has of course the opposite
properties (known/indirect path but the address is the same for phase 1,
phase 2 and BU).

---

From: Mohan Parthasarathy <[email-masked]>
Date: Mon, 19 Mar 2001 16:55:00 -0800 (PST)

> the MN). I.e., this is what you get in IPv4 today, when communicating
Then, this limits the use of mobile ipv6 for certain type of applications
where security is important. Or are we saying that those potential
applications does not need security ? Are you saying that we just
list the shortcomings of mobile ipv6 and let people decide what they
want to do with it ?

-mohan

---

From: AIme Le-Rouzic <[email-masked]>
Date: Tue, 20 Mar 2001 17:04:09 +0100

> authenticate Binding Updates.

 Even if the protocol doesn't require IPSEC to protect BU and
 BA, MobileIPv6 must cohabitate with IPSEC and IKE to let the
 mobile user using MobileIPv6 to protect the datas by AH or
 ESP.  IPSEC is useful to protect all the packet and in
 particularly BU and BA.

 Best regards

-- 
     ________________________Aime LEROUZIC____________________________
     BULL S.A ECHIROLLES FRANCE      mailto:[email-masked]
     http://www-frec.bull.com                tel: +33 (0)4 76 29 75 51
     Communications TCPIP                     http://intranet/lerouzic

---

From: Michael Thomas <[email-masked]>
Date: Tue, 20 Mar 2001 11:51:44 -0800 (PST)

> If this is the case why not to say it (oh! this would be politically
 
While the too expensive argument (for some metric
of expensive) has some appeal, the actual serious
issue is that authentication is not
*authorization*. That is, being able to assert an
identity does not in any way suggest what rights
and privileges I should gain given that identity.

The former is possibly a solvable (though
completely unproven), the latter would require
global coordination, treaties, etc, etc. I there
is high amount of desire to avoid those sorts of
implications if even vaguely plausible.

		Mike

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 Mar 2001 21:22:51 +0100

*authorization*.

=> this is *not* the issue raised in the IESG security concerns...

  That is, being able to assert an
   identity does not in any way suggest what rights
   and privileges I should gain given that identity.
   
=> for a common correspondent they are to build a pair of SAs in order
to authenticate BUs. Note this can be as small as AH for binding stuff
for this given address (and it is possible to keep the same address
(the home address) from the beginning). This is a very small privilege.

   completely unproven),

=> strong authentication seems very hard (PKIs don't work,
DNSsec is not yet usable, AAA is still in the spec phase, ...).

   the latter would require
   
=> I disagree but this is not part of the IESG concerns (nor the
security implications of the home address options).

Regards

---

From: Jean-Michel COMBES <[email-masked]>
Date: Mon, 26 Mar 2001 16:59:15 +0200

Hi,

sorry for the delay ...

Thomas Narten a écrit :

>       current generation of IPsec/IKE implementations

JMC :
I don't agree : I'm used MobileIPv6+IPsec/IKE implementations (INRIA and
Bull) and all BU/BAck are authenticated with AH (using IKE) ...

> (e.g., the IPsec

JMC :
Agree (maximum granurality is Next Header number) . A solution, perhaps,
would be to allow a different Next Header number to BU and BAck
Destinations Options. Is it possible ?

Regards.
JMC.

--

France Telecom R&D - DTL/SSR
Jean-Michel COMBES, Internet/Intranet Security
E-Mail : [email-masked]
Phone +33 (0)1 45 29 45 94, Fax +33 (0)1 45 29 65 19
PGP fingerprint : 07C6 37BF 4DE5 1CE1 EEB1 1F13 5D75 9E33 CFA7 0214

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 27 Mar 2001 10:53:19 -0800

> draft-snoeren-tcp-migrate-00.txt tries to solve this for TCP

Why doesn't pbk solve the problem? 

PF

---

From: Stuart Jacobs <[email-masked]>
Date: Tue, 27 Mar 2001 14:02:38 -0500

IMHO the pbk is a specific example of a special pki oriented just for 
something like MIP.  I would go farther and say the if these pbkeys were 
kept in certificates then they could also be used to initially authenticate 
entities.

Stu

>Why doesn't pbk solve the problem?

==========================
Stuart Jacobs CISSP
Sr. Technologist
Verizon Laboratories
40 Sylvan Road Waltham, MA 02451-1128     USA
telephone: (781) 466-3076   fax: (781) 466-2838
[email-masked]     [email-masked]
==========================

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Mar 2001 11:09:50 -0800 (PST)

I think that the first order question that must be
asked is how we're deriving trust. I believe that
PBK is deriving that trust based on return
routability. If that is the case, I have to wonder
what the initial and subsequent public key
operations are doing to increase security. Why,
for example, can't the CN just continue using the
return routability trust it used to initially
establish trust with the mobile node? What
security function is the public key operations
performing? What vulnerability are they closing?

		 Mike

---

From: Jean-Michel COMBES <[email-masked]>
Date: Mon, 26 Mar 2001 16:59:15 +0200

Hi,

sorry for the delay ...

JMC :

JMC :

Regards.
JMC.

--

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 28 Mar 2001 10:41:46 -0800

> Destinations Options. Is it possible ?

Or just over UDP, as is done with IPv4.   The optimization of piggy-backing
MIP control traffic onto data traffic has back-fired.

PF

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 28 Mar 2001 11:00:58 -0800

At the risk of exposing my ignorance of security protocols:

I assume that the same scaling problem (load at the CN of establishing SAs)
exists for IPv4 route optimization as well.
(draft-ietf-mobileip-optim-10.txt)

PF