Re: [87attendees] IETF wireless

[Stefan Winter <[e-mail]>]

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]
> <mailto:[e-mail]>> 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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/87attendees
> 
> 
> 
> 
> -- 
> Chris Elliott
> [e-mail] <mailto:[e-mail]>


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