Project

General

Profile

Feature #9726

Hash Algorithm configured on child ESP/AH proposals using AES GCM though strongswan strips them

Added by Chris Linstruth 5 months ago. Updated 22 days ago.

Status:
New
Priority:
Normal
Category:
IPsec
Target version:
Start date:
09/04/2019
Due date:
% Done:

100%

Estimated time:

Description

One might want to allow transform sets on a Phase 2 like this:

AES128/192/256-CBC with SHA256
AES128-GCM with no AH

There is currently no way to do that because the AH will be set to be required for the GCM transforms as well as the CBC.

Strongswan, however, seems to do the "right thing" here...

Given this (AH required on all GCM transform sets):
Sep 4 18:56:57 charon 05[CFG] esp=
aes256-sha1-modp2048,
aes256-sha256-modp2048,
aes192-sha1-modp2048,
aes192-sha256-modp2048,
aes128-sha1-modp2048,
aes128-sha256-modp2048,
aes128gcm128-sha1-modp2048,
aes128gcm128-sha256-modp2048,
aes128gcm96-sha1-modp2048,
aes128gcm96-sha256-modp2048,
aes128gcm64-sha1-modp2048,
aes128gcm64-sha256-modp2048,
aes128-sha256-modp2048,
aes128gcm128-sha256-modp2048!

Strongswan does this (No AH on the GCM transforms):
Sep 4 18:56:58 charon 12[CFG] <con2000|1> configured proposals:
ESP:AES_CBC_256/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ,
ESP:AES_CBC_256/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ,
ESP:AES_CBC_192/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ,
ESP:AES_CBC_192/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ,
ESP:AES_GCM_16_128/MODP_2048/NO_EXT_SEQ,
ESP:AES_GCM_16_128/MODP_2048/NO_EXT_SEQ, ESP:AES_GCM_12_128/MODP_2048/NO_EXT_SEQ,
ESP:AES_GCM_12_128/MODP_2048/NO_EXT_SEQ,
ESP:AES_GCM_8_128/MODP_2048/NO_EXT_SEQ,
ESP:AES_GCM_8_128/MODP_2048/NO_EXT_SEQ,
ESP:AES_CBC_128/HMAC_SHA2_256_128/MODP_2048/NO_EXT_SEQ,
ESP:AES_GCM_16_128/MODP_2048/NO_EXT_SEQ

It would probably be best for pfSense to be adjusted to do this (strip any configured AH from all GCM transform sets) and not be dependent on strongswan to do that. Seems the configuration should match what is actually put out on the wire.

Maybe another note under the AH checkboxes saying something like "No Hash Algorithms will be applied to authenticated ciphers such as AES GCM."

History

#2 Updated by Jim Pingle 26 days ago

  • Status changed from New to Pull Request Review
  • Target version set to 2.5.0

#3 Updated by Renato Botelho 26 days ago

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Renato Botelho
  • % Done changed from 0 to 100

PR has been merged. Thanks

#4 Updated by Jim Pingle 22 days ago

  • Status changed from Feedback to New

I reverted this commit. It broke some tunnels:

GUI has:
  • Algo: AES128-GCM
  • Key Length: 128 bit
  • Hash: AES-XCBC
  • DH Group: 32

With this change applied, it does not load:

proposals = aes128gcm128-curve448

loading connection 'con1000' failed: invalid value for: proposals, config discarded

Without this change applied, it loads and connects:

proposals = aes128gcm128-aesxcbc-curve448

#5 Updated by Viktor Gurov 22 days ago

Jim Pingle wrote:

I reverted this commit. It broke some tunnels:

GUI has:
  • Algo: AES128-GCM
  • Key Length: 128 bit
  • Hash: AES-XCBC
  • DH Group: 32

With this change applied, it does not load:
[...]
[...]

Without this change applied, it loads and connects:
[...]

if we do not specify hash it uses some default Hash/PRF value (sha256?)
If no PRF is configured, the algorithms defined for integrity are proposed as PRF.
see https://wiki.strongswan.org/projects/strongswan/wiki/Connsection:

#6 Updated by Jim Pingle 22 days ago

strongSwan won't load the connection with a valid selection of options with the change applied, so it apparently doesn't assume a default. The change does not work as it should. Something is missing. We can't suddenly break working connections with valid combinations of options.

Also the code for PRF is still in a pending PR, so there is no way yet to select a PRF.

All that said, this issue originally is for Phase 2 proposal entries, and the linked PR that I reverted altered the IKE (Phase 1) proposal and not the ESP/AH (Phase 2) proposals (esp_proposals / ah_proposals)

#7 Updated by Viktor Gurov 22 days ago

right,

fixed, phase 2 strip PR:
https://github.com/pfsense/pfsense/pull/4148

#8 Updated by Jim Pingle 22 days ago

  • Subject changed from AH configured on AES GCM transform sets though strongswan strips them. to Hash Algorithm configured on child ESP/AH proposals using AES GCM though strongswan strips them

Updated subject to clarify some ambiguity in the original description.

Also available in: Atom PDF