Questions about mesh SAE authentication merge
j at w1.fi
Sat Mar 19 08:22:42 EDT 2011
On Fri, Mar 18, 2011 at 03:17:45PM -0700, Javier Cardona wrote:
> 1. When to integrate. In its current state, our forked wpa_supplicant
> can discover and authenticate other mesh peers and create peers
> (stations) in the kernel. After that happens, peer link establishment
> continues in the kernel. There is still more work to be done, but the
> authentication is usable and useful as it is. One can now use
> wpa_supplicant to ensure that peer links are only established with
> authenticated peers. And authentication takes place without leaking
> password information over the air.
> So the question is, would you be willing to integrate our patches at
> this point or you'd rather wait until AMPE and encryption are also
I'm fine with getting partial functionality in and I'm interested in
getting this extended for non-mesh cases (well, mainly, station/AP
> 2. Feedback on implementation. Regardless on when and whether we
> integrate, we would really appreciate your feedback on our
> implementation approach. What would be the best way for you to review
> our patches? Submit as RFC's to this list?
Whenever you have a patch that you think would be ready to be included,
sending it on the mailing list (or if longer than the maximum length
limit, making it available on a web server or a git repository etc.)
should work fine.
> 3. License. The reference SAE implementation from Dan Harkins is
> distributed under the original BSD license ( see
> https://github.com/cozybit/hostap-sae/blob/master/src/sae/sae.c ).
> Would you accept that code into your repository as-is (maybe with a
> warning on the COPYING file stating that some files in the project
> cannot be licensed as GPL)? Or would you require that those files are
> downloaded from his project at compile time if SAE is enabled? Other
I'm trying to maintain the same license terms throughout the hostap.git
repository. As such, I'm not prepared to add code that conflicts with
the current requirements (BSD advertisement clause) especially for areas
that are likely to become core components that will in practice be
included in all builds.
In addition to that, I do not really want to add dependencies on
something to be downloaded during the build. My own preferences for this
in decreasing order would be:
- if the copyright holder is willing to license the code under
BSD/GPLv2 (at users' choice), use the same license as elsewhere in
- re-implement SAE from scratch with a suitable license
- make an external library of the SAE components and maintain that as a
It should also be noted that this will eventually need to work without
OpenSSL to make the implementation more suitable for embedded devices.
In addition, keeping the code in a single repository makes it easier to
handle different build environments without having to figure out how an
additional library needs to be built. As such, of those three options,
the first two are of much higher benefit from my view point.
Jouni Malinen PGP id EFC895FA
More information about the HostAP