Feature #5861


extend charon with external authentication interface

Added by laforge about 1 year ago. Updated 13 days ago.

In Progress
Target version:
Start date:
Due date:
% Done:



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.

Related issues

Related to osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #5868: Create a proof-of-concept to forward traffic from IPsec into a GTP tunnelClosed01/21/2023

Actions #1

Updated by lynxis about 1 year ago

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.

Actions #2

Updated by lynxis about 1 year ago

There are two layers of abstraction we can use:
- the credential manager (it is an converter to the simcard manager abstraction)
- the simcard manager (abstracts both side, sim and HLR/HSS)

Actions #3

Updated by lynxis about 1 year ago

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.

Actions #4

Updated by lynxis about 1 year ago

  • Status changed from New to In Progress
Actions #5

Updated by lynxis about 1 year ago

  • Status changed from In Progress to Stalled
  • Parent task set to #5868

Waiting for #5868 to complete.

Actions #6

Updated by lynxis about 1 year ago

  • Parent task deleted (#5868)
Actions #7

Updated by lynxis about 1 year ago

  • Related to Bug #5868: Create a proof-of-concept to forward traffic from IPsec into a GTP tunnel added
Actions #8

Updated by lynxis about 1 year ago

See MSC on for further details on the external interface.
Further it also needs to support disconnecting clients if the HSS requests this.

Actions #9

Updated by lynxis about 1 year ago

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.

Actions #10

Updated by lynxis about 1 year ago

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).
Actions #11

Updated by lynxis 12 months ago

  • Status changed from Stalled to In Progress

I've implemented a basic gsup/ipa based interface which supplies the authentication data.

Actions #12

Updated by lynxis 7 months ago

The authentication data can flow between strongswan, osmo-epdg (erlang component) and over SWx towards the HSS.

Actions #13

Updated by laforge 13 days ago

  • Priority changed from Normal to Urgent

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)