Date: Sat, 10 Nov 2001 08:40:15 +0200 From: Pekka Nikander <Pekka.Nikander@nomadiclab.com> To: Andre Oppermann <oppermann@pipeline.ch> Cc: freebsd-net <freebsd-net@freebsd.org>, Marco Molteni <molter@tin.it> Subject: Re: A minimal IEEE 802.1x aka EAPOL implementation available Message-ID: <3BECCBCF.60903@nomadiclab.com> References: <3BEC4D4C.EDFC47D0@pipeline.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for your comments. This is exactly what I need so that we get an architecturally beautiful but still flexible enough implementation. > I think it would be far cleaner to implement only the 802.1x packet > capturing/sending as a netgraph node, do some sanity checks and then > pass it off trough a socket to a userland daemon. I more or less agree, and that's what I've more or less tried to do. Actually, in my very first version I just had the capture/sending functionality, but it become rather quickly clear that there are benefits from including the 802.1x state machines into the module as well. Furthermore, you can implement the basic packet capture and sanity checking with the ng_bpf module. On that level, there is no point of having a separate 802.1x module. Thus, I went and implemented the 802.1x state machines, too. I agree that the implementation at my web site was far from clean, and based on Julian's comments I am refactoring the code right now. I should get the refactoring ready in a few days. An interim snapshot of the code under refactoring is now at the website http://www.tml.hut.fi/~pnr/EAPOL. What are my goals with the netgraph node, then? First, the kernel space state machine functionality allows you to separate the authenticator (server) and supplicant (client) functionality. Separating them at the user level would not be that easy. If you just forwarded all packets to the userland, and then separated them, you would need some kind of user land IPC, and that would unnecessarily complicate the user land modules since we have muxing/demuxing already at the netgraph level. I consider separation quite important since the client and server are potentially very different. The client could be a KDE or Gnome program, asking the user for password or other info, while the server is typically a daemon. Still further, I want to make it easy to support different kinds of authenticator daemons as well, e.g. one could do authentication locally, other pass all packets to an back end RADIUS server. My second goal is to work towards a solution where one could share one set of userland clients and servers with PPP/EAP. I'm far from that (I haven't looked at the ng_ppp code at all yet), but at least I'm paying attention to the architectural issues involved. Being compatible with PPP requires, then, that the userland doesn't need to care about EAPOL pecularities such as packet retransmissions, timers etc. That's why I've implemented at the netgraph node. My third goal is to make it possible to optionally implement the EAP modules at the kernel space. This might be useful sometimes, e.g., to have a "standard" MD5-Challenge module in the kernel to that it can be easily used in single user mode. > The userland daemon would then implement the various 802.1x authen- > tication methods required/possible. It could do this for example by > using already existing authentication methods available in libraries > like openssl. Right. That's the goal. Furthermore, I'd like to see the possibility of having several parallel userland daemons, each basically implementing just one authentication method. That would make the userland part much easier. And that would give flexibility. For example, you could have MD5-Challenge authenticator using local user accounts and at the same time allow TLS authentication through RADIUS. The architecture is not quite there yet -- I will need some more intelligence somewhere. Right now there are just separate hooks for separate EAP protocols. On the client side, the ng_eapol node responds to the Request/Identity, but after that the subsequent Request/Authentication packets are sent to separate EAP hooks. On the authenticator side, the Response/Identity packet is broadcast to all connected EAP hooks, but after that all Response/Authentication packets are directed only to the relevant hook. Both clien and authenticator need more options, and I am considering them. > Also by doing this in a userland daemon you would gain the possibility > to handle more interfaces in an easy way with configuration files. That's one of the tricky parts with the current architecture. I have to somehow tag the packets going to the userland with both the interface and MAC address. The code is planned to do that, but I still don't know what's the cleanest way of passing this info to the userland. meta doesn't seem to be a possibility since it cannot be passed to the userland side; I'm reluctant of putting this info on the mbuf proper since it would result in quite ugly code. Suggestions? > This would also allow to specify more than one authentication key > for a given interface (think travelling users with different work > places and keys). These keys could be tried one after the other until > you get access. That's completely up to the userland part. > It could also better interact with other userland services like login > or PAM. Think with logging in, it will authenticate you to the > (physical) network and the (ethernet) switch will put you into the > right VLAN for example. Or it could prompt for secure-id. Ditto. > Probably it should even be recognized by the TrustedBSD components, > talk to <rwatson@freebsd.org> for that. I didn't get this one. What are TrustedBSD components, and why I should talk about that? --Pekka Nikander To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BECCBCF.60903>