PDF(1.8 MB) View with Adobe Reader on a variety of devices
ePub(1.9 MB) View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle)(1.6 MB) View on Kindle device or Kindle app on multiple devices
Updated:August 10, 2023
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the way in which you can configure MACsec encryption in an endpoint using Secure Client 5 as supplicant.
Cisco recommends knowledge in these topics:
Identity Services Engine
802.1x and Radius
MACsec MKA encryption
Secure Client version 5 (Formerly known as Anyconnect)
The information in this document is based on these software and hardware versions:
Identity Services Engine (ISE) version 3.3
Catalyst 9300 version 17.06.05
Cisco Secure Client 5.0.4032
MACSec (Media Access Control Security) is a network security standard that provides encryption and protection for Ethernet frames at layer 2 of the OSI model (Data Link), defined by the IEEE as a standard denominated 802.1AE.
MACSec supplies this encryption in a point-to-point connection that can be switch-to-switch or switch-to-host connections, hence the coverage of this standard is limited to wired connections.
This standard encrypts the entire data except for the Source and Destination MAC address of frames that are transmitted in a layer 2 connection.
The MACsec Key Agreement (MKA) protocol is the mechanism from where MACsec peers are going to negotiate the security keys that are needed to secure the link.
Note: This documentation considers that you have already a set-up of rules configured and working for Radius Authentication for the PCs devices and the Cisco IP phone. To setup a configuration from scratch, please refer to ISE Secure Wired Access Prescriptive Deployment Guide to review the configuration in Identity Services Engine and Switch for Identity-Based Network Access.
Setup of policies on ISE
The first task is to configure the corresponding authorization profiles that are applied for both PCs displayed in the preceding diagram (as well as the Cisco IP Phone).
In this hypothetical scenario, the PCs are going to use 802.1X protocol as the authentication method and the Cisco IP Phone uses Mac Address Bypass (MAB).
ISE communicates with the switch through Radius protocol about the attributes that the switch needs to enforce in the interface from where the endpoint is connected through a Radius session.
For MACsec encryption in hosts, the attribute required is cisco-av-pair = linksec-policy, which has these 3 possible values:
Should-not-Secure: The switch does not perform MKA encryption in the interface where the Radius session is happening.
Must-Secure: The switch needs to enforce encryption in the traffic linked with the Radius session, if the MKA session fails or has a timeout the connection is considered as authorization failure, there is a retrial of MKA session establishment.
Should-Secure: The switch attempts to perform MKA encryption, if the MKA session linked to the Radius session is successful the traffic is encrypted, if the MKA fails or times out, the switch allows that unencrypted traffic linked to that Radius session.
Step 1. As considered in the previous information, in both PCs you can enforce a should-secure MKA policy to have flexibility in case a machine with no MKA capabilities connects to the interface Ten 1/0/1.
As an option you can configure a policy for PC2 that enforces a must-secure policy.
In this example configure the policy for the PCs as in Policy > Policy Elements > Results > Authorization Profiles then +Add or Edit an existing profile
Step 2. Complete or customize the fields required for the profile.
Ensure that in Common Tasks you have selected MACSec Policy and the corresponding policy to apply.
Scroll down and Save the configuration.
Step 3. Assign the corresponding authorization profile to the authorization rules that are hit by the devices.
This action needs to be done in Policy > Policy Sets > (Select Policy Set assigned) > Authorization Policy.
Associate the authorization rule with the authorization profile with MACsec Settings. Scroll down Save your configuration.
Setup of MKA in Catalyst 9300
Step 1. Configure a new MKA policy as this example suggests:
! mka policy MKA_PC key-server priority 0 no delay-protection macsec-cipher-suite gcm-aes-128 confidentiality-offset 0 sak-rekey on-live-peer-loss sak-rekey interval 0 no send-secure-announcements no include-icv-indicator no use-updated-eth-header no ssci-based-on-sci !
Step 2. Enable MACsec encryption in the interface where the PCs are connected.
These are debugs of one successfull MKA connection to a host. You can use this as a reference comes up :
%LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/1, changed state to down Macsec interface TenGigabitEthernet1/0/1 is UP MKA-EVENT: Create session event: derived CKN 9F0DC198A9728FB3DA198711B58570E4, len 16 MKA-EVENT EC000025: SESSION START request received... NGWC-MACSec: pd get port capability is invoked MKA-EVENT: New MKA Session on Interface TenGigabitEthernet1/0/1 with Physical Port Number 9 is using the "MKA_PC" MKA Policy, and has MACsec Capability "MACsec Integrity, Confidentiality, & Offset" with Local MAC ac7a.5646.4d01, Peer MAC bc4a.5602.ac25. MKA-EVENT: New VP with SCI AC7A.5646.4D01/0002 on interface TenGigabitEthernet1/0/1 MKA-EVENT: Created New CA 0x80007F30A6B46F20 Participant on interface TenGigabitEthernet1/0/1 with SCI AC7A.5646.4D01/0002 for Peer MAC bc4a.5602.ac25. %MKA-5-SESSION_START: (Te1/0/1 : 2) MKA Session started for RxSCI bc4a.5602.ac25/0000, AuditSessionID C5AA580A00000046CE64E059, AuthMgr-Handle EC000025 MKA-EVENT: Started a new MKA Session on interface TenGigabitEthernet1/0/1 for Peer MAC bc4a.5602.ac25 with SCI AC7A.5646.4D01/0002 successfully. MKA-EVENT bc4a.5602.ac25/0000 EC000025: FSM (Init MKA Session) - Successfully derived CAK. MKA-EVENT bc4a.5602.ac25/0000 EC000025: Successfully initialized a new MKA Session (i.e. CA entry) on interface TenGigabitEthernet1/0/1 with SCI AC7A.5646.4D01/0002 and CKN 9F0DC198... MKA-EVENT bc4a.5602.ac25/0000 EC000025: FSM (Derive KEK/ICK) - Successfully derived KEK... MKA-EVENT bc4a.5602.ac25/0000 EC000025: FSM (Derive KEK/ICK) - Successfully derived ICK... MKA-EVENT bc4a.5602.ac25/0000 EC000025: New Live Peer detected, No potential peer so generate the first SAK. MKA-EVENT bc4a.5602.ac25/0000 EC000025: >> FSM - Generate SAK for CA with CKN 9F0DC198 (Latest AN=0, Old AN=0)... MKA-EVENT bc4a.5602.ac25/0000 EC000025: Generation of new Latest SAK succeeded (Latest AN=0, KN=1)... MKA-EVENT bc4a.5602.ac25/0000 EC000025: >> FSM - Install RxSA for CA with CKN 9F0DC198 on VP with SCI AC7A.5646.4D01/0002 (Latest AN=0)... MKA-EVENT bc4a.5602.ac25/0000 EC000025: Clean up the Rx for dormant peers MACSec-IPC: send_xable send msg success for switch=1 MACSec-IPC: blocking enable disable ipc req MACSec-IPC: watched boolean waken up MACSec-IPC: geting switch number MACSec-IPC: switch number is 1 MACSec-IPC: create_tx_sc send msg success Send create_tx_sc to IOMD successfully alloc_cache called TxSCI: AC7A56464D010002 RxSCI: BC4A5602AC250000 Enabling replication for slot 1 vlan 330 and the ref count is 1 MACSec-IPC: vlan_replication send msg success Added replication for data vlan 330 MACSec-IPC: geting switch number MACSec-IPC: switch number is 1 MACSec-IPC: create_rx_sc send msg success Sent RXSC request to FED/IOMD MACSec-IPC: geting switch number MACSec-IPC: switch number is 1 MACSec-IPC: install_rx_sa send msg success Sent ins_rx_sa to FED and IOMD MKA-EVENT bc4a.5602.ac25/0000 EC000025: Requested to install/enable new RxSA successfully (AN=0, KN=1 SCI=BC4A.5602.AC25/0000) %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/1, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan330, changed state to up MKA-EVENT bc4a.5602.ac25/0000 EC000025: Sending SAK for AN 0 resp peers 0 cap peers 1 MKA-EVENT bc4a.5602.ac25/0000 EC000025: SAK Wait Timer started for 6 seconds. MKA-EVENT bc4a.5602.ac25/0000 EC000025: (KS) Received new SAK-Use response to Distributed SAK for AN 0, KN 1, Latest Key MI 9B0F8380A5697DD4C3D50E42.CKN 9F0DC198 MKA-EVENT bc4a.5602.ac25/0000 EC000025: (KS) All 1 peers with the required MACsec Capability have indicated they are receiving using the new Latest SAK - install/enable TxSA for AN 0, KN 1, Latest Key MI 9B0F8380A5697DD4C3D50E42. MKA-EVENT: Reqd to Install TX SA for CA 0x80007F30A6B46F20 AN 0 CKN 9F0DC198 - on int(TenGigabitEthernet1/0/1)... MKA-EVENT bc4a.5602.ac25/0000 EC000025: >> FSM - Install TxSA for CA with CKN 9F0DC198 on VP with SCI AC7A.5646.4D01/0002 (Latest AN=0)... MACSec-IPC: geting switch number MACSec-IPC: switch number is 1 MACSec-IPC: install_tx_sa send msg success MKA-EVENT bc4a.5602.ac25/0000 EC000025: Before sending SESSION_SECURED status - SECURED=false, PREVIOUSLY_SECURED=false, SAK_REKEY=false, CAK_REKEY=false, OLD_CA=false, NEW_CA=false, CKN=9F0DC198... MKA-EVENT bc4a.5602.ac25/0000 EC000025: Successfully sent SECURED status for CA with CKN 9F0DC198. MKA-EVENT: Successfully updated the CKN handle for interface: TenGigabitEthernet1/0/1 with 9F0DC198 (if_num: 9). %MKA-5-SESSION_SECURED: (Te1/0/1 : 2) MKA Session was secured for RxSCI bc4a.5602.ac25/0000, AuditSessionID C5AA580A00000046CE64E059, CKN 9F0DC198A9728FB3DA198711B58570E4 MKA-EVENT: MSK found to be same while updating the MSK and EAP Session ID in the subblock MKA-EVENT bc4a.5602.ac25/0000 EC000025: After sending SESSION_SECURED status - SECURED=true, PREVIOUSLY_SECURED=true, SAK_REKEY=false, CAK_REKEY=false, OLD_CA=false, NEW_CA=false, CKN=9F0DC198...
Identity Services Engine (ISE) Troubleshooting
The troubleshooting related to this feature is limited to the delivery of the cisco-av-pair attribute linksec-policy=should-secure.
Ensure that the authorization result is sending that information to the Radius session linked to the switchports where the devices are being connected.