> 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.
