Catalyst 4500 Series Switch Software Configuration Guide, IOS XE 3.9.xE and IOS 15.2(5)Ex

MKA Policies

By default, the MKA protocol default policy is enabled on an interface. However, you can apply a defined MKA policy to an interface. Removing the MKA policy configures the default MKA policy on that 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.
• Replay protection. You can configure MACsec window size, as defined by the number of out-of-order frames that are accepted. This value is used while installing the security associations in the MACsec. A value of 0 means that frames are accepted only in the correct order.

Note MKA is not supported in the Virtual Switching System (VSS) mode.

Key Lifetime and Hitless Key Rollover

A MACsec key chain (MKA) can have multiple pre-shared keys (PSKs) each configured with a key ID and an optional lifetime. A key lifetime specifies the time period the key is valid. In the absence of a lifetime configuration, the default lifetime is unlimited. MKA rolls over to the next configured valid pre-shared key in the key chain, when a valid key expires. Time zone of the key can be local or UTC. Default time zone is UTC.

MKA rolls over to the next configured valid pre-shared key in the key chain, when a valid key expires.

Use the key chain key-chain-name macsec to configure the MACsec key chain.

To roll over to the next key within the same key chain, configure a second key in the key chain, and a lifetime for the first key. When the lifetime of the first key expires, it automatically rolls over to the next key in the list. If the same key is configured on both sides of the link at the same time, then the key rollover is hitless, that is, key rolls over without traffic interruption.

Note The lifetime of the keys need to be overlapped to achieve hitless key rollover.

Encryption Algorithms for MKA Control Packets

Cryptographic algorithm selection for MKA control protocol packets encryption is as follows:

• The cryptographic algorithm to encrypt MKA control protocol packets is configured as part of the key chain. There can be only one cryptographic algorithm configured per key chain.
• A key server uses the configured MKA cryptographic algorithm from the key chain.
• All nonkey servers must use the same cryptographic algorithm as the key server.

If an MKA cryptographic algorithm is not configured, a default cryptographic algorithm of AES-CMAC-128 (Cipher-based Message Authentication Code with 128-bit Advanced Encryption Standard) is used.

The following is a sample encryption algorithm for data packets:

Switch(config)# mka policy p1

Switch(config-mka-policy)# macsec-cipher-suite gcm-aes-128

The following is a sample encryption algorithm for MKA control packets:

Switch(config)# key chain key-chain-name macsec

Switch (config-keychain-macsec)# key 01

Switch (config-keychain-macsec-key)# key-string 0001

Switch (config-keychain-macsec-key)# cryptographic-algorithm [ aes-128-cmac | aes-256-cmac ]

Switch (config-keychain-macsec-key)# end

Virtual Ports

You use virtual ports for multiple secured connectivity associations on a single physical port. Each connectivity association (pair) represents a virtual port, with a maximum of two virtual ports per physical port. Only one of the two virtual ports 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

A Catalyst 4500 series switch supervisor running MACsec maintains the configuration files that show which ports on the switch support MACsec. The supervisor-engine performs these functions:

• Processes secure channel and secure association creation and deletion.
• Programs the hardware with the derived secure association key (SAK) for encryption and decryption.

MACsec, MKA, and 802.1X Host Modes

You can use MACsec and the MKA Protocol with 802.1X single-host mode, multiple-host mode, or Multi Domain Authentication (MDA) mode.

Single-Host Mode

MACsec in Single-Host Mode with a Secured Data Session shows how a single EAP authenticated session is secured by MACsec using MKA.

Figure 48-1 MACsec in Single-Host Mode with a Secured Data Session

Multiple-Host Mode

In standard (not 802.1X-2010) 802. 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 no 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. See .

Figure 48-2 MACsec in Standard Multiple-Host Mode - Unsecured

We do not recommend using multi-host mode because after the first successful client, authentication is not required for other clients, which is not secure.

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 statistics command output:

For description of the output fields, see the command reference for this release.

Default MKA MACsec Configuration

MACsec is disabled. No MACsec Key Agreement (MKA) policies are configured.

Configuring an MKA Policy

To create an MKA Protocol policy, perform this task. Note that MKA also requires that you enable 802.1X.

This example configures the MKA policy relay-policy :

Let's say that we configure an MKA policy as follows:

We observe the following:

• The payload starting from the SA (source MAC address) + 50 bytes offset is encrypted.
• Replay protect is YES with a window size of 1000. If the frame received has a packet number (PN) of 1020, for example, all frames with a PN of 20 to 1020 can come out of order (i.e, frame with PN 900 can come first and frame with PN 800 can come later). However, if a frame with a PN of 1021 is received first, followed by a frame with a PN of 20, the frame with PN of 20 is dropped. In this scenario, the expected PN is 1022 and the window size is 1000, so the acceptable PN number is anything greater than or equal to (expected PN - window size) = 22. So, any frame with PN < 22 is dropped.

By default, the MKA protocol default policy is enabled on an interface, if no MKA policies are applied. All the values in the policy (such as confidentiality,offset, and replay protection) take the default values. For example,

