Information About MACsec Encryption
MACsec is the IEEE 802.1AE standard for authenticating and encrypting packets between two MACsec-capable devices. These Catalyst switches support 802.1AE encryption with MACsec Key Agreement (MKA) on downlink ports for encryption between the switch and host device. The switch also supports MACsec encryption for switch-to-switch (inter-network device) security using both Cisco TrustSec Network Device Admission Control (NDAC), Security Association Protocol (SAP) and MKA-based key exchange protocol.
Link layer security can include both packet authentication between switches and MACsec encryption between switches (encryption is optional).
Note |
MACsec is not supported with the NPE license or the LAN Base service image. |
Interface |
Connections |
MACsec support |
Downlink ports |
Switch-to-host |
MACsec MKA encryption |
Uplink ports |
Switch-to-switch |
MACsec MKA encryption Cisco TrustSec NDAC MACsec |
Cisco TrustSec and Cisco SAP are meant only for switch-to-switch links and are not supported on switch ports connected to end hosts, such as PCs or IP phones. MKA is supported on switch-to-host facing links (downlink) as well as switch-to-switch links (uplink). Host-facing links typically use flexible authentication ordering for handling heterogeneous devices with or without IEEE 802.1x, and can optionally use MKA-based MACsec encryption. Cisco NDAC and SAP are mutually exclusive with Network Edge Access Topology (NEAT), which is used for compact switches to extend security outside the wiring closet.
Note |
We do not recommend enabling both Cisco TrustSec SAP and uplink MKA at the same time on any interface. |
Media Access Control Security and MACsec Key Agreement
MACsec, defined in 802.1AE, provides MAC-layer encryption over wired networks by using out-of-band methods for encryption keying. The MACsec Key Agreement (MKA) Protocol provides the required session keys and manages the required encryption keys. MKA and MACsec are implemented after successful authentication using the 802.1x Extensible Authentication Protocol (EAP-TLS) or Pre Shared Key (PSK) framework.
A switch using MACsec accepts either MACsec or non-MACsec frames, depending on the policy associated with the MKA peer. MACsec frames are encrypted and protected with an integrity check value (ICV). When the switch receives frames from the MKA peer, it decrypts them and calculates the correct ICV by using session keys provided by MKA. The switch compares that ICV to the ICV within the frame. If they are not identical, the frame is dropped. The switch also encrypts and adds an ICV to any frames sent over the secured port (the access point used to provide the secure MAC service to a MKA peer) using the current session key.
The MKA Protocol manages the encryption keys used by the underlying MACsec protocol. The basic requirements of MKA are defined in 802.1x-REV. The MKA Protocol extends 802.1x to allow peer discovery with confirmation of mutual authentication and sharing of MACsec secret keys to protect data exchanged by the peers.
The EAP framework implements MKA as a newly defined EAP-over-LAN (EAPOL) packet. EAP authentication produces a master session key (MSK) shared by both partners in the data exchange. Entering the EAP session ID generates a secure connectivity association key name (CKN). The switch acts as the authenticator for both uplink and downlink; and acts as the key server for downlink. It generates a random secure association key (SAK), which is sent to the client partner. The client is never a key server and can only interact with a single MKA entity, the key server. After key derivation and generation, the switch sends periodic transports to the partner at a default interval of 2 seconds.
Note |
Integrity check value (ICV) indicator in MKPDU is optional. ICV is not optional when the traffic is encrypted. |
EAPoL Announcements indicate the use of the type of keying material. The announcements can be used to announce the capability of the supplicant as well as the authenticator. Based on the capability of each side, the largest common denominator of the keying material could be used.
Note |
Must-secure mode is enabled by default. |
MKA Policies
To enable MKA on an interface, a defined MKA policy should be applied to the interface. You can configure these options:
-
Policy name, not to exceed 16 ASCII characters.
-
Confidentiality (encryption) offset of 0, 30, or 50 bytes for each physical interface
Virtual Ports
Use virtual ports for multiple secured connectivity associations on a single physical port. Each connectivity association (pair) represents a virtual port. In uplink, you can have only one virtual port per physical port. In downlink, you can have a maximum of two virtual ports per physical port, of which one virtual port can be part of a data VLAN; the other must externally tag its packets for the voice VLAN. You cannot simultaneously host secured and unsecured sessions in the same VLAN on the same port. Because of this limitation, 802.1x multiple authentication mode is not supported.
The exception to this limitation is in multiple-host mode when the first MACsec supplicant is successfully authenticated and connected to a hub that is connected to the switch. A non-MACsec host connected to the hub can send traffic without authentication because it is in multiple-host mode. We do not recommend using multi-host mode because after the first successful client, authentication is not required for other clients.
Virtual ports represent an arbitrary identifier for a connectivity association and have no meaning outside the MKA Protocol. A virtual port corresponds to a separate logical port ID. Valid port IDs for a virtual port are 0x0002 to 0xFFFF. Each virtual port receives a unique secure channel identifier (SCI) based on the MAC address of the physical interface concatenated with a 16-bit port ID.
MACsec and Stacking
A switch active switch running MACsec maintains the configuration files that show which ports on a member switch support MACsec. The active switch performs these functions:
-
Processes secure channel and secure association creation and deletion
-
Sends secure association service requests to the member switches.
-
Processes packet number and replay-window information from local or remote ports and notifies the key management protocol.
-
Sends MACsec initialization requests with the globally configured options to new switches that are added to the stack.
-
Sends any per-port configuration to the member switches.
A member switch performs these functions:
-
Processes MACsec initialization requests from the active switch.
-
Processes MACsec service requests sent by the active switch.
-
Sends information about local ports to the active switch.
MACsec, MKA and 802.1x Host Modes
You can use MACsec and the MKA Protocol with 802.1x single-host mode, multi-host mode, or Multi Domain Authentication (MDA) mode. Multiple authentication mode is not supported.
Single-Host Mode
The figure shows how a single EAP authenticated session is secured by MACsec by using MKA
Multiple Host Mode
In standard (not 802.1x REV) 802.1x multiple-host mode, a port is open or closed based on a single authentication. If one user, the primary secured client services client host, is authenticated, the same level of network access is provided to any host connected to the same port. If a secondary host is a MACsec supplicant, it cannot be authenticated and traffic would not flow. A secondary host that is a non-MACsec host can send traffic to the network without authentication because it is in multiple-host mode. The figure shows MACsec in Standard Multiple-Host Unsecure Mode.
Note |
Multi-host mode is not recommended because after the first successful client, authentication is not required for other clients, which is not secure. |
In standard (not 802.1x REV) 802.1x multiple-domain mode, a port is open or closed based on a single authentication. If the primary user, a PC on data domain, is authenticated, the same level of network access is provided to any domain connected to the same port. If a secondary user is a MACsec supplicant, it cannot be authenticated and traffic would no flow. A secondary user, an IP phone on voice domain, that is a non-MACsec host, can send traffic to the network without authentication because it is in multiple-domain mode.
MKA Statistics
Some MKA counters are aggregated globally, while others are updated both globally and per session. You can also obtain information about the status of MKA sessions.
This is an example of the show mka sessions command output:
Device# show mka sessions
Total MKA Sessions....... 1
Secured Sessions... 1
Pending Sessions... 0
====================================================================================================
Interface Local-TxSCI Policy-Name Inherited Key-Server
Port-ID Peer-RxSCI MACsec-Peers Status CKN
====================================================================================================
Gi1/0/1 204c.9e85.ede4/002b p2 NO YES
43 c800.8459.e764/002a 1 Secured 0100000000000000000000000000000000000000000000000000000000000000
Device# show mka sessions interface G1/0/1
Summary of All Currently Active MKA Sessions on Interface GigabitEthernet1/0/1...
====================================================================================================
Interface Local-TxSCI Policy-Name Inherited Key-Server
Port-ID Peer-RxSCI MACsec-Peers Status CKN
====================================================================================================
Gi1/0/1 204c.9e85.ede4/002b p2 NO YES
43 c800.8459.e764/002a 1 Secured 0100000000000000000000000000000000000000000000000000000000000000
Device# show mka sessions interface G1/0/1 de
MKA Detailed Status for MKA Session
===================================
Status: SECURED - Secured MKA Session with MACsec
Local Tx-SCI............. 204c.9e85.ede4/002b
Interface MAC Address.... 204c.9e85.ede4
MKA Port Identifier...... 43
Interface Name........... GigabitEthernet1/0/1
Audit Session ID.........
CAK Name (CKN)........... 0100000000000000000000000000000000000000000000000000000000000000
Member Identifier (MI)... D46CBEC05D5D67594543CEAE
Message Number (MN)...... 89567
EAP Role................. NA
Key Server............... YES
MKA Cipher Suite......... AES-128-CMAC
Latest SAK Status........ Rx & Tx
Latest SAK AN............ 0
Latest SAK KI (KN)....... D46CBEC05D5D67594543CEAE00000001 (1)
Old SAK Status........... FIRST-SAK
Old SAK AN............... 0
Old SAK KI (KN).......... FIRST-SAK (0)
SAK Transmit Wait Time... 0s (Not waiting for any peers to respond)
SAK Retire Time.......... 0s (No Old SAK to retire)
MKA Policy Name.......... p2
Key Server Priority...... 2
Delay Protection......... NO
Replay Protection........ YES
Replay Window Size....... 0
Confidentiality Offset... 0
Algorithm Agility........ 80C201
Send Secure Announcement.. DISABLED
SAK Cipher Suite......... 0080C20001000001 (GCM-AES-128)
MACsec Capability........ 3 (MACsec Integrity, Confidentiality, & Offset)
MACsec Desired........... YES
# of MACsec Capable Live Peers............ 1
# of MACsec Capable Live Peers Responded.. 1
Live Peers List:
MI MN Rx-SCI (Peer) KS Priority
----------------------------------------------------------------------
38046BA37D7DA77E06D006A9 89555 c800.8459.e764/002a 10
Potential Peers List:
MI MN Rx-SCI (Peer) KS Priority
----------------------------------------------------------------------
Dormant Peers List:
MI MN Rx-SCI (Peer) KS Priority
----------------------------------------------------------------------
Device# show mka sessions detail
MKA Detailed Status for MKA Session
===================================
Status: SECURED - Secured MKA Session with MACsec
Local Tx-SCI............. 204c.9e85.ede4/002b
Interface MAC Address.... 204c.9e85.ede4
MKA Port Identifier...... 43
Interface Name........... GigabitEthernet1/0/1
Audit Session ID.........
CAK Name (CKN)........... 0100000000000000000000000000000000000000000000000000000000000000
Member Identifier (MI)... D46CBEC05D5D67594543CEAE
Message Number (MN)...... 89572
EAP Role................. NA
Key Server............... YES
MKA Cipher Suite......... AES-128-CMAC
Latest SAK Status........ Rx & Tx
Latest SAK AN............ 0
Latest SAK KI (KN)....... D46CBEC05D5D67594543CEAE00000001 (1)
Old SAK Status........... FIRST-SAK
Old SAK AN............... 0
Old SAK KI (KN).......... FIRST-SAK (0)
SAK Transmit Wait Time... 0s (Not waiting for any peers to respond)
SAK Retire Time.......... 0s (No Old SAK to retire)
MKA Policy Name.......... p2
Key Server Priority...... 2
Delay Protection......... NO
Replay Protection........ YES
Replay Window Size....... 0
Confidentiality Offset... 0
Algorithm Agility........ 80C201
SAK Cipher Suite......... 0080C20001000001 (GCM-AES-128)
MACsec Capability........ 3 (MACsec Integrity, Confidentiality, & Offset)
MACsec Desired........... YES
# of MACsec Capable Live Peers............ 1
# of MACsec Capable Live Peers Responded.. 1
Live Peers List:
MI MN Rx-SCI (Peer) KS Priority
----------------------------------------------------------------------
38046BA37D7DA77E06D006A9 89560 c800.8459.e764/002a 10
Potential Peers List:
MI MN Rx-SCI (Peer) KS Priority
----------------------------------------------------------------------
Dormant Peers List:
MI MN Rx-SCI (Peer) KS Priority
----------------------------------------------------------------------
Device# show mka policy
MKA Policy Summary...
Policy KS Delay Replay Window Conf Cipher Interfaces
Name Priority Protect Protect Size Offset Suite(s) Applied
======================================================================================================
*DEFAULT POLICY* 0 FALSE TRUE 0 0 GCM-AES-128
p1 1 FALSE TRUE 0 0 GCM-AES-128
p2 2 FALSE TRUE 0 0 GCM-AES-128 Gi1/0/1
Device# show mka policy p2 detail
MKA Policy Configuration ("p2")
========================
MKA Policy Name........ p2
Key Server Priority.... 2
Confidentiality Offset. 0
Send Secure Announcement..DISABLED
Cipher Suite(s)........ GCM-AES-128
Applied Interfaces...
GigabitEthernet1/0/1
This is an example of the show mka statistics command output:
Device# show mka statistics interface G1/0/1
MKA Statistics for Session
==========================
Reauthentication Attempts.. 0
CA Statistics
Pairwise CAKs Derived... 0
Pairwise CAK Rekeys..... 0
Group CAKs Generated.... 0
Group CAKs Received..... 0
SA Statistics
SAKs Generated.......... 1
SAKs Rekeyed............ 0
SAKs Received........... 0
SAK Responses Received.. 1
MKPDU Statistics
MKPDUs Validated & Rx... 89585
"Distributed SAK".. 0
"Distributed CAK".. 0
MKPDUs Transmitted...... 89596
"Distributed SAK".. 1
"Distributed CAK".. 0
Device# show mka summary
Total MKA Sessions....... 1
Secured Sessions... 1
Pending Sessions... 0
====================================================================================================
Interface Local-TxSCI Policy-Name Inherited Key-Server
Port-ID Peer-RxSCI MACsec-Peers Status CKN
====================================================================================================
Gi1/0/1 204c.9e85.ede4/002b p2 NO YES
43 c800.8459.e764/002a 1 Secured 0100000000000000000000000000000000000000000000000000000000000000
MKA Global Statistics
=====================
MKA Session Totals
Secured.................... 1
Reauthentication Attempts.. 0
Deleted (Secured).......... 0
Keepalive Timeouts......... 0
CA Statistics
Pairwise CAKs Derived...... 0
Pairwise CAK Rekeys........ 0
Group CAKs Generated....... 0
Group CAKs Received........ 0
SA Statistics
SAKs Generated............. 1
SAKs Rekeyed............... 0
SAKs Received.............. 0
SAK Responses Received..... 1
MKPDU Statistics
MKPDUs Validated & Rx...... 89589
"Distributed SAK"..... 0
"Distributed CAK"..... 0
MKPDUs Transmitted......... 89600
"Distributed SAK"..... 1
"Distributed CAK"..... 0
MKA Error Counter Totals
========================
Session Failures
Bring-up Failures................ 0
Reauthentication Failures........ 0
Duplicate Auth-Mgr Handle........ 0
SAK Failures
SAK Generation................... 0
Hash Key Generation.............. 0
SAK Encryption/Wrap.............. 0
SAK Decryption/Unwrap............ 0
SAK Cipher Mismatch.............. 0
CA Failures
Group CAK Generation............. 0
Group CAK Encryption/Wrap........ 0
Group CAK Decryption/Unwrap...... 0
Pairwise CAK Derivation.......... 0
CKN Derivation................... 0
ICK Derivation................... 0
KEK Derivation................... 0
Invalid Peer MACsec Capability... 0
MACsec Failures
Rx SC Creation................... 0
Tx SC Creation................... 0
Rx SA Installation............... 0
Tx SA Installation............... 0
MKPDU Failures
MKPDU Tx......................... 0
MKPDU Rx Validation.............. 0
MKPDU Rx Bad Peer MN............. 0
MKPDU Rx Non-recent Peerlist MN.. 0
Information About MACsec MKA using EAP-TLS
MACsec MKA is supported on switch-to-switch links. Using IEE 802.1X Port-based Authentication with Extensible Authentication Protocol (EAP-TLS), you can configure MACsec MKA between device uplink ports. EAP-TLS allows mutual authentication and obtains an MSK (master session key) from which the connectivity association key (CAK) is derived for MKA operations. Device certificates are carried, using EAP-TLS, for authentication to the AAA server.
Prerequisites for MACsec MKA using EAP-TLS
-
Ensure that you have a Certificate Authority (CA) server configured for your network.
-
Generate a CA certificate.
-
Ensure that you have configured Cisco Identity Services Engine (ISE) Release 2.0.
-
Ensure that both the participating devices, the CA server, and Cisco Identity Services Engine (ISE) are synchronized using Network Time Protocol (NTP). If time is not synchronized on all your devices, certificates will not be validated.
-
Ensure that 802.1x authentication and AAA are configured on your device.
Limitations for MACsec MKA using EAP-TLS
-
MKA is not supported on port-channels.
-
MKA is not supported with High Availability and local authentication.
-
MKA/EAPTLS is not supported for promiscuous PVLAN Primary port.
-
While configuring MACsec MKA using EAP-TLS, MACsec secure channels encrypt counters does not increment before first Rekey.
Information About MKA/MACsec for Port Channel
Note |
Etherchannel links that are formed as part of the port channel can either be congruent or disparate i.e. the links can either be MACsec-secured or non-MACsec-secured. MKA session between the port members is established even if a port member on one side of the port channel is not configured with MACsec. |
It is recommended that you enable MKA/MACsec on all the member ports for better security of the port channel.
Information About MACsec Cipher Announcment
Note |
Only the MACsec Cipher Suite capabilities which are configured in the MKA policy are announced from the authenticator to the supplicant. |
-
Unsecured Announcements (EAPoL PDUs) : Unsecured announcments are EAPoL announcements carrying MACsec Cipher Suite capabilities in an unsecured manner. These announcements are used to decide the width of the key used for MKA session prior to authentication.
-
Secure Announcements (MKPDUs) : Secure announcements revalidate the MACsec Cipher Suite capabilities which were shared previously through unsecure announcements.
Once the session is authenticated, peer capabilities which were received through EAPoL announcements are revalidated with the secure announcements. If there is a mismatch in the capabilities, the MKA session tears down.
Limitations for MACsec Cipher Announcement
-
If MACsec Cipher Suite Capabilities get changed in an active policy at the authenticator, the updated capabilities are not take into effect until a shutdown/no shutdown is performed on the interface. If you do not disable and restart the interface, EAPoL Announcement continues to announce the older capabilities.
-
The MKA session between the supplicant and the authenticator does not tear down even if the MACsec Cipher Suite Capabilities configured on both do not result in a common cipher suite.
MACsec Connections Across Intermediate Switches
Prior to Cisco IOS XE Gibraltar 16.11.1, MACsec connection between end devices which have WAN MACsec configured with the intermediate switches as the Cisco Catalyst 3650 and 3850 Series Switches was not supported. The encrypted packets were dropped if WAN MACsec was configured on the end devices with MACsec not configured on the intermediate switches. With the ClearTag feature implemented on the ASIC, the switch forwards the encrypted packet without parsing the MACsec header.
Limitations for MACsec Connections Across Intermediate Switches
-
Hop-by-hop MACsec encryption with Catalyst 3650 and 3850 Series switches as intermediate switches where WAN MACsec is configured on the routers is not supported.
-
WAN MACsec configured on the routers with intermediate switches as the Catalyst 3650 and 3850 Series switches is not supported on Layer 3 VPNs.
-
WAN MACsec configured on the routers with intermediate switches as the Catalyst 3650 and 3850 Series switches show Cisco Discovery Protocol neighbors only in should-secure mode.
Cisco TrustSec Overview
The table below lists the TrustSec features to be eventually implemented on TrustSec-enabled Cisco switches. Successive general availability releases of TrustSec will expand the number of switches supported and the number of TrustSec features supported per switch.
Cisco TrustSec Feature | Description |
---|---|
802.1AE Tagging (MACsec) |
Protocol for IEEE 802.1AE-based wire-rate hop-to-hop Layer 2 encryption. Between MACsec-capable devices, packets are encrypted on egress from the transmitting device, decrypted on ingress to the receiving device, and in the clear within the devices. This feature is only available between TrustSec hardware-capable devices. |
Endpoint Admission Control (EAC) |
EAC is an authentication process for an endpoint user or a device connecting to the TrustSec domain. Usually EAC takes place at the access level switch. Successful authentication and authorization in the EAC process results in Security Group Tag assignment for the user or device. Currently EAC can be 802.1X, MAC Authentication Bypass (MAB), and Web Authentication Proxy (WebAuth). |
Network Device Admission Control (NDAC) |
NDAC is an authentication process where each network device in the TrustSec domain can verify the credentials and trustworthiness of its peer device. NDAC utilizes an authentication framework based on IEEE 802.1X port-based authentication and uses EAP-FAST as its EAP method. Successful authentication and authorization in NDAC process results in Security Association Protocol negotiation for IEEE 802.1AE encryption. |
Security Association Protocol (SAP) |
After NDAC authentication, the Security Association Protocol (SAP) automatically negotiates keys and the cipher suite for subsequent MACSec link encryption between TrustSec peers. SAP is defined in IEEE 802.11i. |
Security Group Tag (SGT) |
An SGT is a 16-bit single label indicating the security classification of a source in the TrustSec domain. It is appended to an Ethernet frame or an IP packet. |
SGT Exchange Protocol (SXP) |
Security Group Tag Exchange Protocol (SXP). With SXP, devices that are not TrustSec-hardware-capable can receive SGT attributes for authenticated users and devices from the Cisco Identity Services Engine (ISE) or the Cisco Secure Access Control System (ACS). The devices can then forward a sourceIP-to-SGT binding to a TrustSec-hardware-capable device will tag the source traffic for SGACL enforcement. |
When both ends of a link support 802.1AE MACsec, SAP negotiation occurs. An EAPOL-key exchange occurs between the supplicant and the authenticator to negotiate a cipher suite, exchange security parameters, and manage keys. Successful completion of these tasks results in the establishment of a security association (SA).
Depending on your software version and licensing and link hardware support, SAP negotiation can use one of these modes of operation:
-
Galois Counter Mode (GCM)—authentication and encryption
-
GCM authentication (GMAC)— GCM authentication, no encryption
-
No Encapsulation—no encapsulation (clear text)
-
Null—encapsulation, no authentication or encryption