[pptp-server] pptpd+chapms+radius
Neale Banks
neale at lowendale.com.au
Wed May 31 18:34:52 CDT 2000
On Wed, 31 May 2000, Dragos DOBRE wrote:
> I think I have pinned the bug :)
>
> the normal sequence would be (correct me if I am wrong)
>
> user dials to pptp server
> pptp daemon sees incoming call,
> fires up the ppp daemon
> pppd sends [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap...
> client agrees, passes the username/passwd to server
> pppd using radiusclient contacts radius server,
> radiusserver verifies the client in mysql, auths the client
[snip]
AFAIK, that's not _quite_ how CHAP works (and I'm entirely unsure if this
is going to be in any way significant for you....)
OK up to the bit where the "server" sends LCP requesting CHAP and the two
ppp peers agree on this. Then CHAP is a bit more involved...
In "pure" CHAP, the "client" would then pass only its name.
The "server" looks up this name (presumably this is where the RADIUS
hook-in gets implicated) and obtains a clear-text (or in the MS-perversion
a hashed) password. The "server" generates a random challenge and passes
this back to the "client".
Both the client and server separately encrypt the server-provided
challenge using the "password" (or "shared secret") as a seed tot eh
encryption (or somewhere thereabouts - the important point is that the
output is a function of both the challenge-value and the password). The
client then passes its output of the encryption back to the server.
The server then compares the output of its CHAP-encryption calculation
with the response provided by the client - it they agree then we have
successful authentication.
The main feature of this is that the server can determine that the client
knows the "shared secret" without that secret ever crossing the wire.
HTH,
Neale.
More information about the pptp-server
mailing list