Check that the TLS logic has verified the server is trusted by the CA if
one was configured. This is more of an assert as ell intentionally only
allows empty certificate chains from the peer in server mode (if a CA
certficate is set) although this could be made configurable.
Set an upper limit on a fragmented EAP-TLS request size similar to how
we do it in EAP-TTLS. While there make the code more similar to the
EAP-TTLS flag processing to keep them closer in sync. Note that the
spec suggests a 64KB limit but it's not clear if that is for the TLS
record or EAP request although it takes into account the whole TLS
negotiation so it might be good for both.
eap_append_secret now takes a new cache_policy parameter which can be
used by the EAP method to signal that the value received from the agent
is to never be cached, i.e. each value can only be used once. The
parameter value should be EAP_CACHE_NEVER for this and we use this in
value EAP-GTC where the secret tokens are one time use. The
EAP_CACHE_TEMPORARY value is used in other methods, it preserves the
default behaviour where a secret can be cached for as long as the
network stays in range (this is the current implementation more than a
design choice I believe, I didn't go for a more specific enum name as
this may still change I suppose).
Replace usages of l_settings_get_value with l_settings_get_string, which
will make sure the returned strings are unescaped but also allocates
memeory and forces us to use l_free on most of the strings. Some of
these strings we explicitly set with l_settings_set_string() in our code
so when we retrieved them with l_settings_get_value() we would receive a
different string if there were any escapable characters in the string.
I didn't replace any of the l_settings_get_value() uses where we're just
checking whether a setting is present, or those which are hexstrings or
EAP method names assuming that they can't have any special characters,
although this isn't future proof. I did use l_settings_get_string() for
file paths though.
Accept two setting IDs in eap_append_secret, first for the username and
second for the password in case of the EAP_SECRET_REMOTE_USER_PASSWORD
EAP secret type. In all other cases only the first setting is used.
Until now for EAP_SECRET_REMOTE_USER_PASSWORD secrets we'd generate the
two setting names by adding different suffixes to the ID parameter.
Using the two different setting names automatically fixes the issues
with using the EAP Identity returned by the agent in EAP-MSCHAPv2 and
EAP-PWD.
The EAP-method's .probe methods only checked the method name so do that
in eap.c instead and allocate method state in .load_settings. Rename
method's .remove method to .free to improve the naming.
Add the EAP-TLS authentication method. Currently, all the credentials
data is read from the provisioning file even though things like the
private key passphrase should possibly be obtained from the dbus agent.
