RE: iOS mysterious issues on Freeradius 3.0.14
I've read a lot messages in Freeradius Forum and I continued misunderstand why iOS devices (iPhone, iPad) doesn't connect in my >WPA-Enterprise wifi network. I've installed and configured a freeradius server, version 3.0.14, over openssl 1.1.0e (both have >installed from sources on Debian 8). I've tested connect Android devices to my wifi network and everytime they can connect to >the network, but iOS devices have mysterious issues.
With PEAP you should *always* use Publicly recognised TLS/SSL certificates, preferably with a well-known CA source or one that your University supports. Also it should be at least 2048 bits and uses the SHA256 hash algorithm, SHA1 should be phased out. For example, we use JISC service which uses Quo Vadis CA. Do not use self-signed or internal CA certificates.
When I try connect iOS device to my wifi in first time, they can connect perfectly. Though, if this same iOS device lost >connection (because it's out of range AP signal or air plane mode turn on by the user for 30 minutes or hours) and try connect >again the device doesn't connect. When I've saw the debug mode, I've noticed that EAP-PEAP tunnel athentication was successful >and server sent Access-Challenge, but device doesn't answer this challenge. I don't understand why the android devices doesn't >this issues.
Maybe it's related to session resumption? Have you turned that off?
When switched between Aps, session resumption should be enabled to provide seemless connections. The APS should be using the same SSIDs and Peter Hutchison MCP Senior Network Systems SpecialistS S 01484 473716 Networks Team University of Huddersfield | Queensgate | Huddersfield | HD1 3DH University of Huddersfield inspiring tomorrow's professionals. [http://marketing.hud.ac.uk/_HOSTED/EmailSig2014/EmailSigFooter.jpg] This transmission is confidential and may be legally privileged. If you receive it in error, please notify us immediately by e-mail and remove it from your system. If the content of this e-mail does not relate to the business of the University of Huddersfield, then we do not endorse it and will accept no liability.
On Thu, Mar 23, 2017 at 09:29:54AM +0000, Peter Hutchison wrote:
With PEAP you should *always* use Publicly recognised TLS/SSL certificates, preferably with a well-known CA source or one that your University supports.
That's certainly not the recommended practise that's ever normally given here. All RADIUS certificates should be based on private CA infrastructure where possible for the best security.
Also it should be at least 2048 bits and uses the SHA256 hash algorithm, SHA1 should be phased out.
This is better advice.
For example, we use JISC service which uses Quo Vadis CA. Do not use self-signed or internal CA certificates.
No. Use an internal CA with installers (such as eduroam CAT) to push the config and root CA to the devices. You might find a public CA the right balance between convenience and security for yourselves, and many people do, but it's not the correct advice for a secure network. Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi,
With PEAP you should *always* use Publicly recognised TLS/SSL certificates, preferably with a well-known CA source or one that your University supports. Also it should be at least 2048 bits and uses the SHA256 hash algorithm, SHA1 should be phased out. For example, we use JISC service which uses Quo Vadis CA. Do not use self-signed or internal CA certificates.
wrong. best practice, security wise for EAP 802.1X within the enterprise,, is to use a local CA, do NOT use a public CA. your clients will trust the CA because you use a deployment ool, MDM solution etc to ensure that CA is on your clients - only YOUR clients need to trust the CA of your RADIUS server, if offering a roaming service eg eduroam, visitors never see the CA of your server - the authentication is proxied back to the home site...which they, in turn, are configured to only trust. using a public CA is insecure (for various reasons, first is that many clients can only trust a CA, not a particular server and ANYONE can get a server cert from a public CA...it doesnt have to match the name/realm of your target, just be from same CA) - you are also bound by the public CA timings/requirement s- 2 or 3 years for the server, expires when they decide, not when its good for you - and also, add into the mix, if the CA gets compromised, the OS vendors will blacklist/revoke it (eg those 2 Dutch CAs a few years back) - lets hope you arent using those or none of your clients now have network access :/ alan
On Mar 23, 2017, at 5:29 AM, Peter Hutchison <p.j.hutchison@hud.ac.uk> wrote:
I've read a lot messages in Freeradius Forum and I continued misunderstand why iOS devices (iPhone, iPad) doesn't connect in my >WPA-Enterprise wifi network. I've installed and configured a freeradius server, version 3.0.14, over openssl 1.1.0e (both have >installed from sources on Debian 8). I've tested connect Android devices to my wifi network and everytime they can connect to >the network, but iOS devices have mysterious issues.
With PEAP you should *always* use Publicly recognised TLS/SSL certificates, preferably with a well-known CA source or one that your University supports.
We've been recommending to NOT do this for well over a decade. The problem is that the CA will issue certificates to *anyone*. And anyone can put up an SSID, and use a certificate signed by that CA. With sufficient (i.e. minor) hacks, they can even have the certificate use your university DNS name. This is because the client generally remembers the CA, and *not* the server certificate associated with the SSID. The end user then happily hands his inner credentials (i.e. MS-CHAPv2) to a random person on the net, who then cracks them in about 10 minutes. Supplicant vendors are getting better at catching this, but even if they throw up a warning saying "New RADIUS server certificate!", 99% of users will just click through it. By using a self-signed CA, this issue is largely avoided. Users can't generally click through warning prompts, they have to install the CA cert, and enable it for that SSID. Alan DeKok.
On 23/03/17 13:37, Brian Julin wrote:
Alan Dekok wrote:
With sufficient (i.e. minor) hacks, they can even have the certificate use your university DNS name.
Would you care to elaborate?
I was going to ask that. Because that would be a pretty big problem, completely independent of FreeRADIUS ;o)
On Mar 23, 2017, at 9:37 AM, Brian Julin <BJulin@clarku.edu> wrote:
Alan Dekok wrote:
With sufficient (i.e. minor) hacks, they can even have the certificate use your university DNS name.
Would you care to elaborate?
https://www.jisc.ac.uk/events/networkshop44-22-mar-2016/programme/day-three See the EAP-TLS presentation by Arran, slides 6 and following. Arran wrote a nice pwn tool which acted as a RADIUS server for any SSID you set up. When a user (e.g. BJulin@clarku.edu) connects, the tool goes to the clarku.edu web site, and downloads any HTTPS certificate it finds. It then uses the fields from that certificate to create a new server certificate that it presents to the user. Users who aren't sufficiently wary can click through any warning prompts. Because the certificate has *all of the correct humanly-readable fields*. There are some caveats. In it's current state, it only works for users who don't have WiFi pre-configured. So only they get the message of "unknown CA, do you wish to continue?" However... if you're willing to do a bit more work and spend more money, you could: 1) try to connect via PEAP at a university. This should get you a copy of the CA and server cert used by the university. And with Eduroam, you don't even need to be there in person! 2) if they use a public CA, pay the $3K or so to get a signing certificate issued by that CA 3) use that signing certificate to create your own server certificate... using the fields stolen from the real server certificate in step (1) 4) present the universities SSID to clients, with your own server cert, signing cert, and using the same CA as used by the university 5) people will connect and hand you all of their credentials. The benefit to this approach is that it should work even for users who already have WiFi pre-configured. Because most supplicants historically have not cached the *server* certificate. Instead, they only track the CA certificate. The main reason attackers don't do this is: a) most people use self-signed CAs for RADIUS, which prevents the attack b) even for people using public CAs, getting a signing cert costs money. But there is no *technical* reason which prevents this from happening. So lesson learned: ALWAYS USE A SELF_SIGNED CERTIFICATE FOR RADIUS. Anyone who uses a public CA for "ease of use" or "it's a public CA", or "it's secure" is doing entirely the wrong thing. Stop it, now. And I mean *now*. Alan DeKok.
Alan Dekok wrote:
Arran wrote a nice pwn tool which acted as a RADIUS server for any SSID you set up. When a user (e.g. BJulin@clarku.edu) connects, the tool goes to the clarku.edu web site, and downloads any HTTPS certificate it finds. It then uses the fields from that certificate to create a new server certificate that it presents to the user. Users who aren't sufficiently wary can click through any warning prompts. Because the certificate has *all of the correct humanly-readable fields*. There are some caveats. In it's current state, it only works for users who don't have WiFi pre-configured. So only they get the message of "unknown CA, do you wish to continue?"
With the exception of Android, which may eventually get its act together, If you are going to go through the trouble of installing a local CA on all your clients, you can just as well set up the SSIDs to properly demand that a particular CA root is used, and the DN is checked. Once you've made the commitment to touch all clients in this manner it is a sunk cost.
2) if they use a public CA, pay the $3K or so to get a signing certificate issued by that CA 3) use that signing certificate to create your own server certificate... using the fields stolen from the real server certificate in step (1)
... I don't think commercial intermediate signing certificates that allow you to place arbitrary domains in them are quite that easy to obtain... that would pretty much break the web. Granted there are real trust issues with CAs, but a CA that made a practice of issuing any random unvetted stranger a signing certificate would find itself kicked out of the root stores pretty quick.
a) most people use self-signed CAs for RADIUS, which prevents the attack b) even for people using public CAs, getting a signing cert costs money.
c) all the Apple devices pin the cert after first use... which is great until it needs to be replaced.
Anyone who uses a public CA for "ease of use" or "it's a public CA", or "it's secure" is doing entirely the wrong thing. Stop it, now. And I mean *now*.
Agreed on the two latter, public CAs are certainly not *more* secure than local on any technical level at all. But on the former, I think this is too harsh. Security needs vary by institution and by user category, and in some places, convenience is the only way to get certain classes of users to do anything other than find a random rogue access point named something like "FreePublicWiFi" rather than your institutional SSID. Some institutions cannot practically police their RF environment *at all*, so merely using confusable characters in look-like SSIDs can bypass all your efforts and yield a password dialogue into which users will gladly type their creds, regardless of which kind of CA you run. For those users where credentials are high value, they are likely using managed machines, and managed machines can be easily configured by administrators. Also they are subject to being required to attend meetings telling them how not to set up their WiFi insecurely on their BYOs. Anyway, "convenience" is the whole reason SSO systems are implemented. Addressing that slide presentation about TLS: until it gets a *live* password mechanism in addition to the PKI, it doesn't serve some important security needs. Having either TLS evolve in that direction or PEAP supplicants evolve towards accommodating client certs is probably the point at which I can get management to buy into maintaining our own CA, and if I had to guess which would reach the built-in supplicant base first, it would not be an extended TLS. I think the constant badmouthing of password-based methods both in the EAP and SSH realms is holding back progress in this direction (i.e. how hard really would it be for SSH to use a challenge method for passwords inside the tunnel? Obvious precaution, neglected for decades by people too obsessed with telling people to use the public-key method and doing crazy crap with agents in order to create contagious credentials.) In addition, having institutions rush into using bug-ridden turnkey CA products with no regard for the institutional/procedural work needed to properly administer a CA is in nobody's best interest.
On Mar 23, 2017, at 11:14 AM, Brian Julin <BJulin@clarku.edu> wrote:
... I don't think commercial intermediate signing certificates that allow you to place arbitrary domains in them are quite that easy to obtain... that would pretty much break the web.
https://news.ycombinator.com/item?id=11781915 Symantec has been known to do it.
Granted there are real trust issues with CAs, but a CA that made a practice of issuing any random unvetted stranger a signing certificate would find itself kicked out of the root stores pretty quick.
The point is that the intermediate CA would be vetted. But... that intermediate CA could be malicious, and *no one would know*. How many end users will look at the certificate chain when authentication fails?
a) most people use self-signed CAs for RADIUS, which prevents the attack b) even for people using public CAs, getting a signing cert costs money.
c) all the Apple devices pin the cert after first use... which is great until it needs to be replaced.
Or when you have multiple RADIUS servers, each with their own certificate.
Anyone who uses a public CA for "ease of use" or "it's a public CA", or "it's secure" is doing entirely the wrong thing. Stop it, now. And I mean *now*.
Agreed on the two latter, public CAs are certainly not *more* secure than local on any technical level at all.
But on the former, I think this is too harsh. Security needs vary by institution and by user category, and in some places, convenience is the only way to get certain classes of users to do anything other than find a random rogue access point named something like "FreePublicWiFi" rather than your institutional SSID. Some institutions cannot practically police their RF environment *at all*, so merely using confusable characters in look-like SSIDs can bypass all your efforts and yield a password dialogue into which users will gladly type their creds, regardless of which kind of CA you run.
The point isn't to solve *all* of the security issues of the world. The point is to explain how to solve security issues in our little corner, and what attacks are possible.
For those users where credentials are high value, they are likely using managed machines, and managed machines can be easily configured by administrators. Also they are subject to being required to attend meetings telling them how not to set up their WiFi insecurely on their BYOs.
Like CEOs who are well known for downloading viruses from certain (ahem) non-youtube video sites.
I think the constant badmouthing of password-based methods both in the EAP and SSH realms is holding back progress in this direction
It's bad-mouthed in EAP because it's a bad idea. Until a better method is deployed, it's still a bad idea.
In addition, having institutions rush into using bug-ridden turnkey CA products with no regard for the institutional/procedural work needed to properly administer a CA is in nobody's best interest.
It's pretty much trivial to create your own CA. Putting it on 10K end user machines is a bit more difficult. Alan DeKok.
On 23 Mar 2017, at 15:26, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 23, 2017, at 11:14 AM, Brian Julin <BJulin@clarku.edu> wrote:
In addition, having institutions rush into using bug-ridden turnkey CA products with no regard for the institutional/procedural work needed to properly administer a CA is in nobody's best interest.
It's pretty much trivial to create your own CA. Putting it on 10K end user machines is a bit more difficult.
It’s not that difficult. We use EAP-TLS with a private CA and the database currently shows 40,303 active certificates (i.e. certs which have OSCP’d in last 90 days). Hotspot 2.0 OSU should make the process of deploy a private CA even easier (although it uses Public CA cert to do this). Regards Scott Armitage
Alan DeKok wrote:
On Mar 23, 2017, at 11:14 AM, Brian Julin <BJulin@clarku.edu> wrote:
... I don't think commercial intermediate signing certificates that allow you to place arbitrary domains in them are quite that easy to obtain... that would pretty much break the web.
https://news.ycombinator.com/item?id=11781915
Symantec has been known to do it.
You get to choose your CA. Don't choose them.
Granted there are real trust issues with CAs, but a CA that made a practice of issuing any random unvetted stranger a signing certificate would find itself kicked out of the root stores pretty quick.
The point is that the intermediate CA would be vetted. But... that intermediate CA could be malicious, and *no one would know*.
It's a matter of trust. In one case, you choose to trust a CA you think will do proper vetting... or who never issues such certs.
The point isn't to solve *all* of the security issues of the world. The point is to explain how to solve security issues in our little corner, and what attacks are possible.
My little corner is obviously not the same as yours. If client installers had been the only option for WPA2-enterprise, there's a good chance we'd just about now be finally getting off WPA2-personal rather than nine years ago, and the project would have gone through 3 failed attempts involving many pitchforks.
I think the constant badmouthing of password-based methods both in the EAP and SSH realms is holding back progress in this direction It's bad-mouthed in EAP because it's a bad idea. Until a better method is deployed, it's still a bad idea.
So are user-agnostic public keys.
In addition, having institutions rush into using bug-ridden turnkey CA products with no regard for the institutional/procedural work needed to properly administer a CA is in nobody's best interest.
It's pretty much trivial to create your own CA. Putting it on 10K end user machines is a bit more difficult.
Technical creation of a CA server is trivial. CAs are more than a server. Proper procedures to ensure the CA is used in a way that does not subject it to compromise is... "a bit more difficult". So are disaster recovery precautions (e.g. what group of people are allowed to take airplanes together?) There are whole books about it. e.g. much as I like Aruba's gear, I'm no fan of CPPM, and it has had its fair share of security issues because it is too much bloat crammed on one box. How many guest web portal dialogue boxes vulnerable to apache struts bugs does it take to have your RADIUS private key leaked.... Everyone rushing to build an insecure CA infrastructure could be a pretty dangerous trend.
On 23/03/17 16:04, Brian Julin wrote:
Technical creation of a CA server is trivial. CAs are more than a server. Proper procedures to ensure the CA is used in a way that does not subject it to compromise is... "a bit more difficult". So are disaster recovery precautions (e.g. what group of people are allowed to take airplanes together?) There are whole books about it.
Everyone rushing to build an insecure CA infrastructure could be a pretty dangerous trend.
People don't talk about this enough. A CA is more than just a server or HSM, some scripts and a web UI. It's almost *all* about process and procedure, and as technical people we tend to ignore this. I would be interested to hear an assessment of costs in term of staff/FTE equivalent for running a CA, cross-referenced to an independent evaluation of the security of said CA from a process PoV. Slightly OT: can we have a quick headcount of which client deployment tools people are using to deploy their private CA, ideally annotated with any platforms it *doesn't* support?
On Mar 24, 2017, at 6:04 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
People don't talk about this enough. A CA is more than just a server or HSM, some scripts and a web UI. It's almost *all* about process and procedure, and as technical people we tend to ignore this.
At a high level, the processes and procedures are largely: - automate as much as possible - have as few people as possible interacting with the CA - track all changes in a revision control system - document all processes - follow all processes :) - keep all security sensitive information on one system - keep it simple Typical CA failures happen when people make mistakes. It is extremely rare that an automated process goes wrong.
I would be interested to hear an assessment of costs in term of staff/FTE equivalent for running a CA, cross-referenced to an independent evaluation of the security of said CA from a process PoV.
The costs largely depend on what the CA is doing. If it's just issuing client certs for EAP-TLS, most fields can be taken from LDAP, and client provisioning can be done via automated tools. A huge percentage of complexity I see in peoples systems is people trying to create custom systems due to custom business processes or requirements. Just... stop. Don't do that. Keeping it simple means it stays understandable, maintainable, and less goes wrong. Complex systems tend to end up as unknown black boxes that no one knows anything about. That way lies disaster. Another anti-rule is *don't out-smart the experts*. The number of amateurs who argue over security is amazing. Yes, PAP in RADIUS is OK. Don't force MS-CHAP because "it's more secure". It's not. It's *less* secure than PAP. Don't believe your local "expert" who's read an article on the subject. Believe the people who've been doing it for 20 years.
Slightly OT: can we have a quick headcount of which client deployment tools people are using to deploy their private CA, ideally annotated with any platforms it *doesn't* support?
This would be good to now, and to document on the wiki. Alan DeKok.
People don't talk about this enough. A CA is more than just a server or HSM, some scripts and a web UI. It's almost *all* about process and procedure, and as technical people we tend to ignore this.
Typical CA failures happen when people make mistakes. It is extremely rare that an automated process goes wrong.
As demonstrated by DigiNotar (keys left in the devices/machines).
Slightly OT: can we have a quick headcount of which client deployment tools people are using to deploy their private CA, ideally annotated with any platforms it *doesn't* support?
This would be good to now, and to document on the wiki.
Speaking of which, Alan, I know the bootstrap script is, well, for demo purposes, but it does get used rather a lot for deployments. You may eventually get a replacement for bootstrap from either myself (as proxy) or someone else who thought it was inadequate for production purposes. :-) With Regards Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On Mar 24, 2017, at 7:31 AM, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
Speaking of which, Alan, I know the bootstrap script is, well, for demo purposes, but it does get used rather a lot for deployments.
I use it that way. The reason is that most of the existing OpenSSL tools are horrifically bad. The certificate processes in FreeRADIUS v1 were terrible, so I eventually sat down (for WAY too long), and figured out what to do so that it would be easier for everyone else (and future me!)
You may eventually get a replacement for bootstrap from either myself (as proxy) or someone else who thought it was inadequate for production purposes. :-)
As always, patches are welcome. :) I don't usually recommend CA management systems. Partly because I don't know what people actually need, so recommending a CA system may be wrong. And partly because most CA systems are so convoluted and confusing as to be almost unusable. i.e. when you have functionality to meet the needs of 99% of your users, the 90% that want something *simple* will be confused. The bootstrap scripts in FreeRADIUS are hard to get wrong. That makes them useful, and easy to use. But even with that, a little more functionality wouldn't be bad. Alan DeKok.
I use it that way. The reason is that most of the existing OpenSSL tools are horrifically bad.
So do I, TBH.
The bootstrap scripts in FreeRADIUS are hard to get wrong. That makes them useful, and easy to use. But even with that, a little more functionality wouldn't be bad.
I'm just mentioning this because this came up in conversation a few weeks or so ago. My response to them was the same as yours, i.e. "Patches/improvements are always welcome!" :-) Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
Hi,
Speaking of which, Alan, I know the bootstrap script is, well, for demo purposes, but it does get used rather a lot for deployments. You may eventually get a replacement for bootstrap from either myself (as proxy) or someone else who thought it was inadequate for production purposes. :-)
given that the script creates CA and server cert only valid for 30 days its hardly ready for production. those who want to use the provided scripts to start up their own proper system would normally edit a few values - CA and server lifetime values.. now, assuming that they populate the fields correctly, what are the errors/issues with the provided bootstrap (lots of work has gone into keeping them relevant) - the CA:False etc , migration to SHA methods, better DH etc have all been done. IIRC the only things missing are CRLDP and SubjectAlternativeName , correct? alan
On Mar 24, 2017, at 1:17 PM, A.L.M.Buxey@lboro.ac.uk wrote: given that the script creates CA and server cert only valid for 30 days its hardly ready for production.
those who want to use the provided scripts to start up their own proper system would normally edit a few values - CA and server lifetime values..
Yes.
now, assuming that they populate the fields correctly, what are the errors/issues with the provided bootstrap (lots of work has gone into keeping them relevant) - the CA:False etc , migration to SHA methods, better DH etc have all been done. IIRC the only things missing are CRLDP and SubjectAlternativeName , correct?
Pretty much. Some integration with LDAP may be useful, but that quickly devolves into lots of complexity. Alan DeKok.
Slightly OT: can we have a quick headcount of which client deployment tools people are using to deploy their private CA, ideally annotated with any platforms it *doesn't* support?
Well, we don't use one, yet. I've decided to try to tackle the task of getting helpdesk staff used to running a new deployment program which also parameterizes our SSIDs by tying one to an upcoming new VPN rollout. This is with custom scripts generating a mobileconfig and a custom windows script, since none of the SSID-deployment tools also did VPN profiles and/or were too cookie cutter or too bloated to audit. I haven't gotten around yet to writing the part of the Windows script that does the SSIDs or will eventually allow us to install a root cert, but the mobileconfig side of that is dead simple. So far I've been able to avoid any binary .exes on the Windows side so the whole thing is a one-file, easily auditable script disregarding the pasted-in certs. We don't allow Vista or XP on the network anymore, so I don't have to deal with powershells too old to do the job. Haven't even looked at CA enrollment yet. Would be premature until management takes some interest in the CA project and supplicant support catches up. The danger in this approach is less community support if an OS suddenly decides to make changes that crash the scripts or demand a different .mobileconfig for different OSes. But so far in testing, we haven't needed to discriminate. Didn't bother to do android, because it's futile to be messing around with giant build enviromnets to create apps to use reflection APIs to get at paremeters that should be easily provisionable. We'll just have to wait for that crew to get their thumbs out of their posteriors, and in the meantime coax the users through manual cert installs.
On Fri, Mar 24, 2017 at 10:04:52AM +0000, Phil Mayers wrote:
Slightly OT: can we have a quick headcount of which client deployment tools people are using to deploy their private CA, ideally annotated with any platforms it *doesn't* support?
Worth a page on the FR wiki? It's related, and this thread alone seems to indicate it would be a useful reference for people. Just can't quite work out where it might fit best. As for here: .mobileconfig for Apple, edusetup (https://github.com/mcnewton/edusetup - .msi installer I wrote) for Windows, and, I'm slightly ashamed to say, manual instructions for everything else. (Though I'll add that setup instructions has been done by another team for a few years, so no longer directly my fault...) Managed Windows machines have the CA root (and 802.1X config) pushed on by some Microsoft domain policy thing. Managed Mac Laptops with, I believe, Casper Suite (which probably uses a .mobileconfig file internally). Of course then eduroam CAT/802.1x-config.org works for Windows, Linux and MacOS/iOS, and also Android if you can somehow get the App on first. Grr, Google. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 24/03/17 11:41, Matthew Newton wrote:
Of course then eduroam CAT/802.1x-config.org works for Windows, Linux and MacOS/iOS, and also Android if you can somehow get the App on first. Grr, Google.
What's the issue here? The app is in the app store is it not? (Horrible ratings, but it *is* present...) Or do you mean the chicken/egg problem on wifi-only devices?
On Fri, Mar 24, 2017 at 12:43:13PM +0000, Phil Mayers wrote:
On 24/03/17 11:41, Matthew Newton wrote:
Of course then eduroam CAT/802.1x-config.org works for Windows, Linux and MacOS/iOS, and also Android if you can somehow get the App on first. Grr, Google.
Or do you mean the chicken/egg problem on wifi-only devices?
This. You can easily set up a captive setup network with installers and instructions on it, but no trivial way to get someone to install an (properly authenticated) app. If you manage somehow to give access to the Play Store, then you've not got a captive portal any more. Or you have to ask them to permit installing non-official apps, which is a) a big security risk for them (lots of people will never disable it) and b) you may as well just give them instructions on configuring the wireless themselves. There's just no reason for an app to be required at all, if only the O/S had a built in configuration profile method. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@leicester.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi,
With the exception of Android, which may eventually get its act together, If you are going to go through the trouble of installing a local CA on all your clients, you can just as well set up the SSIDs to properly demand that a particular CA root is used, and the DN is checked. Once you've made the commitment to touch all clients in this manner it is a sunk cost.
1) you cant set the SSID up to demand that clients are comfigured in a certain way.... the server doesnt not know if the client has things checked 2) if you have no control of all clients - eg common in HE, BYOD etc - and anyone can come along, connect their iPad to the SSID and put in user/pass - you have no control over their security. a public CA will let part 2 be a nightmare...a private CA means they cannot connect until private CA installed (become known/trusted)
c) all the Apple devices pin the cert after first use... which is great until it needs to be replaced.
if user just clicks SSID and clicks okay then the server cert is pinned. if the configuration is pushed via profile, then so long as the CA is the same and the server CN/SAN is the same its silently accepted.
"FreePublicWiFi" rather than your institutional SSID. Some institutions cannot practically police their RF environment *at all*, so merely using confusable characters in look-like SSIDs can bypass all your efforts and yield a password dialogue into which users will gladly type their creds, regardless of which kind of CA you run.
the historic issue used to be that getting a local CA onto client devices was a pain.....that is no longer true - with deployment tools - free ones like eduroamCAT or commercial ones like XpressConnect, Clearpass etc - and you really want to use those sorts of tools to ensure your clients are properly configured ANYWAY - so you may as well do the local CA at the same time for more security.
Anyway, "convenience" is the whole reason SSO systems are implemented.
and SSO brngs with it the 'you are using the same password for everything - your password is then very high value indeed'. in these places, use the SSO to GET the required token - EAP-TLS certificate. dont use user/pass for auth - use EAP-TLS, then the MiTM is no possibility (with local CA still too! ;-) )
Addressing that slide presentation about TLS: until it gets a *live* password mechanism in addition to the PKI, it doesn't serve some important security needs. Having either TLS evolve in that direction or PEAP supplicants evolve towards accommodating client certs is probably the point at which I can get management to buy into maintaining our own CA, and if I had to guess which would reach the built-in supplicant base first, it would not be an extended TLS.
PEAP already does client certs - OS support may vary ;-)
I think the constant badmouthing of password-based methods both in the EAP and SSH realms
its 2017 and we're still using passwords - enough said ;-) alan
participants (8)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Brian Julin -
Matthew Newton -
Peter Hutchison -
Phil Mayers -
Scott Armitage -
Stefan Paetow