9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: [9fans] config wisdom? (factotum? cmdline flags? ctl file?)
Date: Wed,  5 Oct 2005 19:08:39 +0200	[thread overview]
Message-ID: <200510051708.j95H8de10107@zamenhof.cs.utwente.nl> (raw)

(back to boring technical questions/discussion)

I'm still not exactly sure what would be the best
(working, easiest to use) way to give my 802.1x
supplicant the information it needs to do its work,
so I'm looking for opinions or reasons to pick one
over the other.

I envision it being run in two ways:
 - on boot, to get the network up to get root from fs
 - by the user on an already up&running system

I can imagine the use of:
 - command line options (cumbersome)
 - factotum (remembers things for us)
 - writing to ctl file (cumbersome)
 - env vars
 - reading config file (needs to think of format)

linux supplicant uses an intimidating config file.
macos x seems to have a nice gui for it.

the config info consists of:
 - 'external identity' (realm, authdom)
 - auth-scheme-specific stuff, for one or more
   auth schemes (currently only ttls-pap is implemented)
   (for ttls-pap we just need user, password,
	where user may be something like name@realm)

So far I call auth_getuserpasswd only once at
the start of the program, which makes factotum ask me
for user and passwd. I expect the user to be of the
form name@realm and then I use the '@realm' part
also for the external identity.
This may not work in the general case.

There seem to be some disadvantages to this:
 - it is easy to forget the '@realm' part
   when factotum asks for user
   (I found how I can make auth_getuserpasswd
	ask separately for realm, in addition to user
	and password, but how to make use of that once
	it is in factotum??)
 - it is not very 'dynamic': in case of errors
   in username or password one has to kill the
   8021x program and delete the keys and start over
   (or else the program will keep retrying with
	the erronous stuff)
   of course one does not make errors, but still...
 - when I tried to integrate this into the booting
   process I did not succeed to make this work
   with factotum, mainly because it might be nice
   to first start 8021x and bring the net up and
   only then start factotum, such that
   factotum can look for a secstore.
 - in the general case much more complex config
   may have to be accomodated
   (do not worry about that now?)

I have been thinking of giving external id (realm)
on command line, and then ask factotum for user/password
whenever it is needed (i.e. in each re-auth).
The latter part allows to 'only' delete keys
and supply new ones, while the program continues
running. (this does not solve the case of mistyped
realm comand line option though)
It might even be possible 'decide' if an 8021x ttls-pap
auth failure was most likely caused by an erroneous
user/passwd, in which case we might try to tell
facotum (how?), so it can ignore the user/passwd it tried.

For the on-boot running,
I've been thinking about using plan9.ini vars to
 - decide whether or not to start 8021x
   (already succeded to use this)
 - specify user/passwd/realm a la the wvkey stuff,
   and then write those to the 8021x ctl file
   but this means I would use _both_ factotum
   _and_ the ctl file to provide the same info.
   that seems a bit duplication of ways/work.


Too many options (and I still have to try to get
the log thing of my previous question working).

Axel.

(hats off to all who contribute(d) to plan 9 --
 tweaking this 8021.x thingy does give me some feedback
 on what effort it (may) take(s) to get things right,
 or (maybe more realistic in my case :-)
 just somewhat arbitrary close(r) to 'right')


             reply	other threads:[~2005-10-05 17:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-05 17:08 Axel Belinfante [this message]
2005-10-05 18:48 ` Russ Cox
2005-10-06  8:02   ` Axel Belinfante

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200510051708.j95H8de10107@zamenhof.cs.utwente.nl \
    --to=axel.belinfante@cs.utwente.nl \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).