AAA and future Diameter support, questions

[Sebastien Decugis]

Hello,

I am considering how to integrate hostapd with Diameter protocol instead
of RADIUS, and I have some ideas and questions.

As a first step I would like to separate more the RADIUS code from the
core code of the hostapd daemon. This would include:

- Reorganize a little the hostapd_config_bss structure (and
configuration file parsing) to regroup data for radius servers in one
structure (radius_server_clients, ...)

- Create a module (structure containing pointers to cb) for AAA
functions, similar to the current wpa_driver_ops, maybe "aaa_ops".
Create one instance of this driver for RADIUS.

- Change the hostapd_data structure and remove all RADIUS-related
fields. It would only contain "void * aaa_priv" and "void *
aaa_sta_priv" fields that are passed to aaa_ops callbacks.

Once this reorganization is complete, it would be easier to add new aaa
modules (Diameter, other...)

About the Diameter protocol, I am planning to implement differently from
RADIUS in the hostapd daemon. All encapsulation / decapsulation would be
done by another process (the Diameter daemon) and communication between
both processes (EAP messages, keying material, accounting data, peer
info...) would be passed between the processes using a UNIX socket.
Therefore the configuration in hostapd would contain only role
information ( authenticator or server ) and path to UNIX socket. The
Diameter-specific configuration is left to the Diameter daemon.

I have two questions:
- Would you consider integrating a patch providing these changes in the
hostapd repository? Are there any restriction (such as: the format of
the configuration file must not change) that I should be aware of?
- Do you have any comment about the proposed design for Diameter handling?

Thank you,
Sebastien.

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)