[pptp-server] PoPToP and Authentication Questions

[Wierzbicki, Ralf]

There will be beer to go with that pizza if someone can get pppd
to authenticate against an NT PDC using pam_smb_auth :)

---
Ralf


-----Original Message-----
From: James MacLean [mailto:macleajb at Trademart-1.ednet.ns.ca]
Sent: Tuesday, March 14, 2000 7:01 PM
To: pptp-server at lists.schulte.org
Subject: Re: [pptp-server] PoPToP and Authentication Questions


On Wed, 15 Mar 2000, Neale Banks wrote:
> On Tue, 14 Mar 2000, Adam Williams wrote:
> > >Interesting... The pizza that is :).
> > Hey, I'm serious.~

Me too, but I've asked lists for quite a while before I began my home-brew
and I am surprised the interest was there and never came forth before.

My desire was to have a centralized radius solution. Now that I _finally_
am starting to see a _bit_ of the LDAP light, I am seeing other
opportunities. But I only asked here (PPTP) and the Radius lists for
interest. There may be some help from the LDAP crew, or as sugested
below, from the PAM'ers.
 
> > >Since one needs that password to CHAPinate, would you care if it was
bare
> > >text stored ACL'd on the LDAP server?
> > I suppose if I don't have a choice, then I don't have one, but i'm not
too
> > excited about storing a plain text password.  Is it possible to
CHAPinate
> > first, and store the chapination?

Nor was I. One other option not exactly elluded to here is to go the way
that Samba does and use PAM to keep a current NT hashed password as well
as a MD5 Linux/Unix password.(And Samba too if you need it). Then you
don't need to store the plain password. Understand that this would work
for MS-CHAPv2. Or, I think it would :).
 
> In theory yes, but you'd lose advantages of CHAP - starting with leaving
> yourself wide open to replay attack (in essence you have reverted to PAP)
> as the random challenge used in teh CHAP computation would be fixed in
> advance.  In short, if you are seriously tempted to go down this path then
> you can probably save yourself a lot of hassle by just using PAP as it is.

Understood. But if you want to play ball with Windows machines and PPTP,
it appears they use the MS-ChapV2 for creating the encryption keys, and
ergo, you can't have one with out.... the other :). Oh what a tangled web
we weave :).

> > >I've had it working this way against ICRadius, but never completed that
> > >project. It was quite an ugly hack at best, but the underlying pain in
> > >the neck was that to make the CHAP compares work, you start with the
plain
> > >text password and go forward, not take and MD5, etc... password and
work
> > >any other way.
> > Yep, I relize this and am curious how NT gets around this problem?
Certainly
> > they don't store the plain text password?~

I believe the are using their normal NT hash passwords. But I could be
wrong.
 
> Correct.  But MS-CHAP is not CHAP ;-)  They perverted the original
> standard (how surprising ;-).

This is how I understood it too :(.

> (a) the PAM-module passes the clear-text password back to the calling pppd
> - this minimises the hacks required in pppd but is a REALLY EVIL idea for
> security - exposing the bare password places a lot of trust i the calling
> application.  Please don't be tempted to implement this.

If the link endpoints are secured (IPSec, Vtund, etc...) then one could
start the arguement. But I think this is definetly not very smooth.
 
> (b) the PAM-module passes a random challenge back to the calling pppd
> which, in the normal manner of CHAP, passes this challenge to the other
> side and receives the computed response back - this computed response is
> then passed back to the CHAP-aware PAM-module.  The PAM-module then also
> performs the CHAP-function on its copy of the shared secret and the random
> chalenge it issued to arrive at it's version of the CHAP-response - if
> the received and computed CHAP-responses match then the PAM-module returns
> "authentication succeeded".  This obviously require relocating the CHAP
> handling from pppd into the PAM-module but is arguably the correct way of
> doing things.

If the chap-hashy thing is available to use for the encryption, then it
sounds doable :). I like the idea that the passwd (hashed or not) is left
on the server and not dished out.

> A completely different approach would be to hack upon pppd and create a
> generic PAM-like interface in place of the current reading of the
> chap-secrets file.

I thought there was a PAM insert in the latest pppd's. It's just meant to
verify for PAP though I think. Your suggestion requires multiple back and
forths from PAM. If that is ok under PAM, then you get my thumbs up :).

But _you'll_ have to make the changes to the current pppd :).
 
> HTH,
> Neale.

take care,
JES
--
James B. MacLean        macleajb at ednet.ns.ca
Department of Education http://www.ednet.ns.ca/~macleajb
Nova Scotia, Canada
B3M 4B2


_______________________________________________
pptp-server maillist  -  pptp-server at lists.schulte.org
http://lists.schulte.org/mailman/listinfo/pptp-server
List services provided by www.schulte.org!