Possible issue with tls_suiteb=1 and signature algorithm selection in Suite-B-192

[Kazuma Okada]

Dear hostap developers,

We integrate wpa_supplicant into our products and have identified a
potential issue related to Suite-B-192 operation during development.
We would appreciate your opinion on this matter.

Observed behavior
=================

When connecting to a WPA3-Enterprise 192-bit network using EAP-TLS with
TLS 1.2, authentication fails when tls_suiteb=1 is configured.

Under the same environment, authentication succeeds when tls_suiteb=0 is
used.

Environment
===========

Module:
  CYW55573

wpa_supplicant:
  v2.11

Authentication method:
  EAP-TLS

Security:
  WPA3-Enterprise 192-bit (Suite-B-192)

Build configuration:
  CONFIG_SUITEB=y
  CONFIG_SUITEB192=y
  TLS 1.2 operation (CONFIG_EAP_TLSV1_3 disabled)

Investigation
=============

While reviewing the source code, we found the following implementation in
src/crypto/tls_openssl.c:

    /* ECDSA+SHA384 if need to add EC support here */
    const char *algs = "RSA+SHA384";

    if (!(flags & TLS_CONN_DISABLE_TLSv1_3))
        algs =
            "RSA+SHA384:ecdsa_secp384r1_sha384:rsa_pss_rsae_sha384";

Our understanding is as follows:

- For the TLS 1.2 path, only RSA+SHA384 is configured.
- ECDSA-based signature algorithms do not appear to be offered in the
  TLS 1.2 path.
- For the TLS 1.3 path, ECDSA is included; however, RSA+SHA384 remains
  the first preferred algorithm.

On the other hand, RFC 6460 includes the following requirement:

  "A Suite B TLS client configured at a minimum level of 192 bits MUST
   offer ECDSA with SHA-384 in the signature_algorithms extension."

Based on our reading of RFC 6460, a Suite-B TLS client operating at the
192-bit security level is required to advertise ECDSA with SHA-384
during TLS negotiation.

Therefore, it appears that the TLS 1.2 implementation may not satisfy
this requirement because only RSA+SHA384 is configured.

In addition, although the TLS 1.3 path includes ECDSA, we are unsure
whether the following ordering is intentional for Suite-B-192 operation:

    RSA+SHA384:ecdsa_secp384r1_sha384:rsa_pss_rsae_sha384

Since RSA+SHA384 is listed as the most preferred algorithm, we would
appreciate clarification on whether this behavior is consistent with the
intended Suite-B-192 implementation.

Verification
============

We modified the code as follows:

    /* ECDSA+SHA384 if need to add EC support here */
    const char *algs = "ECDSA+SHA384";

    if (!(flags & TLS_CONN_DISABLE_TLSv1_3))
        algs =
            "ECDSA+SHA384:ecdsa_secp384r1_sha384:rsa_pss_rsae_sha384";

After applying this modification, EAP-TLS authentication succeeded with
tls_suiteb=1.

Questions
=========

1. Is the observed behavior a known issue?

2. Is the current implementation intentional, or could it be considered
   a bug with respect to Suite-B-192 requirements?

3. Would the modification we implemented (prioritizing ECDSA+SHA384) be
   considered an appropriate approach for addressing this issue, or is
   there another solution that you would recommend?

Best regards,

Kazuma Okada
FUJIFILM Business Innovation Corp.