On Wed, 2011-07-06 at 08:30 +0200, Stefan Winter wrote: > Hello, > > it looks like 0.8 and the upcoming 0.9 don't allow to specify the > "subject_match" parameter for WPAx-Enterprise connections. In the > wpa_supplicant backend, this parameter exists and can be used just fine > (see its man page).
It's been discussed on at least IRC and maybe in email, patches are hopefully being worked on. It's not a huge task, it just needs somebody to sit down and do it. The ideal approach is to define two new properties to the 802.1x setting, both being of type 'array of string' (DBUS_TYPE_G_LIST_OF_STRING) where each element in the string list is a component of the subject match, like "CN=baz.foobar.com". There would be two of these properties, one for phase1, and one for phase2. NM would internally validate these in libnm-util/nm-setting-8021x.c and then reconstruct the final string when sending the configuration to wpa_supplicant. Second of course we need some entries in the editor/panel. Next, and something that woudl be really nice, is to get an indication from wpa_supplicant back to NM about what, exactly, failed when the EAP exchange fails, so that NM can send something intelligent back to the user. That's an area that's lacking right now. When the exchange fails there's often no indication *why* it failed, and that's no help to the user. You have to then enable wpa_supplicant debugging to figure out what went wrong (wrong password? EAP method not supported? Server cert didn't validate?) and that just sucks. So in reality, actually doing the verification is only one battle. We need to also win the war. It's not really that hard, but we need somebody to step up and do it. Dan > Being able to specify the exact expected server name is an important security > property if *not* using self-signed certificates or private CAs. > > > I'm an R&D engineer in a major 802.1X-based roaming consortium > (www.eduroam.org) ; the lack of the subject_match feature has always been a > bit of a grief for me. After reporting this as a feature request against > KNetworkManager, I was told that I should bug the underlying NetworkManager > list instead, so here I am :-) > > Would be nice if this could be changed in the future; maybe even for 0.9? > > > Greetings, > > Stefan Winter > > _______________________________________________ > networkmanager-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/networkmanager-list _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
