Re: adding subject_match to list of configurable options

[Dan Williams <dcbw redhat com>]

On Thu, 2011-07-21 at 08:12 +0200, Stefan Winter wrote:
> 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.

Mainly because wpa_supplicant allows it for phase2 via the
subject_match2/altsubject_match2 options; if we don't really need it
right now, if phase1 subject matches are sufficient for the use-cases we
know about now, then we can skip the phase2 ones and always add them
easily later.

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

We could do that, though what we'd probably do here is play games in the
UI such that if there is no "=" in the input to the text box, then we
assume that means "CN=", but anything else is used verbatim (with
appropriate isprint() validation or something on it).  The supplicant
allows:

# subject_match: Substring to be matched against the subject of the
#       authentication server certificate. If this string is set, the server
#       sertificate is only accepted if it contains this string in the subject.
#       The subject string is in following format:
#       /C=US/ST=CA/L=San Francisco/CN=Test AS/emailAddress=as example com

and I presume it does that for some good reason since the supplicant is
generally excellent.  So just because NM would support *more* than what
users are accustomed to, doesn't mean we have to expose all that
complexity by default in the UI.

> >   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!

Yeah, that's definitely something we need to do, and that has to be done
with cooperation between NM and the supplicant.  It's clearly an area
where we currently fail.

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

The server cert accept thing is something that's being worked on by an
engineer from Novell right now, so hopefully those patches will show up
soon.  It also requires a patch to wpa_supplicant though, so distros
would have to carry that patch until a new supplicant release.

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

Yeah, eduroam users are probably the largest filers of 802.1x bugs
against NM, and it's great that people are around to test this stuff in
a wider setting.

Cheers,
Dan

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