Why not use encryption keys instead? Because if you substitute crypto key for password, then you have an IPSec tunnel. Besides, MS is moving away from PPTP. Take a look at 2k and XP, they have IPSec tunneling, so that seems to be the right direction to go. Dan On Fri, 2002-01-25 at 06:23, Greg Scott wrote: > After tossing and turning half the night, this idea came into my head: > > It's really neat that we can set up GRE tunnels between Linux servers. > Way cool, and thanks! But lack of any kind of security is a problem. > > What if we had a simple way to secure those GRE packets, or at least > some means for the two VPN servers to authenticate each other? > > So this idea popped into my head that seems straightforward to implement. > What if the system admin created accounts in both VPN servers, call them > lanagre and lanbgre. It would be up to the system admin to put in strong > passwords in those accounts. Both sides would each have both accounts, > and it would be up to the system admins on both sides to make sure the > passwords matched. > > So then, when LAN A wants to connect to LAN B, the LAN A VPN server > would look up LAN B's password in LAN A's /etc/shadow file, put together > a key based on that hash, and then use that key to encrypt traffic going > across. Similarly for LAN B. Since both sides have both accounts, nobody > needs to send passwords across the Internet. > > If we had this in place, then Linux could do everything that Microsoft PPTP > does, but Linux wouldn't make the same implementation mistakes > Microsoft made. > > How tough would this be to do? Does the idea make sense? > > - Greg Scott > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/
