Linux wireless drivers development
 help / color / mirror / Atom feed
From: Jouni Malinen <j@w1.fi>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: Tomas Winkler <tomasw@gmail.com>,
	"John W. Linville" <linville@tuxdriver.com>,
	Jiri Benc <jbenc@suse.cz>,
	linux-wireless@vger.kernel.org
Subject: Re: [PATCH] hostapd: use eapol frames from ethernet device
Date: Tue, 14 Aug 2007 21:16:02 -0700	[thread overview]
Message-ID: <20070815041602.GP1415@jm.kir.nu> (raw)
In-Reply-To: <1187002921.27916.77.camel@johannes.berg>

On Mon, Aug 13, 2007 at 01:02:01PM +0200, Johannes Berg wrote:

> The actual technical reason for doing is that subsequent patches totally
> remove the management interface and on the monitor interface the EAPOL
> frames show up undecrypted.

I have to admit that I haven't followed the latest changes on this area,
but before this kind of change goes in, I would like to verify that all
the needed cases will be supported with EAPOL and management frames:

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

- 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

- 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


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.

For me, the management frame interface provides a good and working
solution for this. I know that some people do not like the idea of
having yet another network device showing up here, but I want to make
sure that the "solution" for this is not breaking some needed
functionality or making this unnecessarily complex to implement for user
space apps.

-- 
Jouni Malinen                                            PGP id EFC895FA

  parent reply	other threads:[~2007-08-15  4:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-10 23:48 [PATCH] mac80211: remove special casing of EAPOL on mgmt interface Johannes Berg
2007-08-10 23:53 ` [PATCH] hostapd: use eapol frames from ethernet device Johannes Berg
2007-08-12 10:58   ` Tomas Winkler
2007-08-13  8:51     ` Johannes Berg
2007-08-13 10:46       ` Tomas Winkler
2007-08-13 11:02         ` Johannes Berg
2007-08-14 22:46           ` Tomas Winkler
2007-08-15 10:58             ` Johannes Berg
2007-08-15  4:16           ` Jouni Malinen [this message]
2007-08-20 11:57             ` Johannes Berg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070815041602.GP1415@jm.kir.nu \
    --to=j@w1.fi \
    --cc=jbenc@suse.cz \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=tomasw@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox