Cisco TrustSec

This chapter explains configuring and enforcing Cisco TrustSec features: SGTs, SGACLs, inline tagging, SXP, and ISE integration on Cisco Catalyst 9800 controllers and APs to implement role-based, topology-independent access control.

Cisco TrustSec

A Cisco TrustSec solution is a network security architecture that

  • strongly identifies users, hosts, and network devices within the network

  • provides topology-independent and scalable access controls by classifying data traffic based on user or device roles, and

  • ensures data confidentiality and integrity by establishing trust among authenticated peers and encrypting network links.

The key component of Cisco TrustSec is the Cisco Identity Services Engine (ISE). Cisco ISE can provision switches with TrustSec Identities and Security Group ACLs (SGACLs). SGACLs may be configured manually on the switch.


Note

Before changing CTS server to a new one, manually clear the CTS environment data using the clear cts environment-data command. Running the show cts environment-data command will return updated data.

Feature History

Feature Name

Release

Description

Trustsec policy HA support for FlexConnect mode APs

Cisco IOS XE 17.18.2

 The feature ensures that CTS SGACL enforcement remains available and consistent during HA events such as Stateful Switchover (SSO) between wireless controllers. This provides uninterrupted security policy enforcement on Flex mode APs even during controller failover or redundancy events.

TrustSec support for Cisco Catalyst IW6300 Heavy Duty Series and 6300 Series Embedded Services APs

Cisco IOS XE 17.8.1

Enable and configure Cisco TrustSec Security Group ACL (SGACL) in FlexConnect and Flex+Bridge mode. SGACL enforcement on the controller is available for local and Bridge mode. Inline tagging and SXP are supported only in FlexConnect.

Support for SGT Inline Tagging Over Port-Channel Uplink

Cisco IOS XE 17.3.5a

SGT inline tagging over port-channel uplink is supported for Cisco Catalyst 9800-L, 9800-40, and 9800-80 Wireless Controllers.

If you downgrade to releases that do not support SGT inline tagging over port-channel, the port-channel may be suspended.

Cisco TrustSec features

This table lists the TrustSec features that will be implemented on TrustSec-enabled Cisco switches. Future releases will support more switches and provide additional TrustSec features.

Cisco TrustSec Feature Description
802.1AE Tagging (MACsec)

Protocol for IEEE 802.1AE-based wire-rate hop-to-hop Layer 2 encryption.

On MACsec-capable devices, your network traffic is encrypted when leaving one device, decrypted when entering the next device, while staying unencrypted inside the devices.

This feature is only available between TrustSec hardware-capable devices.
Endpoint Admission Control (EAC)

EAC authenticates each device or user connecting to the TrustSec domain. This usually happens at the access level switch. If authentication and authorization are successful, your device or user session receives a Security Group Tag. You can use 802.1X, MAC Authentication Bypass (MAB), or Web Authentication Proxy (WebAuth) with EAC.

Network Device Admission Control (NDAC)

With NDAC, each network device in your TrustSec domain verifies the credentials and trustworthiness of peer devices. NDAC uses an authentication framework based on IEEE 802.1X port-based authentication and 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 Group Access Control List (SGACL)

Security Group Access Control List (SGACL): An SGACL links a Security Group Tag with a policy that your devices enforce on SGT-tagged traffic leaving the TrustSec domain.

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 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, 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

Configure a device SGT manually (CLI)

Configure a device Security Group Tag (SGT) using commands when the authentication server is unavailable.

When the authentication server is accessible, it assigns an SGT to your device for packets originating from your device. If the authentication server is not available, configure an SGT manually. The server-assigned SGT is always used instead of your manual configuration if both are present.

Procedure

Step 1

Enter the global configuration mode.

Example:

Device# configure terminal

Step 2

Configure a WLAN policy profile and enter the wireless policy configuration mode.

Example:

Device(config)# wireless profile policy profile-policy

Step 3

Specify the Security Group Tag (SGT) number.

Example:

Device(config-wireless-policy)# cts sgt sgt-value

The valid values are from 0 to 65,535.

Step 4

Return to the global configuration mode.

Example:

Device(config-wireless-policy)# exit

Configure ISE for TrustSec (CLI)

Set up ISE to enable secure network access using TrustSec policies using commands.
This task involves configuring a device to communicate with an ISE server as a RADIUS server and integrating TrustSec authorization.

Procedure

Step 1

Enter the global configuration mode.

