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 anymore. 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 http://live.gnome.org/action/subscribe/ProposedNetworkManagerConfigurationSpecification?action=subscribe 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