Since the EAP-SIM/AKA identities are ASCII strings, there is no need to
use more complex way for storing and passing them. In addition, be more
strict about enforcing username (i.e., no realm part) to be used in the
EAP-SIM DB API. Similarly, require specific username type instead of any
of the types to be used as the key in the pseudonym and reauth
operations. This allows simpler lookup operations to be used.
Signed-hostap: Jouni Malinen <j@w1.fi>
The reauth_id prefix can be used to determine which AKA version is used,
so there is no need to store the aka_prime information in a separate
field.
Signed-hostap: Jouni Malinen <j@w1.fi>
If hostapd is built and configured to use SQLite database, store
EAP-SIM/AKA reauth data into the database to allow this to persist
over hostapd restarts.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
This allows hostapd to use an SQLite database for storing EAP-SIM/AKA
pseudonyms over process restarts. CONFIG_SQLITE=y build option adds
support for this and the SQLite database file is specified in eap_sib_db
configuration parameter.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
The previous implementation was able to re-open the connection to an
external program (e.g., hlr_auc_gw) when needed, but required the
connection to be available during startup. Extend this to allow the
initial failure, so that hlr_auc_gw can be started after hostapd.
Signed-hostap: Jouni Malinen <j@w1.fi>
There was a technical change between the last IETF draft version
(draft-arkko-eap-aka-kdf-10) and RFC 5448 in the leading characters
used in the username (i.e., use unique characters for EAP-AKA' instead
of reusing the EAP-AKA ones). This commit updates EAP-AKA' server and
peer implementations to use the leading characters based on the final
RFC.
Note: This will make EAP-AKA' not interoperate between the earlier
draft version and the new version.
Signed-hostap: Jouni Malinen <j@w1.fi>
intended-for: hostap-1
This commit adds a new wrapper, random_get_bytes(), that is currently
defined to use os_get_random() as is. The places using
random_get_bytes() depend on the returned value being strong random
number, i.e., something that is infeasible for external device to
figure out. These values are used either directly as a key or as
nonces/challenges that are used as input for key derivation or
authentication.
The remaining direct uses of os_get_random() do not need as strong
random numbers to function correctly.
