pfSense » pfSense Docs

For some further justification, the NIST Guide to IPsec VPNs (SP 800-77) does not list AES-XCBC as an approved PRF algorithm and further explicitly mention that it is not approved for integrity: "While commonly deployed on Internet of Things (IoT) devices, AES-XCBC is not a NIST- approved integrity algorithm" Approved PRFs are SHA-256, SHA-384, and SHA-512.

It's also worth noting that the native IPsec client in Android 11 and 12 does support AES-XCBC and has it listed before SHA256 in its proposals:

IKE:AES_CTR_256/AES_CBC_256/AES_CTR_192/AES_CBC_192/AES_CTR_128/AES_CBC_128/HMAC_SHA2_512_256/HMAC_SHA2_384_192/HMAC_SHA2_256_128/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA1/PRF_AES128_XCBC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_CMAC/MODP_4096/CURVE_25519/MODP_3072/MODP_2048
IKE:CHACHA20_POLY1305/AES_GCM_16_256/AES_GCM_12_256/AES_GCM_8_256/AES_GCM_16_192/AES_GCM_12_192/AES_GCM_8_192/AES_GCM_16_128/AES_GCM_12_128/AES_GCM_8_128/PRF_HMAC_SHA1/PRF_AES128_XCBC/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_CMAC/MODP_4096/CURVE_25519/MODP_3072/MODP_2048

I seem to recall having an issue connecting using AES-GCM without AES-XCBC on Android 11 but on Android 12 it uses SHA256 without issue. I don't have a device handy that still has 11 to confirm, though. It's probably safe to change any of the XCBC references with regard to Android to SHA256. (This is part of the documentation that isn't yet public, but is still a work in progress).

Thanks for taking this up Jim!

Originally that was recommended as it would result in the highest performance on systems with hardware acceleration for AES but not SHA, such as most early AES-NI implementations, some Intel chips now also accelerate SHA, but it's not as widespread and must also be supported in OS drivers

Totally understandable, although I believe most CPUs supporting AES-NI would also likely support AVX or NEON which can also significantly accelerate SHA hashes. At least, I know Intel first shipped AVX the generation after they added AES-NI, and pretty much every ARMv8 CPU implementing ARMv8's crypto extensions can be expected to support NEON as well.

That said, since this is just for IKE, acceleration probably isn't going to make a significant difference unless there are a lot of tunnels and/or mobile clients negotiating IKE constantly.

For this reason, I feel like it might make sense to be noted in the scaling doc as "only use if you have a significant amount of tunnel churn and/or frequent re-keys" Generally, my intuition is that the choice of PRF is only likely to become a bottleneck in the most extreme cases, so it seems like a bummer to degrade security unless truly necessary.

As for Apple/Microsoft support, that isn't a factor here. There are plenty of combinations we support that they do not, and the docs are already clear on that when it comes to setting up remote access IKEv2 connections.

Faire enough. Mostly my thought process was that an algorithm that should be well-supported by any platform implementing IKEv2 (at least based on RFC 8247) would probably be a better choice for the baseline recommendation than one a couple major vendors are known not to support. By the way, I'm very glad to see y'all recommend GCM here over CBC!

It's also worth noting that the native IPsec client in Android 11 and 12 does support AES-XCBC and has it listed before SHA256 in its proposals

That's interesting context, and I appreciate you looking into that. It seems odd to me that the encryption, integrity, and DH transforms seem to be listed in descending order of security level, but the PRF ones seem to be listed in ascending order instead. I can't imagine it makes sense from a performance or security perspective to calculate a SHA-512 hash over every packet but derive the key material using SHA-1.

Kev Kitchens wrote in #note-5:

Totally understandable, although I believe most CPUs supporting AES-NI would also likely support AVX or NEON which can also significantly accelerate SHA hashes. At least, I know Intel first shipped AVX the generation after they added AES-NI, and pretty much every ARMv8 CPU implementing ARMv8's crypto extensions can be expected to support NEON as well.

There may be support in hardware but that doesn't necessarily mean it's supported all the way through the systems (OS/kernel, drivers, crypto code, etc). That is all still a work in progress upstream.

For this reason, I feel like it might make sense to be noted in the scaling doc as "only use if you have a significant amount of tunnel churn and/or frequent re-keys" Generally, my intuition is that the choice of PRF is only likely to become a bottleneck in the most extreme cases, so it seems like a bummer to degrade security unless truly necessary.

That's essentially what I did, it just isn't in the public docs yet.

It's also worth noting that the native IPsec client in Android 11 and 12 does support AES-XCBC and has it listed before SHA256 in its proposals

That's interesting context, and I appreciate you looking into that. It seems odd to me that the encryption, integrity, and DH transforms seem to be listed in descending order of security level, but the PRF ones seem to be listed in ascending order instead. I can't imagine it makes sense from a performance or security perspective to calculate a SHA-512 hash over every packet but derive the key material using SHA-1.

I've learned not to think too hard about what Google does for things like that. Some of their decisions are logical, others are far from it.