I'm pouring through the alphabet soup of all of this and have a few questions that keep popping up. During a pap conversation, the radius server ends up with the username/password passed to it from the client. It then encrypts the password to match the encryption of the stored password in ldap (or other directory) and tries a bind. Correct? During a PEAP conversation, the radius server also would end-up with a username/password received from the client (either via clear-text or via the mschap conversation). Why can it not then encrypt the password just like PAP did? Does it do the comparison to LDAP stored passwords via MSCHAP as well? Thanks for any info. Matt mda@unb.ca
Matt Ashfield wrote:
During a pap conversation, the radius server ends up with the username/password passed to it from the client. It then encrypts the password to match the encryption of the stored password in ldap (or other directory) and tries a bind. Correct?
No. LDAP bind is done using the clear-text password supplied by the user in the Access-Request. If the "known good" password is stored *hashed* in a DB, then FreeRADIUS isn't doing "LDAP bind". Instead, it pulls the hashed password from the DB, hashes the password in the Access-Request, and compares the two hashes.
During a PEAP conversation, the radius server also would end-up with a username/password received from the client (either via clear-text or via the mschap conversation).
It's almost always MS-CHAP.
Why can it not then encrypt the password just like PAP did? Does it do the comparison to LDAP stored passwords via MSCHAP as well?
If the LDAP server supplies the clear-text password to FreeRADIUS, yes. If it doesn't, LDAP bind won't work, because the Access-Request doesn't contain a clear-text password. And since LDAP servers don't do MS-CHAP, you're left with somehow getting FreeRADIUS to do the job, which means supplying it with the cleartext password. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Feb 14, 2007, at 2:05 PM, Matt Ashfield wrote:
During a pap conversation, the radius server ends up with the username/password passed to it from the client. It then encrypts the password to match the encryption of the stored password in ldap (or other directory) and tries a bind. Correct?
There are two methods when it comes to LDAP, bind or compare. In the bind option, as used when "ldap" is in the authenticate section, does not encrypt the password received from the client, it just uses that in an LDAP bind operation and checks the return status for success or failure. In the compare option, as would be used if you retrieved the password hash from LDAP during the authorize phase and used the PAP module in the authenticate section, the password hash is actually *retrieved* from LDAP and compared against the password retrieved from the client (possibly encrypting the password from the client to see if the hashes match in the case of an encrypted password stored in LDAP).
During a PEAP conversation, the radius server also would end-up with a username/password received from the client (either via clear-text or via the mschap conversation). Why can it not then encrypt the password just like PAP did? Does it do the comparison to LDAP stored passwords via MSCHAP as well?
That depends on the inner authentication. During what most people thing of as PEAP, which is PEAP with EAP-MSCHAPv2 inside the tunnel, the RADIUS server does not received a password for the user. Rather, it received a hash based on information previously sent by the RADIUS server. Since it is not receiving the actual password from the client, there is no way to translate what it receives into what would be needed to do a comparison or bind using the pap or ldap modules. You *can* store a plain-text password or an NTLM-hashed password in your LDAP tree to be used by rlm_mschap for the EAP-MSCHAPv2 portion of the conversation, but that's pretty much your only choice when dealing with LDAP (and is what we do). --Mike
Matt Ashfield wrote:
I'm pouring through the alphabet soup of all of this and have a few questions that keep popping up.
During a pap conversation, the radius server ends up with the username/password passed to it from the client. It then encrypts the password to match the encryption of the stored password in ldap (or other directory) and tries a bind. Correct?
Yes
During a PEAP conversation, the radius server also would end-up with a username/password received from the client (either via clear-text or via the mschap conversation). Why can it not then encrypt the password just like PAP did? Does it do the comparison to LDAP stored passwords via MSCHAP as well?
No, miles off. During a PEAP/MS-CHAP conversation, the server ends up with: challenge == random bytes response == HASH(challenge, HASH(password)) If the server has any of: * the plaintext password * HASH(password) i.e. the NT or LM hashes * access to a domain controller which has the NT/LM hashes ...it can check the challenge and response match and that the client is who they say they are.
participants (4)
-
Alan DeKok -
Matt Ashfield -
Michael Griego -
Phil Mayers