Re: adding subject_match to list of configurable options


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


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 ( ; 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

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

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