Subject: [MOBILE-IP] Simpler AAA for public networks with no accounting

From: Niels Möller <[email-masked]>
Date: Thu, 16 Nov 2000 16:54:40 +0100

Hello all,

I'm not intimately familiar with mobile ip, but I have at least read
RFC 2002, RFC 2977 and draft-ietf-mobileip-ipv6-12.txt. I'm thinking
about a special case, namely mobile wireless networks that are (i)
public, and (ii) not accounted.

By (i), I mean that the operator is willing to provide access to
anyone who shows up in the area, and by (ii) I mean that the operator
either doesn't charge the users anything for access, or that he
accepts payments using some (possibly anonymous) digital payment
system that is orthogonal to the network infrastructure. The operator
still need some way to track users that abuse the system.

Free access with no charge may seem unrealistic, but it may not be. If
I already pay for a decent 10Mbps or more connection to my home or to
my office, and if I can get a base station for $1000 or less, I or the
company may be willing to install a base station, and let friends,
employees and passers-by use it freely (perhaps bandwidth limited or
routed with a lower priority). Likewise, for cafés, hotels, airports
etc that already happen to have a decent net connection, the cost for
setting up a few base stations may get low enough that there's no
point in charging extra for it; if customers like it and stay for
another beer or coffee, that's good enough.

So, what simplifications can be applied to this case? To me, it seems
that one can do away with all the security associations except the
ones between mobile nodes and their respective home agents, and still
get an appropriate level of security.

It's true that one really needs an association between the mobile node
an the base station/FA/access point in order to get good protection
against link level attacks, like eavesdropping and connection
high-jacking. However, for highly sensitive data, one ought to use
end-to-end security anyway, and we may be able to live with the other
threats.

One effort to get public networks off the ground, with a minimum of
central organization, can be found at <URL:
http://www.elektrosmog.nu>. One draft for its security architecture
can be found at <URL:
http://www.lysator.liu.se/~nisse/misc/elektrosmog-authentication.txt>,
included below for convenience. I appreciate your comments, in
particular for the final section on using Mobile IP.

Best regards,
/Niels Möller

--------------8<-----------------
On the first elektrosmog meeting (2000-09-03) we talked about
authentication of elektrosmog users. What follows below are some of my
thoughts on the issue.

Connecting to the Internet via Elektrosmog is a process that takes
several steps.

1. The client talks to a local DHCP server (or stateless address
   autoconfiguration for IPv6). This is done with no authentication
   whatsoever; anyone can get an ip-address on the local network. A
   side effect is any client can communicate with other nearby
   clients, without needing to associate with elektrosmog.

2. Next, the client talks to the base station to authenticate. One
   probably needs to support several authentication mechanisms; for
   local users one may use kerberos or SRP paswords (clear text
   passwords are obviously not suitable). In order to authenticate
   users that are not previously known by the base station one needs
   something more scalable, e.g. dh + spki certificates. One may want
   to look at the IETF AAA working group.

   The output from a successful authentication should create the
   following values:

   A. A session key shared between the base station and the client,
      used for creating a pair of IPSEC tunnels between the client and
      the base station. Packets received from the client that are
      properly authenticated using the session key are routed to the
      Internet, and packets from the Internet to the client are routed
      back using the tunnel.

   B. Some kind of identity that can be used to track misbehaving
      users. It doesn't have to be a globally unique name; it's good
      enough with some pseudonym and some kind certificate from
      someone who promises to reveal the real identity in case of
      abuse. One could also use Freedom-like pseudonyms that can never
      be tracked, but costs some amount of money to get and are
      blacklisted in case of abuse.

   C. Information on whether or not the user should be charged for the
      connection, and if so, how much, and by which micro payment
      mechanism and from which account. The user should also get
      information about how much this base station wants to charge.

   (B) and (C) are independent: B is needed to deal with abuse (if we
   beliee we have to do that; why would a spammer or cracker use a
   slow wireless network in a public area?), while C is for accounting
   and charging.

3. The lifetime of the tunnel created in (A) is called a "session".
   Sessions can cost money. The easiest way to make sure that a user
   pays for the right amount of connection time (i.e. if we forget
   about all the other problems with electronic payments) is perhaps
   to use some kind of "tickets". The base station tells the client
   what the price is for a ticket and how long a ticket is valid (this
   lifetime is called a "period").

   For each ticket period, the client sends a valid payment including
   a sequence number to the base station. If the base station doesn't
   recieve payment in time, it sends a reminder, telling the client
   which sequence number it expects (analogous to a pay phone buzzing
   when you need to insert another coin). If payment is not received
   in reasonable time, and a few reminders have been sent, the base
   station stops routing packets through the tunnel. The tunnel state
   can be kept around for some more time, so that the client can
   reactivate it by just sending another payment.

   It is important that retransmissions of payments really are exact
   copies, so that the base stations can't charge the user for each of
   the retransmitted copies of a ticket. The payment can simply be a
   certificate authorizing the base station operator to withdraw a
   certain amount of money from a given account, but more efficient
   mechanisms are possible.

   The payment protocol can be run on a tcp connection, which is kept
   open for the life time of a session (if one believes that tcp's
   handling of retransmissions etc is appropriate for this
   application), or some special udp-based protocol [ paf commented
   that we *should* use tcp ]. Details depends on the payment protocol
   being used.

A few other things that need consideration...

Is it possible to use DHCP to tell the clients where to find an
authentication server and a payment server? Or should one use a server
location protocol? Or used fixed "private" addresses like 10.0.0.17
for Elektrosmog-local servers?

For some authentication mechanisms, a client may need to speak to the
outside world in order to authenticate to the base station. For
example to run kinit one will need to talk to a kerberos server, and
probably also with some dns server. So the base station should be able
to route some unauthenticated traffic.

Mobile IP issues

At the latest meeting (2000-10-10) we talked about using mobile ip
(RFC 2002) to solve authentication as required in (B). The idea is
that the mobile node (i.e. the Elektrosmog client) has a Security
Association (i.e. a shared secret key) with some Home Agent. The base
station (or some other local server) acts as a Foreign Agent. There
are no security associations between the FA and either of the MN or
HA.

Now, the the MN sends a Registration Request to the FA which forwards
it to the HA. The home agent replies with a Registration Reply, send
to the FA and forwarded to the MN. We have to use a "Co-Located
Care-of address", as there's no SA between the HA and FA.

The crucial question is: Does this qualify as a identification as in
(B), from the point of view of FA, the base station? An abuser could
set up some kind of "fake" home agent, and use that to get access or
give access to other abusers.

I think it is sufficient, assuming that we don't try to do accounting.
An abuser that is able to set up a machine to answer registration
requests for him, could just as well have used the machine directly
for mounting his cracking or spamming attempts; it probably have
better bandwidth than the elektrosmog system. And in any case, the
elektrosmog station will log each user's ip-address with its home
adress and the address of the home agent, so an extra hop via
elektrosmog will not provide much hiding.

We want assure tha FA that abuse by MN can be blamed on the owner of
HA. But FA doesn't trust MN, and it doesn't trust HA. Would it be
possible for a MN to send some messages to an unrelated innocent HA,
fool the FA to think that the registration with HA was successful, and
start routing? If so, abuse by MN will be blamed on FA or HA, which
are both innocent.

/Niels