Hide Forgot
Description of problem: In ipsec.conf man page there is the following section about DH: "Diffie-Hellman groups 19,20 and 21 from RFC- 5903 and 22, 23 and 24 from RFC-5114 are also supported. For all groups, the "dh" keyword can be used. For the MODP based groups, the modp= keyword can be used. for example ike=3des-sha1;dh19. The RFC-5114 DH groups are extremely controversial and MUST NOT be used unless forced (administratively) by the other party. Support for these groups will most likely be removed in 2017, as it cannot be proven these DH groups do not have a cryptographic trapdoor embedded in them (a backdoor by the USG who provided these primes without revealing the seeds and generation process used). Due the the weakness of DH22, support for this group is not compiled in by default and can be re-enabled using USE_DH22=true." There are a couple of issues there: * typo: "be used. for example" -> "be used, for example" * DH23 and DH24 are not supported in libreswan anymore * "Support for these groups will most likely be removed in 2017" I suggest to update it as follows: "Diffie-Hellman groups 19,20 and 21 from RFC-5903 are supported. For all groups, the "dh" keyword can be used, for example ike=3des-sha1;dh19. For the MODP based groups, the modp= keyword can be used. Version-Release number of selected component (if applicable): libreswan-3.32-7.el8_3
Acceptance Criteria: * Information about DH is actual Granting qa_ack+ for RHEL-8.5.0.
This has been updated in upstream https://github.com/libreswan/libreswan/commit/2d2ea290621bdffb4472d3f4372880d4bbbfbc77 The ike= entry now reads: ike IKE encryption/authentication algorithm to be used for the connection (phase 1 aka ISAKMP SA or IKE SA). If this option is not set, the builtin defaults will be used. This is the prefered method, and allows for gradual automatic updates using the same configuration. Some distributions, such as Fedora and RHEL/CentOS, use a System Wide Crypto Policy that sets the default ike= (and esp=) lines. Specifying your own ike= line means overriding all these system or software recommended defaults, but can be neccessary at times. Note that libreswan does not support using a PRF algorithm that is different from the INTEGRITY (hash) algorithm by design. The format is "cipher-hash;modpgroup, cipher-hash;modpgroup, ..." Any omitited option will be filled in with all allowed default values. Multiple proposals are separated by a comma. If an ike= line is specified, no other received proposals will be accepted than those specified on the IKE line. Some examples are ike=3des-sha1,aes-sha1, ike=aes, ike=aes_ctr, ike=aes_gcm256-sha2, ike=aes128-md5;modp2048, ike=aes256-sha2;dh19, ike=aes128-sha1;dh22, ike=3des-md5;modp1024,aes-sha1;modp1536. IKEv2 allows combining elements into a single proposal. These can be specified by using the + symbol. An example is: ike=aes_gcm+chacha20_poly1305;dh14+dh19,aes+3des-sha2+sha1;dh14. Note that AEAD algorithms (aes_gcm, aes_ccm, chacha20_poly1305) and non-AEAD algorithms (aes, 3des) cannot be combined into a single proposal. To support aes and aes_gcm, two proposals seperated by a comma must be used. The default IKE proposal depends on the version of libreswan used. It follow the recommendations of RFC4306, RFC7321 and as of this writing their successor draft documents RFC4306bis and RFC7321bis. As for libreswan 3.32, SHA1 and MODP1536(dh5) are still allowed per default for backwards compatibility, but 3DES and MODP1024(dh2) are not allowed per default. As of libreswan 4.x, modp1024(dh2) support is no longer compiled in at all. For IKEv2, the defaults include AES, AES-GCM, DH14 and stronger, and SHA2. The default key size is 256 bits. The default AES_GCM ICV is 16 bytes. Note that AES-GCM is an AEAD algorithm, meaning that it performs encryption+authentication in one step. This means that AES-GCM must not specify an authentication algorithm. However, for IKE it does require a PRF function, so the second argument to an AEAD algorithm denotes the PRF. So ike=aes_gcm-sha2 means propose AES_GCM with SHA2 as the prf. Note that for phase2alg, there is no prf, so AES-GCM is specified for ESP as esp=aes_gcm-null. The AES-GCM and AES-CCM algorithms support 8,12 and 16 byte ICV's. These can be specified using a postfix, for example aes_gcm_a (for 8), aes_gcm_b (for 12) and aes_gcm_c (for 16). The default (aes_gcm without postfix) refers to the 16 byte ICV version. It is strongly recommended to NOT use the 8 or 12 byte versions of GCM or CCM. These versions are NOT included in the default and will be removed in a future version, following the recommendation of RFC 8247 or it successor. Weak algorithms are regularly removed from libreswan. Currently, 1DES and modp768(DH1) have been removed and modp1024(DH2) has been disabled at compile time. Additionally, MD5 and SHA1 will be removed within the next few years. Null encryption is available, and should only be used for testing or benchmarking purposes. Please do not request for insecure algorithms to be re-added to libreswan. IKEv1 has been disabled per default, and will soon no longer be compiled in by default. For all Diffie-Hellman groups, the "dh" keyword can be used instead of the "modp" keyword. For example ike=3des-sha1;dh19. Diffie-Hellman groups 19,20 and 21 from RFC-5903 are supported. Curve25519 from RFC-8031 is supported as "dh31". Curve448 and GOST DH groups are not yet supported in libreswan because these are not supported yet in the NSS crypto library. Diffie-Hellman groups 22, 23 and 24 from RFC-5114 are implemented but not compiled in by default. These DH groups are extremely controversial and MUST NOT be used unless forced (administratively) by the other party. This is further documented in RFC 8247, but the summary is that it cannot be proven that these DH groups do not contain a cryptographic trapdoor (a backdoor by the USG who provided these primes without revealing the seeds and generation process used). The modp syntax will be removed in favour of the dh syntax in the future
will come in via rebase to libreswan 4.4
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (libreswan bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2021:4299