[strongSwan] "best practices"?
James
jameszee13 at gmail.com
Thu Apr 2 00:51:28 CEST 2015
Andreas - this is tremendously useful. Many thanks for the quick reply!
On Wed, Apr 1, 2015 at 6:49 PM, Andreas Steffen
<andreas.steffen at strongswan.org> wrote:
> Hi James,
>
> here are the default proposals for the ike and esp algorithms
> if you don't define them explictly:
>
> carol charon: 04[CFG] configured proposals:
> IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048,
> IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536,
> IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/AES_CTR_128/
> AES_CTR_192/AES_CTR_256/HMAC_SHA1_96/
> HMAC_MD5_96/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/
> AES_XCBC_96/PRF_HMAC_SHA1/PRF_HMAC_MD5/PRF_HMAC_SHA2_256/
> PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/
> MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/MODP_3072/
> MODP_4096/MODP_8192/MODP_1024/MODP_1024_160,
> IKE:AES_CCM_8_128/AES_CCM_8_192/AES_CCM_8_256/AES_CCM_12_128/
> AES_CCM_12_192/AES_CCM_12_256/AES_CCM_16_128/AES_CCM_16_192/
> AES_CCM_16_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/
> AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_16_128/
> AES_GCM_16_192/AES_GCM_16_256/PRF_HMAC_SHA1/PRF_HMAC_MD5/
> PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/
> PRF_AES128_XCBC/
> MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/MODP_3072/
> MODP_4096/MODP_8192/MODP_1024/MODP_1024_160
>
> carol charon: 13[CFG] configured proposals:
> ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ,
> ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ,
> ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/
> HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/NO_EXT_SEQ
>
> As you can see, the cipher suites in the first position are not the
> strongest ones but are algorithms with a decent strength which most
> of the IPsec endpoints support:
>
> - We still keep 3DES since Windows XP does not support AES.
>
> - We don't include the SHA-2 HMAC algorithms as well as the AES-GCM
> and AES-CCM authenticated encryption schemes in our default
> ESP proposals because Linux kernels older than 2.6.33 do not
> support them and there are still a lot of 2.6.18 kernels around
> (e.g. centOS and other fossils).
>
> If you want strong and fast crypto and you have a recent Linux kernel
> and your processor has the Intel AES-NI instruction set then I suggest
>
> ike=aes128gcm16-prfsha256-ecp256,aes256gcm16-prfsha384-ecp384!
> esp=aes128gcm16-ecp256,aes256gcm16-ecp384!
>
> for 128 bit or 192 bit security strength, respectively.
>
> If you don't trust the NIST elliptic curves then you can use
> NTRU based on lattices instead:
>
> ike=aes128gcm16-prfsha256-ntru256,aes256gcm16-prfsha384-ntru384!
> esp=aes128gcm16-ntru256,aes256gcm16-ntru384!
>
> Best regards
>
> Andreas
>
> On 04/01/2015 08:08 PM, James wrote:
>> All,
>>
>> Looking for best practices on the most secure settings that can be
>> used.
>>
>> I've scoured the net and found very little in terms of which
>> settings are most secure and in which combination.
>>
>> I saw a recommendation on a site that recommended the following
>> settings:
>>
>> conn %default
>> ike=aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,aes256-sha1-modp4096,aes128-sha256-modp1536,aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha256-modp2048,aes256-sha1-modp2048,aes128-sha256-modp1024,aes128-sha1-modp1024,aes256-sha384-modp1536,aes256-sha256-modp1536,aes256-sha1-modp1536,aes256-sha384-modp1024,aes256-sha256-modp1024,aes256-sha1-modp1024!
>>
>>
> esp=aes128gcm16-ecp256,aes256gcm16-ecp384,aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,aes256-sha1-modp4096,aes128-sha256-modp1536,aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha256-modp2048,aes256-sha1-modp2048,aes128-sha256-modp1024,aes128-sha1-modp1024,aes256-sha384-modp1536,aes256-sha256-modp1536,aes256-sha1-modp1536,aes256-sha384-modp1024,aes256-sha256-modp1024,aes256-sha1-modp1024,aes128gcm16,aes256gcm16,aes128-sha256,aes128-sha1,aes256-sha384,aes256-sha256,aes256-sha1!
>>
>> Obviously there's the documentation
>> (https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites)
>>
>>
> but ti doesn't really indicate which are the strongest methods as best
>> I can tell.
>>
>> Should I assume that strongSwan will automatically use the "most
>> secure" communication method possible if both ends are configured
>> _without_ the esp and ike directives?
>>
>> Thanks
>
> ======================================================================
> Andreas Steffen andreas.steffen at strongswan.org
> strongSwan - the Open Source VPN Solution! www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==
More information about the Users
mailing list