Bug 1934714

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