PSK and certificate-based authentication

Choose the trust mechanism

R1 and R2 need a common basis for trusting MKA participation. With PSK MKA, an operator provisions matching CAK and CKN at the peers. No EAP-TLS handshake or RADIUS server is required merely because MKA is used. With certificate-based EAP authentication, validated credentials establish identity and keying material before MKA installs traffic keys.

A certificate does not encrypt Ethernet payloads directly. Nor does an 802.1X “Authorized” status automatically prove that confidentiality is active.

Follow the EAP-to-MKA sequence

1. The supplicant presents its identity using EAP-TLS over EAPOL on the local link. The authenticator can relay EAP to an authentication server using RADIUS.
2. The EAP-TLS endpoints validate the relevant certificate chains and expected identities. Certificate validity, usage, trust and revocation policy matter, not merely the presence of a certificate file.
3. Successful EAP authentication exports master session key material. The supported 802.1X/MACsec procedure derives association key material and identifies the resulting association.
4. MKA authenticates participation, elects a key server and distributes SAKs. MACsec can then protect the controlled data traffic.

The authenticator is not necessarily the EAP-TLS server: in pass-through mode the AAA server terminates EAP. Local EAP and direct device authentication are separate platform-supported designs. Do not mix their configuration with a RADIUS-based design. The CA signs certificates; it is also a distinct role from the authentication server.

Inspect a PSK credential

The following global fragment is the credential portion of the complete protected-link recipe. The identifier is hex 01, the CAK is 128 bits, and both peers need the same values. The key-chain's local name can differ.

configure terminal
key chain LINK-KEY macsec
 key 01
  cryptographic-algorithm aes-128-cmac
  key-string 8c40a71d25f6913b70e2c94a56d809be
end

Replace the example secret before deployment. The CKN is not a second password, and AES-128-CMAC here is the MKA authentication algorithm rather than the data-plane GCM cipher. A 256-bit deployment needs compatible authentication/key sizes, cipher support and licensing; changing one number is insufficient.

Prepare and bind certificate authentication

For the scoped certificate-based switch-to-switch design, prepare CA enrollment, trusted authentication-server identity, unique device certificates/private keys, working clock synchronization, reachable AAA and revocation services, and policies authorizing MACsec keying. Configure both authenticator and supplicant roles as required by the selected network-link design. Enrollment is interactive and site-specific: verify the CA fingerprint through a trusted channel, submit a CSR, install the issued certificate and test its chain before enabling the protected port.

This interface binding fragment assumes the site's tested AAA/802.1X control policy, enrolled LINK-CERT credentials profile and LINK-TLS EAP-TLS profile already exist. It is an authentication binding example, not a replacement for those prerequisite policies. Apply it to a separate certificate-based test link, not on top of the PSK example.

configure terminal
interface TenGigabitEthernet1/0/1
 dot1x pae both
 dot1x credentials LINK-CERT
 dot1x supplicant eap profile LINK-TLS
 macsec access-control must-secure
 macsec network-link
end

The credential profile selects the enrolled trustpoint and local identity; the EAP profile selects TLS and its trustpoint. The site's access-session/control policy must keep unauthenticated data closed and invoke authentication. Follow the linked platform procedure for that policy rather than borrowing a host-access or local-EAP policy unchanged.

Verify each stage separately

R1# show crypto pki certificates LINK-CA
Certificate
 Status: Available
 Subject:
  cn=R1.example.test
 Validity Date:
  start date: 00:00:00 UTC Oct 1 2027
  end date: 00:00:00 UTC Oct 1 2028

For this example the test clock is inside the displayed validity interval. “Available” means installed, not necessarily trusted by the authentication server. Verify identity policy, chain and revocation handling separately.

R1# show access-session interface TenGigabitEthernet1/0/1 details
Interface: TenGigabitEthernet1/0/1
User-Name: R2.example.test
Status: Authorized

R1# show mka sessions
Total MKA Sessions....... 1
 Secured Sessions... 1
 Pending Sessions... 0

Authorization plus a secured MKA session shows the two stages progressed. Finally check MACsec confidentiality, active receive/transmit associations and protected traffic counters. If EAP fails due to an expired certificate, renew the credential and restore trust; if EAP succeeds but MKA remains pending, investigate the keying/policy stage instead of changing the CA blindly.