Project

General

Profile

Feature #3014

Support UTF-8 encoded passwords in EAP-MSCHAPv2

Added by Sebastian Thias over 6 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Tobias Brunner
Category:
interoperability
Target version:
5.8.0
Start date:
Due date:
Estimated time:
Resolution:
Fixed

Description

Hi,

I just set up a strongswan-instance with eap-radius bound to a windows-NPS-radius-server using IKEv2 with EAP-MSChapv2. Everything is working fine, except for users that have non-ascii-characters in their passwords. In this case I stumbled upon a password containing an umlaut and the NPS-Server rejects the authentications-request with a "wrong username or password"-message. When exchanging the umlaut with a plain ASCII-letter, everything works as expected. After some digging I found this:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClooCAC

stating that the NPS encodes in extended ASCII rather than UTF-8. Would there be any possibility to configure the encoding used for communicating with a radius-backend?

Thank you very much in advance!

Best regards,
Sebastian

History

#1 Updated by Tobias Brunner over 6 years ago

  • Category set to interoperability
  • Status changed from New to Feedback

You are confusing the RADIUS password (to protect the communication with the RADIUS server) with the user passwords verified via EAP-MSCHAPv2. The latter are actually UTF-16 encoded, which strongSwan as client doesn't do, it just uses the password bytes and adds a zero byte to each. As server via RADIUS, strongSwan is not involved in the password verification, though, so if that scenario fails with clients other than strongSwan, it's either those clients' or the RADIUS server's fault.

#2 Updated by Sebastian Thias over 6 years ago

Ok, sorry for the misunderstanding and thanks for the quick reply.

Actually I tried this with the strongswan-app on android and MacOS as client - the behaviour shows the same problems. We also use this NPS-server as an authentication-backend for our 802.1x-wifi-authentication where the password check works flawlessly, this was why I suspected something between strongswan and the NPS to be the issue.

I'll try to investigate further...

#3 Updated by Tobias Brunner over 6 years ago

Actually I tried this with the strongswan-app on android and MacOS as client - the behaviour shows the same problems.

That's exactly what I'm saying. strongSwan does not support this as client.

#4 Updated by Sebastian Thias over 6 years ago

OK! So you say that the conversion to UTF-16 will go wrong if a multibyte-character is sent in a password-string, because strongswan just pads each password-byte with a 0x00 ?

Is there any chance to change this behaviour?

#5 Updated by Tobias Brunner over 6 years ago

So you say that the conversion to UTF-16 will go wrong if a multibyte-character is sent in a password-string, because strongswan just pads each password-byte with a 0x00 ?

The password is never sent, this happens on the client during EAP-MSCHAPv2 (source:src/libcharon/plugins/eap_mschapv2/eap_mschapv2.c#L545).

Is there any chance to change this behaviour?

Unlikely to happen anytime soon (in non-GUI setups you could use pre-prepared NTLM secrets to avoid this issue).

#6 Updated by Sebastian Thias over 6 years ago

So the task would be to include something like this to convert utf-8 to utf-16?

https://doc.freeradius.org/misc_8c_source.html#l00580

#7 Updated by Tobias Brunner over 6 years ago

  • Tracker changed from Issue to Feature
  • Subject changed from Possible Encoding-Issue between Microsoft NPS and eap-radius to Support UTF-8 encoded passwords in EAP-MSCHAPv2
  • Target version set to 5.8.0
  • Affected version deleted (5.6.2)

So the task would be to include something like this to convert utf-8 to utf-16?

Yes, if we assume the password is provided in UTF-8 encoding (which I guess is reasonable nowadays). I pushed something to that effect to the 3014-eap-mschap-utf8 branch.

#8 Updated by Sebastian Thias over 6 years ago

Thank you !!!

#9 Updated by Tobias Brunner over 6 years ago

  • Assignee set to Tobias Brunner
  • Resolution set to Fixed

I've uploaded a beta version of our Android app that includes this fix to Google Play. Let me know if this works for you.

#10 Updated by Sebastian Thias over 6 years ago

Yes - authenticating via the app towards a Microsoft-NPS-Server via strongswan-eap-radius now also works with German umlauts! Thanks a lot!

#11 Updated by Tobias Brunner over 6 years ago

  • Status changed from Feedback to Closed

Yes - authenticating via the app towards a Microsoft-NPS-Server via strongswan-eap-radius now also works with German umlauts! Thanks a lot!

Thanks for testing. The app is now live.

#12 Updated by Sebastian Thias over 6 years ago

Wonderful! Thank you very much for your incredibly quick and valuable communication and help!