Example:

Device# configure terminal

Step 2

Specify the RADIUS server name.

Example:

Device(config)# radius server server-name

Step 3

Specify the primary RADIUS server parameters.

Example:

Device(config-radius-server)# address ipv6 ip-address

Step 4

Specify the authentication and encryption key used between the Device and the key string RADIUS daemon running on the RADIUS server.

Example:

Device(config-radius-server)# pac key key

Step 5

Return to the configuration mode.

Example:

Device(config-radius-server)# exit

Step 6

Create a radius server-group identification.

Example:

Device(config)# aaa group server radius server-group

Note

 

server-group refers to the server group name. The valid range is from 1 to 32 alphanumeric characters.

Step 7

Create a CTS authorization list.

Example:

Device(config)# cts authorization list mlist-name

Step 8

Create an authorization method list for web-based authorization.

Example:

Device(config)# aaa authorization network mlist-name group group-name

Note

 

Ensure that the ISE IP address configured on your controller is the same as the IP address configured on ISE ( Work Center > TrustSec > Components > Trustsec AAA Servers ).

Note

 

If the ISE version is 002.005(000.239), 002.004(000.357), 002.003(000.298), 002.002(000.470), 002.001(000.474), 002.000(001.130), or 002.000(000.306), use the access-session tls-version 1.0 command to download PAC from ISE. For other ISE versions, the above command is not required.

Verify Cisco TrustSec configuration

To display the wireless CTS SGACL configuration summary, use this command:

Device# show wireless cts summary

Local Mode CTS Configuration

Policy Profile Name               SGACL Enforcement     Inline-Tagging   Default-Sgt      
----------------------------------------------------------------------------------------
xyz-policy                        DISABLED              ENABLED          0                
wireless-policy1                  DISABLED              DISABLED         0                
w-policy-profile1                 DISABLED              DISABLED         0                
default-policy-profile            DISABLED              DISABLED         0                


Flex Mode CTS Configuration

Flex Profile Name                 SGACL Enforcement     Inline-Tagging   
-----------------------------------------------------------------------
xyz-flex                          DISABLED              ENABLED          
demo-flex                         DISABLED              DISABLED         
flex-demo                         DISABLED              DISABLED         
xyz-flex-profile                  DISABLED              DISABLED         
default-flex-profile              DISABLED              DISABLED

To display CTS-specific configuration status for various wireless profiles, use this command:

Device# show cts wireless profile policy xyz-policy

Policy Profile Name         		: xyz-policy
CTS
  Role-based enforcement         : ENABLED
  Inline-tagging                 : ENABLED
  	Default SGT		 : 100

Policy Profile Name          		: foo2
CTS
  Role-based enforcement         : DISABLED
  Inline-tagging                 : ENABLED
  Default SGT		         : NOT-DEFINED

Policy Profile Name           	        : foo3
CTS
  Role-based enforcement         : DISABLED
  Inline-tagging                 : DISABLED
  Default SGT			 : 65001

To display CTS configuration for a given wireless profile, use this command:

Device# show wireless profile policy detailed xyz-policy
 
Policy Profile Name           : xyz-policy
Description                   : 
Status                        : DISABLED
VLAN                          : 1
Client count                  : 0
Passive Client                : DISABLED
ET-Analytics                  : DISABLED
StaticIP Mobility             : DISABLED
!
.
.
.WGB Policy Params
  Broadcast Tagging           : DISABLED
  Client VLAN                 : DISABLED
Mobility Anchor List
  IP Address                                  Priority
CTS
  Role-based enforcement         : ENABLED
  Inline-tagging                 : ENABLED
  Default SGT	                  : NOT-DEFINED

Security Group Access Control List (SGACL)

A security group access control list (SGACL) is a network security policy mechanism that

  • enforces access control between groups of users, devices, and resources based on their assigned security group

  • simplifies policy management by using unique security group tags (SGTs) to dynamically control permissions, and

  • reduces administrative overhead by decoupling access policies from the network topology or addressing.

Security groups are defined by the administrator in Cisco Identity Services Engine (ISE). As new users and devices are added to the Cisco TrustSec domain, the authentication server assigns these new entities to the appropriate security groups. Cisco TrustSec assigns each security group a unique 16-bit number that is globally scoped within a Cisco TrustSec domain. The number of security groups on a wireless device is limited by the number of authenticated network entities. You do not need to configure the security group numbers manually.

