* a.l.m.bu...@lboro.ac.uk <a.l.m.bu...@lboro.ac.uk> [Thu, 5 Feb 2009 16:52:36 +0000]: > >> I had to ask, I have people telling me that this is a limitation of only >> FreeRADIUS and not all RADIUS servers in general. There is a concern >> that the UP is being stored in clear text in Novell and we need to turn >> off that service and only use simple password. Since I am no Novell >> admin I really do not have a clue if we can encrypt the UP that is stored >> on the server or what other implications there are in turning off UP. > > you *might& be able to encrypt it - it'll still have to be in the same > place etc - then you might be able to use the auto-handle features > of FreeRADIUS for it to decrypt the password to something suitable. > never tried, but sounds feasible. the record would/may(?) have to > start with the encryption flavour used eg {SHA256} or somesuch > A shared secret would need to be known by both parties (or to have some public key infrastructure in place) for encryption/decryption to work. If you have a shared secret between already then there hardly is any point. This is where EAP-TTLS steps in to save the day, effectively SSL for RADIUS/EAP.
<nitpick> hash != encryption </nitpick> You can use hashes to provide authenticity of a chunk of data (HMAC's). To encrypt that's where AES, Blowfish and such step in and for those to work you need a key, which means you need a shared secret between you and the client; which in a round about way defeats the point of the authentication. 'Other' RADIUS servers, I am almost certain, just do a bog standard LDAP bind[1] and work on from there. Cheers [1] use the plaintext password and authenticate pretending to be an LDAP client using the users credentials; identical to how you would use ldap(search|modify|add|kitchensink) with credentials -- Alexander Clouter .sigmonster says: Graduate life: It's not just a job. It's an indenture. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html