Re: Simple connect feature for xl2tpd

Dan Williams <dcbw redhat com> writes:

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

Dan, how set are you on using NSS? I believe this job is better fit for
just supporting PKCS#11 in NM and making nm-applet use gnome-keyring's
PKCS#11 interface by default. Using just PKCS#11 is a much lighter
dependency and far simpler design. Also, using NSS in NM would require
it to be integrated in the supplicant, but wpasupplicant already
supports PKCS#11.

Unfortunately, openswan doesn't support pkcs#11. Paul, openswan already
supports opensc directly where as strongswan has general pkcs#11
support, which supports opensc through its pkcs#11 implementation. Could
openswan move to the same model as strongswan?

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

I would be very happy to work on adding the PKCS#11 support integrated
into nm-applet so that NM no longer needs to handle certs directly

Months ago I added support to wpasupplicant for PKCS#11 and it was
accepted upstream. I then filed NM bugs #537237 and #537239; the former
contains the necessary patches to NM core to support PKCS#11. A few days
ago, I published
to describe the necessary changes to the configuration specification
that would be necessary. I am still working on a patch to nm-applet.

- dds

Attachment: pgpYDppX0vu75.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]