AAA and future Diameter support, questions

[Jouni Malinen]

On Tue, Feb 03, 2009 at 03:08:00PM +0900, Sebastien Decugis wrote:

> 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.

OK, that sounds reasonable.

> 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.

Is there any particular reason for using this type of architecture?
Would there be other processes using this Diameter daemon?

> - 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?

The proposed changes sound useful. I would prefer to this in two steps,
so that the configuration format changes would be separated from the
internal structure/interface changes. I have been quite a bit more
careful about not modifying configuration file format in a way that
would break compatibility with previously used files, but there is no
strict requirement for this during development phase (i.e., okay to do
it now in 0.7.x, but not in 0.6.x or 0.5.x).

> - Do you have any comment about the proposed design for Diameter handling?

I would need to better understand what are the reasons for an external
process. In general, I would prefer to do this within hostapd process,
but if there is justification for doing something with an external
process, that can be a valid design, too. Anyway, making the AAA ops
design easier to replace in hostapd certainly makes it easier to add
this type of mechanism and/or other Diameter implementation, if desired.

-- 
Jouni Malinen                                            PGP id EFC895FA