eduroam using Eap-ttls and securing user's password

[Gerald Vogt]

On Fri, Jun 17, 2011 at 9:15 AM, Reg Emailster <regemailster at 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 at 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