extend charon with external authentication interface
right now there's a charon plugin for eap-aka. It uses a local CSV file for storage of K/OP values, and it assumes it can synchronously access that and use it to derive AUTN challenges. so basically it includes a mini-hss/hlr.
We need to modify/replace that with a system where we get an asynchronous request for authentication over some external interface (currently called CEAI in my diagram at EPDG_implementation_plan), like a unix domain socket. Charon then needs to wait until whatever external application has obtained auth tuples, and proceed with EAP-AKA only once a tuple has been received.
This can be developed and tested independent of the actual ePDG by implementing a small stub program that for example reas key material from a local CSV file (again), or possibly even by asking osmo-hlr via GSUP (we do have all the related libraries in place for C and python, AFAIR). So the latter might actually be easier than the CSV approach, where again one needs to do key derviation etc.
Strongswan already understands the concept of a credential manager.
# eap_aka_3gpp_functions.c shared = lib->credmgr->get_shared(lib->credmgr, SHARED_EAP, id, NULL);
The AKA and AKA' code expects K and OPC returned by this call as concatenated value. Id is the imsi.
Either I would implement a simple unix socket interface with simple PDUs. Or we could use libgsup to talk with osmo-epdg.
Further there is also a configuration manager to push the P_CSCF_IP4_ADDRESS to the UE.
When the authentication via EAP-AKA is over, the GTP tunnel must be open before allowing the IPsec connection to get through.
Use the configuration manager api to supply the P-CSCF Address and to hook into IPsec to have the time to request the GTP tunnel.
See MSC on https://osmocom.org/projects/osmo-epdg/wiki/EPDG_implementation_plan for further details on the external interface.
Further it also needs to support disconnecting clients if the HSS requests this.
The structure of strongswan/charon seems to require us to implement a thread-safe queue model. Every ipsec SA is a thread.
So far I understood the authentication model is, that the plugin should block the authentication until it is finish.
When a UE connects, strongswan requests the Auth data via CEAI (strongswan <-> ePDG) and blocks until there is an answer.
Later in the auth process of the UE we need to SAR (Server Assignment Request) the HSS before sending the EAP Success to the UE.
So either we implement the interface between strongswan and ePDG within strongswan with a thread-safe queue. Or every time strongswan requests something from the ePDG it opens a new connection we do the state handling within ePDG.
I'll implement the CEAI in GSUP as a strongswan plugin.
I would like to use the GSUP en/decoder from libosmocore. Most likely not the remaining parts and re-implement those in strongswan.
strongswan should connect towards the osmo-epdg.
- Add a new message class IPSEC_EPDG to gsup.
- Use Send Auth Information Req/Resp (sswan => ePDG) when strongswan requires auth information.
- Use Update Location Req/Resp (sswan => ePDG) when the ePDG would call Service Request Assignment/Updates the HSS with the new location.
- Use Cancel Location Req/Resp (sswan <= ePDG) when the ePDG wants to close an IPSec SA.
- Use Insert Data Req/Resp (sswan => ePDG) (or add a new message type) when strongswan is asking the ePDG for the IKEv2 CFG_REPLY data (ePDG will use GTPv2 Create Session Request towards the PGW).