Project

General

Profile

Actions

Feature #9726

closed

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

Added by Chris Linstruth about 5 years ago. Updated over 4 years ago.

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

100%

Estimated time:
Plus Target Version:
Release Notes:

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."


Related issues

Related to Regression #12324: Hash algorithm GUI options are disabled after switching a phase 2 entry to AH modeResolvedViktor Gurov

Actions
Actions #2

Updated by Jim Pingle almost 5 years ago

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

Updated by Renato Botelho almost 5 years 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

Actions #4

Updated by Jim Pingle almost 5 years 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

Actions #5

Updated by Viktor Gurov almost 5 years 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:

Actions #6

Updated by Jim Pingle almost 5 years 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)

Actions #7

Updated by Viktor Gurov almost 5 years ago

right,

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

Actions #8

Updated by Jim Pingle almost 5 years 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.

Actions #9

Updated by Jim Pingle almost 5 years ago

  • Status changed from New to Pull Request Review
Actions #10

Updated by Renato Botelho almost 5 years ago

  • Status changed from Pull Request Review to Feedback

PR has been merged. Thanks!

Actions #11

Updated by Viktor Gurov over 4 years ago

tested on 2.5.0.a.20200220.1948

This small fix is still needed for cases where both AEAD and non-AEAD ciphers are selected at the same time:
https://github.com/pfsense/pfsense/pull/4198

Actions #12

Updated by Jim Pingle over 4 years ago

  • Status changed from Feedback to Pull Request Review
Actions #13

Updated by Renato Botelho over 4 years ago

  • Status changed from Pull Request Review to Feedback

PR has been merged. Thanks!

Actions #14

Updated by Viktor Gurov over 4 years ago

  • Status changed from Feedback to Resolved

tested on 2.5.0.a.20200221.1911

now works as expected in all cases

Actions #15

Updated by Viktor Gurov about 3 years ago

  • Related to Regression #12324: Hash algorithm GUI options are disabled after switching a phase 2 entry to AH mode added
Actions

Also available in: Atom PDF