Project

General

Profile

Actions

Correction #12471

open

AES-XCBC should not be recommended as PRF for IPsec

Added by Kev Kitchens about 1 month ago. Updated about 1 month ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
IPsec
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

The IPsec Configuration (https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configure.html) and VPN Scaling (https://docs.netgate.com/pfsense/en/latest/vpn/performance.html) sections of the pfSense docs recommend using AES-XBC as the PRF when AES-GCM is in use and SHA-256 otherwise. It would be better to only recommend SHA-256

The motivation for supporting AES-XCBC in IKE was to allow constrained platforms to re-use their AES-CBC hardware accelerators. So, this recommendation would make sense when configuring legacy AES encryption as it is CBC-based, but makes less sense when using AES-GCM.

Also, using XCBC in IKEv2 (AES-GCM isn't supported in IKEv1) requires the initiator and responder nonces to be truncated to 64 bits when calculating SKEYSEED in order to match the 128-bit key size required by XCBC, reducing the entropy of SKEYSEED. This is not a restriction of any other PRF supported by IKEv2, including SHA-256.

Finally, it's worth noting that neither Microsoft nor Apple support AES-XCBC in their respective IKEv2 implementations (see https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd125380(v=ws.10) and https://developer.apple.com/documentation/networkextension/nevpnikev2integrityalgorithm)

Actions #1

Updated by Kev Kitchens about 1 month ago

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.

Actions #2

Updated by Jim Pingle about 1 month ago

  • Assignee set to Jim Pingle

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.

There is always a security vs performance tradeoff, though the docs could be more clear about that. It still makes sense in the scaling doc since it is focused on performance, but in the regular configuration doc it should probably change to SHA256 as you suggest. 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.

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.

I'll update this along with the other IPsec changes but they may not be live for a while yet as much of the IPsec updates are targeted at the next release.

Actions #3

Updated by Jim Pingle about 1 month ago

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

Actions #5

Updated by Kev Kitchens about 1 month ago

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.

Actions #6

Updated by Jim Pingle about 1 month ago

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.

Actions

Also available in: Atom PDF