Project

General

Profile

Actions

Bug #5990

closed

AES-GCM should be an allowed encryption algorithm for IKEv2 in P1

Added by Lars Pedersen over 5 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Normal
Category:
IPsec
Target version:
Start date:
03/14/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.3.x
Affected Architecture:

Description

Can see that GCM options for phase1 IPsec has been removed again at:

https://github.com/pfsense/pfsense/commit/76bec1ab8790964c9714f7f8497edfa1a6c53409

A few topics regarding this already exists but think its time to be sure that the correct options are available on the website for both IKEv1 and IKEv2

https://redmine.pfsense.org/issues/5758
https://redmine.pfsense.org/issues/4042

I have already commented something on github but I think a redesign is needed on the website, since IKEv2 doesnt have a concept of phase 1 and phase 2. The initial exchange in IKEv2 (known as Phase 1 in IKEv1) covers both the establishment of the IKE SA and establishment of the first child SA. Hence in IKEv2 there is no “phase 2” after the initial exchange (at least not until the first child SA needs to be rekeyed).

IKEv2 specification
https://tools.ietf.org/html/rfc7296#section-1.2

Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
exchanges (known in IKEv1 as Phase 1). These initial exchanges
normally consist of four messages, though in some scenarios that
number can grow. All communications using IKE consist of request/
response pairs. We'll describe the base exchange first, followed by
variations. The first pair of messages (IKE_SA_INIT) negotiate
cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
exchange [DH].

Difference between IKEv1 and IKEv2
https://tools.ietf.org/html/rfc6071#section-2.3.1
” Protection of IKE messages based on ESP, rather than a method
unique to IKE

IKEv2 uses the same protection for IKE messages as for ESP. So if one wants to use GCM for ESP, one will also have to use GCM for IKE messages.

Actions #1

Updated by Lars Pedersen over 5 years ago

strongswan also got a test configuration using GCM in both "IKE" and "ESP" parameter
https://www.strongswan.org/testing/testresults/ikev2/alg-aes-gcm/index.html

Actions #2

Updated by Lars Pedersen about 5 years ago

Took the initiative and asked the strongswan mailing list if the AES-GCM was supported in IKEv2. The response is in the github commit link. So I think the webconfigurators IPsec section must be resigned for with a IKEv1 and IKEv2 layout since they are different.

Actions #3

Updated by Jim Pingle about 5 years ago

  • Assignee set to Steve Beaver
  • Target version set to 2.3.2
  • Affected Version set to 2.3

Testing confirms that it does not work with IKEv1, as expected, but that it does work with IKEv2 following that strongSwan example.

Looks like we could accommodate it in the current GUI:

1. The AES-GCM options must only be shown for IKEv2, not IKEv1 (and rejected if somehow chosen for IKEv1, such as an upgrade from an older version that incorrectly allowed it)

2. A note or other nudge that it's best to use AES-XCBC for the "hash" (really PRF) when selecting AES-GCM for IKE in IKEv2.

For the immediate future, if someone needs GCM in p1 quickly, they could use this patch with the System Patches package (path strip = 2) to get the options back, but they'd show incorrectly for IKEv1, so it's not good to commit as-is: http://files.atx.pfsense.org/jimp/patches/gcmp1-2.3.x.patch

Actions #4

Updated by Michael Newton about 5 years ago

Can I suggest that in the meantime, there shouldn't be a default selection made for encryption algorithm? And further, perhaps a warning message displayed? It's poor form to remove a feature without any notice to the user; especially since it's not removed from the back end. So as long as you don't make any changes it keeps working!

I made a small change to our tunnel configuration a few days ago, not realizing that AES-GCM had been silently changed to AES when I saved the changes. The tunnel was stopped and started a couple of times afterwards, with no problems. But once the pfSense was rebooted and came back up, the tunnel was broken and people started yelling! Upgrade to 2.3 happened months ago.

Actions #5

Updated by Chris Buechler about 5 years ago

  • Subject changed from Webconfiguration IPSec IKEv2 GCM option to AES-GCM should be an allowed encryption algorithm for IKEv2 in P1
  • Status changed from New to Feedback
  • Assignee changed from Steve Beaver to Chris Buechler
  • Affected Version changed from 2.3 to 2.3.x

fix pushed

Actions #6

Updated by Lars Pedersen about 5 years ago

Chris Buechler wrote:

fix pushed

Looks good. Will verify it when the next snapshot is being build.

Actions #7

Updated by Renato Botelho about 5 years ago

Lars Pedersen wrote:

Chris Buechler wrote:

fix pushed

Looks good. Will verify it when the next snapshot is being build.

FYI, new snapshots are available :)

Actions #8

Updated by Jose Luis Duran about 5 years ago

Is this going to be backported?

As this was a breaking change from 2.2 to 2.3 (not appearing in the Change log).

Actions #9

Updated by Chris Buechler about 5 years ago

  • Status changed from Feedback to Resolved

fixed

Nothing to back port it to, 2.3.2 is the next release.

Actions #10

Updated by Renato Botelho about 5 years ago

Jose Luis Duran wrote:

Is this going to be backported?

As this was a breaking change from 2.2 to 2.3 (not appearing in the Change log).

It's going to be available on 2.3.2, that will be released soon

Actions #11

Updated by Lars Pedersen about 5 years ago

Confirmed that it works with IKEv2 PSK mobile client using:

ike = aes256gcm128-sha512-ecp512bp!
esp = aes256gcm128-ecp512bp!
Actions

Also available in: Atom PDF