Bug 1934714 - DH section in ipsec.conf man page is outdated
Summary: DH section in ipsec.conf man page is outdated
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libreswan
Version: 8.4
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Daiki Ueno
QA Contact: BaseOS QE Security Team
Depends On: 1958968
TreeView+ depends on / blocked
Reported: 2021-03-03 17:27 UTC by Ondrej Moriš
Modified: 2021-11-10 01:34 UTC (History)
0 users

Fixed In Version: libreswan-4.4-1.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Last Closed: 2021-11-09 18:49:51 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2021:4299 0 None None None 2021-11-09 18:50:02 UTC

Description Ondrej Moriš 2021-03-03 17:27:23 UTC
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):


Comment 2 Ondrej Moriš 2021-03-10 17:24:27 UTC
Acceptance Criteria:

 * Information about DH is actual

Granting qa_ack+ for RHEL-8.5.0.

Comment 3 Paul Wouters 2021-03-16 19:18:13 UTC
This has been updated in upstream https://github.com/libreswan/libreswan/commit/2d2ea290621bdffb4472d3f4372880d4bbbfbc77

The ike= entry now reads:

           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:
           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

           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

Comment 4 Paul Wouters 2021-04-22 19:47:47 UTC
will come in via rebase to libreswan 4.4

Comment 12 errata-xmlrpc 2021-11-09 18:49:51 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.