After a device is authenticated, Cisco TrustSec tags each packet originating from that device with an SGT containing the device's security group number. The packet carries this SGT everywhere in the network, in the Cisco TrustSec header.

As the SGT contains the security group of the source, the tag can be referred to as the source SGT (S-SGT). The destination device is also assigned to a security group (destination SG) that can be referred to as the destination SGT (D-SGT), even though the Cisco TrustSec packet does not contain the security group number of the destination device.

You can control the operations that users can perform based on the security group assignments of users and destination resources, using the Security Group Access Control Lists (SGACLs). Policy enforcement in a Cisco TrustSec domain is represented by a permission matrix, with the source security group numbers on one axis and the destination security group numbers on the other axis. Each cell in the matrix body contains an ordered list of SGACLs, which specify the permissions that must be applied to packets originating from the source security group and destined for the destination security group. When a wireless client is authenticated, the controller downloads all the SGACLs in the matrix cells.

When a wireless client connects to the network, the client pushes all the ACLs to the controller .

Cisco TrustSec achieves role-based topology-independent access control in a network by assigning users and devices in the network to security groups and applying access control between the security groups. The SGACLs define access control policies based on the device identities. The security policy remains unchanged if the roles and permissions stay the same, even when the network topology changes. Assigning a user to an appropriate security group immediately grants the user permissions for that group when the user is added to the wireless group.

Role-based permissions reduce ACL size and simplify their maintenance. With Cisco TrustSec, the number of Access Control Entities (ACEs) that are configured is determined by the number of permissions specified, resulting in a much smaller number of ACEs.

For a list of Cisco APs that support SGACL, see the release notes.: https://www.cisco.com/c/en/us/support/wireless/catalyst-9800-series-wireless-controllers/products-release-notes-list.html


Note

Clients receive zero SGT value and DHCP clients receive an Automatic Private IP Addressing (APIPA) address when TrustSec policy “unknown to unknown” is denied in TrustSec matrix.

Clients receive correct SGT values and DHCP clients receive an IP address when TrustSec policy “unknown to unknown” is permitted in TrustSec matrix.

Supported SGACL

The scenarios supported for SGACLs on the Cisco Catalyst 9800 Series Wireless Controller are:

  • Wireless-to-wireless (within Enterprise network):

    • In FlexConnect mode with local switching, the egress AP enforces SGACL when a packet moves from a source wireless network to a destination wireless network.

    • In FlexConnect mode with central switching, SGACL enforcement is performed on the egress AP. To achieve this, the controller exports IP address to security group tag (IP-SGT) binding over SGT Exchange Protocol (SXP).

  • Wired-to-wireless (DC-to-Enterprise network): Enforcement occurs when a packet reaches the destination AP.

  • Wireless-to-wired (Enterprise network-to-DC): Enforcement occurs on the uplink switch when a packet reaches the ingress of the wired network.

Guidelines and restrictions of SGACL

These are the guidelines and restrictions of Security Group Access Control List (SGACL).

  • SGACL enforcement is carried out on the controller for local mode.

  • SGACL enforcement is carried out on an AP for flex-mode APs performing local switching.

  • SGACL enforcement for wireless clients is carried out either on the upstream switch or on the border gateway in a Branch-to-DC scenario.

  • SGACL enforcement is not supported for non-IP or IP broadcast or multicast traffic.

  • Per-WLAN SGT assignment is not supported. Static SGACL configuration on an AP is not supported.

  • SGACL enforcement is not carried out for control-plane traffic between an AP and the wireless controller (for upstream or from upstream traffic).

  • Non-static SGACL configurations are supported only for dynamic SGACL policies received from ISE.

  • In case of Allow List model, you need to explicitly allow DHCP protocol for the client devices to get the DHCP IP address and then request the controller for SGACL policies.

Enable SGACL on the AP (GUI)

Use the GUI to apply SGACL enforcement to APs as part of your security configuration workflow.

Procedure

Step 1

Choose Configuration > Tags & Profiles > Flex.

Step 2

Click Add.

Step 3

In the General tab, check the Inline Tagging and SGACL Enforcement check boxes and select the CTS profile name from the CTS Profile Name drop-down list.

Step 4

Click Apply to Device.

Enable SGACL on the AP (CLI)

Enable role-based access control on APs for enhanced network security using commands.

Note

Use the no form of the commands given below to disable the configuration. For example, cts role-based enforcement disables role-based access control enforcement for APs.

