Showing results for 
Search instead for 
Did you mean: 

MKA, MACsec Key Agreement Exchange, on the wire


This document will contain a number of MACsec specific terms,  please see the History & Terminology document I wrote for a detailed understanding. I also encourage you to Click Helpful, if this is helpful or to comment if you have questions or concerns!



When establishing a MACsec session, MACsec Key Agreement (MKA) will exchange EAPoL-MKA frames between switches, the switches will process the frames but will not forward them. Those EAPoL frames contain the CKN of the sender, key server priority, and the MACsec capabilities. MKA occurs in the control plane of the device.  



Network Diagram

In this example we will be using two Cisco Catalyst 9200 switches, both run IOS XE 17.3(1). Both switches are configured for MKA Pre Shared Key, also known as Static CKN. MAC Addresses shown are the burned-in addresses on the Interface.




Frame Summary

Here is an overview of the frames in the exchange.

Frames 1, 2, 3, 4, 5 are all part of the MACsec Key Agreement Exchange (MKA).   Frames numbered 6, 8 are MACsec keepalives.





Key Server Election

Key servers are selected based on key server priority. The device with the lowest priority is the one that will become the key server.  If no value is configured IOS XE 17.3 on my Catalyst 9200 uses a priority of zero (0). In the event that both devices have the same priority the device with the lowest SCI will become the key server. The SCI is the MAC Address of the interface concatenated with the virtual port id.



Keys, Generation, and Usage

If you read my MACsec History and Terminology you see that MACsec uses a lot of keys, CAK, SAK, ICK, KEK etc…. Here I will try and explain how these are used.


First, the Connectivity Association Key (CAK) and the Secure Association Key (SAK) have no connection to each other.





Frame 1

Bot-Sw -> Well Known EAP MAC Address


The switchport is configured for MACsec and as such the first frame that is sent once the link is up is EAPoL. You will see in all the frames that the destination MAC address is the well-known EAP MAC Address 01:80:C2:00:00:03.  


The Key Agreement section includes Key Server Priority, Key Server status, Secure Channel Identifier (SCI), Member Identifier (MI), Member Number (MN) and the Connectivity Association Key Name (CKN). 


All MACsec \ MKA frames can include an Integrity Check Value Indicator (ICV). The ICV is validated with the Connectivity Association Key (CAK). ICV in MKPDU us optional.  ICV is required when traffic is encrypted.  


A few things to note, with every new EAPoL frame the Member Number is incremented by one, the SCI is just the source MAC address plus the Port Number. 





Frame 2

Top-Sw -> Well Known EAP MAC Address


Similar to Frame 1, this is the first frame this switch sends after it detects Link Up.  It contains the same attributes except these are specific to the local switch.



Frame 3

Bot-Sw -> Well Known EAP MAC Address


At this point both switches know each others Key Server Priority and since Bot-Sw has a lower priority it has become the Key Server. In this Frame we see that Bot-Sw still stating Key Server = True.  


We also see the Actor MN incrementing to 2.






Frame 4

Top-Sw -> Well Known EAP MAC Address


In this frame we see the Top-Sw acknowledging it has lost the Key Server election and therefore it is advertising Key Server = False.


Here we see this switch also increment the Actor MN to 2. With each new EAPoL message the switch will increment the MN by 1.



Frame 5

Bot-Sw -> Well Known EAP MAC Address


In this Frame the Key Server distributes the SAK to the Peer Member. The Key Server performs an AES Key Wrap function on the SAK before distributing it so that the encryption key is not sent in clear text.


After this frame the two switches are able to transmit data across a secure link.