eduroam using Eap-ttls and securing user's password
Hi all, Sorry if this question has been posted before. I have a simple question regarding how to ensure the user's password is never leaked or found out by anyone, including administrators of the radius server or the backend LDAP server. My requirement is that I would like to store the user password as a hash (eg SHA-256) within the LDAP. Now if I was to use this LDAP server as the authentication source for the Radius server for eduroam. I would need to use EAP-TTLS with PAP as the inner authentication (since I don't have a reversible password at the backend). Now I notice that because it uses PAP, if I enable user-password logging on the radius server, I can see the user's supplied password when their machine is authenticating to access eduroam. This problem is even worse if the user is traveling at a partner's institution and using eduroam, in that if that partner insititution's RADIUS server has user-password logging enable, they too can see my user's password. I wonder if there's anything that can be done to prevent this, or have I missed something in my understanding? Thanks,
On Fri, Jun 17, 2011 at 8:36 AM, <regemailster@gmail.com> wrote:
This problem is even worse if the user is traveling at a partner's institution and using eduroam, in that if that partner insititution's RADIUS server has user-password logging enable, they too can see my user's password.
That's not correct. The "partner institution" (the place your user visits) only proxies radius requests. They don't know what is inside. They don't see any passwords from your users. They would only see the password if one of your users incorrectly tries to authentication against the "partner institution" domain. But this should never happen if they set up eduroam correctly, set the correct user name including the domain name of your institution and also only accept the certificate of your radius server. If the eduroam wireless connection is set up correctly on the computer and the user uses it correctly the "partner institution" radius server will only see the outer identity and then proxies the requests back to your radius server. This requires correct settings on the user's computer and knowledge not accept certificates or radius servers which you did not configure before... Gerald
Thanks Gerald for the reply. Just to confirm, you are saying that at the partner's institution, the user's client will set up an encrypted channel all the way back to the client's home institution RADIUS server (determined using the login realm), and their plain password will be passed inside this encrypted channel? IIf that is the case, then I would feel a lot safer since the only place which can potentially see the password is the home institution RADIUS server which is not such a concern I guess. On 17/06/2011, at 4:09 PM, Gerald Vogt wrote:
On Fri, Jun 17, 2011 at 8:36 AM, <regemailster@gmail.com> wrote:
This problem is even worse if the user is traveling at a partner's institution and using eduroam, in that if that partner insititution's RADIUS server has user-password logging enable, they too can see my user's password.
That's not correct. The "partner institution" (the place your user visits) only proxies radius requests. They don't know what is inside. They don't see any passwords from your users.
They would only see the password if one of your users incorrectly tries to authentication against the "partner institution" domain. But this should never happen if they set up eduroam correctly, set the correct user name including the domain name of your institution and also only accept the certificate of your radius server.
If the eduroam wireless connection is set up correctly on the computer and the user uses it correctly the "partner institution" radius server will only see the outer identity and then proxies the requests back to your radius server. This requires correct settings on the user's computer and knowledge not accept certificates or radius servers which you did not configure before...
Gerald - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 06/17/2011 08:15 AM, Reg Emailster wrote:
Thanks Gerald for the reply.
Just to confirm, you are saying that at the partner's institution, the user's client will set up an encrypted channel all the way back to the client's home institution RADIUS server (determined using the login realm), and their plain password will be passed inside this encrypted channel?
Correct. In Eduroam, the EAP flows between a client and their home site. The visited site is just a proxy, and only ever receives the final per-session random crypto keys needed for WPA-Enterprise to encrypt the wireless link. However: a malicious visited (partner, as you call it) site or an attacker impersonating an eduroam site could in theory try to terminate the TTLS portion of the EAP. This is why "validate server certificate" is so important. Be sure you instruct your clients to tick the appropriate boxes.
On Fri, Jun 17, 2011 at 9:15 AM, Reg Emailster <regemailster@gmail.com> wrote:
Just to confirm, you are saying that at the partner's institution, the user's client will set up an encrypted channel all the way back to the client's home institution RADIUS server (determined using the login realm), and their plain password will be passed inside this encrypted channel? IIf that is the case, then I would feel a lot safer since the only place which can potentially see the password is the home institution RADIUS server which is not such a concern I guess.
Exactly. That's why it's TTLS. It's a TLS connection between the client and your radius server. Inside that TLS connection will be the user authentication using PAP or MSCHAP. But again: your users must understand what they are doing. Too many users simply accept any certificate warning they see without ever really looking at it or know what they should accept and what not. That's why the client computers should be configured correctly in advance and users should be told to never accept any certificate warning if they come across one during a connection attempt through eduroam. For example, on Windows 7 (using PEAP or SecureW2/TTLS) you can configure which certificates to trust for this connection, the name of the radius servers to accept. If you do that they should never see a certificate warning or will be asked to check a server certificate. If they do, there is something wrong and the user MUST NOT continue. They should also not try different user names or other things in case the connection does not work. If the password is not remember, all they have to do is to enter the password. Nothing else. Thus, important task for you is to make sure your users obey these rules. Otherwise things like these happen: 1. the connection does not immediately work. The user is prompted again for the username and password. The user tries a different user name, e.g. instead of gerald@example.com he tries only gerald. The latter authenticates against the partner radius domain revealing the password if it is PAP... All the while, your radius server was down for a few minutes and could not be reached. The user should never change the user name and should know to always include the domain. 2. the partner radius server is misconfigured and does not proxy the requests to your radius server but instead wants to do local authentication. Your user sees a warning message asking whether or not to accept the server certificate issued to a different radius server name and/or from a different CA. The user doesn't care and accepts it. This reveals the PAP password again to the partner institution. -Gerald
participants (4)
-
Gerald Vogt -
Phil Mayers -
Reg Emailster -
regemailster＠gmail.com