• Confidentialityoffset is 0—Encrypts the payload that is immediately after the SA (source MAC address).
• Replay protect is YES with window size 0—Frames cannot come out of order.

Configuring MACsec on an Interface

To configure MACsec on an interface with one MACsec session for voice and one for data, perform this task:

This is an example of configuring and verifying MACsec on an interface:

Configuring MKA Pre-Shared Key

To configure MACsec Key Agreement (MKA) pre-shared key, perform this task:

	Command	Purpose
Step 1	configure terminal	Enters global configuration mode.
Step 2	key chain key-chain-name [ macsec ]	Configures a key chain and enters keychain MACsec configuration mode. Note The key ID and the key string should not be all zeros.
Step 3	key hex-string	Configures a key and enters keychain-MACsec key configuration mode. The key ID must be an even-digit-sized hex-string. Note Ensure that the key  is a non-zero value. If key  is set to 00, validation failure occurs and the following message is displayed: MKA Session bring-up failure: FSM (Derive KEK/ICK) - Zero CKN input
Step 4	cryptographic-algorithm [ aes-128-cmac | aes-256-cmac ]	Sets the cryptographic encryption algorithm. Note Cisco Catalyst 4500-X Series Switches do not support AES-256 encryption.
Step 5	key-string {[ 0 | 6 ] pre-shared-key | 7 | pre-shared-key }	Sets the pre-shared key for a key string. The key-string should be a 32 or 64-digit hex-string, that is in sync with the cryptographic algorithm that is configured. Note Ensure that the key-string  is a non-zero value. If key-string  is set to 00, validation failure occurs and the following message is displayed: MKA Session bring-up failure: FSM (Derive KEK/ICK) - Zero CAK input
Step 6	lifetime { local hh:mm:ss | hh:mm:ss } day month year { duration seconds | hh:mm:ss day month | infinite }	Sets a lifetime for the MACsec key.
Step 7	end	Returns to privileged EXEC mode.
Step 8	copy running-config startup-config	(Optional) Saves your entries in the configuration file.

This example shows how to configure MKA pre-shared key:

Example: Connectivity Association Key Rekey

The connectivity Association Key (CAK) is a long-lived master key that is used to generate all other keys needed for MKA/MACsec.

The CAK rekey happens in the following cases:

• When moving from Key 01 to Key 02 within the Key Chain K1.
• When moving from one Key Chain K1 to another Key Chain K2.

Note We recommend that you configure keys such that there is an overlap between the lifetime of the keys so that CAK rekey is successful and there is a seamless transition between the keys/CA (without any traffic loss or session restart.)

Prerequisites for MKA MACsec with EAP-TLS

• Ensure that you have a Certificate Authority (CA) server configured for your network.
• Generate a CA certificate.
• We recommend that you configure 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).
• Ensure that 802.1x authentication and AAA are configured on your device.

Limitations for MKA MACsec with EAP-TLS

• MKA is not supported on port-channels.
• MKA is not supported with High Availability and local authentication.
• MKA supports encryption using AES-GCM-128 encryption only. MKA does not support Security Group Tagging and AES-GCM-256 encryption.

Understanding Certificate Enrollment

Certificate enrollment is the process of obtaining a certificate from a Certificate Authority (CA). Each end host that wants to participate in the Cisco IOS public key infrastructure (PKI) must obtain a certificate. Certificate enrollment occurs between the end host requesting the certificate and the CA. The figure below and the following steps describe the certificate enrollment process.

1. The end host generates an RSA key pair.

2. The end host generates a certificate request and forwards it to the CA.

3. The CA receives the certificate enrollment request, and, depending on your network configuration, one of the following options occurs:

– Manual intervention is required to approve the request.

– The end host is configured to automatically request a certificate from the CA. Thus, operator intervention is no longer required at the time the enrollment request is sent to the CA server.

Note If you configure the end host to automatically request certificates from the CA, you should have an additional authorization mechanism.

4. After the request is approved, the CA signs the request with its private key and returns the completed certificate to the end host.

5. The end host writes the certificate to a storage area such as NVRAM.

Generating RSA Key Pairs

To generate RSA key pairs, perform this task:

Configuring Enrollment using SCEP

Simple Certificate Enrollment Protocol (SCEP) is a Cisco-developed enrollment protocol that uses HTTP to communicate with the certificate authority (CA) or registration authority (RA). SCEP is the most commonly used method for sending and receiving requests and certificates.

Configuring Manual Enrollment

If your CA does not support SCEP or if a network connection between the router and CA is not possible. Perform the following task to set up manual certificate enrollment:

Ensure that you enroll both the participating devices and the RADIUS server to the PKI infrastructure.

For more information on PKI configuration, see the Public Key Infrastructure Configuration Guide .

Configuring MKA MACsec Using EAP-TLS

To configure MACsec with MKA on point-to-point links, perform these tasks:

• Configure an Authentication Policy
• Configure EAP-TLS Profiles and IEEE 802.1x Credentials
• Configure 802.1x and MKA MACsec using EAP-TLS on Interfaces

