cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Configuring MACsec Switch to Switch with Pre-Shared-Key

280
Views
5
Helpful
0
Comments

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 MACsec Switch to Switch with Local Authentication

Configuring MACsec Switch to Switch with ISE Authentication

Configuring MACsec Switch to Host with ISE

 

Network Diagram

 

sw-sw-psk1.png

 

 

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 keychain1 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 keychain1
!
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

sw-sw-psk2.png

 

 

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

 sw-sw-psk3.png

 

With no key server priority configured the Bot-Sw naturally becomes the Key Server for the G1/0/1 <-> G1/0/1 link. 

sw-sw-psk4.png 

 

 

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.

 sw-sw-psk5.png

 

sw-sw-psk6.png

 

 

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

 sw-sw-psk7.png

 

… snipped output …

sw-sw-psk8.png

 

Show Command Usage

show mka session
show mka session interface g1/0/1 detail
show macsec summary
show macsec interface g1/0/1