Re: Simple connect feature for xl2tpd

[Paul Wouters <paul xelerance com>]

On Wed, 2 Jul 2008, Dan Williams wrote:

> > ipsec whack can also be used to add/remove connections to the configuration
> > without putting those in a config file.
> 
> Great; that's exactly what we'd like.
> 
> > The one tricky thing there is, is passing x509 certificates and PSK's into
> > pluto. It can reread the /etc/ipsec.secrets (and include files) via
> > the command 'ipsec secrets'. so one somewhat hacky way of doing things
> > could be to add an include into /etc/ipsec.secrets for /tmp/foobar.secrets,
> > then run 'ipsec secrets' and immediately remove /tmp/foobar.secrets. The
> > secret will then be loaded into the openswan pluto daemon.
> 
> Hmm, that's icky.  I'd rather be able to push stuff directly to openswan
> via whack.  Is there no facility to do that at this point?  Basically,
> there's data that describes a single IPSec connection which would
> presumably include any x509 certificates or PSKs the connection
> requires.  All necessary data should be pushed down to openswan when the
> connection is added, and should be updated when necessary by
> NetworkManager or whatever.

We are thinking about how best to add the required features for NM.

How would a user configure the NM l2tp connection? He would have to supply
a PKCS#12 file (.p12) or a PSK (preshared secret), or supply the parts
that make up a PKCS#12 file (user.cert, user.key, ca.cert).

Where would NM store this? Note that the PKCS#12 can have an "import password"
(meant to only protect the file during transit, not used to unlock once on
 a system). Note that after importing the PKCS#12 file, the private key should
be stored securely. Openswan assumes "root" is trusted, and stores keys in
/etc/ipsec.d/private and stores the passphrase to the key in /etc/ipsec.secrets.
Obviously, this needs to change for NM. 

Is NM integrated with some keychain manager? Would NM be responsible for
unlocking the private key and passing it on without further passphrases to
openswan via whack?

What is the behaviour during fast user switching? Should the VPN stay up (possibly
giving another user access to somewhere they should not have access to) or should
it terminate (thereby killing the user's active sessions). Does NM handle all
of the up and down requests of tunnels in these events?

> > For non-l2tp XAUTH based connections, the XAUTH password can also be stored
> > in ipsec.secrets (and the username passed using whack options)
> 
> We can't store that in ipsec.secrets, because that's not system-wide
> information in all cases; it's pulled either from the user's local data
> or entered by the user themselves during the connection or out-of-band.

It can be passed via the whack interface as well.

> We need to be able to push the key down to openswan when openswan needs
> the key, and if the key is wrong (can't decrypt a private key, or the
> server denies auth) we'd need to know about that so we can ask the user
> for a different key.

Slightly differently I think. If NM is handling the storing of the key with
passphrase, then NM should give openswan the key without any passphrase left
on it.

Paul