Cisco TrustSec: Обзор архитектуры и механизмов безопасности (EN)

Restrictions for Cisco TrustSec

Cisco TrustSec Overview Cisco TrustSec builds secure networks by establishing domains of trusted network devices. Each device in the domain is authenticated by its peers. Communication on the links between devices in the domain is secured with a combination of encryption, message integrity check, and data-path replay protection mechanisms.

Restrictions for Cisco TrustSec, on page 1 Information About Cisco TrustSec Architecture , on page 2 Device Identities, on page 4 Device Credentials, on page 5 User Credentials, on page 5 Protected Access Credential (PAC), on page 5 PAC Provisioning , on page 6 Deploying Devices in High Availability Setup, on page 6 PAC-less Authentication, on page 7 Configuring Cisco TrustSec Credentials, on page 7 Security Group-Based Access Control, on page 9 Authorization and Policy Acquisition, on page 14 Environment Data Download, on page 15 RADIUS Relay Functionality, on page 15 Link Security, on page 16 SXP for SGT Propagation Across Legacy Access Networks, on page 18 Layer 3 SGT Transport for Spanning Non-TrustSec Regions, on page 19 VRF-Aware SXP, on page 20 Feature History for Cisco TrustSec Overview, on page 20 Restrictions for Cisco TrustSec • Protected access credential (PAC) provisioning fails and remains in hung state, when an invalid device ID is specified.

Even after clearing the PAC, and configuring the correct device ID and password, PAC still fails. As a workaround, in the Cisco Identity Services Engine (ISE), uncheck the Suppress Anomalous Clients option in the Administration> System> Settings> Protocols> Radius menu for PAC to work. • Cisco TrustSec is not supported in FIPS mode when PAC is enabled. • Cisco TrustSec over Radsec is not supported. Cisco TrustSec Overview 1

Стр. 1

Information About Cisco TrustSec Architecture

• Cisco TrustSec cannot be configured on a pure bridging domain with the IPSG enabled. • System generated packets are not sent with Cisco TrustSec tag on the Cisco TrustSec manual link for the egress interface. Restrictions for configuring Cisco TrustSec in PAC-less mode: • PAC-less mode is only supported on ISE 3.4.x and later. • When the device is in PAC-less mode, all servers within the server group must be configured with the PAC-Less configuration (key ). Mixing configurations, such as having one server with a PAC key configuration and another with PAC-less configuration, is not allowed.

• In PAC-less mode, the Cisco TrustSec credential command with the device ID is the only parameterneeded to download environment data. However, SGACL requests do not require any credential information. • Device in PAC-Less mode can be identified by “cts-pac-less” attribute by radius debug. • IPv6 support for PAC-less is not available. • Multi-ISE support is limited to up to 2 ISEs. Information About Cisco TrustSec Architecture The Cisco TrustSec security architecture builds secure networks by establishing domains of trusted network devices. Each device in the domain is authenticated by its peers.

Communication on the links between devices in the domain is secured with a combination of encryption, message integrity check, and data-path replay protection mechanisms. Cisco TrustSec uses the device and user credentials acquired during authentication for classifying the packets by security groups (SGs) as they enter the network. This packet classification is maintained by tagging packets on ingress to the Cisco TrustSec network so that they can be properly identified for the purpose of applying security and other policy criteria along the data path.

The tag, called the security group tag (SGT), allows the network to enforce the access control policy by enabling the endpoint device to act upon the SGT to filter traffic. Note Cisco TrustSec IEEE 802.1X links are not supported on platforms supported in the Cisco IOS XE Denali (16.1.x to 16.3.x), Cisco IOS XE Everest (16.4.x to 16.6.x), and Cisco IOS XE Fuji (16.7.x to 16.9.x) releases, and hence only the Authenticator is supported; the Supplicant is not supported. The Cisco TrustSec architecture incorporates three key components:

• Authenticated networking infrastructure—After the first device (called the seed device) authenticates with the authentication server to begin the Cisco TrustSec domain, each new device added to the domain is authenticated by its peer devices already within the domain. The peers act as intermediaries for the domain’s authentication server. Each newly-authenticated device is categorized by the authentication server and assigned a security group number based on its identity, role, and security posture.

