[Swan] Secure VPN Setup

Paul Wouters paul at nohats.ca
Mon Apr 25 21:18:08 UTC 2016


On Mon, 25 Apr 2016, Kenny wrote:

> Thank you for your help Paul - is there a way to get a list of each of the available crypto attributes that ARE available?  Is there a man page entry for the configuration file that shows them or a command parameter that can be used with -h or --help or something similar to see them?
>
> For example ipsec -phase2alg --help or something similar? Ipsec -phase2alg -l to list it ?

No there is not, since part of these things depend on the runtime.
Kernel crypto depends on loaded modules. Userland crypto depends
on the version of the NSS library.

Paul

> -----Original Message-----
> From: Paul Wouters [mailto:paul at nohats.ca]
> Sent: Thursday, April 21, 2016 2:55 PM
> To: Kenny
> Cc: swan at lists.libreswan.org
> Subject: Re: [Swan] Secure VPN Setup
>
> On Wed, 20 Apr 2016, Kenny wrote:
>
>> Can anyone offer any suggestions if they have already done the
>> research?  I am a bit opposed to doing 2-factor authentication by
>> introducing other software into the mix = increasing the attack
>> surface.  But would like to do some other form of 2 factor authentication, like a USB stick or smart card or something, is this possible using x.509 with pam?
>
> you can do X.509 or PSK for the IKE SA, then add XAUTH authentication on top. xauth can be a password file on the server, system pam, custom pam module, etc. google-authenticator works too.
>
> use xauthby=pam and create /etc/pam.d/pluto with your pam configuration.
> google authenticator example can be found at
>
> https://github.com/libreswan/libreswan/blob/master/pam.d/pluto.example.google-authenticator
>
>> I’d like to use IKEv2 with the strongest configuration possible – but
>> have had some issues in finding whether or not  I can utilize client
>> certificates AND a username and password, or if there are custom
>> checks I can do on the host (registry values, software installed, certain services running, etc.) I don’t think this is possible but wanted to ask anyway.
>
> IKEv2 only supports EAP as second authentication, and we do not yet support that (it is heavilly intertwined with openssl while we use nss)
>
>> I’d like to avoid NIST recommendations if possible because I don’t trust the selection process….
>
> Well, if you don't like 3des or aes or aes_gcm you can use camellia or twofish or even cast5.
>
>> For some base requirements I’m thinking – main mode, IPv4 only as I
>> don’t trust IPv6 in any way yet, the
>
> main mode only applies to IKEv1, not IKEv2.
>
>> strongest encryption algorithm (CHACHA?), the most entropic
>> pseudo-random function PRF_HMAC_SHA2_512?, the
>
> chacha20poly1305 is not yet supported. We are waiting on the next release of NSS which will have chacha20poly1305 support.
>
>> strongest hashing integrity algorithm AUTH_HMAC_SHA2_512_256?, the
>> strongest ESP encryption = AES-CBC (SUCKS), the strongest ESP
>> authentication algorithm = AES-GMAC with AES-128?, the strongest DH
>> transform
>
> It's all relative, but yes any of the SHA2 HMAC/PRF constructs are safe (in fact so is HMAC SHA1 and even HMAC MD5)
>
> We do not support AES-GMAC. You can use AES_GCM or AES_CCM for ESP. Or as I said, AES_CBC, 3DES, TWOFISH, CAST or Camellia.
>
>> brainpoolP512r1?,
>
> We only support DH MODP groups, no curves. MODP2048 or higher is fine, just stay away from DH 22,23,24.
>
>> strongest certificate (and way to most safely secure password for
>> cert) and hashing algorithm SHA3? and other attributes public key size
>> limit = 4096 8192 do we know what the threshold is where
>
> There is no SHA3 for IKE/IPsec yet.
>
>> we may be introducing other issues obviously we don’t need to go with
>> something insanely high but I don’t want it to even be possible
>> assuming that governments lie about computing power which they do?
>> Prime number generate for seeding for certificate with a limit on value lower bounds, the strongest , no compression, strongest hash algorithm SHA2-512 hash algorithm?, strongest secure password method PACE?
>
> passwords would all be based on the underlying scheme. XAUTH means plaintext (but encrypted under the IKE SA), and EAP can mean any method.
>
>> 1.)    Can I do main mode IKEv2 with a remote access to VPN server NAT-T setup?
>
> IKEv2 has just one mode. There is no "main mode" or "aggressive mode" in IKev2.
>
>> 2.)    Can I do AH and ESP with this setup, or is AH or ESP alone more
>> secure, I know AH is typically tunnel and ESP is typically transport but there are differing opinions online?
>
> Forget AH. ESP always contains AH. when you specify esp= you specify both an encryption and an authentication algorithm.
>
>> 3.)    Can I do client certificate and password without using another
>> product piece of software that relies on an external source e.g.
>> google or RSA tokens one OTP
>
> note google authenticator does not rely on google. It is not a "service". Same for certificates. It is all constrained to your own generated CA cert.
>
>>  – maybe a usb stick or smart card or some other software token that
>> does not have to reach out externally? My concern is the VPN server
>> having to get this information primarily – best case scenario would be
>> cert and pass PLUS a google OTP or RSA token number. I know I’m
>> reaching on this one, just wondering what thinking out of the box
>> solutions there might be that libreswan is capable of doing
>
> You can generate/store the NSS database with certificates onto a smartcard or HSM. Anything PKCS#11 should work.
>
>> 4.)    Can I check host configuration and OS or other software
>> attributes before finalizing (finalizing meaning at whatever point
>> would be secure and still possible)
>
> You could run in FIPS mode, which enforces integrity checks of the kernel, NSS and libreswan using the fipscheck library (and kernel code)
>
>> 5.)    Can anyone list the most secure of each IKEv2 spec?  In my
>> research the ones I’ve listed above are the best – chacha, brainpool,
>> SHA2, public key sizes greater or equal to 4096 – but for the others I
>> don’t know – like ESP, AH, PRF, hashing integrity algorithm, prime number seeding with boundaries on low numbers,  secure password method, etc.
>
> That's a long debate you can fight out on one of the crypto lists :)
>
> Paul
>
>


More information about the Swan mailing list