Project

General

Profile

Bug #9309

Configuration AES-GCM for IKEv2 phase 1 does not work

Added by Florian K. 12 days ago. Updated 12 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
IPsec
Target version:
-
Start date:
02/07/2019
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.4.4_2
Affected Architecture:

Description

If you want to use AES-GCM, you don't need an integrity algorithm, but you do need a pseudo random function.

See https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites :

If combined-mode (AEAD) ciphers are proposed there won't be any integrity algorithms from which to derive PRFs, so in such a proposal PRF algorithms have to be configured explicitly.

Also, please see the comment of Joel Schulze regarding phase one proposals in https://wiki.strongswan.org/issues/2808

Problem: When I configure a "Phase 1 Proposal (Encryption Algorithm)" of
- Algorithm: AES256-GCM
- Keylength: 128 bits
- Hash: SHA256
- DH-Group: 21

Then, the line `ike = aes256gcm128-sha256-ecp521!` will be created in ipsec.conf.
However, the correct value would be `ike = aes256gcm128-prfsha256-ecp521!`
(Note that sha256 is a hash function and prfsha256 is a pseudo-random-function.)

Proposal:
- Rename the label of the dropdown "Hash" to "Hash/PRF" (the values of the dropdown can fortunately stay the same)
- When a AES-GCM algorithm is selected, interpret the value in this field as PRF and therefore add the correct value as described in
"Pseudo-random Functions" of https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites .
(Basically, use the same string, but with a "prf" prefix.)

History

#1 Updated by Jim Pingle 12 days ago

That's what AES-XCBC is for:

https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configuring-a-site-to-site-ipsec-vpn.html

This could be handled better, but the correct choice is documented.

#2 Updated by Florian K. 12 days ago

Thanks Jim for pointing out the documentation - but the documentation does not match the implementation:

The documentation says:

When using AES-GCM, this is used solely as a PRF because AES-GCM already performs hashing internally.

That would be the correct behavior. However, pfSense behaves differently. As I wrote above, it does NOT use "prfsha256" (as it should and as it is documented). It uses "sha256" which is wrong (see the strongswan docs and the comment of Joel Schulze.)

Maybe AES-XCBC is a good choice - but if the client does not support it, it would be good to be able to use prfsha256 (or one of the other PRFs.)

Also available in: Atom PDF