Hello Everybody, We are dealing with secuirty problems of Radius in proxy chaining setup whre end-to-end security is missing. According to RFC 2607 (Proxy Chaining and Policy Implementation in Roaming) follwing are the security threats : Message editing Attribute editing Theft of passwords Theft and modification of accounting data Replay attacks Connection hijacking Fraudulent accounting We are particulary intrested to solve the problem of Theft of password. Our idea is based on the assumtion each remote or home Radius server will have its own key pair (public and private key). whenever a user is in some other domain, then the user will sends it's passwrod encrypted with the public key of its home radius sever and send to NAS of visting domain, which will further encrypt and send to its Radius server which will forward to the Remote Radius server. Upon receving Access-request remote radius server as a first step decrypt the password field with the shared secret between itself and proxy radius server residing a hop before remote server. And finally the remote server decrypt the passwod field with its private key. Now the password is in clear text for authenticaiton. The advantage of this scheme is proxy radius server cannot see password in clear text. We are planning to implement this feature. I would like to hear feedback and comments on this scheme. Is there any other way to overcome theft of password threat? Thanks in advance. Tahseen
Hi,
We are particulary intrested to solve the problem of Theft of password. (snipp) The advantage of this scheme is proxy radius server cannot see password in clear text.
Why send clear text passwords over the net at all? I.e., why don't you simply use CHAP or a similar protocol? Regards, Stefan
Hi Stefan,
Why send clear text passwords over the net at all? I.e., why don't you simply use CHAP or a similar protocol?
The problem is end-to-end security in proxy chaining envrionment. What ever may be the protocol(CHAP or any EAP method) proxy server can see the passwrod since it posses the shared secret key together with the radius server residing one hop before and after itself. So there is threat of theft of password. In order to overcome this threat we planned to use public key cryptography as explained in previous email. (request) (request) (request) NAS ----------> Proxy1 ----------> Proxy2 ----------> Home (reply) (reply) (reply) Server <--------- <--------- <--------- To make it more clear lets take help of above figure. Here proxy1 and proxy2 are threat to user password because both of these proxies can decrypt the password field and see the password in clear text. Thanks in advance, Tahseen.
"Tahseen Hussain" <stud3080@itu.dk> wrote:
The problem is end-to-end security in proxy chaining envrionment. What ever may be the protocol(CHAP or any EAP method) proxy server can see the passwrod
No. This is NOT true. With CHAP or MS-CHAP, the proxying server does not see the password. With EAP, the proxying server MAY see the password, depending on the EAP type, and how the proxying works. It will NOT see the password for EAP-MD5, PEAP (MSCHAPv2), EAP-TLS, EAP-SIM, etc. Please understand how the existing protocols work before designing another one. Alan DeKok.
"Tahseen Hussain" <stud3080@itu.dk> wrote:
We are dealing with secuirty problems of Radius in proxy chaining setup whre end-to-end security is missing.
There was a proposal years ago to use kerberos to solve thus (and other) problems, but it went nowhere.
Our idea is based on the assumtion each remote or home Radius server will have its own key pair (public and private key). whenever a user is in some other domain, then the user will sends it's passwrod encrypted with the public key of its home radius sever
How are you going to fix the umpteen million clients out there to have this public key, and implement this algorithm? On way to get the same effect (without the problems) is to use EAP-TTLS with PAP inside of the tunnel. All of the intermediate proxies can proxy the TLS session, but they don't know what's inside it. The home server terminates the tunnel, so it gets access to the key. All that's required here is that the supplicant have the home servers certificate, AND that the "validate server certificate" checkbox is selected.
We are planning to implement this feature. I would like to hear feedback and comments on this scheme. Is there any other way to overcome theft of password threat?
If you do this, I'm curious to know which clients you will update to have this feature, and how you will implement it. Personally, I'd just use a standard authentication method. Alan DeKok.
participants (3)
-
Alan DeKok -
Stefan.Neis＠t-online.de -
Tahseen Hussain