Chris Parker wrote:
> 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.
>
"ad homenim"? How should I reply to a response when someone just says "read the
FAQ" 2 thousand times and never answers the question?
>
> >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.
>
Again it depends on the question. I really wasnt asking for that info but it was
interesting to see the code.
>
> >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?
If he wrote the code then he should be able to explain it. I am not harshing the
code just trying to understand on the authentication for CHAP worked.
>
> >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.
This is the kind of information I was looking for. It is NOT mentioned in RFC 1994
or the FAQ and this is why I asked it.
Thanks for the recursive loop read above.
>
> >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.
>
Yes this again assumed that you had a clear text password to compare the shadow
file with.
>
> >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.
>
If everyone would just get pissed off like you and explain everything very clearly
above on what I asked for then I will need to piss people off more often.
Thanks again for clearing up this issue.
Russell
>
> -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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
