(Maybe it's safer to use a different password for wireless access than for the rest of your enterprise services to mitigate the problem? But if you're going to do that, you could just go the EAP-TLS route anyway. And it doesn't obviate the need for checking the AP certificate to prevent traffic interception)
Some organisations already do this. Some universities are clear about this, i.e. that your eduroam password should not be the same as your login password to your mail etc. 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 1 Oct 2016, at 12:16, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
(Maybe it's safer to use a different password for wireless access than for the rest of your enterprise services to mitigate the problem? But if you're going to do that, you could just go the EAP-TLS route anyway. And it doesn't obviate the need for checking the AP certificate to prevent traffic interception)
Some organisations already do this. Some universities are clear about this, i.e. that your eduroam password should not be the same as your login password to your mail etc.
We do this at the University of Cambridge - our ‘Network Access Token’ is a randomly-generated long-ish password users cannot choose. They can visit a website (authenticated with their normal username/password) and see it. The only option they have to reset (perhaps their laptop is lost or stolen) it is to push a button and a new password is generated. This is largely equivalent to ‘application-specific passwords’ that Google and Microsoft support (mainly for legacy applications that don’t support 2-factor authentication). It’s not perfect but it does solve the problem of the password being the same as the one the user would choose themselves (they won’t pick one of the ones we autogenerate for them!) and means we care less(*) about the security of them in that they can’t get at email or private files/systems - so some of the limitations of 802.1X supplicants is less of an issue. We also use this token for our IPSec VPN service. - Bob * note that I said ‘less’ - we do still care about it -- Bob Franklin rcf34@cam.ac.uk / (+44 1223 7) 48479 Networks, University Information Services, University of Cambridge
participants (2)
-
Robert Franklin -
Stefan Paetow