[372] in athena10
Re: Debathen VPN Config Package
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Mon Aug 4 22:18:32 2008
Cc: athena10@mit.edu
Message-Id: <8FDC40DF-BAFB-4577-94D9-45F900EF5603@mit.edu>
From: Jonathan Reed <jdreed@MIT.EDU>
To: Evan Broder <broder@mit.edu>
In-Reply-To: <4897B37D.4070108@mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Mon, 4 Aug 2008 22:17:46 -0400
I certainly have thoughts, but I'm hardly the canonical source for a
policy such as this.
Regardless of how closely guarded the "secret" is or isn't, I think it
should be under the same access restrictions as the MITnet-VPN.pcf -
namely MIT-only. That may preclude a config package, and instead we
may want to provide a stock answer documenting configuration of the
VPN client, or perhaps a configuration file itself, certificate
protected.
Now that I think about it, a really clever hack would be a set of
patches against vpnc which would allow it to use a Cisco config file,
seeing as how it's supposed to be a replacement for Cisco's client.
I believe the various key decryption tools rely on a bug in the Cisco
libraries which expose the cleartext key in memory, but perhaps the
decryption has been reverse-engineered at this point. But that's
almost certainly more effort than it's worth.
However, I believe there is also a preference within IS&T for the
official Cisco client, and it would probably be a good idea if Athena
didn't completely ignore that.
Also, won't Zephyr (even krb5 zephyr) be sad behind a VPN? Although
that could be an artifact of the way the Cisco client clobbers the
networking stack, as opposed to vpnc which plays nice via tun0. We
should probably document things that will break if we're going to
pretend to support Athena behind a VPN.
I will follow up offline on the key issue and IS&T software preferences.
-Jon
On Aug 4, 2008, at 9:57 PM, Evan Broder wrote:
> I've been meaning to build a Debathena package to configure the MIT
> VPN through vpnc, but I've been hung up on the issue of the
> "secret". As per the discussion on -c sipb earlier, it's my
> understanding that the "secret" wasn't particularly closely guarded,
> but putting it in a config package makes it completely public, since
> our source is freely available.
>
> Jon - Mitch suggested that you might be a good person to talk to. Do
> you have any thoughts on whether it would be appropriate or not to
> include the VPN key in a Debathena package? Or who should I talk to
> instead?
>
> - Evan
