MGTK/IGTK changes do not work about authsae HOT 19 CLOSED

What hardware are you on? This revision - master of my branch ( https://github.com/cococorp/authsae ) works fine on ath10k.
Also, are you running latest kernel/compat-wireless? mac80211 patches went in sometime in the end of June, I believe.

from authsae.

we are running with 4.1.25 upstream kernel on ath9k

if this only works with e newer version then the functionality should probably be disabled somehow.
currently it seems like total fail, sorry

from authsae.

btw I changed nothing in our configuration, and therefore did not expect it to get enabled

from authsae.

@alexgrin , I believe that/your master branch is not quite in sync with upstream and in fact does not include the MGTK/IGTK changes

from authsae.

Ooops, I was wrong about what I'm running - I'm using this revision in my Makefile - uniumwifi@dca726e
It's my VHT branch that is a few revisions behind, but has MGTK/IGTK stuff.
Check that your kernel has this patch in it - https://patchwork.kernel.org/patch/9192401/
There could be more, but this likely is the one that makes new GTK stuff work.
Also, I have not tried this on ath9k devices, I'll see if if get a minute to try it today.

from authsae.

thanks for the patch link, maybe I can try it tomorrow

from authsae.

That patch (upstream 46f6b06050b736dab4d41494dae27b883cddc365) went into 4.8

from authsae.

I'm currently running a 4.4 kernel, but I'm using compat-wireless 10-08-2016 from LEDE/OpenWRT. You might have to go same route.

from authsae.

@bcopeland Bob, you added this code. Is it possible to somehow disable it when run on a kernel < 4.8?

from authsae.

On Thu, Oct 27, 2016 at 12:42:37PM -0700, Ferry Huberts wrote:

@bcopeland Bob, you added this code. Is it possible to somehow disable it when run on a kernel < 4.8?

I think the thing to do is optionally use the same key as the IGTK,
which should make it work for older kernels that are expecting GTK=IGTK.

I can cook up a patch for that tomorrow.

Bob Copeland %% http://bobcopeland.com/

from authsae.

I think that need to set mesh config file with pmf to 1. Give it a try.

On Oct 28, 2016 10:19 AM, "Bob Copeland" [email protected] wrote:

On Thu, Oct 27, 2016 at 12:42:37PM -0700, Ferry Huberts wrote:

@bcopeland Bob, you added this code. Is it possible to somehow disable
it when run on a kernel < 4.8?

I think the thing to do is optionally use the same key as the IGTK,
which should make it work for older kernels that are expecting GTK=IGTK.

I can cook up a patch for that tomorrow.

Bob Copeland %% http://bobcopeland.com/

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#50 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABBewo6DW99qez4J1AKArlyypjk0UOKXks5q4VvIgaJpZM4KiKeI
.

from authsae.

@fhuberts so I made such a patch, but I think @chunyeow's advice is better: just add pmf = 1; to the meshd section in your authsae.conf. I tried this with an older kernel (4.5) and it worked fine. Notably that kernel has the symptoms you describe without pmf=1.

What is going on here:

• older kernels require an IGTK to be configured since they use that to protect HWMP frames
• newer kernels encrypt HWMP frames with GTK
• pmf = 1 forces IGTK generation

There are some scenarios where you would want GTK=IGTK, namely if you are running a mixture of old and new authsae daemons and an old kernel (since old authsae will configure IGTK using GTK), but if you are using the new version of authsae everywhere then just setting pmf=1 should work.

from authsae.

ok, I can try that.

from authsae.

ok, pmf=1 appears to work.

thanks.

I'll open a PR later with this as example in a config file.

from authsae.

I do see that even with pmf=1 the old version is not interoperable with the new version

from authsae.

Yes, in order to make that kind of interoperability work, you can try something like this:

diff --git a/ampe.c b/ampe.c
index 852eceb..2a86149 100644
--- a/ampe.c
+++ b/ampe.c
@@ -1160,7 +1160,8 @@ int ampe_initialize(struct mesh_node *mesh)
         sae_hexdump(AMPE_DEBUG_KEYS, "mgtk: ", mgtk_tx, sizeof(mgtk_tx));

         if (mesh->conf->pmf) {
-            RAND_bytes(mesh->igtk_tx, 16);
+            // RAND_bytes(mesh->igtk_tx, 16);
+            memcpy(mesh->igtk_tx, mgtk_tx, 16);
             mesh->igtk_keyid = 4;
             memset(mesh->igtk_ipn, 0, sizeof(mesh->igtk_ipn));
             sae_hexdump(AMPE_DEBUG_KEYS, "igtk: ", mesh->igtk_tx, sizeof(mesh->igtk_tx));

from authsae.

Just wrote this: https://bobcopeland.com/blog/2016/10/encrypted-mesh-psa/ which is a somewhat more verbose explanation of the problem.

from authsae.

thanks bob

from authsae.

On 31/10/16 15:12, Bob Copeland wrote:

Yes, in order to make that kind of interoperability work, you can try
something like this:

Well, I have full control of all the nodes so I'll just update them all ;-)

from authsae.