[FEATURE] EAP-TLS configuration support

[jrb0001]

Is your feature request related to a problem? Please describe.
I have a network which uses EAP-TLS which isn't supported by nmrs at the moment.

Describe the solution you'd like
TLS needs the following additional values:

• private-key
• private-key-password if the private key is encrypted
• client-cert

The following currently implemented values only apply to PEAP and TTLS and are irrelevant to TLS:

• password
• anonymous-identity
• phase2-auth

It might be good to also implement WPA3 Enterprise 192-bit mode. The NetworkManager configuration is just EAP-TLS plus key-mgmt=wpa-eap-suite-b-192. TLS is the only supported method.

For Developers- what would your solution be?

I wrote a small PoC for everything needed by my application:

• Move the PEAP/TTLS specific config to a new struct which is then used in EapMethod::Peap/EapMethod::Ttls.
• Create a new struct for the TLS specific config and add it to EapMethod::Tls.
• Make the new private key and certificate fields as well as the old ca_cert (also used by TLS) accept either a path or the data (uses blob scheme):
  • File scheme: Byte array must start with file:// and end in a null byte.
  • Blob scheme: Byte array with Just the raw data, DER format for ca-cert and client-cert or "encrypted PEM" for private-key or PKCS#12 for private-key (then client-cert must be identical?).
  • While it might work for ca-cert to send the path as a string, it gives an unhelpful error if the same is done for client-cert/private-key. Documentation specifies all three as byte array.

This approach is obviously not backwards compatible, but it's clearer about which values are needed for which method.

The alternative would be to add all new values to the current EapOptions struct and extend the validation logic. It is still a breaking change because password+phase2-auth have to become optional, but the update path is easier.

[cachebag]

@jrb0001
Your PoC is nice, but would indeed break API.

That said, adding EAP-TLS itself does not have to be breaking. Because EapMethod and EapOptions are already #[non_exhaustive], so I think a compatible path is possible. Something along these lines...

• Add EapMethod::Tls.
• Add optional TLS fields to EapOptions, e.g. client_cert, private_key, private_key_password.
• Add explicit constructors/builders like EapOptions::tls(...) or EapOptionsBuilder::tls_client_cert(...).
• Update validation so password and phase2 are required only for PEAP/TTLS, not TLS.
• Update wifi_builder to omit password and phase2-auth for TLS and emit client-cert / private-key.

The awkward part is that EapOptions::new(identity, password) and the builder encode PEAP/TTLS assumptions. But we can preserve those and add a TLS-specific path without breaking existing users.

For WPA3 Enterprise 192-bit, I’d probably want to avoid silently overloading plain WpaEap. Maybe we add an explicit option or method, because it changes key-mgmt from wpa-eap to wpa-eap-suite-b-192 and only works with TLS.

I think the “cleaner” model is semver-breaking and if we are going that route, it's best we save this for 4.0. But as I said, we could use additive fields/constructors and push this to a minor version if needed.