At 12:41 PM 10/24/2001 -0400, Russell Enderby wrote:
>Since you are going to act like a baby about this I can talk down to your
>level:
Nice ad homenim attack on the people you are asking to help you.
>This pittly function that calls librad_md5_calc() when passed a string means
>absolutely nothing about this conversation.
No, it means everything, as it explains how CHAP works to a degree of
precision that is hard to match in any other format.
>I doubt that you comprehend my question and a full understand of the CHAP
>protocol yourself.
Who do you think wrote the code that is FreeRADIUS?
>This is key information that I am talking about. If what you say below
>about how
>the radius server sends the encrypted password back to the NAS then the
>answer to
>this is:
>
>No. The RAS receives the password from the radius server.
Uhm, no. Thanks for playing.
PAP works as follows:
User->NAS Sends password in cleartext
NAS->Radius Makes MD5 hash of password & shared secret ( note that
MD5 hash is reversible if you have the shared secret. )
Sends hash value to Radius server.
Radius Reverses the MD5 hash to obtain the password submitted
by the user.
The password is encrypted using the salt from the system
password for that user. This process is not reversible,
however, each unique input has one and only one unique
result. If the result of the encryption on the password
sent from the NAS matches the stored encrypted password,
this it is posited that the same input was given to the
encryption function and the passwords therefore match.
If the unencrypted password is stored on the radius server,
than a simple comparison is done between the two plaintext
passwords.
CHAP:
NAS->User NAS sends the user a "challenge" which is a pseudo random
string.
User performs a one-way hash on the challenge and the password
that the user knows.
User->NAS User sends one-way hash back to the NAS.
NAS->Radius NAS sends a copy of the original "challenge" and the users
result to the radius server.
Radius The radius server uses a copy of the plain-text password
and the "challenge" and runs it through the same one-way
hash algorithm.
The radius server then compares the user's result, with it's
own result. If they match, then the input was the same,
and user is authenticated.
Note, if the radius server does *not* have access to the plaintext
password it cannot perform the one-way hash to verify the user. Let's
quote from RFC 1994, which defines the CHAP protocol:
-- begin --
CHAP provides protection against playback attack by the peer through the
use of an incrementally changing identifier and a variable challenge value.
The use of repeated challenges is intended to limit the time of exposure to
any single attack. The authenticator is in control of the frequency and
timing of the challenges. This authentication method depends upon a
"secret" known only to the authenticator and that peer. The secret is not
sent over the link. Although the authentication is only one-way, by
negotiating CHAP in both directions the same secret set may easily be used
for mutual authentication. Since CHAP may be used to authenticate many
different systems, name fields may be used as an index to locate the proper
secret in a large table of secrets. This also makes it possible to support
more than one name/secret pair per system, and to change the secret in use
at any time during the session.
CHAP requires that the secret be available in plaintext form. Irreversably
encrypted password databases commonly available cannot be used. It is not
as useful for large installations, since every possible secret is
maintained at both ends of the link.
-- end --
Please read those last two sentences over and over until it sinks in.
>The FAQ does NOT EXPLAIN JACK! If you are referring to section 4.4 and
>4.5 in the
>
>I repeat. This statement is BS. A shadow password file contains a PLAIN TEXT
>PASSWORD that you can compare against.
Uhm, no. Utterly bogus statement. Send us copy of your /etc/shadow if
you really feel it contains a plain text password. You have actually
looked at /etc/shadow, haven't you?
No /etc/shadow system that I know stores the unecrypted or reversibly
encrypted password. If it does, then it's utterly contradictory to every
other system I'm aware of.
>Again here are the two scenarios:
>
>#1: The radius server receives a password to check. It encrypts it with
>md5 and
>does a text compare to the shadow file and your done.
Wrong. Utterly wrong.
>#2: If you are telling me that we only get the name of the user and we
>send back
>the encrypted password to be decoded by the NAS then we go and read the shadow
>file and we send it down to the NAS and it needs to do a md5 encode on the
>password handed to it by the user and again do a text compare of the two
>strings.
No. Utterly wrong once again.
> > Go read the FAQ. CHAP requires access to a plain text password, and
> > you CANNOT use /etc/passwd, or /etc/shadow for CHAP authentication.
> > Anyone who tells you different is lying.
>
>Saying the same thing over and over gets you know where.
So does claiming you know how CHAP works when you obviously don't.
Go understand CHAP. Try Google ( www.google.com ). You can come back
when you can admit you were wrong about CHAP and stop arguing with everyone
that tells you you are wrong.
Goodbye, and good luck, my patience with you is at an end.
-Chris
--
\\\|||/// \ Chris Parker - Manager, Development Engineering
\ ~ ~ / \ WX *is* Wireless! \ [EMAIL PROTECTED]
| @ @ | \ http://www.starnetwx.net \ (847) 963-0116
oOo---(_)---oOo--\------------------------------------------------------
\ Without C we would have 'obol', 'basi', and 'pasal'
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
