Re: Simple connect feature for xl2tpd

[Dan Williams <dcbw redhat com>]

On Fri, 2008-07-04 at 14:38 -0400, Paul Wouters wrote:
> 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).

Probably any one of the above?

> 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. 

Certs will ideally get stored by either a system certificate store (like
NSS cert database) or a user certificate store since there are already
plenty of them, and since they can talk to crypto cards and the like
already.  They usually take care of secure storage of the private key.

For 802.1x authentication, we currently decrypt the private key
on-the-fly after pulling the passphrase from secure storage (a keyring)
and push the decrypted private key to the supplicant via D-Bus, so that
the decrypted private key is _never_ on-disk.

> 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?

Yes, NM is integrated with the gnome-keyring for GNOME desktops, and the
KDE equivalent for KDE desktops.  NM could certainly push unlocked
private keys down to openswan like we do to the 802.1x supplicant
already.

But what I'd eventually like to do is just pass tokens around to both
the supplicant and openswan, and then they can ask the cert store
themselves.  Fewer hands for the secret data to pass through.

In the ideal future, any operation requiring the private key would be
passed off to the certificate store (NSS) and NSS would do the
operation, instead of requiring secret data to be passed back and forth.
Thus the private key would _never_ need to leave the cert store.  This
would take architectural changes to projects like wpa_supplicant and
openswan though and therefore is a future goal.

> 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?

There are two types of connections with NM; user and system.  Somewhat
analgous to Window's "let any user control this network device"
functionality.  User connections have credentials and settings stored in
the user's session and thus are not accessible from other sessions.
System connections are stored by the system (root usually) and thus are
accessible to all users, but may be locked down by the system
administrator.  Thus, only System connections can be shared between
users during fast user switching.

If a connection (including VPNs) is a user connection, it will be
terminated during a fast user switch.  If it is a system connection, it
will not.

> > > 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.

Ok, great.

> > 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.

Ok, that's what we currently do for 802.1x so we can reuse a lot of code
there.  It doesn't handle pkcs12 certs yet (just PEM and DER) but I
expect we'll add that functionality in the near future.

Thanks!
Dan