Re: Android 2.3.5 supplicants failing after upgrade to FreeRADIUS 2.2.5 from 2.2.0
Hi, About this issue, I remember we having problems in the past with some Android and Linux devices where in the configuration you had to fill up the anonymous login field, or else it would not authenticate if that field was blank. At that time, I instructed our helpdesk to fill it up with the login of the user. I just mention this, because could be due to some configuration in the inner/outer tunnel, or a change of the default protocols. For instance, I already helped in a case where the FreeRadius admin was telling me he only used PEAP, but after an upgrade the Apple devices starting using the default TTLS configuration. Regards, Rui Ribeiro
Message: 7 Date: Mon, 2 Jun 2014 10:47:48 +0100 From: Robert Franklin <rcf34@cam.ac.uk> To: Alan Buxey <A.L.M.Buxey@lboro.ac.uk> Cc: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Android 2.3.5 supplicants failing after upgrade to FreeRADIUS 2.2.5 from 2.2.0 Message-ID: <25867EE6-3519-4698-97B7-7B174A8AB152@cam.ac.uk> Content-Type: text/plain; charset=us-ascii
On 31 May 2014, at 10:35, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
So not just FR update but also the OS updated too...so possible eg samba upgrade too
I don't think anything majorly -- nothing like OpenSSL changing beyond some patches SuSE would have backported. Our password backend is a PostgreSQL server with Cleartext-Password being store; there is no Samba involved.
If the RPM blatted your config like that then it may also have done something to your EAP config too - eg certificates (especially if the debug shows the clients failing at that point) . Did your windows client have correct/secure EAP settings or was it just 'user/password don't care about cert details' mode?
I think the certs are all the same and being referenced the same -- we use a signed cert from the Janet Certificate Service and the chain all looks to be there (checking 'radiusd -X' output to see which files are read).
My Windows 7 PC to test the same credentials is configured with the full 802.1X security setup - it only has the 'AddTrust External CA root' ticked, as well as the server name for the certificate as ' network.tokens.csx.cam.ac.uk'. If I change these settings on the PC to deliberately break them (such as ticket a different CA, or change the server name to 'network2.tokens.csx.cam.ac.uk') then the authentication fails (I do re-enter the credentials following this). So I think everything is being checked correctly.
Also, that all the users of other platforms (>13,000 last week) are getting on without issue makes me think there's something odd here, like a chain certificate issue.
I'm trying to lay my hands on a 2.3.5 device I can muck about with but it's proving tricky.
Is there anything that can be determined from the raddebug output I sent (in terms of which end is stopping the EAP dialogue) or do I need to get more or a different type of output?
- Bob
-- Bob Franklin rcf34@cam.ac.uk / +44 1223 748479 Networks, University Information Services, University of Cambridge
anonymous@your_realm would be more appropriate ☺ Stefan From: freeradius-users-bounces+stefan.paetow=ja.net@lists.freeradius.org [mailto:freeradius-users-bounces+stefan.paetow=ja.net@lists.freeradius.org] On Behalf Of Rui Ribeiro Sent: 02 June 2014 11:42 To: FreeRadius users mailing list Subject: Re: Android 2.3.5 supplicants failing after upgrade to FreeRADIUS 2.2.5 from 2.2.0 Hi, About this issue, I remember we having problems in the past with some Android and Linux devices where in the configuration you had to fill up the anonymous login field, or else it would not authenticate if that field was blank. At that time, I instructed our helpdesk to fill it up with the login of the user. I just mention this, because could be due to some configuration in the inner/outer tunnel, or a change of the default protocols. For instance, I already helped in a case where the FreeRadius admin was telling me he only used PEAP, but after an upgrade the Apple devices starting using the default TTLS configuration. Regards, Rui Ribeiro Message: 7 Date: Mon, 2 Jun 2014 10:47:48 +0100 From: Robert Franklin <rcf34@cam.ac.uk<mailto:rcf34@cam.ac.uk>> To: Alan Buxey <A.L.M.Buxey@lboro.ac.uk<mailto:A.L.M.Buxey@lboro.ac.uk>> Cc: FreeRadius users mailing list <freeradius-users@lists.freeradius.org<mailto:freeradius-users@lists.freeradius.org>> Subject: Re: Android 2.3.5 supplicants failing after upgrade to FreeRADIUS 2.2.5 from 2.2.0 Message-ID: <25867EE6-3519-4698-97B7-7B174A8AB152@cam.ac.uk<mailto:25867EE6-3519-4698-97B7-7B174A8AB152@cam.ac.uk>> Content-Type: text/plain; charset=us-ascii On 31 May 2014, at 10:35, Alan Buxey <A.L.M.Buxey@lboro.ac.uk<mailto:A.L.M.Buxey@lboro.ac.uk>> wrote:
So not just FR update but also the OS updated too...so possible eg samba upgrade too
I don't think anything majorly -- nothing like OpenSSL changing beyond some patches SuSE would have backported. Our password backend is a PostgreSQL server with Cleartext-Password being store; there is no Samba involved.
If the RPM blatted your config like that then it may also have done something to your EAP config too - eg certificates (especially if the debug shows the clients failing at that point) . Did your windows client have correct/secure EAP settings or was it just 'user/password don't care about cert details' mode?
I think the certs are all the same and being referenced the same -- we use a signed cert from the Janet Certificate Service and the chain all looks to be there (checking 'radiusd -X' output to see which files are read). My Windows 7 PC to test the same credentials is configured with the full 802.1X security setup - it only has the 'AddTrust External CA root' ticked, as well as the server name for the certificate as 'network.tokens.csx.cam.ac.uk<http://network.tokens.csx.cam.ac.uk>'. If I change these settings on the PC to deliberately break them (such as ticket a different CA, or change the server name to 'network2.tokens.csx.cam.ac.uk<http://network2.tokens.csx.cam.ac.uk>') then the authentication fails (I do re-enter the credentials following this). So I think everything is being checked correctly. Also, that all the users of other platforms (>13,000 last week) are getting on without issue makes me think there's something odd here, like a chain certificate issue. I'm trying to lay my hands on a 2.3.5 device I can muck about with but it's proving tricky. Is there anything that can be determined from the raddebug output I sent (in terms of which end is stopping the EAP dialogue) or do I need to get more or a different type of output? - Bob -- Bob Franklin rcf34@cam.ac.uk<mailto:rcf34@cam.ac.uk> / +44 1223 748479 Networks, University Information Services, University of Cambridge Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
On 2 Jun 2014, at 11:41, Rui Ribeiro <ruyrybeyro@gmail.com> wrote:
About this issue, I remember we having problems in the past with some Android and Linux devices where in the configuration you had to fill up the anonymous login field, or else it would not authenticate if that field was blank.
At that time, I instructed our helpdesk to fill it up with the login of the user.
In this case, the user has not filled in the outer username as anonymous and the phone is just using username@cam.ac.uk (which you can see in the raddebug). The EAP tunnel doesn't get established as things stop before then, so we haven't even checked the inner username yet. Our local policy insists that the outer username must either be the inner username OR empty (i.e. "@cam.ac.uk"). We do not allow anything local "anonymous@cam.ac.uk", although that would be rejected later. [The policy is that you can either keep your identity secret, or disclose it, but you can't send anything misleading, including "anonymous", which we don't special case.] This issue does got logged with a specific message so we can see it happens. I've never had it reported as an issue, though (it's a Reply-Message, which most users wouldn't see). - Bob -- Bob Franklin rcf34@cam.ac.uk / +44 1223 748479 Networks, University Information Services, University of Cambridge
On 2 Jun 2014, at 13:56, Robert Franklin <rcf34@cam.ac.uk> wrote:
The EAP tunnel doesn't get established as things stop before then, so we haven't even checked the inner username yet.
I've done some further testing with eapol_test compiled under Linux. I can't get this to authenticate at all, so I either have it misconfigured or the server problem extends to this. I've attached the output from eapol_test to see if someone can make sense of it. I can see the certificate chain and CA being reported as being sent by the server, but there is also this part (full stuff in the attached file): CTRL-EVENT-EAP-TLS-CERT-ERROR reason=10 depth=0 subject='/C=GB/ST=England/L=Cambridge/O=University of Cambridge/OU=Computing Service/CN=network.tokens.csx.cam.ac.uk' err='Server used client certificate' EAP: Status notification: remote certificate verification (param=Server used client certificate) SSL: (where=0x4008 ret=0x22e) SSL: SSL3 alert: write (local SSL3 detected an error):fatal:certificate unknown EAP: Status notification: local TLS alert (param=certificate unknown) SSL: (where=0x1002 ret=0xffffffff) SSL: SSL_connect:error in SSLv3 read server certificate B OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed I'm not sure if this is the problem, but then I don't know if this error is correct or not. I have this in the configuration file (as the only network - there is lots of other stuff at the top: network={ ssid="eduroam" key_mgmt=WPA-EAP eap=PEAP identity="300-145-354@wireless.cam.ac.uk" anonymous_identity="@cam.ac.uk" password="a4bumip3" ca_cert="/usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt" phase1="peaplabel=1" phase2="autheap=MSCHAPV2" } If there's some extra test I should be trying or a misconfiguration in the test, please let me know. I do now have a blank Android 2.3.5 phone (an HTC Wildfire S - stop dribbling at the back there!) and it is failing in the same way as the other users. - Bob -- Bob Franklin rcf34@cam.ac.uk / +44 1223 748479 Networks, University Information Services, University of Cambridge
On 2 Jun 2014, at 20:30, Robert Franklin <rcf34@CAM.AC.UK> wrote:
err='Server used client certificate'
That's interesting, and rather definitive. Could you post the output of: $ openssl x509 -noout -text -in /path/to/certficate.crt I think there's going to be something in the kU / eKU fields that's triggering this. Thanks, Adam Bishop gpg: 0x6609D460 Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
On 2 Jun 2014, at 21:26, Adam Bishop <Adam.Bishop@ja.net> wrote:
That's interesting, and rather definitive.
And also a wpa_supplicant bug, so unrelated to your android issue: http://lists.shmoo.com/pipermail/hostap/2014-February/029517.html Your android issue looks a lot like this though, have you eliminated this as a cause: https://blogs.it.ox.ac.uk/networks/2012/01/25/eduroam-connectivity-issues-on... Thanks, Adam Bishop gpg: 0x6609D460 Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
Hi,
And also a wpa_supplicant bug, so unrelated to your android issue:
http://lists.shmoo.com/pipermail/hostap/2014-February/029517.html
I was going to emntion this as an interesting thing - though this code isnt in android 2.3.x it may certainly appear in newer Linux systems this year as the distros roll things out. its quite clear that server certificates are going to have to be pretty much perfect in the eyes of the supplicant developers (which is good really, you dont want any old thing used for business critical systems :-) ) alan
On 2 Jun 2014, at 21:54, Adam Bishop <Adam.Bishop@JA.NET> wrote:
And also a wpa_supplicant bug, so unrelated to your android issue:
http://lists.shmoo.com/pipermail/hostap/2014-February/029517.html
OK - I'll take a look at this tomorrow, thanks. I would like to see eapol_test running to confirm things are basically OK.
Your android issue looks a lot like this though, have you eliminated this as a cause:
https://blogs.it.ox.ac.uk/networks/2012/01/25/eduroam-connectivity-issues-on...
Reading that and the big code.google.com thread it links to certainly all fits what we're seeing, although I'm not sure if where the EAP dialogue is aborting (prior to it saying the tunnel has been established) is where we would expect it to, if that was the the problem. I've tried the various suggestions on that thread but none have worked for me on the test phone. This includes installing the WiFi Advanced Configuration Editor and adjusting the details of the configuration, but they do keep resetting to the broken ones people describe. So... the above problem seems likely, but I'm not sure why it's suddenly started occurring. I think it's most likely changes to OpenSSL, perhaps as the reported SuSE version (0.9.8j) has some fixes from later versions backported, I believe. I think we'll have to do some tests with this, although time may dictate we just put it down as an Android bug and say we can't resolve it. Thanks for everyone's help but if you have something else, it's be welcome! - Bob -- Bob Franklin rcf34@cam.ac.uk / +44 1223 748479 Networks, University Information Services, University of Cambridge
On Tue, Jun 3, 2014 at 6:56 AM, Robert Franklin <rcf34@cam.ac.uk> wrote:
On 2 Jun 2014, at 21:54, Adam Bishop <Adam.Bishop@JA.NET> wrote:
Your android issue looks a lot like this though, have you eliminated this as a cause:
https://blogs.it.ox.ac.uk/networks/2012/01/25/eduroam-connectivity-issues-on...
Reading that and the big code.google.com thread it links to certainly all fits what we're seeing, although I'm not sure if where the EAP dialogue is aborting (prior to it saying the tunnel has been established) is where we would expect it to, if that was the the problem.
I've tried the various suggestions on that thread but none have worked for me on the test phone. This includes installing the WiFi Advanced Configuration Editor and adjusting the details of the configuration, but they do keep resetting to the broken ones people describe.
So... the above problem seems likely, but I'm not sure why it's suddenly started occurring. I think it's most likely changes to OpenSSL, perhaps as the reported SuSE version (0.9.8j) has some fixes from later versions backported, I believe.
If you think it's related to openssl version, have you had the chance to create a test environment with older OS version (e.g. sles11sp2, not updated) or opensuse 13.1? It should help narrow down the bug. And since you say you use opensuse build service, creating a new package for it should take less than 15 minutes. -- Fajar
On 3 Jun 2014, at 08:17, Fajar A. Nugraha <list@fajar.net> wrote:
If you think it's related to openssl version, have you had the chance to create a test environment with older OS version (e.g. sles11sp2, not updated) or opensuse 13.1?
It should help narrow down the bug. And since you say you use opensuse build service, creating a new package for it should take less than 15 minutes.
That's true but we'd also have to set up the machine to run it on, including FreeRADIUS, etc., configure the wireless system to point a test SSID at it, etc. If we believe the problem is the Android issue reported (and I think we're all of the opinion it is here) then other time pressures will likely dictate we state that and stop investigating further, especially as there's no indication that this could be resolved by further indication. I've asked higher up people to make that call. We may return to investigate further when time allows (of if we receive a significant number of additional complaints!). Thanks all for your help, in the meantime, - Bob -- Bob Franklin rcf34@cam.ac.uk / +44 1223 748479 Networks, University Information Services, University of Cambridge
Hi,
On 2 Jun 2014, at 20:30, Robert Franklin <rcf34@CAM.AC.UK> wrote:
err='Server used client certificate'
That's interesting, and rather definitive.
Could you post the output of:
$ openssl x509 -noout -text -in /path/to/certficate.crt
I think there's going to be something in the kU / eKU fields that's triggering this.
Probably. The OP should update (to 2.x branch) or downgrade (to 2.0) his eapol_test then though. This "TLS CLient Auth eKU is prohibited" was a check which was introduced in wpa_supplicant 2.1, got a fair share of bashing, and will go away for 2.2 again. 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: +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
On 3 Jun 2014, at 06:54, Stefan Winter <stefan.winter@restena.lu> wrote:
I think there's going to be something in the kU / eKU fields that's triggering this.
Probably. The OP should update (to 2.x branch) or downgrade (to 2.0) his eapol_test then though. This "TLS CLient Auth eKU is prohibited" was a check which was introduced in wpa_supplicant 2.1, got a fair share of bashing, and will go away for 2.2 again.
Trying eapol_test from wpa_supplicant 2.0 works (I've attached the output), so this does appear to be the bug reported before. Thanks to all for confirming that. - Bob -- Bob Franklin rcf34@cam.ac.uk / +44 1223 748479 Networks, University Information Services, University of Cambridge
Hi, these
err='Server used client certificate' EAP: Status notification: remote certificate verification (param=Server used client certificate)
...having a quick look I see the following: X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Basic Constraints: critical CA:FALSE X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.6449.1.2.2.29 Policy: 2.23.140.1.2.2 thats a heck of a lot of x509 extensions for a RADIUS server. why the "TLS Web Client Authentication" entitlement? - as per the other post that could cause issues. the cert shouldnt be valid for digital signatures or such - I wonder if the TCS are at fault here for some of the assertions/additions? we just have X509v3 Extended Key Usage: TLS Web Server Authentication (and a CRLDP (thanks Windows Mobile and Windows 8!) ) alan
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Adam Bishop -
Fajar A. Nugraha -
Robert Franklin -
Rui Ribeiro -
Stefan Paetow -
Stefan Winter