Christopher, Wow, reading this list is a lesson in project management. Lesson 1: Properly scope your project. Scope it small!
There is lots of talk on here about setting up IP filters and other such nonsense. Wow. First of all, only in Communist Russia could you filter everything besides 1 or 2 types of packets and call it "open". That isn't open, saying so is a lie. Nor is it smart to run any services that you have the technical expertise to monitor and maintain. That is a solution for paranoids. If they want to have a network more locked down than an inner city community college, then so be it, but don't be surprised when no one wants to go through the effort of using some crazy setup to use your wifi. Nor would blocking everything but IPsec actually do anything when IPsec become common. To support such a solution would be to support a filtered Internet, which I cannot do. On the contrary, I feel the obligation to oppose such plans in ernest. And that's in addition to the fact that's its insecure running such services on SOHO routers. Really, the only thing I see right off hand, reading all this, is your solution to just fix EAP-TLS. (I did not see you on the list before I threw out your name last time, so I'm kinda glad you were already involved.) I threw out your name because your solution is the best short term solution with minimal impact and the potential for backwards compatiblity. (And I wanted you involved.) I will be looking at your patches and those UNAUTH-TLS patches to see what kind of policy (configuration) options would be needed to have the hostapd builtin AAA just not send a TLS client certificate request in the EAP-TLS conversation, if so configured. I just can't see it being that difficult technically, especially since you already have patches so I know where to look. (I will have to get some configuration code in there, which I have not looked at.) One issue I see is that Jouni Malinen may be aiming for some sort of equivilent feature with that UNAUTH-TLS patchset, and may reject such a patch as competition. (Has anything else been said on those patches? Like why? BTW I have been bitching in the OpenWRT IRC chat ever since I saw your posts..) In that case, there is always pleading with OpenWRT etc maintainers that your solution will allow your Blackberry to connect, while the UNAUTH-TLS vender method will show up as an unsupported method on anything but the next release of wpa_supplicant. They would have to be some high quality patches to get around any veto from Jouni, but the code base is VERY clean so that shouldn't pose that much of a problem. (I actually think he may be part of the core OpenWRT crew IDK its been a while.) They still may reject it, and it may just be one of those politically impossible patches that linger as a stain on the good name of hostapd, but I hope not. ;) I hope we can bang out some patches that are clean and acceptable and non-intrusive. Are you still interested in this route? One of the first things I will be doing is documenting code paths for the EAP-TLS implementation, and how configuration hooks are used. Should I spam this list with my findings? Or do you already know the codebase fairly well? -- Me _______________________________________________ Tech mailing list [email protected] https://srv1.openwireless.org/mailman/listinfo/tech
