crypto: algif_aead - Allow gcm(aes) for privileged users

iwd (via ell) implements TLS for the EAP-TLS/TTLS/PEAP authentication methods and uses AF_ALG for the AES-GCM AEAD of the TLS_*_WITH_AES_{128,256}_GCM_SHA{256,384} cipher suites. With af_alg_restrict=1 these suites are silently dropped from the ClientHello, and authentication fails against RADIUS servers that only accept GCM suites (common for eduroam deployments). This contradicts the stated intent of commit 2f204fe718f5 ("crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1"), which was to keep iwd working under the default restriction level.

iwd runs with CAP_NET_ADMIN, so add gcm(aes) to the privileged part of the AEAD allowlist, next to ccm(aes) which iwd also uses.

---
 crypto/algif_aead.c | 1 +
 1 file changed, 1 insertion(+)

index 5574e2d70539..a5c9e29b64be 100644
@@ -36,6 +36,7 @@
 
 static const struct af_alg_allowlist_entry aead_allowlist[] = {
 	{ "ccm(aes)" }, /* bluez */
+	{ "gcm(aes)" }, /* iwd */
 	{},
 };
 

2.55.0

Is this with upstream iwd, and do you have a source code reference? "gcm(aes)" is L_AEAD_CIPHER_AES_GCM in libell, but iwd has no references to L_AEAD_CIPHER_AES_GCM. It didn't show up in the search before either
(https://lore.kernel.org/iwd/[email protected]/),
and the iwd maintainer confirmed the full list without "gcm(aes)" on it.

- Eric

Yes. I'm using upstream iwd 3.12 with upstream ell 0.83.

The reference is in ell rather than in iwd, which is probably why your grep missed it.

iwd's EAP-TLS, EAP-TTLS and EAP-PEAP implementations hand the TLS tunnel to ell (src/eap-tls-common.c:641, l_tls_new()). ell's TLS 1.2 cipher suite table uses L_AEAD_CIPHER_AES_GCM for the eight *_WITH_AES_{128,256}_GCM_* suites:

https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/tls-suites.c?h=0.83#n1220
(tls_aes128_gcm / tls_aes256_gcm, used by the suites at lines 1322-1425, e.g. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384)

That maps to the AF_ALG name "gcm(aes)" and is bound through AF_ALG:

https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/cipher.c?h=0.83#n224
(aead_cipher_type_to_name(), then create_alg("aead", ...) in l_aead_cipher_new(), and the bind() probe in l_aead_cipher_is_supported())

When the probe fails, ell drops those suites from the ClientHello:

https://git.kernel.org/pub/scm/libs/ell/ell.git/tree/ell/tls.c?h=0.83#n413
("Cipher suite %s's AEAD cipher algorithm not supported by the kernel")

With af_alg_restrict=1 that is what happens, and EAP authentication then fails against RADIUS servers that only accept GCM suites. This is the failure in the linked report. An affected user confirmed that setting af_alg_restrict=0 fixed the connection.

Everything else iwd uses through ell is already on the privileged allowlist, and ell has no ChaCha20-Poly1305 AEAD, so gcm(aes) is the only missing algorithm.

Okay, thanks. Can you document explicitly in your commit message that iwd can use "gcm(aes)" indirectly via libell's TLS support, despite iwd itself never mentioning either "gcm(aes)" or L_AEAD_CIPHER_AES_GCM? Even the iwd folks themselves apparently don't know they are depending on AF_ALG support for this algorithm :(

You also mentioned that iwd uses "ccm(aes)". If that's true, the comment next to "ccm(aes)" should also be updated to say
/* iwd, bluez */ instead of just /* bluez */. However, libell doesn't actually have L_AEAD_CIPHER_AES_CCM in its TLS cipher list, so I still don't see that one. Do you have evidence that AES-CCM is used as well, or did you just assume that one would be the same?

- Eric

Will do, I'll send a v2 patch.

Yeah, I just assumed based on the ccm(aes) binds in init_supported(). I double checked and it actually isn't: the only AEAD user in ell is tls_change_cipher_spec() in ell/tls.c, and the suite table in ell/tls-suites.c only has L_AEAD_CIPHER_AES_GCM. I'll correct the commit message.

iwd depends on the AF_ALG algorithm "gcm(aes)", although iwd's own source never mentions "gcm(aes)" or L_AEAD_CIPHER_AES_GCM. The dependency is indirect, through the TLS implementation in libell (ell) that iwd uses for EAP-TLS, EAP-TTLS and EAP-PEAP: iwd's src/eap-tls-common.c hands the EAP tunnel to l_tls_new(). In ell, the TLS 1.2 cipher suite table in ell/tls-suites.c uses L_AEAD_CIPHER_AES_GCM for the eight *_WITH_AES_{128,256}_GCM_* suites, ell/cipher.c maps that to the AF_ALG name "gcm(aes)", and tls_change_cipher_spec() in ell/tls.c instantiates it with l_aead_cipher_new(). Before offering a suite, ell checks that its AEAD could be bound on an AF_ALG socket (l_aead_cipher_is_supported()) and drops the suites whose bind() failed.

With af_alg_restrict=1 the bind of "gcm(aes)" fails even for iwd, which holds CAP_NET_ADMIN, so the AES-GCM suites silently disappear from iwd's ClientHello and EAP authentication fails against RADIUS servers that only accept GCM suites (common for eduroam deployments). This contradicts the intent of commit 2f204fe718f5 ("crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1"), which was to keep iwd working under the default restriction level; the iwd algorithm list it was based on evidently did not account for the algorithms used by ell's TLS code.

Add "gcm(aes)" to the privileged part of the AEAD allowlist. It is the only AEAD that iwd actually uses: ell's TLS code has no CCM or ChaCha20-Poly1305 suites, and no other ell or iwd code creates an AEAD cipher. (ell does bind "ccm(aes)" once at startup, in init_supported() in ell/cipher.c, to probe which AEADs are available, but nothing uses it, so its allowlist comment is left as is.)

---
 crypto/algif_aead.c | 1 +
 1 file changed, 1 insertion(+)

index 5574e2d70539..a5c9e29b64be 100644
@@ -36,6 +36,7 @@
 
 static const struct af_alg_allowlist_entry aead_allowlist[] = {
 	{ "ccm(aes)" }, /* bluez */
+	{ "gcm(aes)" }, /* iwd */
 	{},
 };
 

2.55.0

- Eric