Re: adding subjecT_match to list of configurable options

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 "".
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.


> 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 ( ; 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
> networkmanager-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]