Can I use with Radius + LDAP passwords in md5

I want to use radius to work with cisco ipsec. User accounts stored in ldap. Passwords are stored in a ldap md5. In the config Radius found such a restriction:

        #  However, LDAP can be used for authentication ONLY when the
        #  Access-Request packet contains a clear-text User-Password
        #  attribute.  LDAP authentication will NOT work for any other
        #  authentication method.
        #  This means that LDAP servers don't understand EAP.  If you
        #  force "Auth-Type = LDAP", and then send the server a
        #  request containing EAP authentication, then authentication
        #  WILL NOT WORK.

Q - Can I use with Radius + LDAP passwords in md5?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

nociSoftware EngineerCommented:
Not for EAP or most modern authentication mechanisms...

IF your password goes over the wire/air UNENCRYPTED it can be stored encrypted.  this seems not to be desirable.

IF your password is hashed together with other info at the source,
then to compare the same must be done on the destination the other info included might be time or knowledge about the link (source & destination IP address)  etc. all are common at both ends.
to be able to do that REQUIRES an unencrypted password (in storage).

Therefore you cannot use an MD5 password with an modern authentication mechanism.

Password stores nowadays aren't flat files anymore that were visible to everybody.  So the protection of stored data can be achieved in a different way.
And the networked medium arguably is much easier to tap then a straight cable.
mik0sAuthor Commented:
But store passwords in the clear as it seems to me very badly. What do I do?
nociSoftware EngineerCommented:
If you store the password in LDAP then you can store the files on an encrypted filesystem if you like.  You have to manage proper security on the access to the data. LDAP can help you can restrict access to a field in ldap based on credentials.
In the past the password files were public readable (there was more info there that was needed afterwards by other processes) this was alleviated when the shadow password file came to use.
LDAP should protect access to your passwords. If your system is for general use you can think about moving LDAP to a specialized identity server (a system that ONLY runs LDAP and is only accessible for systems management) Could be done in a 4-eyes principle if needed.

The alternative to storing password unencrypted is to send them unencrypted over the wire when authenticating... that's even more undesirable.
Security is never absolute.
Your password is only secure in a system if you turn the power off and pour the system under concrete. But its not usable anymore.
It's a scale and it's about risk management. Who do you trust more:
Your company personel or any person from the street. (Again there is no absolute trust).
Do You Have a Trusted Wireless Environment?

A Trusted Wireless Environment is a framework for building a complete Wi-Fi network that is fast, easy to manage, and secure.

mik0sAuthor Commented:
I understand that, but I can not store the passwords in clear text in LDAP, because they use other software, which can not work with clear text passwords.
In this case, what mechanism should I use on Cisco Air?
nociSoftware EngineerCommented:
Right, but it is a restriction by some other application, it is not a restirction for LDAP.
If you need to authenticate to LDAP it doesn't matter what password you put there it can handle a lot of different methods.

You might need to configure a different field as the "password for network access" field which is not encrypted.
People do have two passwords then.
mik0sAuthor Commented:
Ok, thanks, I already considered that variant, but would like to see someone this limitation - freeradius? It may be another Radius server to use, which has no such restriction?
nociSoftware EngineerCommented:
The limitation is not the radius implementation it is the method how authentication happens...

EAP works like this:

Both sides generate a random number and both exchange that, and both agree on an encryption & signing method.

The initiator:
Agrees with the other on a random string of bits (sometimes named 'cookie' or 'salt') which is used to randomize the signing.
The password, or known secret, is then pulled through a md5/sha1 together with the salt.
The hashed password is sent over the wire after encrypting it with available keys (public/private, or symmetric).

The receiving end can then ONLY decrypt until the it has the hashed password. (this decryption certifies the other end to a degree, because it must have the private key or knowns the symmetric key)
It also has the the salt and IT HAS the known secret., Using the salt + known secret it can generate an identical hash as the initiator did. If the hashes match it is considered proof of identity...

If one side only has the MD5 stored, the random string must be known in advance (and it must stay fixed...). This is also with passwords stored in the password file the salt is generated from the username + a random value. That random value is prefixed in an md5 password.

The technique used (EAP) means that the password MUST BE available in clear text form at BOTH sides of a channel. So if you dont want to do that you need to find something else then EAP to be used. whichever software you used it's the authentication mechanism that demands this.
(That is allready so when using CHAP in ppp. pap sends the password unencrypted over the wire while chap more less works like EAP, it only doesn't use certificates.)

If you compare this to f.e. CISCO then the passwords are not encrypted, they are only obfusciated. Tools do exist make a password readable again from the obfusciated one, the cisco algorithm is slightly better then rot-13.

The public key is extracted from a certificate

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
mik0sAuthor Commented:
These theme seems very difficult to me. I'm afraid I don't understand all you wrote about.
Maybe you can recommend me a good book about it?
nociSoftware EngineerCommented:
Please lookup the documents mentioned in the reference section of the Article:

Also check this article about pap&chap (the precursors for EAP).
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.