The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Tomasz Wolniewicz <twoln AT umk.pl>]

Hi,
  as a follow-up to this discussion we have now enabled a new testing
scenario on EAPlab: https://eaplab.supplicants.net
where the server has a wildcard certificate. With this I have run
multiple tests and discovered some interesting facts about the default
Windows supplicants.

For PEAP all seems to work fine. However in this case accordong to
Microsoft documentation the server name should be set as
*\.supplicants\.net rather then *.supplicants.net. There have been some
worries that setting the second form could open a door for attack but my
tests do not confirm this.

The default TTLS-PAP is a completely different story. Here, I was not
able to set the profile so that the connection to a server with a
wildcard cert would be accepted without questioning. When you set the CA
certificate, the supplicant will still ask for a confirmation during the
connection and if the server uses the wildcard certificate it will add
";*.supplicants.net" to the accepted servers window (observe the leading
semicolon). When you connect again, it will ask again and add another
";*supplicants.net" to the allowed names and just keep on going like
that. When you change the server which now has a "proper" name like
radius.supplicants.net, then the supplicant will add this name at the
end of the previous string but will not accept it for the future anyway,
only after you delete everything but this server name the supplicant
will start acting as it should.

Playing with this, I have noticed one other thing about the TTLS
supplicant. If you set things up securely and then try to connect to a
server with an incorrect certificate then the supplicant will not
connect (of course) but will also wipe out the credentials, therefore at
a next "legal" connection the user will be asked for credentials again.
This does not happen with PEAP.

My final message after these tests would be - if you care for your
Windows users do not use TTLS as your first choice method.
If you insist on using TTLS the *do not* use wildcard certificates or
wildcard server names. I would actually advise not to use wildcard at all.

Hope this is helpful
Tomasz



W dniu 2016-04-29 o 12:41, Stefan Winter pisze:
> Hi,
>
>> Using the 'Check realm reachability' feature and Live login tests with the 
>> 'Real (inner) username' and password completed with valid credentials and 
>> the ' Anonymous outer ID (optional)' left blank the test apparently 
>> succeeds and the NPS logs show PEAP in phase 1 and 'Microsoft: Secured 
>> password (EAP-MSCHAP v2)' in phase 2.  The test does note that we are 
>> using a wildcard server certificate and "This can be problematic on some 
>> supplicants" so I did a bit more Googling and found a reference stating 
>> "The downside of wildcard certificate is that they are not currently 
>> supported by Microsoft Windows 802.1X supplicants", I haven't yet been 
>> able to verify that but it would fit with your idea that it is actually 
>> the phase 1 server certificate validation that is the problem. I'll try to 
>> get the server manager to replace the certificate and have another go then.
> Ah, yes, that is a known problem for Windows 8+ (I haven't verified it
> for Winodws 10 yet though; does Windows 10 work for you in this setup?).
> We have recorded this as a possible pitfall under
>
> https://wiki.geant.org/display/H2eduroam/EAP+Server+Certificate+considerations
>
> (Consideration 2, server name, third item)
>
> We can update it with Windows 10 if that one also has this problem.
>
> Greetings,
>
> Stefan Winter
>
>> Thanks,
>>
>> Tim
>> -----Original Message-----
>> From: Stefan Winter 
>> [mailto:stefan.winter AT restena.lu]
>> Sent: 29 April 2016 10:03
>> To: Hadlow, Tim; 
>> 'cat-users AT lists.geant.org'
>> Subject: Re: [[cat-users]] CAT admin login through social networks
>>
>> Hi,
>>
>>> Using a CAT installer eduroam profile for Windows 8 against our ORPS
>>> authentication fails. Our ORPS is Microsoft NPS so local
>>> authentications require what on Android is described as “EAP method:
>>> PEAP” and “Phase 2
>>> authentication: MSCHAPV2”. When successful authentications go through
>>> they how in the event logs as “Authentication Type: PEAP” and “EAP Type:
>>> Microsoft Secured Password (EAP-MSCHAP v2)”
>>>
>>> Using CAT with the profile setting “Supported EAP types for this
>>> profile” set to only “PEAP-MSCHAPv2”, the Windows 8 and Windows 10
>>> installers it generated run quite happily but eduroam connections fail
>>> with the NPS event log messages showing “Authentication Type: PEAP”
>>> and “EAP Type: - ”, i.e. the Phase 2 authentication method appears not
>>> to be being configured.
>>>
>>> Can anyone who uses or knows about NPS offer guidance or suggestions
>>> on the CAT configuration of a profile to work with a Microsoft NPS
>>> Radius server?
>> I am by no means a NPS user, for from it. But I think I recall something 
>> on the list in that direction.
>>
>> I believe the trick is to understand that the log message is quite 
>> misleadingly formulated: the "EAP Type: - " does not mean that a second 
>> phase is not configured; it's rather that the EAP conversation never 
>> proceeded to phase 2, so EAP didn't take place at all.
>>
>> And that would mean the authentication attempt was aborted in phase 1 - 
>> which is server certificate validation and TLS tunnel setup.
>>
>> Did you run the "Check realm reachability" with a valid outer ID yet 
>> (Profile -> Realm and Profile -> anonymous outer ID set)? It would fetch 
>> the server certificate and tell you if there's something odd in the 
>> certificate; that would be the most likely reason for failures at that 
>> stage.
>>
>> Or, I'm completely wrong and am sending you onto the wrong track :-)
>>
>> Greetings,
>>
>> Stefan
>>
>> --
>> Stefan WINTER
>> Ingenieur de Recherche
>> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de 
>> la Recherche 2, avenue de l'Université
>> L-4365 Esch-sur-Alzette
>>
>> Tel: +352 424409 1
>> Fax: +352 422473
>>
>> PGP key updated to 4096 Bit RSA - I will encrypt all mails if the 
>> recipient's key is known to me
>>
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
>>
>>
>> ******************************************************************************************************************
>> Experience the British Library online at www.bl.uk<http://www.bl.uk/>
>> The British Library’s latest Annual Report and Accounts : 
>> www.bl.uk/aboutus/annrep/index.html<http://www.bl.uk/aboutus/annrep/index.html>
>> Help the British Library conserve the world's knowledge. Adopt a Book. 
>> www.bl.uk/adoptabook<http://www.bl.uk/adoptabook>
>> The Library's St Pancras site is WiFi - enabled
>> *****************************************************************************************************************
>> The information contained in this e-mail is confidential and may be 
>> legally privileged. It is intended for the addressee(s) only. If you are 
>> not the intended recipient, please delete this e-mail and notify the 
>> postmaster AT bl.uk<mailto:postmaster AT bl.uk>
>>  : The contents of this e-mail must not be disclosed or copied without the 
>> sender's consent.
>> The statements and opinions expressed in this message are those of the 
>> author and do not necessarily reflect those of the British Library. The 
>> British Library does not take any responsibility for the views of the 
>> author.
>> *****************************************************************************************************************
>> Think before you print
>> To unsubscribe, send this message: 
>> mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
>> Or use the following link: 
>> https://lists.geant.org/sympa/sigrequest/cat-users
>>
>

-- 
Tomasz Wolniewicz    
          
twoln AT umk.pl
        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne   Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika     Nicolaus Copernicus University,
pl. Rapackiego 1, Torun               pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576