Before you begin

  • Security Group Access Control List (SGACL) on an AP is enabled only when the wireless controller is in FlexConnect mode.

  • Configure the cts manual command on the uplink port to send or receive a tagged packet.

Procedure

Step 1

Enter the global configuration mode.

Example:

Device# configure terminal

Step 2

Configure an RF profile and enter the RF profile configuration mode.

Example:

Device(config)# wireless profile flex flex-profile

Step 3

Enable role-based access control enforcement for the AP.

Example:

Device(config-wireless-flex-profile)# cts role-based enforcement

Step 4

Enable inline tagging on the AP.

Example:

Device(config-wireless-flex-profile)# cts inline-tagging

Step 5

Enable the CTS profile name and return to the global configuration mode.

Example:

Device(config-wireless-flex-profile)# cts profile profile-name
Device(config-wireless-flex-profile)# exit

Step 6

Configure a site tag and enter the site tag configuration mode.

Example:

Device(config)# wireless tag site site-name

Step 7

Configure a FlexConnect profile and return to the global configuration mode.

Example:

Device(config-site-tag)# flex-profile flex-profile-name
Device(config-site-tag)# exit

Step 8

Configure an AP and enter the AP profile configuration mode.

Example:

Device(config)# ap mac-address

Step 9

Map a site tag to an AP.

Example:

Device(config-ap-tag)# site-tag site-tag-name

What to do next

show cts ap sgt-info ap-name command to verify the SGACL configuration on the AP.

Policy enforcement

A policy enforcement mechanism is a network security control that

  • applies access control policies to network traffic using predefined rules

  • uses attributes such as Security Group Tags (SGTs) to dynamically determine permitted actions, and

  • enables context-based enforcement at key points within the network infrastructure.

Cisco TrustSec access control is implemented using ingress tagging and egress enforcement. At the ingress point to the Cisco TrustSec domain, the traffic from the source is tagged with an SGT containing the security group number of the source entity. The SGT is propagated across the domain with the traffic. At the egress point of the Cisco TrustSec domain, an egress device uses the security group of the destination entity (D-SGT) to determine the access policy to apply from the SGACL policy matrix.


Note

A Cisco AP must be in Listener mode or Both (Listener and Speaker) mode to enforce traffic because Listener mode maintains the complete set of IP-SGT bindings. After you enable enforcement on an AP, the corresponding policies are downloaded and pushed to the AP.

SGACL policies for guest wireless clients

A SGACL policy is an access control mechanism that

  • defines the network permissions for wireless guest clients

  • is enforced on the anchor controller in guest mobility scenarios, and

  • uses integration with Cisco ISE for policy download and enforcement.

When a client joins the wireless network (WLAN), its session is managed by the Cisco Catalyst 9800 Series Wireless LAN Controller that the AP is connected to is the foreign controller. Auto-Anchor Mobility allows a specific WLAN (for example, Guest WLAN) to be anchored to a particular controller, regardless of the client’s entry point into the network. Auto-Anchor Mobility is a wireless guest service in which all guest traffic tunnels back to the DMZ controller, regardless of the client's association point on the network.

In case of Auto-Anchor mobility, these apply to Cisco TrustSec support:

  • Classification: Occurs during authentication and hence on Foreign for Layer 2 security WLANs and on Anchor for Layer 3 security cases.

  • Propagation: Always occurs at the Anchor controller where the client traffic enters the wired network.

  • Enforcement: SGACL download and enforcement occur on the Anchor controller; the Anchor controller must have connectivity to Cisco Identity Services Engine (ISE) and be registered as a Network Access Server (NAS). Enforcement is not supported on the Foreign controller even if the enforcement CLI is configured there.

This feature is supported in local mode and in FlexConnect Central Switching of the controller. FlexConnect mode with local switching and Fabric mode are not supported in guest scenarios because traffic does not pass through the controller.

Roaming of a guest client occurs only at the Guest Foreign controller, and the Guest Anchor remains fixed. The two types of supported roaming are inter-controller roaming and intra-controller roaming. Roaming during WebAuth pending is a special case that is also supported for Central Web Authentication (CWA) and Local Web Authentication (LWA).

Enable SGACL policy enforcement globally (CLI)

Enforce Cisco TrustSec SGACL policies on all routed interfaces to provide unified access control for both IPv4 and IPv6 traffic using commands.

