FreeRADIUS without Universal Password

[Alexander Clouter]

* A.L.M.Buxey at lboro.ac.uk <A.L.M.Buxey at 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.