RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1335949 - libreswan: remove or disable any deprecated ciphers
Summary: libreswan: remove or disable any deprecated ciphers
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libreswan
Version: 7.4
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Paul Wouters
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On:
Blocks: 1335929 1377248 1411853 1428409
TreeView+ depends on / blocked
 
Reported: 2016-05-13 15:20 UTC by Nikos Mavrogiannopoulos
Modified: 2017-11-27 17:48 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1335950 (view as bug list)
Environment:
Last Closed: 2017-08-01 12:31:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2101 0 normal SHIPPED_LIVE libreswan bug fix and enhancement update 2017-08-01 16:07:26 UTC

Description Nikos Mavrogiannopoulos 2016-05-13 15:20:13 UTC
RHEL includes several cryptographic components who's security doesn't remain constant over time. Algorithms such as (cryptographic) hashing and encryption typically have a lifetime after which they are considered either too risky to use or plain insecure. That would mean we need to phase out such algorithms from the default settings, or completely disable if they could cause irreparable issue. 

This bug is about removing by default algorithms that are deemed unsafe by the IETF IPSECME Working group (MUST NOT). Algorithms that are in SHOULD NOT state will be kept but removed from the default set.

The relevant (at the moment) drafts are:
 * draft-ietf-ipsecme-rfc4307bis
 * draft-mglt-ipsecme-rfc7321bis

Comment 2 Ondrej Moriš 2017-05-30 19:50:49 UTC
From draft-ietf-ipsecme-rfc4307bis-18 [1]:

2.2.  Type 2 - IKEv2 Pseudo-random Function Transforms

                ...
                | PRF_HMAC_MD5      | MUST NOT |         |
                +-------------------+----------+---------+

But it looks like it actually is still supported if I am reading it correctly:

000 "test": 10.16.41.25<10.16.41.25>...10.16.46.52<10.16.46.52>; erouted; eroute owner: #2
000 "test":     oriented; my_ip=unset; their_ip=unset
000 "test":   xauth us:none, xauth them:none,  my_username=[any]; their_username=[any]
000 "test":   our auth:secret, their auth:secret
000 "test":   modecfg info: us:none, them:none, modecfg policy:push, dns1:unset, dns2:unset, domain:unset, banner:unset, cat:unset;
000 "test":   labeled_ipsec:no;
000 "test":   policy_label:unset;
000 "test":   ike_life: 3600s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0;
000 "test":   retransmit-interval: 500ms; retransmit-timeout: 60s;
000 "test":   sha2-truncbug:no; initial-contact:no; cisco-unity:no; fake-strongswan:no; send-vendorid:no; send-no-esp-tfc:no;
000 "test":   policy: PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV2_ALLOW+IKEV2_PROPOSE+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO;
000 "test":   conn_prio: 32,32; interface: eth0; metric: 0; mtu: unset; sa_prio:auto; sa_tfc:none;
000 "test":   nflog-group: unset; mark: unset; vti-iface:unset; vti-routing:no; vti-shared:no;
000 "test":   dpd: action:hold; delay:0; timeout:0; nat-t: encaps:auto; nat_keepalive:yes; ikev1_natt:both
000 "test":   newest ISAKMP SA: #1; newest IPsec SA: #2;
000 "test":   IKE algorithms wanted: 3DES_CBC(5)_000-MD5(1)-MODP2048(14)
000 "test":   IKE algorithms found:  3DES_CBC(5)_192-MD5(1)-MODP2048(14)
000 "test":   IKEv2 algorithm newest: 3DES_192-AUTH_HMAC_MD5_96-PRF_HMAC_MD5-MODP2048
000 "test":   ESP algorithms wanted: 3DES(3)_000-SHA1(2)
000 "test":   ESP algorithms loaded: 3DES(3)_000-SHA1(2)
000 "test":   ESP algorithm newest: 3DES_192-HMAC_SHA1; pfsgroup=<Phase1>
000 #2: "test":500 STATE_V2_IPSEC_I (IPsec SA established); EVENT_SA_REPLACE in 27837s; newest IPSEC; eroute owner; isakmp#1; idle; import:admin initiate
000 #2: "test" esp.ca6cab5b.46.52 esp.2b9e65fa.41.25 tun.0.46.52 tun.0.41.25 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=0B 
000 #1: "test":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REPLACE in 2847s; newest ISAKMP; isakmp#0; idle; import:admin initiate
000 #1: "test" ref=0 refhim=0 Traffic: 