• Security group-based access control—Access policies within the Cisco TrustSec domain are topology-independent, based on the roles (as indicated by security group number) of source and destination devices rather than on network addresses. Individual packets are tagged with the security group number of the source. Cisco TrustSec Overview Information About Cisco TrustSec Architecture Cisco TrustSec Overview 2

Стр. 2

Information About Cisco TrustSec Architecture

• Secure communication—With encryption-capable hardware, communication on each link between devices in the domain can be secured with a combination of encryption, message integrity checks, and data-path replay protection mechanisms. The following figure shows an example of a Cisco TrustSec domain. In this example, several networking devices and an endpoint device are inside the Cisco TrustSec domain. One endpoint device and one networking device are outside the domain because they are not Cisco TrustSec-capable devices or because they have been refused access.

The authentication server is considered to be outside of the Cisco TrustSec domain; it is either a Cisco Identities Service Engine (Cisco ISE), or a Cisco Secure Access Control System (Cisco ACS). Figure 1: Cisco TrustSec Network Domain Example Each participant in the Cisco TrustSec authentication process acts in one of the following roles: • Supplicant—An unauthenticated device connected to a peer within the Cisco TrustSec domain, and attempting to join the Cisco TrustSec domain. • Authentication server—The server that validates the identity of the supplicant and issues the policies that determine the supplicant’s access to services within the Cisco TrustSec domain.

• Authenticator—An authenticated device that is already part of the Cisco TrustSec domain and can authenticate new peer supplicants on behalf of the authentication server. Cisco TrustSec Overview Information About Cisco TrustSec Architecture Cisco TrustSec Overview 3

Стр. 3

Device Identities

When the link between a supplicant and an authenticator first comes up, the following sequence of events typically occurs: 1. Authentication (802.1X)—The supplicant is authenticated by the authentication server, with the authenticator acting as an intermediary. Mutual authentication is performed between the two peers (supplicant and authenticator). 2. Authorization—Based on the identity information of the supplicant, the authentication server provides authorization policies, such as security group assignments and ACLs, to each of the linked peers. The authentication server provides the identity of each peer to the other, and each peer then applies the appropriate policy for the link. 3.

Security Association Protocol (SAP) negotiation—When both sides of a link support encryption, the supplicant and the authenticator negotiate the necessary parameters to establish a security association (SA). SAP is not supported on 100G interfaces. We recommend that you use MACsec Key Agreement protocol (MKA) with extended packet numbering (XPN) on 100G interfaces. Note When all three steps are complete, the authenticator changes the state of the link from the unauthorized (blocking) state to the authorized state, and the supplicant becomes a member of the Cisco TrustSec domain. Cisco TrustSec uses ingress tagging and egress filtering to enforce access control policy in a scalable manner.

Packets entering the domain are tagged with a security group tag (SGT) containing the assigned security group number of the source device. This packet classification is maintained along the data path within the Cisco TrustSec domain for the purpose of applying security and other policy criteria. The final Cisco TrustSec device on the data path, either the endpoint or network egress point, enforces an access control policy based on the security group of the Cisco TrustSec source device and the security group of the final Cisco TrustSec device.

Unlike traditional access control lists based on network addresses, Cisco TrustSec access control policies are a form of role-based access control lists (RBACLs) called security group access control lists (SGACLs). Ingress refers to packets entering the first Cisco TrustSec-capable device encountered by a packet on its path to the destination and egress refers to packets leaving the last Cisco TrustSec-capable device on the path. Note Device Identities Cisco TrustSec does not use IP addresses or MAC addresses as device identities. Instead, you assign a name (device ID) to each Cisco TrustSec-capable switch to identify it uniquely in the Cisco TrustSec domain.

This device ID is used for the following: • Looking up the authorization policy • Looking up passwords in the databases during authentication Cisco TrustSec Overview Device Identities Cisco TrustSec Overview 4

Стр. 4