Key server election on peer-to-peer MACsec with MKA

Emond Papegaaij emond.papegaaij at
Fri Sep 18 15:21:38 EDT 2020

On Fri, Sep 18, 2020 at 8:52 PM Michael Siedzik
<msiedzik at> wrote:
> A couple of months ago Mickael Chazaux posted a thread on this very topic:
> So it looks like the existing code is incorrectly handling key server elections with more than two peers, and GroupCAs in general.  Mickael was on the right track with his attempted patches, but additional work and testing of 3-peer networks is required.  Part of his solution was to remove parameter block failures in certain circumstances.

This matches with what I observed. It seems GroupCAs were never fully
implemented in wpa_supplicant.

>  The problem is certainly fixable but it will take an in-depth knowledge of IEEE802.X-2010 and a some knowledge of C.

Yes, it seems the basic principles are in place. However, I'm not a
very good C programmer. I've been doing mostly Java for the past 20
years. Also, I'm not that much at home in network infrastructure
terminology, which makes the IEEE802.X-2010 spec very hard to read.
This makes it very hard for me to try to fix these issues. We also ran
into another problem with the 2-peer network: when wpa_supplicant is
restarted, it causes the entire routing table for both the macsec
*and* the underlying ethernet link to be dropped. This was on CentOS
7, with a rather old version of wpa_supplicant, so the behavior may be
different with newer versions. This additional problem did however
cause us to decide to abandon the macsec route. We are now going to
set up a wireguard network between the peers. I did like the
macsec/wpa_supplicant solution because of simplicity and elegance, but
the issues we had were too difficult for us to fix and we have a
limited timeframe to get this all working. Thanks for the help and
insight anyway!

Best regards,
Emond Papegaaij

More information about the Hostap mailing list