Hi you all, I've got an LDAP attribute mapped into user-password RADIUS attribute. This attribute is RSA-ciphered so RADIUS have to deciphered it when it arrives in order to use it for authentication. The problem arise when I try to use an RSA key pretty much longer than 1400 bytes, because the resulting value exceed the 253 bytes RADIUS specification length limit. My questions are: Is this size limit mandatory even when this RADIUS attribute is never put on the wire? If so, could anybody point a way which allow me to use longer RSA keys? Thanks in advance. Greetings -- ========================================================= Fco. Javier Melero de la Torre Universidad Carlos III de Madrid Servicio de Informática y Comunicaciones Area de Seguridad y Comunicaciones (https://asyc.uc3m.es) e-mail: javier@di.uc3m.es phone: (+34) 916.249.980, (+34) 918.561.341 fax: (+34) 916.249.430 =========================================================
Fco. Javier Melero wrote:
I've got an LDAP attribute mapped into user-password RADIUS attribute. This attribute is RSA-ciphered
And why would you do that? It's completely useless.
so RADIUS have to deciphered it when it arrives in order to use it for authentication. The problem arise when I try to use an RSA key pretty much longer than 1400 bytes, because the resulting value exceed the 253 bytes RADIUS specification length limit. My questions are:
Is this size limit mandatory even when this RADIUS attribute is never put on the wire?
In the current implementation of the server, yes.
If so, could anybody point a way which allow me to use longer RSA keys?
Run a separate program to connect to LDAP, obtain the password, and decrypt it. Alan DeKok.
Alan DeKok escribió:
Fco. Javier Melero wrote:
I've got an LDAP attribute mapped into user-password RADIUS attribute. This attribute is RSA-ciphered
And why would you do that? It's completely useless.
Well, surely I'm missing something, but that's the way I've found to store clear text passwords in LDAP keeping some peace of mind. What could be the alternative? Thanks for your help -- ========================================================= Fco. Javier Melero de la Torre Universidad Carlos III de Madrid Servicio de Informática y Comunicaciones Area de Seguridad y Comunicaciones (https://asyc.uc3m.es) e-mail: javier@di.uc3m.es phone: (+34) 916.249.980, (+34) 918.561.341 fax: (+34) 916.249.430 =========================================================
Fco. Javier Melero wrote:
Well, surely I'm missing something, but that's the way I've found to store clear text passwords in LDAP keeping some peace of mind. What could be the alternative?
Storing them as clear-text. Encrypting them adds *zero* benefit, because application that needs the passwords has to be given the decryption key. Since the decryption key is scattered all over the place in your network, it's not adding much security. To put it another way, almost no one does what you're doing. Alan DeKok.
Alan DeKok escribió:
Fco. Javier Melero wrote:
Well, surely I'm missing something, but that's the way I've found to store clear text passwords in LDAP keeping some peace of mind. What could be the alternative?
Storing them as clear-text.
Encrypting them adds *zero* benefit, because application that needs the passwords has to be given the decryption key. Since the decryption key is scattered all over the place in your network, it's not adding much security.
To put it another way, almost no one does what you're doing.
Maybe some context will help. What we are trying to do is implement a 802.1x wireless lan which can allow multiple EAP methods under the same SSID. If you want TTLS/PAP and PEAP/MSCHAP working together the only way is to use clear text passwords (or I think so). In our scenario, which is only a test so far, there will be no applications using this attribute. Radius server will be the only one which will have the private key, and hopefully keeping it as save as we could the whole system will have a reasonable security. Are we driving ourselves insane? Tell me the truth ;-) Have a nice weekend. -- ========================================================= Fco. Javier Melero de la Torre Universidad Carlos III de Madrid Servicio de Informática y Comunicaciones Area de Seguridad y Comunicaciones (https://asyc.uc3m.es) e-mail: javier@di.uc3m.es phone: (+34) 916.249.980, (+34) 918.561.341 fax: (+34) 916.249.430 =========================================================
Fco. Javier Melero wrote:
Maybe some context will help. What we are trying to do is implement a 802.1x wireless lan which can allow multiple EAP methods under the same SSID. If you want TTLS/PAP and PEAP/MSCHAP working together the only way is to use clear text passwords (or I think so).
That is the easiest method.
In our scenario, which is only a test so far, there will be no applications using this attribute. Radius server will be the only one which will have the private key, and hopefully keeping it as save as we could the whole system will have a reasonable security.
You can enforce SSL access to the LDAP server, which will secure the passwords on the wire. You can add filter lists on the LDAP server to prevent anyone else from reading the clear-text password.
Are we driving ourselves insane? Tell me the truth ;-)
Yes. Alan DeKok.
Alan DeKok escribió:
That is the easiest method.
Ok, I've had a look at your Deploying Radius site and that compatibility table. I haven´t seen it before. I guess ntlm_auth can do it too. And we could add a pre-calculated digest hash for those VoIP dudes. We will try all that.
You can enforce SSL access to the LDAP server, which will secure the passwords on the wire. You can add filter lists on the LDAP server to prevent anyone else from reading the clear-text password.
But if somebody manages to break into your LDAP server that won't help you.Of course, somebody can break into your RADIUS server too, but, at least in our case, the RADIUS server is easier to protect (no operators updating the database and not unknown clients connecting to it). IMHO It's better to avoid plain-text passwords, but, if you really need them, the whole system security will be stronger (or less weak) with that asymmetric ciphering than without it.
Yes. lol Well, It wouldn't surprise me.
Javier
Fco. Javier Melero wrote:
Ok, I've had a look at your Deploying Radius site and that compatibility table. I haven´t seen it before. I guess ntlm_auth can do it too. And we could add a pre-calculated digest hash for those VoIP dudes. We will try all that.
You need ntlm_auth ONLY for Active Directory. For every other LDAP server, you can just store the NT hash directly. But even that is pretty meaningless. You can get crackers that will turn 99% of the NT hash into clear-text passwords in 5 minutes. Fake security just wastes your time.
But if somebody manages to break into your LDAP server that won't help you.Of course, somebody can break into your RADIUS server too, but, at least in our case, the RADIUS server is easier to protect (no operators updating the database and not unknown clients connecting to it).
If it is visible on the network, then people can attack it. They may not succeed, but they can try. And the security of the RADIUS protocol is pretty bad.
IMHO It's better to avoid plain-text passwords, but, if you really need them, the whole system security will be stronger (or less weak) with that asymmetric ciphering than without it.
I'm not sure I agree. Adding little pieces of security to address perceived flaws is almost always a waste of time. It's better to do a *system* security analysis, and a suite of security fixes for your entire system. Alan DeKok.
I'm not sure I agree. Adding little pieces of security to address perceived flaws is almost always a waste of time.
It's better to do a *system* security analysis, and a suite of security fixes for your entire system.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I think is clear enough. Thanks for your patient and valuable comments. We'll really keep them in mind. Javier
participants (2)
-
Alan DeKok -
Fco. Javier Melero