More secure Diffie - Hellman groups, why not?

[dusan]

I'm not a programmer. This is a six-year old and already answered question. But I'm sorry I don't think it's resolved:

http://forum.pfsense.org/index.php/topic,2937.0.html

The question is: why pfSense doesn't support more secure Diffie - Hellman groups?

For example, group 14 (modp 2048) and group 15 (modp 3072) which provide 112-bit and 128-bit security, respectively.

I'm aware of this KAME document

http://www.kame.net/racoon/racoon.conf.5

which states that racoon supports only groups 1, 2 and 5.

That [very old] document is clearly obsolete. Nowaday ipsec-tools v.0.8 (in pfSense v.2) supports many RFC3526 groups, including groups 14 and 15. Besides the new documentation, another convincing argument is the file dhgroup.h from the source code /usr/ports/security/ipsec-tools.

It's my understanding that ipsec-tools performs all public-key crypto stuffs, including Diffie-Hellman key exchange, by itself. It requires no special kernel services. AFAIK the IPsec-enabled kernel performs only secret-key crypto stuffs. With built-in AES, the kernel is ready for 128-bit security. We just need a proper [symmetric] 112- or 128-bit key derived by racoon,

and a Web UI with more DH group options, generating the proper racoon.conf.

[jimp]

If it's supported by racoon, then there may not be anything holding it back. Open a feature request ticket at http://redmine.pfsense.org/ and we can look into it.

The problem may just be inertia - it works as-is, and nobody has tried to change it, so it's stayed the same. While we're at it, we could add in sha256, sha384, and sha512 rather than just MD5/SHA1.

Looks like the racoon.conf man page is a bit more up-to-date than what you saw.

For P1:

proposal { sub-substatements }
                    encryption_algorithm algorithm;
                            Specifies the encryption algorithm used for the
                            phase 1 negotiation.  This directive must be
                            defined.  algorithm is one of following: des,
                            3des, blowfish, cast128, aes, camellia for Oak-
                            ley.  For other transforms, this statement should
                            not be used.
                    hash_algorithm algorithm;
                            Defines the hash algorithm used for the phase 1
                            negotiation.  This directive must be defined.
                            algorithm is one of following: md5, sha1, sha256,
                            sha384, sha512 for Oakley.
                    authentication_method type;
                            Defines the authentication method used for the
                            phase 1 negotiation.  This directive must be
                            defined.  type is one of: pre_shared_key, rsasig
                            (for plain RSA authentication), gssapi_krb,
                            hybrid_rsa_server, hybrid_rsa_client,
                            xauth_rsa_server, xauth_rsa_client,
                            xauth_psk_server or xauth_psk_client.
                    dh_group group;
                            Defines the group used for the Diffie-Hellman
                            exponentiations.  This directive must be defined.
                            group is one of following: modp768, modp1024,
                            modp1536, modp2048, modp3072, modp4096, modp6144,
                            modp8192.  Or you can define 1, 2, 5, 14, 15, 16,
                            17, or 18 as the DH group number.  When you want
                            to use aggressive mode, you must define the same
                            DH group in each proposal.

And for P2:

encryption_algorithm algorithms;
                    des, 3des, des_iv64, des_iv32, rc5, rc4, idea, 3idea,
                    cast128, blowfish, null_enc, twofish, rijndael, aes,
                    camellia (used with ESP)
            authentication_algorithm algorithms;
                    des, 3des, des_iv64, des_iv32, hmac_md5, hmac_sha1,
                    hmac_sha256, hmac_sha384, hmac_sha512, non_auth (used
                    with ESP authentication and AH)

So the GUI options could be expanded quite a bit, assuming those all work.

[jimp]

https://github.com/bsdperimeter/pfsense/commit/665340db1142980ca40d49b9dddf1b07e07da3b8

[dusan]

Great.

I've applied your patch in a 2.0.1-RELEASE (i386) installation and tested it against a Shrew Soft VPN Client v.2.1.7. A phase 2 tunnel using PFS DH group 15 was established. It works.

More results will follow soon.

Many thanks for your good job.

[jimp]

Be sure to read my notes on the commit I linked about using that on 2.0.x. The DH groups should be safe though.

[Timpscan]

So this will not work on 2.1?

[jimp]

It will work on 2.1, and it does work on 2.1.

You just couldn't mix them between 2.0.x and 2.1 for SHA256-512, which is why I left it out of 2.0.x and don't encourage people to use the patches on 2.0.x.

[dusan]

I use it, for the whole year, in a production VPN with 2.0.1-RELEASE devices and Fortinet FortiOS v.4.x devices. All IKE sessions use DH group 14 (the maximum supported by FortiOS standard edition) without any problem.

Many thanks.