Subject: [mobile-ip] Some thoughts on BAKE and MIPv6 security

From: Michael Thomas <[email-masked]>
Date: Tue, 1 May 2001 15:01:45 -0700 (PDT)

Lars,

I hope that after all of the dust settles, we
still have a way to secure binding updates with
strong authentication when the conditions are
right (ie, when it is reasonable to assume some
sort of distributed keying system). That said, it
would be nice if we had a "secure-enough"
mechanism for when that's not practical or
desirable.

In the home agent cookies draft, I tried to
consider what would happen if the wireless link was
unprotected.  When thinking about how to protect
against it, I ran into some issues with NAT's
which seemed pretty pathological. After a while, I
gave up for the time being since the entire
scenario seemed pretty out in the weeds: if you
have a first hop which is eavesdroppable where
there are potential attackers, you have a pretty
basic problem which should be addressed at L2. I'm
hoping that the 802.1x folks are trying to address
this, as well as the 3G folks because the problems
with this scenario are certainly not limited to
binding updates.

		Mike

Lars Henrik Petander writes:
 > Hi all!
 > 
 > Since BAKE allows active attacks on local links using a broadcast medium
 > that redirect the traffic to the attackers machine, it allows a similar
 > attack against CNs as a fake icmp redirect. A good example of a vulnerable
 > host is a MN in its home network, which is likely to be wireless and
 > eavesdroppable.
 > 
 > Although this vulnerability already exists in IPv4 it might lead to
 > the disabling of MIPv6 CN functionality in many nodes in the same way as
 > ICMP redirects often are disabled today. Do we really want to limit the
 > use of full CN functionality to trusted links? 
 > 
 > I am afraid that any unauthenticated key exchange is likely to suffer from
 > the same (or a similar) vulnerability. Thus it would probably be a good
 > idea to make strong authentication of the peers possible by using public
 > key cryptography, which would allow them to retrieve each other's
 > certificates from DNS or some other repository and authenticate each other
 > strongly. In absence of a PKI they could always revert to unauthenticated
 > key establishment, the use of which should be configurable in CNs.
 > 
 > 
 > Regards,
 > 
 > Henrik Petander
 >

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 02 May 2001 08:35:07 +0100

[Sorry for the late reply.]

Henrik,

I am covering just a couple of points.

> > MN's home network is indeed vulnerable, since being located there
> > allows an attacker to launch an active attack against an arbitrary CN.

> I meant MN in the sense of it being just a CN while it is in its home
> network.

For CNs that are also MNs and away from home, the next revision of BAKE 
will contain protection.  The basic means is to use a reverse ESP 
tunnel from the CN to its home agent, as suggested by Francis Dupont.

Right now we are NOT planning to support insecure home links.
IMHO, if your "natural" home link is insecure, you most probably
should not use that as a home link at all, but have a box to
act as a virtual home link for a large number of MNs.  That would 
certainly be a secure home link, being inside one box :-)  The only
drawback in that scheme is that your mobiles will always be 
away-from-home, but maybe you should consider that a benefit :-)

.....

> > from the given design constraints: do no harm (or be as safe as IPv4 is)
> > and do not require any heavy computations.  The latter requirement
> > basically made all PK operations and D-H infeasible.
> 
> Probably the MN's will use SSL, SSH or other protocols requiring
> similar operations in any case. BAKE is now the only proposed solution
> fully without public key operations.

Well, I think that there will be very different MNs, and very
different CNs.  Since being a CN is aimed to be a requirement for
anyone (e.g. light bulbs and computers embedded in clothing and shoes),
we cannot mandate D-H or public key operations.

I am working to see how to have D-H and PK as an optional feature in BAKE, 
but getting things to work out nicely it not so easy.  And I want
any D-H or PK operations in BAKE to fit nicely in, meaning that
  
  a) there must not be new DoS vulnerabilities
  b) there must be the _minimum_ amount of options.

Reaching those goals is not so easy.

> > Authentication and public key operations are a different issue.
> > I think that something like CAM/SUCV/PBK-ADDRESSES could and
> > probably should be added to BAKE as an optional feature.  I just
> > haven't had enough time to properly think about that yet.  If you
> > have any suggestions of how to do that, please share them.
> 
> That sounds complex.

I don't think it necessarily needs to be that complex. 

What I am trying to reach (I don't know if I can) is a protocol 
that has exactly one option: run without D-H and PK (the current BAKE),
or run with both D-H and PK.  In the latter case the keys can either 
come from some CAM/SUCV/PBK-ADDRESSES like mechanism, or from 
locally trusted certificates or some other locally trusted means.  

The policy will not be so simple, if you want to support all the
alternatives.  But the protocol itself MUST be as simple as possible.

> > Please remember the underlying authorization problem.  This question
> > is really not only about knowing who your peer is, but also making
> > sure that your peer is indeed authorized to create bindings for the
> > given Home Address.
> 
> Yes, that is true and I think that DNS provides a nice way of doing this.
> Although with out deployment of DNSSec this approach is
> applicable only if MN and CN use the same DNS server.

If you go ahead and analyze a little bit what using secure reverse
DNS would require in practise, you may realize that it is not
necessarily that nice.  Yes, it is the "right" PKI, meaning that
if we use a PKI for authenticating binding updates, we definitely
should use secure reverse DNS.  But, just to amuse you, take one
realistic example with two arbitrary hosts and try to figure out 

  a) how many DNS queries you need
  b) how many SIG verifications you need

The numbers are not so nice...

--Pekka