Re: [PATCH] hostapd: use eapol frames from ethernet device

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1: Type: text/plain, Size: 3075 bytes --]

On Tue, 2007-08-14 at 21:16 -0700, Jouni Malinen wrote:

> - user space needs to be able to transmit EAPOL frames encrypted
>   (WPA/WPA2) and in plain (IEEE 802.1X with dynamic WEP) even if keys
>   are configured for the receiver; how is this done for the IEEE 802.1X
>   rekeying case?

Indeed, I hadn't fully considered the rekeying case. However, we
currently injected EAPOL frames via the management interface to achieve
this behaviour, it should be easy to achieve the same via the radiotap
injection interface.

> - management frames will need to be encrypted and decrypted in kernel
>   (802.11w), e.g., when user space is sending and receiving action
>   frames; i.e., there would need to be a mechanism to receive management
>   frames that has been decrypted by the kernel and to be able to send
>   management frames with kernel doing encryption; both are optional and
>   depend on the key configuration for the sender/receiver

Again, when sending them this should be part of the radiotap interface,
reception is a bit more complicated, however; see below.

> - plaintext EAPOL frames need to be received in some cases (mainly, IEEE
>   802.1X with dynamic WEP) even if there is a configured key for the
>   sending; ideally, user space apps would know whether the frame was
>   encrypted or not

If they're received unencrypted they will show up on monitor interfaces
regardless of encryption, they may or may not show up on the
802.3-framed device. Currently, EAPOL packets seem to be allowed
through, but if we go for monitor interfaces we might as well not have
them come through the 802.3-framed interface unless 802.1X is configured
to allow unencrypted frames through.

> I don't really like the idea of having to implement encryption and
> decryption for all these frames in both the user and kernel space.
> Furthermore, some things like receiption of unencrypted EAPOL frames
> would be quite difficult to do in user space unless the kernel were
> actually to help here.

I agree. The radiotap injection provides us with a means to fully
control what is happening when we need to send frames, so I wouldn't
worry about that. If anything, we'd need to extend the radiotap a bit;
there is apparently some work underway to make a "vendor-specific"
extension for radiotap that we could use in Linux.

As for receiving encrypted frames, I recently floated the idea to
introduce a crypto hook very early in frame processing so that to the
rest of the code it looks almost though the hardware was fully capable
of doing hardware offload for all encryption operations (might or might
not include MIC etc).

This has some seemingly weird implications, but ultimately it would mean
that the distinction between software and hardware encryption becomes
transparent at all levels which is a good thing. It would also mean that
the decrypted frames (if decryption was possible) show up on monitor
interfaces with a flag indicating that they were encrypted which should
address all needs here.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]