For some reason, the previous version was not understood to be null
terminating the buffer from recv(). It was doing this fine, though. Try
to use a bit more simpler design in hopes of getting static analyzers to
understand this. (CID 72702)
Signed-off-by: Jouni Malinen <j@w1.fi>
If the connection from hostapd authentication server to hlr_auc_gw fails
due to hlr_auc_gw not running yet, the local socket file was left
behind. Delete the socket file on connect() failure path.
Signed-off-by: Jouni Malinen <j@w1.fi>
This should probably have used monotonic time for entry timestamps, but
as those aren't used at all right now, so just remove them entirely.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are quite a few places in the current implementation where a nul
terminated string is generated from binary data. Add a helper function
to simplify the code a bit.
Signed-hostap: Jouni Malinen <j@w1.fi>
The EAP-SIM/AKA code is already validating the prefix and the following
lookup would not find matches if the prefix is incorrect, so there is no
need for the extra checks here.
Signed-hostap: Jouni Malinen <j@w1.fi>
If EAP-Response/Identity includes a known pseudonym or re-auth username,
skip the AKA/Identity exchange since we already know the permanent
username of the peer.
Signed-hostap: Jouni Malinen <j@w1.fi>
These fields are used only as the search key, so the value is already
known and does not need to be copied from the database.
Signed-hostap: Jouni Malinen <j@w1.fi>
Store permanent username (i.e., including prefix character) instead of
IMSI in the SQLite DB. Convert the string to a string since the EAP-AKA
prefix can start with zero. This cleans up the field names since the
value was already with the prefix included instead of just IMSI. In
addition, this explicitly removes some theoretical cases where the
different identity types could have been mixed.
Signed-hostap: Jouni Malinen <j@w1.fi>
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.
