Using wpa_supplicant/hostapd in IKEv2 daemon...

[Jouni Malinen]

On Fri, Aug 18, 2006 at 08:54:36PM +0200, Stjepan Gros wrote:

> First idea is to implement everything from stretch and the second is to
> take existing code base (like wpa_supplicant/hostapd) and integrate it
> into IKEv2 daemon. But, those two ideas require too much resources that
> we don't have now so we would like to avoid them.
> 
> Now, the third solution is to write glue layer that would allow us to
> take and pass EAP messages from/to wpa_supplicant/hostapd.

I don't see how this would be less work than the second idea mentioned
above.

> To minimize necessary changes we are thinking about leaving
> wpa_supplicant/hostapd as a separate processes that communicate with
> IKEv2 via some IPC mechanism. 

Well, I guess this would be possible, if IKEv2 interacts with EAP state
machine in similar way as IEEE 802.1X/EAPOL. However, this brings in the
complexity of possibly having to work around things that EAPOL state
machines do. For example, re-tries are defined in EAPOL and I don't know
whether the design there is compatible with IKEv2.

> 1. Generally, do you think is this idea feasible?

Feasible, yes, but certainly not the cleanest way of doing this.

> 2. We are thinking at implementing glue code at the l2_packet level,
> that just relays EAP packet to IKEv2 daemon (and vice versa). That is in
> wpa_supplicant. Is this the best place? Note that we need raw EAP
> packets.

If you really want to go ahead with this in the way you described, yes,
l2_packet would likely be the best place. However, I would strongly
consider doing it at the architecturally correct place, i.e., next to
EAP state machine, by implementing the EAPOL-EAP state machine interface
(see eap.h). The names are referring to EAPOL, but there is no strict
requirement of the other side really being EAPOL state machine, it could
as well be IKEv2..

> 3. There are no such files (l2_packet*) in hostapd so where is the best
> place to do such thing in hostapd?

l2_packet* are used with some driver interface. For example, see what
driver_madwifi.c is doing with l2_packet for receiving and sending EAPOL
frames.


Anyway, I would be more interested in making sure that the EAP state
machine can be used in other environments than trying to solve issues
with EAPOL/IEEE 802.1X getting in way. The EAP code in wpa_supplicant
has already been used in other systems than EAPOL/IEEE 802.1X, e.g.,
with WiMax. You could try to use it as an external library in the IKEv2
implementation.

I'm working on making the EAP server/peer implementations in
hostapd/wpa_supplicant look more clearly as libraries for the next
development branch (0.6.x). They already are mostly separate modules
from rest of hostapd/wpa_supplicant and I would be willing to help with
any remaining issue on this separation area if such issues show up with
IKEv2.

-- 
Jouni Malinen                                            PGP id EFC895FA