Support of the other MUST NOT algorithms from rfc4307bis-18 is disabled.

[1] https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-18#section-2.1

Comment 3 Paul Wouters 2017-05-30 19:58:42 UTC
yes since too many people migrate ikev1 to ikev2 configs still. We are planning to remove it soon but not yet. Note that HMAC_Md5 is not a security issue 

Note it has been removed from all defaults in IKEv2, so it will never be used unless explicitly configured.

The same is true for MODP1024

Comment 4 Ondrej Moriš 2017-06-01 15:48:28 UTC
Verified requirements from:

Algorithm Implementation Requirements and Usage Guidance for IKEv2 [1].

IKEv2 Encryption Algorithm Transforms
=====================================
ENCR_DES (MUST NOT)

- PASS, already not supported

Type 2 - IKEv2 Pseudo-random Function Transforms
================================================
PRF_HMAC_MD5 (MUST NOT)

- WAIVED, see comment #2 and #3

Type 3 - IKEv2 Integrity Algorithm Transforms
=============================================
AUTH_HMAC_MD5_96 (MUST NOT)

- PASS, MD5 is in default set but in 128 bit size (128-MD5(1))

AUTH_DES_MAC (MUST NOT)

- PASS, alrady not supported

AUTH_KPDK_MD5 (MUST NOT)

- PASS, already not supported

Type 4 - IKEv2 Diffie-Hellman Group Transforms
==============================================
768-bit MODP Group - DH1 (MUST NOT)

- PASS, already not supported

1024-bit MODP Group with 160-bit Prime Order Subgroup - DH22 (MUST NOT)

- PASS, not supported from 3.20 

1536-bit MODP Group (SHOULD NOT)

- PASS, modp1536 is supported but modp2048 is default

1024-bit MODP Group (SHOULD NOT)

- PASS, modp1024 is supported but modp2048 is default

2048-bit MODP Group with 224-bit Prime Order Subgroup - DH23 (SHOULD NOT)

- PASS, DH23 is supported but modp2048 is default

2048-bit MODP Group with 224-bit Prime Order Subgroup - DH24 (SHOULD NOT)

- PASS, DH24 is supported but modp2048 is default

[1] https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-18

Comment 5 Paul Wouters 2017-06-01 15:58:18 UTC
Note that DH22 support should be enabled in the spec file via USE_DH22=TRUE, but like DH23/DH24 it is not enabled per default unless manually configured.

I'm surprised MD5 is in any default set. It should not be. It should be supported for manual configuration in both IKEv1 and IKEv2, but not part of the default list?

Note that we now also support DH19, DH20 and DH21 now (the NIST ECC groups)

