[9fans] config wisdom? (factotum? cmdline flags? ctl file?)

[9fans] config wisdom? (factotum? cmdline flags? ctl file?)

[Axel Belinfante]

(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')

Re: [9fans] config wisdom? (factotum? cmdline flags? ctl file?)

[Russ Cox]

You should use factotum to hold keys.

   key proto=pass service=802.1x user? realm? !password?

Ideally you wouldn't use proto=pass but I don't know
enough about 802.1x to know whether that's easy.

If you get a key from factotum and you are sure that it is
incorrect, I think it would be okay to try to delkey it before
asking factotum again.  Maybe there should be a disable
control message to mark the keys disabled like factotum
already does for found-to-be-bad p9sk1 keys.  But delkey
is fine to start and we'll see if that's useful.

To get the realm out, you'll want to modify auth_userpasswd
to return the AuthRpc* (perhaps inside the UserPasswd*)
instead of auth_freerpc'ing it.  Then you can call auth_attr
to get a list of all the public attributes for the key,
and _strfindattr to find the realm.

That only answers the question of where to get the keys.
It doesn't fully answer the question of which one to use.

A user with keys for multiple realms may give factotum
multiple keys, in which case the intended-canonical approach
is to give your program a -k keyspec option like cpu(1) has
and pass that to factotum when you start the protocol:

   auth_userpasswd(auth_getkey,
     "proto=pass service=802.1x user? realm? !password? %s",
     keyspec);

So if the user says -k 'realm=nj9620' then you get the
first key that matches that.  And if you don't say -k then
you get the first key.  But if the user wanted to mark the
keys with the easier-to-remember 'location=work' and
use that with -k, that would be okay too.  -k doesn't care.

Now the question is how do you find a -k option.  At boot
time, I think it's reasonable to invoke it with a -k argument
taken from plan9.ini if one is specified.  (I assume you have
to change /boot anyway).  This would only be necessary
when the user has multiple 802.1x keys in his factotum.

Russ

Re: [9fans] config wisdom? (factotum? cmdline flags? ctl file?)

[Axel Belinfante]

Thanks for your elaborate reply.
Below I'm just thinking out loud, to get things
'organized' and to check my understanding.

One thing I get from it is to focus at the case at hand
(ttls-pap) and try to get that right, and not worry about
all other auth schemes 'in' 802.1x for which we don't have
an implementation anyway. Nevertheless...

802.1x allows _a_lot_ of different auth schemes.
So, I guess the auth scheme should also be 'encoded'
in the facotum key line.
Should we 'encode' the scheme in the service (802.1x-ttls-pap)?
Or maybe, ideally, not in the service but in the proto?

hmm... early in the 802.1x protocol is a 'handshake'
to decide on the auth scheme that is going to be used,
where 'the other side' invites us to 'do' a particular
auth scheme, and we can play along, or tell it which
schemes we do support, after which it will propose
something we said we do support, or give up (I think).

To support a scheme we need to have it implemented,
and we need to have the keys (or other info) needed
to 'run' it. Our implementation knows what is implemented,
but it should be able to find/distinguish the keys for
it in/via factotum.

> You should use factotum to hold keys.
> 
>    key proto=pass service=802.1x user? realm? !password?
> 
> Ideally you wouldn't use proto=pass but I don't know
> enough about 802.1x to know whether that's easy.

I'm not sure I understand how you mean this,
but let me try to guess...

The 802.1x protocol (suite?) needs the realm in
one of the first messages, the other things may
be needed only much later.
In the case of PAP over Tunneled TLS the user/password
are only needed in the second phase of the protocol,
once the TLS handshake has been succesfully completed.
In that second phase, the username/password have to be
wrapped inside some attribute-value format and then
sent over the tls connection.

I could imagine that factotum could be extended
to do this wrapping/sending, when given the fd
of the tls connection (just like it can also set
wep keys, when given the fd of the ether ctl file).
Is this what you mean? I can seen how this would work.

Hmm... or could the overall 'supervision' about
the phases (in our case, first do tlsClient, and then
do something over the secure connection, other things
could be done once the tls connection is there,
and yet other 802.1x auth schemes may just consist
of a single phase) also be done by factotum, where
the 8021x supplicant 'just' takes care of transport
of messages?
This is inspired by the more involved protocols
I see in factotum -- but I guess the interaction
might be a bit intricate.

As I wrote above, just thinking out loud...


Axel.