user space 802.1x supplicant program.

first of all, I'm becoming slightly more proud of the code --
this is work in progress, the n-th rough version that works.
it still needs cleaning up.

First (or so) version that mounts itself at (after) /net, as /net/8021x.
/net/8021x/^(status log tlslog) have some useful info.
tlslog output is likely incomplete for the (huge) certificates
(I recall I had to change /sys/src/libsec/port/tlshand.c
 a while ago to see all of it).
/sys/log/8021x now contains overview details.

Further Ideas:
 - control debug amount via ctl
 - be able to read current settings from ctl
    (such that editing and writing back is simple)
 - start keeping counts, and report via stats
    (use stats from 802.1x document for inspiration)
 - when debug option given, start collecting data
    for log/tlslog right away, instead of waiting for open --
    otherwise we will always miss the initial debug msgs.

(the next may change when working on russ' 9fans reply)
 - accept 'realm' (802.1x auth domain) via ctl,
    only start doing real work after this has been set,
    because we need this in one of the first eap messages
 - accept auth type via ctl (currently only ttls-pap)
 - accept ttls-pap username and password via ctl
 - ask for username and password via factotum if
    not given via ctl (we only need these for the pap
    over the tls tunnel, in the second phase)

Then, to take root from fs using 802.1x auth we
need to enhance plan9.ini a bit like for wavelan,
to be able to specify the auth type, real, username
and password; and we have to adapt the boot stuff
to start 8021x (we already did this earlier) and to
write the plan9.ini configured items to it (not done).

Now cleanup seems to be right --
if everything works fine, no more threadint needed.
As a safety measure there still is threadkill,
just in case all else failes but that code should never be called;
maybe we should sysfatal instead of calling that code
(see the discussion in thread "thread confusion" on 9fans).
The only problem with sysfatal (or any other failure) is that
this may be run at boot time as part of the set-up needed
to get a root filesystem - if this gives up, we would then
(within 20 minutes) loose the connection to the root fs,
unless the remaining time is sufficient to bring this up
again.

clean up in particular:
 - creating/parsing of messages [partly done, can still improve ttls.c,
    esp. regarding the send? and recv? variables; merge the various
    send/build frame messages]
    [cleaned up the Buf type and remove all send? and recv? variables]
    [todo: rename ttls.c wbuf and rbuf into something more suitable,
     or even better, just have one set of bufs and take both ptoe and etop
     from it]
 - debugging output (reduce amount, make more useful)
    [now -d is deprecated, lots of debug goes to syslog,
     should be changed. file server file?]
    [now file server files log and tlslog]
 - more robust message parsing (check all lengths)
    [tried to do this]
 - make sure we do the right thing when we 'hang'
    in the tls handshake, and have to clean up because
    in the middle of the tls handshake we receive a new
    Identity request - tlsClient may hang in readN)
    [high priority. now we threadkill the clientproc,
     and this may waste resources:
       - keeping open handle to '#a/tls', in particular
          to #a/tls/X/hand' while handshake was going on,
          ties up a '#a/tls' instance
       - consume memory somehow kept do to this]
   [updated to instead threadint the clientproc,
    hoping this will take it out of readN, if necessary,
    and still gives it the opportunity to clean up]
   [updated to work around a 'close pipe with reads
    hanging at both ends' problem, so now we should
    be able to run without threadkill/threadint
    (but see above)]
 - fix the timers such that reset gets rid of one that
    hangs in sleep [high priority]
    [restructured the timer stuff, better but still not perfect]
    [simplified the timer stuff: timerproc just sends ticks,
     the counter decrements and expiration checks
     are done in/at the alts]
 - fix memory leak (certificate? sessionID?) [done, I think]

I hope this will happen in due time.

I'm making this available to allow constructive criticism.


This depends on:
 - the tlshand patches I submitted on sources/patch
    and which have been applied in the mean time
 - fastkey support in wlan driver
     (separate wavelan.[ch] etherwavelan.c)

It assumes a writable, append-only /sys/log/8021x file.
to which it writes some debugging;
for the details see the log and tlslog file of the fs.

command line option -d outputs lots of debugging
command line option -D outputs tls handshake debugging

there are command line options to pass thumbprint directory,
and use the thumbprints to check certificate, but this
has never been tried.

before starting this the right essid should be set,
and encryption should be enabled.
wep keys should be (left) empty.
(at utwente: essid WLAN, crypt on,
 user name (below) is radiususer@utwente.nl
    i.e. mxxxxxxx@utwente.nl or sxxxxxxx@utwente.nl
 password is radius password)

it uses factotum to ask for a user name and password,
only once, at the start of the program (but see below *)
The user name should be of the form ``user@domain'' .
the ``@domain'' part is used in the response to the
eap-identity request (to know with which radius server to speak)
the full  ``user@domain'' and ``password'' are used to
authenticate in the second phase, after the (T)TLS
connection has been set up, by sending it as a PAP
message over the secure connection.

(*) One could argue that it should ask ``by need'',
which is easy in case of the password, which we
only need in the second phase of the authentication,
so we can postpone asking for it.
We do need an ``external identity'' early in the message
exchange, as the response to the eap identity request.
this ``external identity'' can be a domain; it may/will be
used by ``the other side'' to choose/indicate the (radius?)
server which will handle our authentication request.

One advantage of ``by need'' asking and re-asking
would be that a wrong user name or password
(but with correct ``external identity'') which would
result in a fail in the second phase, could be corrected
in factotum (delkey, after which new key will be requested).
The question is, if then the ``external identity'' should be
requested via factotum (or derived from the username),
or just be given as command line option.


we do not need to worry about TLS session resumption,
after the rewrite of the state machines + threadmain
the whole auth+keysetting now takes approx. 2 seconds
to complete (instead of the earlier 15 sec only needed
by tlsClient


TODO:
 - choose smaller stacksizes -- acid -lthread stacksizes() gives
      threadmain (pae) 968
      readproc 248
      clockproc 16
       back 368 (could be in main process with pae)
      etherproc 240
update: reduced stacksizes to 8k (from 32k)
     threadmain (pae) 972
      readproc 252
      clockproc 264
       back 372 (could be in main process with pae)
      etherproc 244
update 2: changed some local variables into global ones,
                and moved back into main process with pae
     threadmain (pae) 472
      readproc 252
      clockproc 264
       back 372
      etherproc 244
 - rename clockproc to tickproc
 - have threadmain and back in same process?
 - make sure we do the right thing when AP mac == 44444444
    which means we are not connected, eg. when essid is ok
    but crypt is off
 - code cleanup
 - test server certificate thumbprint checking
    [not tested, but we have code that is supposed to work]
 - reduce (debug) output to syslog
 - add nsec output to log
    (need millisecs like snoopy, but formatted as hr:min:sec.ms)
 - make the whole thing a file server?
    with e.g.
     - a ctl file for control messages (what kind of?)
     - a stats file for statistics (e.g. numbers suggested in 802.1x standard)
     - a log file, to which logging will be written if/when opened
     - a tlslog file, to which the tls handshake trace will be written,
        if/when opened
     - others?
 - manual page

Axel.Belinfante@cs.utwente.nl