From owner-freebsd-net Fri Nov 9 13:42:36 2001 Delivered-To: freebsd-net@freebsd.org Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by hub.freebsd.org (Postfix) with SMTP id CFBB237B422 for ; Fri, 9 Nov 2001 13:42:31 -0800 (PST) Received: (qmail 23853 invoked from network); 9 Nov 2001 21:41:11 -0000 Received: from unknown (HELO pipeline.ch) ([62.48.21.110]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 9 Nov 2001 21:41:11 -0000 Message-ID: <3BEC4D4C.EDFC47D0@pipeline.ch> Date: Fri, 09 Nov 2001 22:40:28 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Nikander Cc: freebsd-net , Marco Molteni Subject: Re: A minimal IEEE 802.1x aka EAPOL implementation available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Pekka Nikander wrote: > Hi, > > My IEEE 802.1x EAPOL implementation is now minimally > functional and tested. It doesn't include any EAP modules, > but the EAPOL state machines seem to work fine. > > I'd appreciate if someone with more experience with netgraph > would read the code and send comments how it should > be improved so that it could be included into -CURRENT > at some later date. I'm especially worried about memory > leaks, I've tried to check the paths to make sure that > mbufs are always freed correctly, but most probably > I have missed a case or two. > > The code is available at > > http://www.tml.hut.fi/~pnr/eapol/ 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. 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. Also by doing this in a userland daemon you would gain the possibility to handle more interfaces in an easy way with configuration files. 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. 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. Probably it should even be recognized by the TrustedBSD components, talk to for that. -- Andre > Right now I have only tested it under 4.4-STABLE, > but it shouldn't be too hard to modify it for -CURRENT. > My problem is that I haven't got any test machines > running -CURRENT available. > > Yours, > > --Pekka Nikander To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message