Configuring MACsec Encryption
This chapter describes how to configure Media Access Control Security (MACsec) encryption on the Catalyst 4500 series switch.
MACsec is the IEEE 802.1AE standard for authenticating and encrypting packets between two MACsec-capable devices. The Catalyst 4500 series switch supports 802.1AE encryption with MACsec Key Agreement (MKA) on downlink ports for encryption between the switch and host devices. The switch also supports MACsec link layer switch-to-switch security by using Cisco TrustSec Network Device Admission Control (NDAC) and the Security Association Protocol (SAP) key exchange. Link layer security can include both packet authentication between switches and MACsec encryption between switches (encryption is optional).
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.
All downlink ports on a switch can run Cisco TrustSec MACsec link layer switch-to-switch security.
Table 1 MACsec Support on Switch Ports
|
|
|
User-facing downlink ports |
Switch-to-host |
MKA MACsec encryption |
Switchports connected to other switches |
Switch-to-switch |
Cisco TrustSec NDAC MACsec MKA MACsec encryption |
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 both switch-to-host facing links, and switch-to-switch links as well. Host-facing links typically use flexible authentication ordering for handling heterogeneous devices with or without IEEE 802.1X, and can optionally use MKA 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.
This chapter includes the following major sections:
Note For more information, refer to the Cisco TrustSec Switch Configuration Guide:
http://www.cisco.com/en/US/docs/switches/lan/trustsec/configuration/guide/trustsec.html
For complete syntax and usage information for the switch commands used in this chapter, see the
Cisco IOS Command Reference Guides for the Catalyst 4500 Series Switch.
If a command is not in the Cisco Catalyst 4500 Series Switch Command Reference , you can locate it in the Cisco IOS Master Command List, All Releases.
Understanding 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) and EAP-Transport Layer Security (EAP-TLS) framework. MKA MACsec supports both host facing links (links between network access devices and endpoint devices such as a PC or IP phone) and switch-to-switch links, beginning in Cisco IOS Release 15.2(5)E and Cisco IOS XE Release 3.9.0E.
A switch using MACsec accepts either MACsec or non-MACsec frames, depending on the policy associated with the client. MACsec frames are encrypted and protected with an integrity check value (ICV). When the switch receives frames from the client, 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 client) 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-2010. 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.
Pre-shared keys (PSKs) are used to generate Connectivity Association Keys (CAKs). In symmetric cryptography, PSK means a key or a shared secret. This key is shared between parties before it is used. The PSK is used to generate the Key Encryption Key (KEK) and the integrity check value (ICV) Key (ICK).
Note PSK supports encryption using AES-GCM-128 encryption only and does not support AES-GCM-256.
In a switch-to-switch connection using the PSK, there is no concept of the authenticator, because of the EAP authentication on the switch. So the switch with highest priority becomes the Key Server (KS). In the current implementation, MKA can act as a non-KS without much change, except for accepting the PSK instead of the CAK.
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). Because the switch is the authenticator, it is also the key server, generating a random 128-bit secure association key (SAK), which it sends it 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.
The CAK and CKN will be derived from the configured PSK name and value
The packet body in an EAPOL Protocol Data Unit (PDU) is referred to as a MACsec Key Agreement PDU (MKPDU). MKA sessions and participants are deleted when the MKA lifetime (6 seconds) passes with no MKPDU received from a participant. For example, if a client disconnects, the participant on the switch continues to operate MKA until 6 seconds have elapsed after the last MKPDU is received from the client.
These sections provide more details:
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.
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:
SWitch# show mka statistics
Secured.................... 32
Reauthentication Attempts.. 31
Deleted (Secured).......... 1
Keepalive Timeouts......... 0
Pairwise CAKs Derived...... 32
Pairwise CAK Rekeys........ 31
Group CAKs Generated....... 0
Group CAKs Received........ 0
SAKs Generated............. 32
SAKs Rekeyed............... 31
SAKs Received.............. 0
SAK Responses Received..... 32
MKPDUs Validated & Rx...... 580
MKPDUs Transmitted......... 597
"Distributed SAK"..... 32
Bring-up Failures.................. 0
Reauthentication Failures.......... 0
SAK Generation.................. 0
Hash Key Generation............. 0
SAK Encryption/Wrap............. 0
SAK Decryption/Unwrap........... 0
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.. 2
Rx SC Creation................... 0
Tx SC Creation................... 0
Rx SA Installation............... 0
Tx SA Installation............... 0
MKPDU Tx......................... 0
MKPDU Rx Validation.............. 0
MKPDU Rx Bad Peer MN............. 0
MKPDU Rx Non-recent Peerlist MN.. 0
For description of the output fields, see the command reference for this release.
Understanding MKA MACsec with EAP-TLS
Beginning in Cisco IOS XE Release 3.9.0E, MKA MACsec is supported on switch-to-switch links on Cisco Catalyst 4500-X series switches and Cisco Catalyst 4500-E series switches with Supervisor Engine 8-E.
Using IEEE 802.1X Port-based Authentication with Extensible Authentication Protocol (EAP-TLS), you can configure MKA MACsec 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.
Note MKA MACsec is not supported on multi-point to multi-point links.
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:
|
|
|
Step 1 |
|
Enters global configuration mode. |
Step 2 |
crypto key generate rsa
label
label name
general-keys modulus
size
|
Generates a RSA key pair for signing and encryption. You can also assign a label to each key pair using the label keyword. The label is referenced by the trustpoint that uses the key pair. If you do not assign a label, the key pair is automatically labeled <Default-RSA-Key>. If you do not use additional keywords this command generates one general purpose RSA key pair. If the modulus is not specified, the default key modulus of 1024 is used. You can specify other modulus sizes with the modulus keyword. |
Step 3 |
|
Returns to privileged EXEC mode. |
Step 4 |
show crypto key mypubkey rsa
|
(Optional) Displays the RSA public keys of your device. This step allows you to verify that the RSA key pair has been successfully generated. |
Step 5 |
copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
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.
|
|
|
Step 1 |
|
Enters global configuration mode. |
Step 2 |
crypto pki trustpoint
server name
|
Declares the trustpoint and a given name and enters ca-trustpoint configuration mode. |
Step 3 |
enrollment url
url name
pem
|
Specifies the URL of the CA on which your device should send certificate requests. An IPv6 address can be added in the URL enclosed in brackets. For example: http:// [2001:DB8:1:1::1]:80. The pem keyword adds privacy-enhanced mail (PEM) boundaries to the certificate request. |
Step 4 |
|
Specifies which key pair to associate with the certificate. |
Step 5 |
|
The none keyword specifies that a serial number will not be included in the certificate request. |
Step 6 |
|
The none keyword specifies that no IP address should be included in the certificate request. |
Step 7 |
|
Specifies CRL as the method to ensure that the certificate of a peer has not been revoked. |
Step 8 |
auto-enroll
percent
regenerate
|
Enables auto-enrollment, allowing the client to automatically request a rollover certificate from the CA. If auto-enrollment is not enabled, the client must be manually re-enrolled in your PKI upon certificate expiration. By default, only the Domain Name System (DNS) name of the device is included in the certificate. Use the percent argument to specify that a new certificate will be requested after the percentage of the lifetime of the current certificate is reached. Use the regenerate keyword to generate a new key for the certificate even if a named key already exists. If the key-pair being rolled over is exportable, the new key pair will also be exportable. The following comment will appear in the trustpoint configuration to indicate whether the key pair is exportable: “! RSA key pair associated with trustpoint is exportable.” It is recommended that a new key pair be generated for security reasons. |
Step 9 |
crypto pki authenticate
name
|
Retrieves the CA certificate and authenticates it. |
Step 10 |
|
Exits Global Configuration mode. |
Step 11 |
show crypto pki certificate
trustpoint name
|
Displays information about the certificate for the trust point. |
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:
|
|
|
Step 1 |
|
Enters global configuration mode. |
Step 2 |
crypto pki trustpoint
server name
|
Declares the trustpoint and a given name and enters ca-trustpoint configuration mode. |
Step 3 |
|
Specifies the manual cut-and-paste certificate enrollment method. The certificate request will be displayed on the console terminal so that it may be manually copied (or cut). The pem keyword configures the trustpoint to generate PEM-formatted certificate requests to the console terminal. |
Step 4 |
|
Specifies which key pair to associate with the certificate. |
Step 5 |
|
The none keyword specifies that a serial number will not be included in the certificate request. |
Step 6 |
|
The none keyword specifies that no IP address should be included in the certificate request. |
Step 7 |
|
Specifies CRL as the method to ensure that the certificate of a peer has not been revoked. |
Step 8 |
|
Exits ca-trustpoint configuration mode and returns to global configuration mode. |
Step 9 |
crypto pki authenticate
name
|
Retrieves the CA certificate and authenticates it. |
Step 10 |
|
Generates certificate request and displays the request for copying and pasting into the certificate server. Enter enrollment information when you are prompted. For example, specify whether to include the device FQDN and IP address in the certificate request. You are also given the choice about displaying the certificate request to the console terminal. The base-64 encoded certificate with or without PEM headers as requested is displayed. |
Step 11 |
crypto pki import
name
certificate
|
Imports a certificate via TFTP at the console terminal, which retrieves the granted certificate. The device attempts to retrieve the granted certificate via TFTP using the same filename used to send the request, except the extension is changed from “.req” to “.crt”. For usage key certificates, the extensions “-sign.crt” and “-encr.crt” are used. The device parses the received files, verifies the certificates, and inserts the certificates into the internal certificate database on the router. Note Some CAs ignore the usage key information in the certificate request and issue general purpose usage certificates. If your CA ignores the usage key information in the certificate request, only import the general purpose certificate. The device will not use one of the two key pairs generated. |
Step 12 |
|
Exits Global Configuration mode. |
Step 13 |
show crypto pki certificate
trustpoint name
|
Displays information about the certificate for the trust point. |
Step 14 |
copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
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:
|
|
|
Step 1 |
|
Enters global configuration mode. |
Step 2 |
dot1x credentials
profile
|
Creates 802.1x credentials profile. This must be attached to the port that is configured as supplicant. |
Step 3 |
|
Creates a username. |
Step 4 |
|
Creates a password. |
Step 5 |
|
Exits dot1x-creden configuration mode and returns to global configuration mode. |
Step 6 |
|
Configures the EAP profile, and enters eap-profile configuration mode. |
Step 7 |
|
Configures the EAP-TLS method. |
Step 8 |
|
Configures the default PKI trustpoint. |
Step 9 |
|
Exits eap-profile configuration mode and enters global configuration mode. |
Step 10 |
|
Creates a service template and enters service template configuration mode. |
Step 11 |
linksec policy must-secure
|
Sets a data link layer security policy, The must-secure keyword specifies that the device port must be authorized only if a secure MACsec session is established. |
Step 12 |
|
Exits service-template configuration mode and returns to global configuration mode. |
Step 13 |
copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
Configuring an Authentication Policy
To configure an authentication policy, perform the following task:
|
|
|
Step 1 |
|
Enters global configuration mode. |
Step 2 |
|
Exits service-template configuration mode and returns to global configuration mode. |
Step 3 |
policy-map type control subscriber
control-policy-name
|
Defines a control policy for subscriber sessions and enters control policy-map event configuration mode. |
Step 4 |
event
event-name
match-all
|
Specifies that the session-started event triggers actions in a control policy if conditions are met. match-all is the default behavior. |
Step 5 |
priority-number
class always do-until-failure
|
Associates a priority with an action in the control policy. |
Step 6 |
action-number
authenticate using dot1x both
|
Initiates the authentication of a subscriber session using the IEEE 802.1x method as both a supplicant and an authenticator. |
Step 7 |
event
authentication-failure
match-all
|
Specifies that the authentication-failure event triggers actions in a control policy if conditions are met. match-all is the default behavior. |
Step 8 |
priority-number
class always do-until-failure
|
Associates a priority with an action in the control policy. |
Step 9 |
action-number
terminate dot1x
|
Terminates the authentication of a subscriber session using the IEEE 802.1x method |
Step 10 |
action-number
authentication-restart
seconds
|
Sets a timer to restart the authentication process after an authentication or authorization failure. |
Step 11 |
|
Exits control policy-map event configuration mode and returns to global configuration mode. |
Step 12 |
copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
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:
|
|
|
Step 1 |
|
Enters global configuration mode. |
Step 2 |
|
Identifies the MACsec interface, and enter interface configuration mode. The interface must be a physical interface. |
Step 3 |
|
Enables MKA MACsec using EAP-TLS, on the interface. |
Step 4 |
|
Enables reauthentication for this port. |
Step 5 |
authentication timer reauthenticate
interval
|
Sets the reauthentication interval. |
Step 6 |
access-session host-mode multi-host
|
Allows hosts to gain access to the interface. |
Step 7 |
|
Prevents preauthentication access on the interface. |
Step 8 |
access-session port-control auto
|
Sets the authorization state of a port. |
Step 9 |
|
Configures the port as an 802.1X port access entity (PAE) supplicant and authenticator. |
Step 10 |
dot1x credentials
profile
|
Assigns a 802.1x credentials profile to the interface. |
Step 11 |
dot1x supplicant eap profile
name
|
Assigns the EAP-TLS profile to the interface. |
Step 12 |
service-policy type control subscriber
control-policy
name
|
Applies a subscriber control policy to the interface. |
Step 13 |
|
Returns to privileged EXEC mode. |
Step 14 |
show access-session interface
interface-id
|
(Optional) Displays the active MKA sessions for the interface, and verifies your MKA MACsec configuration. |
Step 15 |
show mka session interface
interface-id
|
Step 16 |
show macsec interface
interface-id
|
Step 17 |
copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
Example: MKA MACsec Switch-to-Switch Configuration
Switch# configure terminal
Switch(config)# crypto key generate rsa label mkaioscarsa mod 2048
The name for the keys will be: mkaioscarsa
% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 2 seconds)
Switch(config)# crypto pki trustpoint POLESTAR-IOS-CA
Switch(ca-trustpoint)# subject-name CN=catdevice@polestar.com, C=IN, ST=KA, OU=ENG,O=Polestar
Switch(ca-trustpoint)# revocation-check none
Switch(ca-trustpoint)# rsakeypair mkaioscarsa
Switch(ca-trustpoint)# storage nvram:
Switch(ca-trustpoint)# end
Switch# configure terminal
Switch(config)# crypto pki authenticate POLESTAR-IOS-CA
Enter the base 64 encoded CA certificate.
End with a blank line or the word "quit" on a line by itself
!!PASTE THE CERTIFICATE CONTENT HERE AND END WITH ENTER!!
% Do you accept this certificate? [yes/no]: Yes
Trustpoint CA certificate accepted.
% Certificate successfully imported
Switch# show crypto pki certificate POLESTAR-IOS-CA
Certificate Serial Number (hex): 01
Certificate Usage: Signature
cn=POLESTAR-DHCP-CM.polestar.com
cn=POLESTAR-DHCP-CM.polestar.com
start date: 09:39:53 IST Apr 13 2016
end date: 09:39:53 IST Apr 13 2017
Associated Trustpoints: POLESTAR-IOS-CA
Switch# configure terminal
Switch(config)# crypto pki enroll POLESTAR-IOS-CA
% Start certificate enrollment..
% The subject name in the certificate will include: CN=catdevice@polestar.com, C=IN, ST=KA, OU=ENG,O=Polestar
% The subject name in the certificate will include: Device.polestar.com
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Display Certificate Request to terminal? [yes/no]: yes
Certificate Request follows:
MIIC8TCCAdkCAQAwgYoxETAPBgNVBAoTCFBvbGVzdGFyMQwwCgYDVQQLEwNFTkcx
CzAJBgNVBAgTAktBMQswCQYDVQQGEwJJTjEfMB0GA1UEAwwWY2F0NDUwMHgxQHBv
bGVzdGFyLmNvbTEsMCoGCSqGSIb3DQEJAhYdUE9MRVNUQVItNDUwMFgtMS5wb2xl
c3Rhci5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9gJrSiouv
yRr37Wf/i0MwWKr7VreQvQwSD3/Vr9YcVJ+8bULHcaB89wqF67Tlyuwqt1UgO/q9
Jr+qfP3anhvj5H0VRAl0wt/tvv66LLoH8y92/yb0dEY9h+DSRpFXQbUdQkIoYbkS
DnWZnuzvlOk4yKUAbslC3uZsrlnhIQz27bc/xlE0oigQxd0PjC82eZFt5EgwLO81
TzmaGsTnAUzWGQyhN6U97yDt0JXCmXIuND6uUXzZp1MDiRpNYjXwSWBZHaVEAFnF
tLBrtqA46eUj2b7iywqQ5WzqzSluPnw7ATo6sprj3TpQj2hLKihqfOPs8JK86Ow+
BGrp97PO5pllAgMBAAGgITAfBgkqhkiG9w0BCQ4xEjAQMA4GA1UdDwEB/wQEAwIF
oDANBgkqhkiG9w0BAQUFAAOCAQEAtOqEekXckNKy1+lWjy38AY7LHIiT0amQJ0SY
abw6P+SAlE+Ro6EbyS4gMPildjkDZSgaH/q9IdtmdG3GGz25CNXb0imK+2NroV+f
aOJZ6A19nqvdTz/OQ5LREcRlzfaeuNMnA2mzCpzyC0/kLQ6r040Uvz/GzPdmjWQh
sXRb57UFWffrOb1lC/7SsCo7HUcG1yCiYRFTKccHbLL/0+Q7yNHapWEZ0jaKAaj6
NhKR9WNrP0onZoHIivDm44CYc3iKS96XSsz7cu4J4HLimhB36tGk6M8jPGyNl4dc
eYYh4H2RSQqJLqy2D9q01uQFecHE5D79byKvVDPd1uSyVLpExg==
Redisplay enrollment request? [yes/no]: No
Switch# configure terminal
Switch(config)# crypto pki import POLESTAR-IOS-CA certificate
Enter the base 64 encoded certificate.
End with a blank line or the word "quit" on a line by itself
!!PASTE THE CERTIFICATE CONTENT AND END WITH ENTER!!
% Router Certificate successfully imported
Switch(config)# policy-map type control subscriber DOT1X_POLICY_RADIUS
Switch(config-event-control-policymap)# event session-started match-all
Switch(config-class-control-policymap)# 10 class always do-until-failure
Switch(config-action-control-policymap)# 10 authenticate using dot1x both
Switch(config-action-control-policymap)# event authentication-failure match-all
Switch(config-class-control-policymap)# 10 class always do-until-failure
Switch(config-action-control-policymap)# 10 terminate dot1x
Switch(config-action-control-policymap)# 20 authentication-restart 7
Switch(config-action-control-policymap)# end
Switch# configure terminal
Switch(config)# eap profile EAPTLS-PROF-IOSCA
Switch(config-eap-profile)# method tls
Switch(config-eap-profile)# pki-trustpoint POLESTAR-IOS-CA
Switch(config-eap-profile)# end
Switch# configure terminal
Switch(config)# dot1x credentials EAPTLSCRED-IOSCA
Switch(config-dot1x-creden)# username catdevice@polestar.cisco.com
Switch(config-dot1x-creden)# pki-trustpoint POLESTAR-IOS-CA
Switch(config-dot1x-creden)# end
Switch(config)# interface Tengigabitethernet 1/10
Switch(config-if)# shutdown
Switch(config-if)# macsec network-link
Switch(config-if)# authentication periodic
Switch(config-if)# authentication timer reauthenticate 43200
Switch(config-if)# access-session host-mode multi-host
Switch(config-if)# access-session closed
Switch(config-if)# access-session port-control auto
Switch(config-if)# dot1x pae both
Switch(config-if)# dot1x credentials EAPTLSCRED-IOSCA
Switch(config-if)# dot1x supplicant eap profile EAPTLS-PROF-IOSCA
Switch(config-if)# service-policy type control subscriber DOT1X_POLICY_RADIUS
Understanding Cisco TrustSec MACsec
Table 48-2 summarizes the Cisco TrustSec features supported on the switch. For more detailed explanations, see the Cisco TrustSec Switch Configuration Guide:
http://www.cisco.com/en/US/docs/switches/lan/trustsec/configuration/guide/arch_over.html#wp1054561
Table 48-2 Cisco TrustSec Features
|
|
802.1AE Encryption (MACsec) |
Protocol for 802.1AE-based wire-rate hop-to-hop Layer 2 encryption. Between MACsec-capable devices, packets are encrypted on egress from the sending device, decrypted on ingress to the receiving device, and in the clear within the devices. This feature is only available between 802.1AE-capable devices. |
Network Device Admission Control (NDAC) |
NDAC is an authentication process by which each network device in the TrustSec domain can verify the credentials and trustworthiness of its peer device. NDAC uses an authentication framework based on IEEE 802.1X port-based authentication and uses Extensible Authentication Protocol Flexible Authentication via Secure Tunnel (EAP-FAST) as its EAP method. Authentication and authorization by NDAC results in Security Association Protocol negotiation for 802.1AE encryption. |
Security Association Protocol (SAP) |
SAP is a Cisco proprietary key exchange protocol between switches. After NDAC switch-to-switch authentication, SAP automatically negotiates keys and the cipher suite for subsequent switch-to-switch MACsec encryption between TrustSec peers. The protocol description is available under a nondisclosure agreement. |
Security Group Tag (SGT) Note SGT is not supported in this release. |
An SGT is a 16-bit single label showing 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), including SXPv2 |
With SXP, devices that are not TrustSec-hardware capable can receive SGT attributes for authenticated users or devices from the Cisco Access Control System (ACS). The devices then forward the source IP-to-SGT binding to a TrustSec-hardware capable device for tagging and security group ACL (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
Cisco TrustSec uses AES-128 GCM and GMAC and is compliant with the 802.1AE standard. GCM is not supported on switches running the NPE or the LAN Base image.
Cisco TrustSec NDAC SAP is supported on trunk ports because it is intended only for network device to network device links, that is, switch-to-switch links. It is not supported on:
- Host facing access ports (these ports support MKA MACsec)
- Switch virtual interfaces (SVIs)
- SPAN destination ports
The switch also does not support security group ACLs.
You must set the Cisco TrustSec credentials to create the Cisco TrustSec network.
You can configure Cisco TrustSec link layer security in 802.1X mode or manual mode.
Configuring Cisco TrustSec MACsec
Following topics are discussed:
Note The sample configuration in the last section shows the AAA and the RADIUS configuration. Use this example to configure RADIUS and AAA before configuring switch-to-switch security.
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:
|
|
|
Step 1 |
cts credentials id
device-id
password
cts-password
|
Specifies the Cisco TrustSec credentials for this switch to use when authenticating with other Cisco TrustSec devices with EAP-FAST.
- id device-id — Specifies a Cisco TrustSec device ID for the switch. The device-id argument has a maximum length of 32 characters and is case sensitive.
- password cts-password — Specifies the Cisco TrustSec password for the device.
|
Step 2 |
|
(Optional) Displays Cisco TrustSec credentials configured on the switch. |
Step 3 |
copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
To delete the Cisco TrustSec credentials, enter the clear cts credentials privileged EXEC command.
This example shows how to create Cisco TrustSec credentials:
Switch# cts credentials id trustsec password mypassword
CTS device ID and password have been inserted in the local keystore. Please make
sure that the same ID and password are configured in the server database.
Switch# show cts credentials
CTS password is defined in keystore, device-id = trustsecchange-password Initiate password change with AAA server
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:
|
|
|
Step 1 |
|
Enters global configuration mode. |
Step 2 |
|
Enters interface configuration mode. |
Step 3 |
|
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 |
|
Exits Cisco TrustSec 802.1X interface configuration mode. |
Step 6 |
|
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:
Switch# configure terminal
Switch(config)# interface tengigabitethernet 1/1/2
Switch(config-if)# cts dot1x
Switch(config-if-cts-dot1x)# sap mode-list gcm-encrypt null no-encap
Switch(config-if-cts-dot1x)# exit
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:
|
|
|
Step 1 |
|
Enters global configuration mode. |
Step 2 |
|
Enters interface configuration mode. |
Step 3 |
|
Enters Cisco TrustSec manual configuration mode. |
Step 4 |
sap pmk
key [
mode-list
mode1 [
mode2 [
mode3 [
mode4 ]]]]
|
(Optional) Configures the SAP pairwise master key (PMK) and operation mode. SAP is disabled by default in Cisco TrustSec manual mode.
- key —A hexadecimal value with an even number of characters and a maximum length of 32 characters.
The SAP operation mode options:
- 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. |
Step 5 |
|
Prevents the interface from transmitting the SGT to the peer and is required in manual mode. Use the no form of this command when the peer is incapable of processing a SGT. |
Step 6 |
|
Exits Cisco TrustSec 802.1X interface configuration mode. |
Step 7 |
|
Returns to privileged EXEC mode. |
Step 8 |
show cts interface
[
interface-id |
brief
|
summary
]
|
(Optional) Verifies the configuration by displaying TrustSec-related interface characteristics. |
Step 9 |
copy running-config startup-config
|
(Optional) Saves your entries in the configuration file. |
This example shows how to configure Cisco TrustSec authentication in manual mode on an interface:
Switch# configure terminal
Switch(config)# interface tengiigabitethernet 1/1/2
Switch(config-if)# cts manual
Switch(config-if-cts-manual)# sap pmk 1234abcdef mode-list gcm-encrypt null no-encap
Switch(config-if-cts-manual)# no propagate sgt
Switch(config-if-cts-manual)# exit
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:
Switch(config)#
aaa new-model
Switch(config)# radius server ACS-1 address ipv4 10.5.120.12 auth-port 1812 acct-port 1813 pac key cisco123
Switch(config)# radius server ACS-2 address ipv4 10.5.120.14 auth-port 1812 acct-port 1813 pac key cisco123
Switch(config)# radius server ACS-3 address ipv4 10.5.120.15 auth-port 1812 acct-port 1813 pac key cisco123
Switch(config)#
aaa group server radius cts-radius
Switch(config-sg-radius)#
server name ACS-1
Switch(config-sg-radius)#
server name ACS-2
Switch(config-sg-radius)#
server name ACS-3
Switch(config-sg-radius)#
exit
Switch(config)#
aaa authentication login default none
Switch(config)#
aaa authentication dot1x default group cts-radius
Switch(config)#
aaa authentication network cts-radius group radius
Switch(config)#
aaa session-id common
Switch(config)#
cts authorization list cts-radius
Switch(config)#
dot1x system-auth-control
Switch(config)#
interface gi1/1/2
Switch(config-if)#
switchport trunk encapsulation dot1q
Switch(config-if)#
switchport mode trunk
Switch(config-if)#
cts dot1x
Switch(config-if-cts-dot1x)#
sap mode-list gcm-encrypt gmac
Switch(config-if-cts-dot1x)#
exit
Switch(config)#
interface gi1/1/4
Switch(config-if)#
switchport trunk encapsulation dot1q
Switch(config-if)#
switchport mode trunk
Switch(config-if)#
cts manual
Switch(config-if-cts-dot1x)#
sap pmk 033445AABBCCDDEEFF mode-list gcm-encrypt gmac
Switch(config-if-cts-dot1x)#
no propagate sgt
Switch(config-if-cts-dot1x)#
exit
Switch(config)#
radius-server vsa send authentication
Switch# cts credentials id cts-36 password trustsec123
Non-Seed Device:
Switch(config)# aaa new-model
Switch(config)# aaa session-id common
Switch(config)# dot1x system-auth-control
Switch(config)# interface gi1/1/2
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk
Switch(config-if)#
shutdown
Switch(config-if)# cts dot1x
Switch(config-if-cts-dot1x)# sap mode-list gcm-encrypt gmac
Switch(config-if-cts-dot1x)# exit
Switch(config)# interface gi1/1/4
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk
Switch(config-if)#
shutdown
Switch(config-if)# cts manual
Switch(config-if-cts-dot1x)# sap pmk 033445AABBCCDDEEFF mode-list gcm-encrypt gmac
Switch(config-if-cts-dot1x)#
no propagate sgt
Switch(config-if-cts-dot1x)# exit
Switch(config)# radius-server vsa send authentication
Switch# cts credentials id cts-72 password trustsec123