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

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

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.