Comment 6 Ondrej Moriš 2017-06-01 16:09:13 UTC
(In reply to Paul Wouters from comment #5)
> Note that DH22 support should be enabled in the spec file via USE_DH22=TRUE,
> but like DH23/DH24 it is not enabled per default unless manually configured.
> 
> I'm surprised MD5 is in any default set. It should not be. It should be
> supported for manual configuration in both IKEv1 and IKEv2, but not part of
> the default list?

May be I am reading it incorrectly, with ike=3des I see the following on both sides:

000 "test":   IKE algorithms wanted: 3DES_CBC(5)_000-SHA2_256(4)-MODP2048(14), 3DES_CBC(5)_000-SHA2_512(6)-MODP2048(14), 3DES_CBC(5)_000-SHA1(2)-MODP2048(14), 3DES_CBC(5)_000-MD5(1)-MODP2048(14)
000 "test":   IKE algorithms found:  3DES_CBC(5)_192-SHA2_256(4)-MODP2048(14), 3DES_CBC(5)_192-SHA2_512(6)-MODP2048(14), 3DES_CBC(5)_192-SHA1(2)-MODP2048(14), 3DES_CBC(5)_192-MD5(1)-MODP2048(14)

My understanding is that default set of IKEv2 integrity algorithms is: sha1_256(4), sha2_512(6), sha1(2) and MD5(1). Is that correct? BTW: I noticed that I incorrectly stated that the size od MD5 is 128. I actually do not know its size... :-/.

> Note that we now also support DH19, DH20 and DH21 now (the NIST ECC groups)

Comment 7 Ondrej Moriš 2017-06-02 07:35:30 UTC
Verified requirements from:

Cryptographic Algorithm Implementation Requirements and Usage Guidance
for Encapsulating Security Payload (ESP) and Authentication Header (AH) [1]

ESP Encryption Algorithms
=========================
ENCR_DES_IV64 (MUST NOT)

- PASS, not supported

ENCR_DES (MUST NOT)

- PASS, not supported

ENCR_BLOWFISH (MUST NOT)

- PASS, not supported

ENCR_3IDEA (MUST NOT)

- PASS, not supported

ENCR_DES_IV32 (MUST NOT)

- PASS, not supported

ENCR_3DES (SHOULD NOT)

- PASS, default is AES_GCM_C_256-NONE

ESP and AH Authentication Algorithms
====================================
AUTH_NONE (MUST NOT)

- PASS, not supported

AUTH_HMAC_MD5_96 (MUST NOT)

- PASS, MD5 is supported from 128 bits

AUTH_DES_MAC (MUST NOT)

- PASS, not supported

AUTH_KPDK_MD5 (MUST NOT)

- PASS, not supported

[1] https://tools.ietf.org/html/draft-ietf-ipsecme-rfc7321bis-05#section-3

Comment 8 Ondrej Moriš 2017-06-02 07:47:42 UTC
All cryptographic requirements related to this bug were verified. The only question to be clarified is that libreswan has MD5(1) (ie. algorithm IKE hash: id=1, name=OAKLEY_MD5, hashlen=16) in it default set of IKEv2 integrity algorithms despite that draft-ietf-ipsecme-rfc4307bis-18 speciefies AUTH_HMAC_MD5_96 as MUST NOT. Is MD5(1) equal to AUTH_HMAC_MD5_96? If so, what can we do about it?

[*] It is probably harmless since with ike=3des libreswan picks 3DES_192-AUTH_HMAC_SHA2_256_128-PRF_HMAC_SHA2_256-MODP2048.

Comment 10 errata-xmlrpc 2017-08-01 12:31:06 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, 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-2017:2101

Comment 11 Paul Wouters 2017-11-27 17:48:04 UTC
(In reply to Ondrej Moriš from comment #8)
> All cryptographic requirements related to this bug were verified. The only
> question to be clarified is that libreswan has MD5(1) (ie. algorithm IKE
> hash: id=1, name=OAKLEY_MD5, hashlen=16) in it default set of IKEv2
> integrity algorithms despite that draft-ietf-ipsecme-rfc4307bis-18
> speciefies AUTH_HMAC_MD5_96 as MUST NOT. Is MD5(1) equal to
> AUTH_HMAC_MD5_96? If so, what can we do about it?
> 
> [*] It is probably harmless since with ike=3des libreswan picks
> 3DES_192-AUTH_HMAC_SHA2_256_128-PRF_HMAC_SHA2_256-MODP2048.

md5 is allowed but not in any default proposal set.


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