Re: [87attendees] IETF wireless

[Dan Harkins <[e-mail]>]

On 8/8/13 5:10 AM, "Stefan Winter" <[e-mail]> 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+con
>siderations
>
>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 :-)

  Trust stores... CA bootstrapping.... Maybe we should get some
authentication scheme on the ietf.1x network that doesn't require using
certificates. Maybe RFC 5931 :-) There's none of that "inner method"
nonsense, no need to select a CA, no real identity versus anonymous
identity issues.

  I certainly would not mind eating that brand of dog food.

  Dan.

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