I have configured a working EAP-TLS system and am now migrating to use EAP-TTLS (with both client side certificates and a password authentication mechanism). I'm stuck trying to work out how to avoid sending the password unhashed to the server and think that some form of CHAP/MSCHAPv2 might be the right way to go. My current thoughts are that I should use PAP with SHA1 or SSHA1 but I seem to get the right config (if it is even possible). So, with this problem, can anybody suggest a way to use SHA1/SSHA1 or some other form of cryptographically secure, non-cleartext password within the inner authentication mechanism of EAP-TTLS for use in WPA2 Enterprise/802.1x. If this is feasible/possible, are there any gotcha's with the various supplicants to getting this to work from the client side and avoiding sending the passwords in cleartext (inside the EAP-TLS tunnel). Also, while I'm here, any suggestions for an appropriate backend password store so that there is never a cleartext password except for the initial entry (password change) on the server side would be appreciated. cheers, James
James Lever wrote:
I'm stuck trying to work out how to avoid sending the password unhashed to the server
Why?
and think that some form of CHAP/MSCHAPv2 might be the right way to go. My current thoughts are that I should use PAP with SHA1 or SSHA1 but I seem to get the right config (if it is even possible).
If you use PAP, it means cleartext passwords are being sent to the server. "PAP with SSHA1" is meaningless, because it's contradictory and impossible.
If this is feasible/possible, are there any gotcha's with the various supplicants to getting this to work from the client side and avoiding sending the passwords in cleartext (inside the EAP-TLS tunnel).
See my web page for compatibility issues: http://deployingradius.com/documents/protocols/compatibility.html
Also, while I'm here, any suggestions for an appropriate backend password store so that there is never a cleartext password except for the initial entry (password change) on the server side would be appreciated.
Your desires are contradictory. If the password is hashed in EAP-TTLS, then the server needs the cleartext password in order to authenticate the user. I don't understand why giving the server access to the cleartext passwords is such a terrible thing to do. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On 29/01/2007, at 10:07 PM, Alan DeKok wrote:
James Lever wrote:
I'm stuck trying to work out how to avoid sending the password unhashed to the server
Why?
Two reasons - first I am trying to limit risk of client misconfiguration - if a client has misconfigured their supplicant, to avoid passwords inadvertently going through in the clear and secondly to limit the risk of account compromise through abuse of privileges on the radius server. Yes, I realise that this is a small risk, but I'm just trying to see how far I can go in terms of securing the user credentials.
See my web page for compatibility issues: http:// deployingradius.com/documents/protocols/compatibility.html
Thanks for the pointer. This helps clarify the requirements of the different authentication mechanisms.
Your desires are contradictory. If the password is hashed in EAP- TTLS, then the server needs the cleartext password in order to authenticate the user. I don't understand why giving the server access to the cleartext passwords is such a terrible thing to do.
What are the risks of client misconfiguration such that it will actually get to the point of attempting to transmit the password in the clear? cheers, James
Hi,
I'm stuck trying to work out how to avoid sending the password unhashed to the server and think that some form of CHAP/MSCHAPv2 might be the right way to go. My current thoughts are that I should use PAP with SHA1 or SSHA1 but I seem to get the right config (if it is even possible).
MSCHAPv2 is the main way to go. offering challenge/response means the password is never sent clear. alternatively you could use MD5 instead of plain. but client support is an issue... alan
On 29/01/2007, at 11:03 PM, A.L.M.Buxey@lboro.ac.uk wrote:
MSCHAPv2 is the main way to go. offering challenge/response means the password is never sent clear. alternatively you could use MD5 instead of plain. but client support is an issue...
After reading through Alan DeKok's compatibility page and a bit further research from that, it would appear that the risk of compromise is greater from poor storage on the server than the transient cleartext credentials inside the EAP-TLS session. cheers, James
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
James Lever