A co-worker of mine here has been asking questions of the list today
but I have some of my own.
Namely, I don't know much about how Radius does it's magic, but
unless I am completely off the bat here, it appears to me that some
sort of channel is created between the Radius client and the server
over which requests are sent. These requests include a user and a
password and other information. The radius server will then compare
the user and password to the ones in it's configured database and
either authenticate or not.
Unix passwords are encrypted through a one-way function and stored in
a password file. These passwords can no longer be reversed back to
their clear text format but it is possible to take a clear text
user and password (from the radius client) and convert it to this
format and compare the two thus matching, or not.
I can imagine that PEAP, specifically, does the password encryption
on the client and passes that on, using a similar but obviously not
the same, one way encryption algorithm, thus requiring the radius
server to have access to a clear text password which it would encrypt
with the same key and algorithm in order to match to the one from
the client.
If this is the case, than I can readily see how it can never (never
being a long time) be possible to use these sorts of passwords along
with UNIX encrypted passwords. This is a darn shame, but if it is
indeed the case, so be it.
I am asking the list if this is the case or if the reason
authentication isn't possible is a simple programming effort that
hasn't been done.
Also, given our setup:
Client: Cisco Wireless AP (1200)
Server: Linux running Freeradius
What is the optimal means to provide maximum security and still be
able to authenticate against the unix shadow password file?
Thank you for your time - Yossie
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
