Hi, Dan, thanks for picking up the topic! (mobilities, there's opportunity for volunteer work below ;-) ) > 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. All good, but why is the CN validation needed in phase2? There are EAP types that require a client certificate alright, but that is not subject to any validation by the supplicant - the supplicant was configured to use that certificate, it picks it up from the config, and sends it no matter what. The server-side needs to validate that. There *could* be some very special edge cases like EAP-TLS with identity protection *and* the server handshake in phase 1 being a different cert from the server handshake in phase 2. But to be honest, I've never even seen a supplicant support EAP-TLS with identity protection alone. And consequently also not that it would use a different server-side certificate in phase 2 then. I would certainly already be completely happy with the phase1 validation. BTW, other supplicants typically only take the string *content* of CN, without the prefix "CN=" in their input boxes. Not saying that that's any better than your approach, just different (and being different in user-facing stuff often leads to confused users). > 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. I couldn't agree more! There is exactly one supplicant in history that did it very accurately and conveniently: Intel's PRO/Set Wireless. When something went wrong, a click on diagnostics would tell you in plain English words at which part of the EAP state machine things went wrong. Typical cases where this really shines is: - RADIUS server didn't reply (supplicant sent first EAPoL packet, but no EAPoL reply came back) (<- infrastructure problem - try again later) - RADIUS server EAP type negotiation failed (server suggested type X, client NAKed and suggested Y,Z, but RADIUS server doesn't do Y or Z) (<- configuration problem) - RADIUS server presented certificate from wrong CA (<- either you are being attacked, or configuration problem) - RADIUS server presented certificate from correct CA, but unexpected name (<- either you are being attacked, or configuration problem) - RADIUS communication is alright, but the request was rejected (<- this is the *only* case where a UI should say "Probably your password was wrong") It would be extremely cool if that kind of feedback could be extracted and displayed to the user! BTW, the distinction between "attacked" and "configuration problem" is often asked too much from the user. Some supplicants offer a "lock-down mode". Once a CA/CN are configured, the supplicant will either ask the user "Hey, there's a unexpected certificate coming along - Do you want to accept it?" (the non-lockdown-mode) or it will silently fail the connection attempt, not giving the user an opportunity to "click accept" to protect him from himself (that's lockdown). Non-lockdown is arguably useful when bootstrapping a new supplicant - a bit like SSH fingerprints with a leap of faith during initial setup. For properly pre-configured supplicants though, lockdown is usually better. > 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. Well, I wish I could help, since us eduroamers are probably the biggest user group of 802.1X in the world - but I haven't done C++ programming for way too long and don't think I'm competent enough. I've copied in the mobility list of TERENA, the thinktank that came up with the eduroam idea. Maybe some people there know C++ / NetworkManager and would volunteer to do something *wink* *wink*. Greetings, Stefan Winter > > 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 >> networkmanager-list gnome org >> http://mail.gnome.org/mailman/listinfo/networkmanager-list > -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
Attachment:
signature.asc
Description: OpenPGP digital signature