[isf-wifidog] Roadmap?

Alexandre Carmel-Veilleux saruman at northernhacking.org
Mer 18 Mai 20:29:39 EDT 2005


On Wed, May 18, 2005 at 12:03:27PM -0700, Jo Walsh wrote:
> 
> hello Mina, list; our 2 cents from quite new wifidog users:
> 
> +1 on this; wifidog-auth-lite seemed like a good start; it was very
> easy to write a python clone of open mode to plug onto our userdb/
> portal server; i'd be happy to contrib to a standalone python auth
> server in future. NoCatAuth had pluggable modules for different
> sources of userdata (DBI,LDAP,PAM, etc...)
> this does seem like a good way forward.

	I have commit rights to the CVS and I wouldn't mind coordinating
the light-weight auth server(s). I've been mostly inactive since the new
year and it's high time I got back into coding.

	For the most part I coded a lot of the gateway and along with
Benoit, Philippe and Dave designed version 1 of the protocol. However
I've gotten quite out of touch with wifidog since, it's been all about
the auth server which is good for ISF but very custom and getting
quite complicated. Something a little more customizable is appealing
right now to me.

> having the token exchange / URI protocol exchange documented would rock.
> I've been talking with Schuyler about his plans to implement auth in
> NoCatSplash based on the NoCatAuth design but using the TEA encryption
> algorithm rather than GnuPG (12 lines of C!). This won't happen *very*
> soon, so i am working with the wifidog client now.
> 
> my plan is for our auth server to interface with both. right now we
> perceive possible security issues in that your design can have https
> between gateway-running-wifidog and auth-server, but is sending
> plaintext between the client and the gateway.

	The goal of the protocol as it stands is to send a string of
random garbage called a "token" for one time use to the gateway. That
way, encryption is not needed: a token is only good once for one
combination of gateway, mac and IP. The login happens with the auth
server over SSL. The gateway validates the token through the auth
server.

	The two main routes of attack are to hijack another user's MAC,
IP and token. Requiring a DoS on that person before. And a Man in the
Middle attack between the gateway and the auth server at which point,
you already have, by definition, Internet access so the point is moot.

> This is what i inferred from looking at auth-lite, please correct me
> if this assumption is wrong! I don't mind this much anyway;
> a login password to a few syndicating web services
> is information i'm happy to scatter around the ether. I imagine that a
> user base looking at you/Splash, with more transaction oriented use
> cases in mind, might care rather more.

	No password ever gets sent over the clear if the auth server is
using SSL. Third party apps on the gateway, if any, are on their own.

	ISF uses openvpn for management of hotspots. It could be used to
wrap the Auth Server <-> Gateway channel in strong encryption (I think
it uses SSL or something very similar, they certainly use certificates.)
It's available for openwrt and works on all the 42+ ISF hot spots.

> we've been patching wifidog client so that if gw_id is not set in
> wifidog.conf, then the client sends the MAC address as gw_id instead.
> making an ipkg... will keep pinging; will send a dodgy inkscape flow
> diagram of the putative splash/auth design if useful for protocol
> re-engineering...

	Have you gotten this to work? It's a nice feature and if it
works well, I think it should go into ISF's gateway.

Alex
-------------- section suivante --------------
Une pièce jointe non texte a été nettoyée...
Nom: non disponible
Type: application/pgp-signature
Taille: 230 octets
Desc: non disponible
Url: http://listes.philippeapril.com/pipermail/wifidog/attachments/20050518/62bbf810/attachment.pgp


Plus d'informations sur la liste de diffusion WiFiDog