Re: Cisco VPN config files converter

[David Zeuthen <davidz redhat com>]

On Wed, 2005-05-25 at 19:16 -0400, Bill Moss wrote:
> A couple of points about decoding encrypted Cisco Group passwords (Secrets).
> 
> 1. Anyone with an early version of the Cisco VPN client (4.0.3.B) can do 
> the conversion without using the web site. All the web site does is 
> automate the process.
> 
> 2. Cisco has announced they will close the security hole but not when.
> 
> 3. Other vpnc front ends like kvpnc have a similar import utility.
> 
> 4. What liability is involved in exploiting this security hole? The web 
> site you reference has a note that the Secret should be obtained from 
> your network admin. Not all network admins may be happy about the decoding.
> 
> 5. Whatever you do make sure the user is informed if the the import 
> utility fails to find the Secret for whatever reason.
> 

What concerns me is the fact that we store the "group password" on disk
which means that if someone steals your hard drive they can use this
exploit

 http://www.cisco.com/warp/public/707/cisco-sn-20040415-grppass.shtml

to recover your personal password. Also note that if one is using vpnc
with a config file /etc/vpnc.conf you're vulnerable to this attack. This
is pretty bad. We simply cannot store the group password in plain text.
It's not secure.

So, I talked to Dan about this and what we came up with is that we
shouldn't store the "group password" in gconf at all. What we will do
(for vpnc) instead is simply prompt the user for two passwords when
connecting - for convenience both of these can be stored in the keyring
in an encrypted form. Which means that the user only needs to type in
their keyring password for 2nd and subsequent connection attempts.

Also note that if we need not rely on an external web-service to decode
the "group password" in .PCF files which in my personal opinion is a
grey legal area (this mail is legal advice though).

However, workflow-wise the sysadmin will still need to distribute two
passwords, not one, but such is life.

So, Dan and I talked about implementing this in the following way:
nm-applet will load the VPN-type dependent code that asks for
authentication details. For vpnc we'll just ask for two passwords. This
will fit nicely in with then plans about separating *all* the vpnc code
(backend, ui widget for details and now authentication) from
NetworkManager and placing it in a single tarball. 

Keep in mind that the grand plan here is to provide a stable ABI so any
open source project (openvpn, openswan comes to mind) or VPN vendor can
integrate with NetworkManager both backend- and frontend-wise. This
specifically means that Cisco may implement their own code (that does
something similar to vpnc), however we need to rethink the licenses of
both nm-vpn-properties and, now, nm-applet to allow such integration (my
idea is that we should dual-license these as GPLv2 and AFL2.0). We may
only need this for nm-vpn-properties (of which I'm currently the sole
copyright holder) but I'm not sure yet.

I hope this clarifies.

Cheers,
David