The "H" function used by SAE and EAP-PWD was effectively the same
function, EAP-PWD just used a zero key for its calls. This removes
the duplicate implementations and merges them into crypto.c as
"hkdf_256".
Since EAP-PWD always uses a zero'ed key, passing in a NULL key to
hkdf_256 will actually use a 32 byte zero'ed array as the key. This
avoids the need for EAP-PWD to store or create a zero'ed key for
every call.
Both the original "H" functions never called va_end, so that was
added to hkdf_256.
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.
James Prestwood