You must enable SGACL policy enforcement globally on Cisco Catalyst 9800 Series Wireless Controller. The same configuration commands that are used for enforcement of IPv4 traffic apply for IPv6 traffic as well.

Procedure

Step 1

Enter the global configuration mode.

Example:
Device# configure terminal

Step 2

Enable Cisco TrustSec SGACL policy enforcement on routed interfaces.

Example:
Device(config)# cts role-based enforcement

Enable SGACL policy enforcement per interface (CLI)

Enforce access control policies on selected network interfaces for enhanced security using SGACLs using commands.

After enabling the SGACL policy enforcement globally, enable Cisco TrustSec-on the uplink interfaces.

Procedure

Step 1

Enter the global configuration mode.

Example:
Device# configure terminal

Step 2

Specify interface on which to enable or disable SGACL enforcement.

Example:
Device(config)# interface gigabitethernet interface number

Step 3

Enable Cisco TrustSec SGACL policy enforcement on routed interfaces.

Example:
Device(config-if)# cts role-based enforcement

Step 4

Verify that SGACL enforcement is enabled.

Example:
Device(config-if)# do show cts interface

Inline tagging

An inline tag is a transport mechanism that

  • carries the source SGT in packet headers as wireless traffic moves through the network

  • enables enforcement of Security Group Access Control Lists (SGACLs) by controllers, and

  • supports both centrally and locally switched wireless deployments.

There are two types of transport mechanisms: central switching and local switching.

  • For central switching, the controller performs inline tagging of all packets sourced from wireless clients associated with the controller by tagging these packets with the Cisco Meta Data (CMD) tag. For packets inbound from the distribution system, inline tagging also requires the controller to strip the CMD header from the packet to identify the S-SGT tag. Afterward, the controller forwards the packet, which includes the S-SGT, for SGACL enforcement.

  • To transmit locally switched traffic, an AP performs inline tagging for packets that are associated with the AP and sourced from clients. To receive traffic, the AP handles both locally and centrally switched packets, uses the S-SGT tag, and applies the SGACL policy.

When wireless Cisco TrustSec is enabled on the controller , enabling and configuring SXP to exchange tags with the switches is optional. Both wireless Cisco TrustSec and SXP modes are supported; however, there is no use case for enabling both wireless Cisco TrustSec (on an AP) and SXP concurrently.

Consideration and restriction for inline tagging over port-channel

  • Configure the cts manual command on port-channel and its member interfaces to send or receive a tagged packet.

  • If you downgrade to Cisco IOS XE releases that do not support inline tagging over port-channel, the port-channel may be suspended.


    Note

    Inline tagging over port-channel is supported in Cisco IOS XE 17.3.5 17.6.3 17.8.1 releases.

Configure SGACL, inline tagging, and SGT in local mode (GUI)

Configure SGACL enforcement, inline tagging, and default SGT values in local mode through the GUI.
Enable Security Group Access Control Lists (SGACL), inline tagging, and assign default Security Group Tags (SGT) on a policy profile operating in local mode.
Procedure

Step 1

Choose Configuration > Tags & Profiles > Policy.

Step 2

Click the Policy Profile Name. The Edit Policy Profile is displayed.

Step 3

Choose General tab.

Step 4

In the CTS Policy settings, check or uncheck the Inline Tagging and SGACL Enforcement check boxes, and enter the Default SGT value.

Step 5

Click Update & Apply to Device.

Configure SGACL, inline tagging, and SGT in local mode (CLI)

Use this procedure to configure Secure Group Access Control Lists (SGACL), inline tagging, and Security Group Tag (SGT) enforcement in local mode on a controller using commands.
Procedure

Step 1

Enter the global configuration mode.

Example:
Device# configure terminal

Step 2

Create a policy profile for the WLAN.

Example:
Device(config)# wireless profile policy profile-name

Step 3

Enable CTS inline tagging.

Example:
Device(config-wireless-policy)# cts inline-tagging

Note

 

Configure the cts manual on the physical interface. If the cts manual is configured on the physical interface and cts inline-tagging is not enabled, packets remain tagged at egress in the controller.

Step 4

Enable CTS SGACL enforcement.

Example:
Device(config-wireless-policy)# cts role-based enforcement

Step 5

(Optional) Set the default Security Group Tag (SGT).

Example:
Device(config-wireless-policy)# cts sgt sgt-value

Note

 

SGT is required for a user session only when the client uses open authentication, and not the ISE server.