MGTK/IGTK changes do not work

[fhuberts]

We had to back out these changes (go back to 813ec0e).

The network appears to come up but we can't get data over it, even pings do not work

[alexgrin]

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.

[fhuberts]

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

[fhuberts]

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

[fhuberts]

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

[alexgrin]

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.

[fhuberts]

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

[fhuberts]

That patch (upstream 46f6b06050b736dab4d41494dae27b883cddc365) went into 4.8

[alexgrin]

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.

[fhuberts]

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

[bcopeland]

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/

[chunyeow]

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" notifications@github.com 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
.

[bcopeland]

@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.

[fhuberts]

ok, I can try that.

[fhuberts]

ok, pmf=1 appears to work.

thanks.

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

[fhuberts]

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

[bcopeland]

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));

[bcopeland]

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

[fhuberts]

thanks bob

[fhuberts]

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 ;-)