Configuring EAP-TLS and 802.1x Credentials

To configure EAP-TLS and 802.1x credentials, perform the following task:

Configuring an Authentication Policy

To configure an authentication policy, perform the following task:

Applying the 802.1x and MKA MACsec Configuration on Interfaces

To apply 801.1x and MKA MACsec using EAP-TLS to interfaces, perform the following task:

Example: MKA MACsec Switch-to-Switch Configuration

Configuring Cisco TrustSec Credentials on the Switch

To enable Cisco TrustSec features, you must create Cisco TrustSec credentials on the switch to use in other TrustSec configurations.

To configure Cisco TrustSec credentials, perform this task:

To delete the Cisco TrustSec credentials, enter the clear cts credentials privileged EXEC command.

This example shows how to create Cisco TrustSec credentials:

Note Before you configure Cisco TrustSec MACsec authentication, you should configure Cisco TrustSec seed and non-seed devices. For 802.1X mode, you must configure at least one seed device, that device closest to the access control system (ACS). See this section in the Cisco TrustSec Switch Configuration Guide:

http://www.cisco.com/en/US/docs/switches/lan/trustsec/configuration/guide/trustsec.html

Configuring Cisco TrustSec Switch-to-Switch Link Security in 802.1X Mode

You enable Cisco TrustSec link layer switch-to-switch security on an interface that connects to another Cisco TrustSec device. When configuring Cisco TrustSec in 802.1X mode on an interface, follow these guidelines:

• To use 802.1X mode, you must globally enable 802.1X on each device.
• If you select GCM as the SAP operating mode, you must have a MACsec encryption software license from Cisco.

Note MACsec is supported on the Catalyst 4500 series switch universal k9 image. It is not supported with the NPE license or with a LAN Base service image.

If you select GCM without the required license, the interface is forced to a link-down state.

To configure Cisco TrustSec switch-to-switch link layer security with 802.1X, perform this task:

	Command	Purpose
Step 1	configure terminal	Enters global configuration mode.
Step 2	interface interface-id	Enters interface configuration mode.
Step 3	cts dot1x	Configures the interface to perform NDAC authentication.
Step 4	sap mode-list mode1 [ mode2 [ mode3 [ mode4 ]]]	(Optional) Configures the SAP operation mode on the interface. The interface negotiates with the peer for a mutually acceptable mode. Enter the acceptable modes in your order of preference. Choices for mode are: gcm-encrypt —Authentication and encryption Note Select this mode for MACsec authentication and encryption if your software license supports MACsec encryption. gmac —Authentication, no encryption no-encap —No encapsulation null —Encapsulation, no authentication or encryption Note If the interface is not capable of data link encryption, no-encap is the default and the only available SAP operating mode. SGT is not supported.
Note Although visible in the CLI help, the timer reauthentication and propagate sgt keywords are not supported. However, the no propagate sgt keyword is supported (refer to Step 5 in the next section).
Step 5	exit	Exits Cisco TrustSec 802.1X interface configuration mode.
Step 6	end	Returns to privileged EXEC mode.
Step 7	show cts interface [ interface-id | brief | summary ]	(Optional) Verifies the configuration by displaying TrustSec-related interface characteristics.
Step 8	copy running-config startup-config	(Optional) Saves your entries in the configuration file.

This example shows how to enable Cisco TrustSec authentication in 802.1X mode on an interface using GCM as the preferred SAP mode:

Configuring Cisco TrustSec Switch-to-Switch Link Security in Manual Mode

If your switch does not have access to an authentication server or if 802.1X authentication is not needed, you can manually configure Cisco TrustSec on an interface. You must manually configure the interface on each end of the connection.

When manually configuring Cisco TrustSec on an interface, consider these usage guidelines and restrictions:

• If no SAP parameters are defined, neither encryption nor MACsec Encapsulation are performed.
• If you select GCM as the SAP operating mode, you must have a MACsec Encryption software license from Cisco. If you select GCM without the required license, the interface is forced to a link-down state.
• These protection levels are supported when you configure SAP pairwise master key ( sap pmk):

– SAP is not configured—no protection.

– sap mode-list gcm-encrypt gmac no-encap —protection desirable but not mandatory.

– sap mode-list gcm-encrypt gmac— confidentiality preferred and integrity required. The protection is selected by the supplicant according to supplicant preference.

– sap mode-list gmac —integrity only.

– sap mode-list gcm-encrypt —confidentiality required.

– sap mode-list gmac gcm-encrypt —integrity required and preferred, confidentiality optional.

To manually configure Cisco TrustSec on an interface to another Cisco TrustSec device, perform this task:

This example shows how to configure Cisco TrustSec authentication in manual mode on an interface:

Cisco TrustSec Switch-to-Switch Link Security Configuration Example

This example shows the configuration necessary for a seed and non-seed device for Cisco TrustSec switch-to-switch security. You must configure the AAA and RADIUS for link security. In this example, ACS-1 through ACS-3 can be any server names and cts-radius is the Cisco TrustSec server.

Seed Device Configuration:

Non-Seed Device: