Re: [87attendees] IETF wireless

[Chris Elliott <[e-mail]>]

Stefan,

Thanks for your feedback. Note that we have little control over attendee's
client configs, unlike universities or companies. However, we can certainly
provide more information and automated tools like the eduroam community
does.

As none of us are as expert in this field, doing it part time three times a
year on a volunteer basis, we may need further expert advise. The eduroam
docs are great, but if we need more we'll contact you. We'll follow up with
you on this once the VMs are spun up at their between meetings home and I'm
back from vacation--early to mid September.

Chris.



On Thursday, August 8, 2013, Stefan Winter wrote:

> Hi,
>
> > The cert we are using for the IETF SSIDs authenticated via 802.1X (not
> > including eduroam) is from the same CA that is providing the certs for
> > the rest of the IETF (including web, email, dnssec, and more, I
> > believe). This CA (Starfield Secure Certification Authority) is in most
> > or all recent OSes and browsers root certificate store. Which means most
> > 802.1X supplicants /can/ verify the server cert we supply. It's up to
> > the user to not un-check the "Check server cert" box! Our thought was
> > that that was sufficient.
>
> No! This is a common misconception. The "browser trust" and EAP trust
> are different, and it is insignificant if the CA used is in the browser
> trust store or not.
>
> It may save you the step of installing the PEM file itself, sure, but
> the crucial part is that you need to be able to tell your EAP supplicant
> on the device that the expected server cert comes from *exactly one* CA.
>
> Further to this, contrary to the web browser case, you need to manually
> configure which server name to expect; in the browser, this is
> explicitly input by the user in his URL bar - but no equivalent of that
> exists for EAP.
>
> We have fought for years to get that into our Identity Providers' heads.
> Our official eduroam documentation has an extensive section about all
> the concepts and nits to consider:
>
>
> https://confluence.terena.org/display/H2eduroam/EAP+Server+Certificate+considerations
>
> If you don't pin the exact CA *and* server name in config, you make
> yourself susceptible to MitM attacks still:
>
> - if you trust all CAs in the "browser trust" store: the MitM gets
> himself an arbitrary certificate from any CA in the trust store and uses
> it for his fraudulent EAP server - your EAP supplicant would trust it,
> even if it has nothing to do with your EAP server.
>
> - if you don't verify the name (but the exact CA): the MitM tries to
> connect to the genuine network once, sees which CA is expected, goes to
> the same CA and gets himself a certificate for an unrelated name (to
> which he is entitled to by say having a corresponding domain name). He
> sets up a fraudulent EAP server with that certificate - your EAP
> supplicant will accept it even if he does the extra step of verifying
> the CA.
>
> > However, we certainly can look into doing as you suggest and publishing
> > more information. Of course, the page we post this to will probably also
> > be verified by this same CA... ;-)
>
> That's the default CA bootstrap problem. You can put the CA's
> fingerprint in a text file, and PGP-sign the file with IETF brass PGP
> keys if you like :-)
>
> In eduroam, we *require* IdPs to "publish all information needed to
> uniquely identify the authentication server"; and we even have an
> automated provisioning tool which sets up supplicants with all the
> correct and secure settings - including the CA installation.
>
> It works everywhere except on Karen O'Donoghue's Mac. ;-)
>
> Greetings,
>
> Stefan Winter
>
> >
> > Chris.
> >
> >
> > On Thu, Aug 8, 2013 at 2:35 AM, Stefan Winter <[e-mail]<javascript:;>
> > <mailto:[e-mail] <javascript:;>>> wrote:
> >
> >     Hi,
> >
> >     > Scary how many are using the unencrypted wifi.
> >
> >     Don't only count the ietf.1x network. The IETF also provides eduroam,
> >     which is WPA2/AES with 802.1X and - sorry, NOC: actual server
> >     certificate verification, not a "don't verify ours, and we won't
> verify
> >     yours".
> >
> >     The Max numbers in the NOC report are
> >
> >     the 3 "secure" ones: 25+27+37 = 89
> >     the two "edu" ones: 38 53 = 91
> >
> >     Which makes for a total of 180 max simultaneous encrypted
> connections.
> >
> >     Sure, compared to approx. 700 on the open networks it's not so really
> >     great, but still quite a significant portion.
> >
> >     > A suggestion for next IETF would be to call the 802.1x wifi "IETF"
> and
> >     > the open one "IETF_UNENCRYPTED".
> >
> >     Without verifying the server cert of the 802.1x network, you may well
> >     talk to the network encryptedly, but the network might be a MitM who
> can
> >     decrypt and snoop out your traffic.
> >
> >     The ietf.1x network is just not as good as it could be - maybe more
> >     people would be inclined to use it if it provides the extra benefit
> of
> >     being able to identify itself as *the genuine* IETF network. Neither
> the
> >     open network nor the ietf.1x currently do that.
> >
> >     The fix would be surprisingly simple: in the Network Information
> page,
> >     actually *publish* the CA cert and its fingerprint that signs the
> auth
> >     server, and also publish the server's subject/subjectAltNames. This
> >     allows every user to check whether he's on the real thing when
> >     connecting.
> >
> >     There are also provisioning tools that can install the CA certs and
> EAP
> >     settings onto client devices. It's not rocket science.
> >
> >     Greetings,
> >
> >     Stefan Winter
> >
> >
> >
> >
> >     --
> >     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: [phone] <tel:%2B352%20424409%201>
> >     Fax: [phone] <tel:%2B352%20422473>
> >
> >
> >     _______________________________________________
> >     87attendees mailing list
> >     [e-mail] <javascript:;> <mailto:[e-mail]<javascript:;>
> >
> >     https://www.ietf.org/mailman/listinfo/87attendees
> >
> >
> >
> >
> > --
> > Chris Elliott
> > [e-mail] <javascript:;> <mailto:[e-mail]<javascript:;>
> >
>
>
> --
> 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: [phone]
> Fax: [phone]
>
>

-- 
Chris Elliott
[e-mail]