MKA and key lifecycle

Assign each key a job

Use the same direct R1–R2 link, with one peer elected key server. A connectivity association is the group of participants sharing a CAK. Each sender has its own unidirectional secure channel; changing its traffic key creates a new secure association, identified by an association number.

MKA is carried by EAPOL, not by a TCP session or routed neighbor adjacency. Its messages are authenticated using derived integrity material. The SAK is wrapped for distribution. MACsec data-frame encryption does not need to enclose the MKA messages that establish that encryption.

Establish and replace the SAK

1. Peers with matching active association credentials exchange authenticated MKA messages and establish live membership.
2. MKA elects a key server. Election resolves the key-distribution role; a lower configured eligible priority is preferred in the scoped PSK implementation, with tie-breaking defined by MKA.
3. The server generates a SAK and announces it with key-identifying information. Receivers unwrap and install it.
4. Participants coordinate receive/transmit use so a transition can retain the previous association while the new one becomes usable.
5. Later SAK replacement avoids packet-number exhaustion and serves key-management policy. The association number alone is not a globally unique key identity: it can be reused with later keys.

Do not reset a packet number under an unchanged key to “repair” a session. Cryptographic uniqueness depends on key and packet-number rules. A change in key server may trigger new key-management activity but is not equivalent to a physical-link failure. Verify the resulting state and data counters.

Rotate the CAK separately

A SAK rekey does not remove a compromised CAK. Rotate long-term credentials separately, installing the same new secret and identifier at both ends. Store them securely and remove the retired credential only after both peers have moved. An optional fallback key is still a secret credential, not permission to send cleartext; retaining it indefinitely retains trust in that credential.

This example schedule uses device-local time in an agreed time zone. Set the clock/NTP first and adapt the dates before use. The two CAK lifetimes overlap from 00:00 to 00:10 on 1 November 2027. Start with this two-key schedule provisioned on both devices; do not blindly replace a live unlimited lifetime using sample dates.

configure terminal
key chain LINK-KEY macsec
 key 01
  cryptographic-algorithm aes-128-cmac
  key-string 8c40a71d25f6913b70e2c94a56d809be
  lifetime local 00:00:00 Oct 1 2027 00:10:00 Nov 1 2027
 exit
 key 02
  cryptographic-algorithm aes-128-cmac
  key-string 71d98a0643be2fc5801a6d39c4e7b205
  lifetime local 00:00:00 Nov 1 2027 infinite
end

The published hex strings are teaching values, not deployable secrets. Use distinct random CAKs of the required length, distribute them through an approved secret channel, and keep synchronized time. Platform-supported rollover can avoid a break when both peers possess the next key in time; it is not a guarantee for an untested mixed-vendor or unsynchronized pair.

Read the transition evidence

R1# show mka sessions interface TenGigabitEthernet1/0/1 detail
Status: SECURED - Secured MKA Session with MACsec
Key Server............... YES
Latest SAK Status........ Rx & Tx
Latest SAK AN............ 1
Old SAK Status........... Rx

The current SAK is installed for both directions and an old association remains receive-capable during transition. This excerpt does not prove which CAK is active. At the scheduled CAK rollover, also inspect the session's CKN, then verify protected traffic continues at both ends.

R1# show mka statistics interface TenGigabitEthernet1/0/1
SA Statistics
 SAKs Generated.......... 2
 SAKs Rekeyed............ 1
 SAK Responses Received.. 2

These are cumulative local counters. Record before/after values and correlate with the key identity and time; do not infer a failure merely because a key server generates keys while its peer receives them. If the new credential is absent or inactive at one end, restore a common valid credential using management access rather than enabling unsecured forwarding.