Mac OSX + PEAP/MSCHAPv2 + Special characters in password
Hello, One of our institution reported that some of their users, using Mac OSX, couldn't connect to eduroam. It appears that those users have special characters in their password (éৣ ect). I can log with such an account using Windows, iOS, Android or eapol_test, but with the default settings on Mac OSX (PEAP/MSCHAPv2) it fails : mschap : MS-CHAP2-Response is incorrect. The current workaround at the moment is to deploy a .mobileconfig profile to configure their 802.1x settings to use TTLS/PAP, which works correctly. We spent some time debugging this issue with Arran and think that's an implementation error by MacOSX regarding the encoding of the password used to generated the hash for MSCHAPv2. But so far I wasn't able to confirm it by looking at the Apple discussion forums. Has anyone of you also encountered this issue ? Regards, Olivier B. -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mail: olivier@heliosnet.org
On 14/05/14 13:44, Olivier Beytrison wrote:
We spent some time debugging this issue with Arran and think that's an implementation error by MacOSX regarding the encoding of the password used to generated the hash for MSCHAPv2. But so far I wasn't able to confirm it by looking at the Apple discussion forums.
Has anyone of you also encountered this issue ?
Not directly, but very similar issues yes. It tends to happen when the client doesn't correctly convert the unicode password into an octet string before generating the hash. What locale are those OSX devices set to?
On 14/05/14 14:21, Olivier Beytrison wrote:
On 14.05.2014 15:12, Phil Mayers wrote:
What locale are those OSX devices set to?
fr_CH.UTF-8
They could be making the obvious mistake of treating the password as bytes rather than a unicode string, and generating "pseudo" utf-16-le by padding "xyz" to "x\x00y\x00z\x00" The string: test§ ...is UTF-8 bytes 74657374c2a7 (note the "c2" in penultimate octet) ...but UTF-16-LE 7400650073007400a700 If they are making this obvious mistake, they're effectively generating the MD4/NT hash from "test§" instead of "test§". Might be possible to confirm this by changing the server-side password to the "wrong" one.
Unfortunately all too much software makes that mistake. :-/ Stefan -----Original Message----- 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 Phil Mayers Sent: 14 May 2014 16:03 To: freeradius-users@lists.freeradius.org Subject: Re: Mac OSX + PEAP/MSCHAPv2 + Special characters in password On 14/05/14 14:21, Olivier Beytrison wrote:
On 14.05.2014 15:12, Phil Mayers wrote:
What locale are those OSX devices set to?
fr_CH.UTF-8
They could be making the obvious mistake of treating the password as bytes rather than a unicode string, and generating "pseudo" utf-16-le by padding "xyz" to "x\x00y\x00z\x00" The string: test§ ...is UTF-8 bytes 74657374c2a7 (note the "c2" in penultimate octet) ...but UTF-16-LE 7400650073007400a700 If they are making this obvious mistake, they're effectively generating the MD4/NT hash from "test§" instead of "test§". Might be possible to confirm this by changing the server-side password to the "wrong" one. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html 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 14/05/14 16:36, Stefan Paetow wrote:
Unfortunately all too much software makes that mistake. :-/
Indeed. The context I've seen it was early version of MIT Kerberos encoding the password to iso-8859-1 versus Windows 2000 which encodes to UTF8. In that situation, any character not in the basic US-ASCII range 32-126 inclusive was unsafe to use cross-platform. We still advise people to avoid non-ASCII characters in passwords :o( The IT industry really is a bad joke, told by a malicious higher power...
I shan't mention one of my former employers then who advised users to avoid the GBP STG symbol because it caused issues with their ANSI (!!!) password read/write mechanisms. *eyeroll* Stefan -----Original Message----- 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 Phil Mayers Sent: 14 May 2014 16:52 To: freeradius-users@lists.freeradius.org Subject: Re: Mac OSX + PEAP/MSCHAPv2 + Special characters in password On 14/05/14 16:36, Stefan Paetow wrote:
Unfortunately all too much software makes that mistake. :-/
Indeed. The context I've seen it was early version of MIT Kerberos encoding the password to iso-8859-1 versus Windows 2000 which encodes to UTF8. In that situation, any character not in the basic US-ASCII range 32-126 inclusive was unsafe to use cross-platform. We still advise people to avoid non-ASCII characters in passwords :o( The IT industry really is a bad joke, told by a malicious higher power... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html 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 14.05.2014 17:03, Phil Mayers wrote:
If they are making this obvious mistake, they're effectively generating the MD4/NT hash from "test§" instead of "test§". Might be possible to confirm this by changing the server-side password to the "wrong" one.
It sounds like a good idea :) I'll try this to confirm the issue. It it's confirme, the hard part will be to report it to apple :p Thx ! Olivier B. -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mail: olivier@heliosnet.org
On 14.05.2014 21:54, Olivier Beytrison wrote:
On 14.05.2014 17:03, Phil Mayers wrote:
If they are making this obvious mistake, they're effectively generating the MD4/NT hash from "test§" instead of "test§". Might be possible to confirm this by changing the server-side password to the "wrong" one.
It sounds like a good idea :) I'll try this to confirm the issue. It it's confirme, the hard part will be to report it to apple :p
Thx !
Olivier B.
Well no, setting the password in the backend with the incorrectly encoded password doesn't work. the MAC is still unable to connect. Time to escalate this to Apple. Olivier -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mail: olivier@heliosnet.org
Olivier Beytrison wrote:
We spent some time debugging this issue with Arran and think that's an implementation error by MacOSX regarding the encoding of the password used to generated the hash for MSCHAPv2. But so far I wasn't able to confirm it by looking at the Apple discussion forums.
If you can't make progress, ping me offline, and I'll see if my contacts at Apple can help. Alan DeKok.
participants (5)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Olivier Beytrison -
Phil Mayers -
Stefan Paetow