Re: [9fans] factotum/802.1x catch 22?

[Axel Belinfante <Axel.Belinfante@cs.utwente.nl>]

> if code needs to be added to the bootstrap process to feed factotum
> wireless keys and to later point factotum at the secstore server, then
> that code needs to be added.

just to give some background of what 802.1x is about,
and the role of my current 802.1x supplicant.
(see also http://en.wikipedia.org/wiki/802.1x )
I'll reply to lucio in a separate message.

802.1x is a standard for port-based Network Access Controls,
to allow access to the LAN only to those that have proven
themselves worthy. the network hardware (switch, access point)
does not allow those unauthenticated to talk any protocol other
than 802.1x, which is to be used for authentication with (e.g.)
a radius server (not even dhcp may be available yet).
there is the concept of a 'realm' to allow roaming: the realm
tells which radius server (could be off-site) should be
contacted to do the authentication.
a site can choose from many possible authentication methods.
at our univ a tls tunnel must be set up through which a
user/passwd is passed (this is the ttls-pap method).
other methods may involve e.g. certificates or challenge/resp.

I think 802.1x was originally developed to control access to
wired networks. when used on wireless networks 802.1x can be
used to distribute (and periodically renew) wep keys.


my 802.1x supplicant takes care of setting up the tunnel
and passing the user/passwd over it. it uses factotum
to obtain the user/passwd that is to be passed; it should
(but does not) use factotum to do the passing such that the
supplicant never sees user/passwd.
for other auth methods (when implemented) factotum might
play a bigger role (our univ now also supports peap
which uses mschap).
the supplicant receives wep keys passed via 802.1x and
feeds them directly to the wavelan driver (by writing
to /net/ether0/0/ctl). also here factotum could be used,
but I guess that would only complicate things (I have
a vague recollection that russ advised against passing
the wep keys to via factotum, but I could be wrong).

only after the supplicant has authenticated itself
for the first time (and obtained wep keys in the process)
it will be useful to run ipconfig, because dhcp may not work
until authenticated.
I wrote 'may not' because this seems to be a local decision.
at our univ dhcp does not work until authenticated.
at a different univ (where I can use the wireless net
via a roaming agreement, and authentication is done
using our univ radius server) dhcp is also available when
unauthorized (but ip is disabled until auth-ed).

after the supplicant has authenticated itself and
obtained wep keys it continues to run in the background
to do the periodic re-authentication and obtain new
wep keys and pass them to the wavelan driver.


Axel.