Subject: Re: [mobile-ip] Concern over draft-team-mobileip-mipv6-sec-reqts-00.txt

From: Charlie Perkins <[email-masked]>
Date: Wed, 01 Aug 2001 00:56:40 -0700

Hello Thomas,

Thomas Narten wrote:

> "Charles E. Perkins" <[email-masked]> writes:
>
> > This is because it is declared several times in the draft that mobility
> > opens security vulnerabilities when home agents and correspondent
> > nodes accept Binding Updates without any authentication.
>
> One point that we all could probably be much more clear about is that
> it is the route optimization part of MIPv6 that has the security
> issues.

The route optimization part would only be vulnerable if Binding
Updates could be applied without authentication.  Since this is
clearly prohibited, I am sure that the route optimization part does
not have the vulnerability under discussion.  How can it be otherwise?

Maybe some nodes wouldn't have security associations with
a mobile node sending a Binding Update.  Then they could not
accept the Binding Update.

Is there something in the current specification that does not make
this point sufficiently clear?  If so, please let me know what
improvement to make.  Or else, maybe I am not understanding
your point...?  I am really curious to find out!

Do you mean that some nodes wouldn't be able to accept Binding
Updates at all?  Then why is this a security vulnerability?

Do you mean that some nodes would accept a Binding Update
without authenticating it?  Then this is a violation of Mobile IPv6!

I think this is a fundamental enough point, with specific technical
documentation, that we should be able to agree on the issue,
but somehow it seems that there is not yet agreement, so I hope
you can help me see why you believe there is some vulnerability
here, when I am so certain it is prohibited by the existing
specification!!

> I agree with Charlie that it is not MIPv6 in general.  This
> distinction is very important, because MIPv4 has *exactly* the same
> problem. Yet, very few people (and especially not those in the press)
> seem to be noticing this.  This has to some extent caused additional
> PR problems for MIPv6, since many folks don't distinguish MIPv6 from
> just the route optimization. It would be good for all of us to
> continually educate folks that don't make this distinction.

Even IPv4 route optimization doesn't have the vulnerability,
because IPv4 Binding Update is _also_ required to be discarded
unless it can be authenticated.

> > More generally, I would suggest that every scenario should have
> > an additional "STATUS" subtopic heading.  That is, for each of
> > the scenarios, the current status of the threat should be listed.
> > So, for instance, each of the remote redirect scenarios (in addition
> > to being reworded) could contain the following paragraph:
>
> >    STATUS: prevented within Mobile IPv6 by the requirement that
> >            all Binding Updates MUST be validated using the
> >            unforgeable Authentication Data provided along with
> >            the Binding Update.
>
> This is an interesting suggestion. But rather than making the threat
> analysis document do this for the various proposals, it might be
> better for each proposed solution to describe how (and whether) it
> deals with each of the described threats.  Certainly, one of the
> intents of the threat analysis document was to provide a
> straightforward way of comparing various proposed solutions to see
> exactly which threats they guarded against.

I was talking about specifically the "base" Mobile IPv6 document,
without key distribution.  I would agree that ancillary documents
should need to do their own analysis -- and yet the threat document
mostly refers to features specific to the Mobile IPv6 document itself.

Regards,
Charlie P.

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 5 Aug 2001 14:55:46 +0200 (CEST)

> 
> Hello Erik,
> 
> I thought that we were going to have to devise a way for all
> IPv6 nodes to get security associations with mobile nodes.
> Isn't IKE too much to ask from every IPv6 node?  And, yet,
> I agree that we should have a way to use IKE to get keys that
> would be useful for authenticating Binding Updates.  I just
> expected it wouldn't be the universally mandated way.

Charlie,
your comments seem to be unrelated to my comment.
I was merely commenting on what looked like a statement that IKE can be
used to create security associations for something other that ESP and AH.
Thus my comment had no direct association with mobile IPv6.

  Erik

> Erik Nordmark wrote:
> > 
> > > Therefore, we are free to choose between
> > > MIP-specific BU protection and IPsec AH independent of how
> > > the key management is solved.
> > 
> > You are assuming that it is easy to use IKE to create non-IPsec keys e.g.
> > for MIP specific BU protection.
> > Are you sure it is that easy?
> > (I don't have any data - but I thought IKE was tied to IPsec.)
> > 
> >   Erik