From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <200510060802.j9682Oc28090@demeter.cs.utwente.nl> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] config wisdom? (factotum? cmdline flags? ctl file?) In-reply-to: Your message of "Wed, 05 Oct 2005 14:48:20 -0400." References: <200510051708.j95H8de10107@zamenhof.cs.utwente.nl> From: Axel Belinfante MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28080.1128585744.1@demeter.cs.utwente.nl> Date: Thu, 6 Oct 2005 10:02:24 +0200 Topicbox-Message-UUID: 9548cb78-ead0-11e9-9d60-3106f5b1d025 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.