Bug #5990
closed
AES-GCM should be an allowed encryption algorithm for IKEv2 in P1
0%
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.
Updated by Lars Pedersen about 8 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
Updated by Lars Pedersen almost 8 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.
Updated by Jim Pingle almost 8 years ago
- Assignee set to Anonymous
- 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
Updated by Michael Newton almost 8 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.
Updated by Chris Buechler almost 8 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 Anonymous to Chris Buechler
- Affected Version changed from 2.3 to 2.3.x
fix pushed
Updated by Lars Pedersen almost 8 years ago
Chris Buechler wrote:
fix pushed
Looks good. Will verify it when the next snapshot is being build.
Updated by Renato Botelho almost 8 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 :)
Updated by Jose Luis Duran almost 8 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).
Updated by Chris Buechler almost 8 years ago
- Status changed from Feedback to Resolved
fixed
Nothing to back port it to, 2.3.2 is the next release.
Updated by Renato Botelho almost 8 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
Updated by Lars Pedersen almost 8 years ago
Confirmed that it works with IKEv2 PSK mobile client using:
ike = aes256gcm128-sha512-ecp512bp!
esp = aes256gcm128-ecp512bp!