You can do this with NETCONF-YANG as well. Click here to see YANG models that can help automate this process.
Summary
Here we will go over the configuration needed for MACsec Switch to Switch using a Pre-Shared Key. Topics that will be covered include, command usage, key derivation and key server election. Please see the MACsec History and Terminology for a basic understanding of where MACsec came from, the cipher suites and encryption methods, and acronym definitions. While I am using Switch to Switch this can also be used for Router <-> Switch or Router <-> Router as long as MACsec is supported on the interfaces. Configuring MACsec on NX-OS is likely to be different from these examples.
In these examples, I’m using two Catalyst 9200 switches, both running IOS XE 17.3(1).
This will be the one in a series of documents I write on MACsec. Some of the other topics I’ll be writing are…
MACsec History and Terminology
Creating a CSR, Authenticating a CA and Enrolling Certificates on IOS XE
Configuring Certificate Based MACsec Switch to Switch with Local Authentication
Configuring Certificate Based MACsec Switch to Switch with Remote ISE Authentication
Configuring MACsec Switch to Host with Cat9k & ISE
Network Diagram
Switch Configuration
The on-switch configuration is pretty simple. First, we will create a key chain that will contain both the Connectivity Key Name (CKN) and the Connectivity Association Key (CAK). The CKN must be an even number of Hex digits and the CAK must be 32 or 64 Hex digits. Optionally we can create a MACsec Key Agreement policy. Finally, we will enable MACsec network link on the interface, apply the MKA policy and the key. The configuration for the CKN and the CAK must be the same on both sides of the link.
!
configure terminal
key chain mka-keys macsec
!
! Must match on both sides.
! Must be an even number of digits
! Connectivity Key Name (CKN)
key HEX-CKN-EVEN#
!
! Must match on both sides
! MKA Authentication Cipher
cryptographic-algorithm aes-256-cmac
!
! Must match on both sides
! Must be 32 characters for 128 bits
! OR Must be 64 characters for 256 bits
! Connectivity Association Key (CAK)
key-string ----32-OR-64-HEX-CHARS----
!
mka policy mkapolicy1
! 128 bit is supported by Cat 9200
! 256 bit is supported by Cat 9300
macsec-cipher-suite gcm-aes-128
!
!
! Interface Configuration
!
int g1/0/1
macsec network-link
mka policy mkapolicy1
mka pre-shared-key key-chain mka-keys
!
end
!
Type 6 & Type 7 Passwords
When you review this configuration, you will possibly see that the key-string has been encoded as a type 7 password. We all should know by now that type 7 is encoding, it’s not hashing and it’s not encryption. Being the security minded individuals we are, we will use some newer encryption for this, we will use type 6. Type 6 are supported in IOS XE 16.10.1 and later. Enabling this is a box-wide configuration change.
Note: Enabling this will change your Type 7 (easily decode) password to Type 6 (don’t even think about decrypting). There are concerns and you should do some reading before making this change. Once you’re done your research your SecOps team and Auditors will be happy you made this change. Some other things that will change in the startup and running config are line passwords, RADIUS & TACACS shared secrets & local username passwords. Make sure to store your Master Key in a safe spot!
!
config term
key config-key password-encrypt MASTER-KEY
password encryption aes
end
!
You may receive a message stating Master key change notification called without new or old key. While this looks like an error it is not.
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvs52230
Additionally, there is a bug in older IOS versions that break MKA when Type 6 passwords are used. This is not a problem in newer IOS & IOS XE.
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvp48045
Sorry for the off-topic tangent….
MKA Key Generation
Note: Definitions for these terms can be found in the History & Terminology document.
When Pre-Shared-Key is used the Connectivity Association Key (CAK) is the same as the Pre-Shared-Key (PSK), both the CAK & the Connectivity Key Name (CKN) must be manually entered in the key chain. When a link comes up and after both peers agree that the CAK and the CKN are the same, the key server election process occurs. When the Key Server election is complete it will perform a Random Number Generation (RNG) and then perform a Key Derivative Function (KDF) on the RNG to create the Secure Association Key (SAK).
The key wrapped SAK will then be sent across the wire to the peer. It’s important to note up to this point these are all control plane functions. After the far-side peer receives the SAK and installs it, both of the peers are able to start encrypting data. This encryption is occurring in the data plane.
Key Server Priority
This process is compatible with MKA PSK and other Authentication types.
By default, the key-server priority is zero (0), if key-server priority is left at the default then the switch port with the lowest MAC Address will be elected Key Server.
If there is a need to configure one switch as the key server this can be configured in the MKA Policy using the key-server priority command as shown below. The lower the configured key-server priority wins the election. If you never want a switch to be elected key-server use priority 255.
!
conf t
mka policy my-mka-policy
key-server priority
end
!
In the examples below we show how MAC address influences and key priority can the key server role.
Key Server Example 1
With no key server priority configured the Bot-Sw naturally becomes the Key Server for the G1/0/1 <-> G1/0/1 link.
Key Server Example 2
Now let’s change the MAC address on the Top-Sw and try and force it to be the MKA key server.
Key Server Example 3
Let’s use the BIA MAC addresses and change the key server using the MKA policy. Remember as we saw in Example 1 the Bot-Sw has the switch port that is the key server. In order to change the key server, we will add the key-server priority
to the MKA policy. As we stated earlier, by default the key-server priority is zero (0), you can see this in the following command.
show runn all | sec mka policy
Now let’s change the devices.
!
! On Bot-Sw
!
config term
mka policy mkapolicy1
key-server priority 100
end
!
!
! On Top-Sw
!
config term
mka policy mkapolicy1
key-server priority 99
end
!
We can see in the screen shot below that the MAC addresses have been returned to the burned in addresses. We can also see that the switch with the higher MAC address is the key server. We expected this to occur because we gave the Top-Sw a lower MKA key server priority.
You can see the newly configured key server priority with the following command.
show mka session interface g1/0/1 detail
… snipped output …
Show Command Usage
show mka session
show mka session interface g1/0/1 detail
show macsec summary
show macsec interface g1/0/1
M@rco, sorry for the delay, it took me a bit to find the info.
I don't see it in the release notes but MACsec PSK with should-secure is supported on C9300 in IOS XE 17.7(1).
There is also an enhancement to show macsec interface to show the MACsec should-secure vs. must-secure.
Hope this helps.
