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