Overview of AAA


AAA is implemented on the switch for two purposes:

  • Switch Management

  • Identity-based Network Services (IBNSs)

Switch Management

Just like routers, switches can be configured for AAA implementation for management purposes. The configuration may differ based on which mode is running (Native IOS or Hybrid). The primary focus of this chapter is the Hybrid mode (Cat OS), as the Native IOS AAA implementation on the switch is the same as Router IOS (see Chapter 9, "Troubleshooting AAA on IOS Routers," for details for device management purpose).

Identity-Based Network Services (IBNSs)

Identity-based Network Services (IBNSs), a Cisco initiative, is a superset of IEEE 802.1x functionality. IBNS is a systems framework for delivering local-area network (LAN) authentication, a part of which is using 802.1x. 802.1 x works in link layer (Layer 2) of the OSI model.

Figure 11-1 shows a typical IBNS network in which phones, laptops, and desktop computers may be connected to the switch ports, and some or all of the ports on the switch may be running dot1x authentication. If the IBNS is implemented on the switch port, devices must be authenticated before receiving connectivity.

Figure 11-1. Typical Setup of IBNS in Switch Environment


IBNS is built upon three main components: IEEE 802.1x Framework, Extensible Authentication Protocol (EAP), and Remote Authentication Dial-In User Service (RADIUS) protocol. Although EAP is used for actual authentication, EAP encapsulation over LANs (EOPL), which is defined by the IEEE 802.1x standard and RADIUS protocol, is used as the transport medium for carrying EAP packets between the Supplicant and the Authentication Server. So, to understand the IBNS concept completely, you need to understand all three components that are the building blocks of the IBNS technology solution as explained in the sections that follow.

IEEE 802.1x Framework

IEEE 802.1x (also known as dot1x) is a standard set by the IEEE 802.1 working group. It's a framework designed to address and provide port-based access control using authentication. The 802.1x authenticates network clients using information unique to the client and with credentials known only to the client. This service is called port-level authentication because, for security reasons, it is offered to a single endpoint for a given physical port. The 802.1x framework defines the following three roles in the authentication process as depicted in Figure 11-2:

Figure 11-2. 802.1x Authentication Sequence


  • Supplicant The endpoint that is seeking network access is known as the supplicant. The supplicant may be an end user device or a standalone device, such as an IP phone. The device must be running 802.1x-compliant software.

  • Authenticator The device to which the supplicant directly connects and through which the supplicant obtains network access permission is known as the authenticator. The authenticator performs the following operations:

    - Requests identity information (credentials) from the supplicant

    - Verifies credentials using the RADIUS server

    - Relays a response to the supplicant.

    - Encapsulates and decapsulates the EAP frames and interacts with the RADIUS server as an AAA client.

  • Authentication server Performs the actual authentication of the supplicant. The authentication server is a RADIUS server that validates the identity of the supplicant and notifies the switch whether or not the supplicant is authorized to access the LAN and switch services. The authentication server can also send information to the switch about the Virtual Local Area Network (VLAN) that is assigned to the user.

In Table 11-1, the terminology for different components is mapped to AAA terms for your understanding.

Table 11-1. IEEE 802.1x Terminology Mapped to AAA Terminology

IEEE Terms

AAA Terms

Supplicant

Client

Authenticator

Network Access Device

Authentication Server

AAA/RADIUS Server


The authentication process, which consists of exchanges of Extensible Authentication Protocol (EAP) messages, occurs between the supplicant and the authentication server. The authenticator acts as a transparent relay (middleman) for this exchange and as a point of enforcement for any policy configuration instructions the authentication server may send back as a result of the authentication process.

The IEEE 802.1x specification defines a new link layer protocol, 802.1x, which is used for communications between the supplicant and the authenticator. Communications between the supplicant and authentication server also leverage the RADIUS protocol carried over standard UDP.

Figure 11-3 shows a dot1x frame that contains the EAP information.

Figure 11-3. dot1x Frame Format


EAP encapsulation over LANs (EAPOL)

EAP over LAN carries EAP packets between the supplicant and the authenticator (switch). Figure 11-4 shows the EAPOL frame format.

Figure 11-4. EAPOL Frame Format


Depending on the functions being performed, the EAPOL can be one of the following types:

  • EAPOL-Start

  • EAPOL-Logoff

  • EAP-Packet

  • EAPOL-Key

  • EAPOL-Encapsulated-ASF-Alert

At this point you can explore the basic operation of the 802.1x framework as explained in the following section.

Standard 802.1x Operation

When 802.1x is enabled on a switch port, the port is set to an unauthorized mode, allowing only EAPOL traffic to pass through the switch port (see Figure 11-5).

Figure 11-5. Standard 802.1x Operation


Because of the default operation of 802.1x, the Media Access Control (MAC) address of a machine is unknown until a supplicant transmits EAPOL frames, or until the port is authorized after successful authentication.

As Figure 11-5 shows, only EAPOL traffic can be processed by a switch port before it is authenticated via 802.1x. Once a port is authorized, only one MAC address can send traffic into the network. Any other MAC address on the wire is a security violation on the port. This operation ensures the validity of the authenticated session.

The IEEE 802.1x standard defines a client/server access control and authentication protocol that restricts unauthorized devices from connecting to a LAN through publicly accessible ports. The 802.1x protocol controls network access by creating two distinct virtual access points at each port. One access point is an uncontrolled port; the other is a controlled port. All traffic through the single port is available to both access points. 802.1x authenticates each user device that is connected to a switch port. It can assign the port to a VLAN before making available any services that are offered by the switch or the LAN. Until a device is authenticated, 802.1x access controls restrict traffic through the port to which the device is connected; only EAPOL traffic is permitted. After authentication is completed, enterprise traffic is allowed through the port.

Extensible Authentication Protocol (EAP)

EAP was initially developed for Point-to-Point Protocol (PPP) authentication. It is a flexible protocol used to carry arbitrary authentication information. It typically rides on top of another protocol such as 802.1x or RADIUS, as Figure 11-3 shows. This protocol is defined by RFC 2284 and 3748 (3748 made 2284 obsolete). Figure 11-6 shows the format of an EAP frame.

Figure 11-6. EAP Frame Format


In Figure 11-6, the code can be any of the following four values:

  • Request This code is used when the packet is sent from the authenticator (switch) to the authentication server.

  • Response This code is used when the authentication server responds back to the authenticator with success or failure.

  • Success When the user is successfully authenticated, this code is used to inform the authenticator.

  • Failure If the user fails either due to bad username or password, this code is used.

The identifier is used to match responses with requests, and format of the data field is determined by the code field.

The following is a list of authentication methods used with EAP:

  • Challenge-response-based

    - EAP-MD5 Uses MD5 based challenge-response for authentication.

    - LEAP Uses username/password authentication.

    - EAP-MSCHAPv2 Uses username/password MSCHAPv2 challenge-response authentication.

  • Cryptographic-based

    - EAP-TLS Uses x.509 v3 PKI certificates and the TLS mechanism for authentication. (TLS stands for Transport Layer Security.)

  • Tunneling methods

    - PEAP Protected EAP tunnel mode EAP encapsulator; tunnels other EAP types in an encrypted tunnel, much like Web-based SSL.

    - EAP-TTLS Other EAP methods over an extended EAP-TLS encrypted tunnel.

    - EAP-FAST Recent tunneling method designed to avoid the requirement of certificates for deployment.

  • Other

    - EAP-GTC Generic token and OTP authentication.

EAP implementation in the Microsoft environment is well explained in the following link: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/eap/eap/about_extensible_authentication_protocol.asp

RADIUS IN 802.1x

Just as dot1x carries the EAP packet between the supplicant to the authenticator, RADIUS carries the EAP packet between the authenticator to the authentication server. The IEEE 802.1X RADIUS Usage Guidelines are defined by RFC 3580. Figure 11-7 shows a RADIUS packet with the EAP packet in it.

Figure 11-7. Format of a RADIUS Packet with dot1x


RADIUS may carry policy instructions back to the authenticator in the form of Attribute Value (AV) pairs to the switch as shown in Figure 11-8.

Figure 11-8. Format of a RADIUS Packet with AV Pairs with dot1x


What Is Authenticated

In 802.1x framework, both user and machine may be authenticated if configured. To understand how that may affect the Windows login procedure, examine the sequence of events that happens when Windows 2000 or XP boots up with user and machine authentication turned on:

1.

Power On.

2.

Load NDIS Drivers.

3.

802.1x Machine Auth.

This step is skipped if machine authentication is turned off. Note that this step occurs before receiving the DHCP IP address. So, if the machine authentication fails, the machine doesn't receive the IP address.

4.

Dynamic Host Configuration Protocol (DHCP).

5.

Setup secure channel to Domain Controller (DC).

6.

Download applicable domain-configured Computer Group Policy Objects (GPOs).

7.

Apply Computer Group Policy Objects.

8.

Present the Graphical Identification and Authentication (GINA) (Ctrl-Alt-Del) login to the end user.

Windows Domain Authentication occurs.

At this stage, 802.1x user authentication occurs when the user credentials are provided either in the form of a username/password or through a certificate.

If user authentication fails, even though the machine authentication succeeds, actual user traffic will not be allowed. The only traffic allowed is through the secured tunnel to the domain controller to perform the 802.1x user authentication.

9.

Machine queries the DHCP server to get the IP address, default gateways, and so on, using DHCP.

Note this is the second DHCP query after user authentication. In this step, the IP address can be assigned based on the VLAN assignment.

Machine Authentication

Microsoft introduced machine authentication to allow the supplicant to authenticate at boot time using the identity and credentials of the computer, so that the client could establish the required secure channel to update and participate in the domain GPO model. Machine authentication allows the computer to authenticate itself to the network using 802.1x, just after a PC loads device drivers at boot time. At boot time, the Windows OS uses machine authentication to authenticate using 802.1x, and to subsequently communicate with Windows domain controllers to pull down machine group policies. This alleviates the problem of domain GPOs being broken by the introduction of 802.1x. The identity that is used is the actual name of the computer as it exists in the active directory. The credentials used to authenticate the computer can be password-based or PKI certificate-based, depending on the EAP type used. Protected Extensible Authentication Protocol (PEAP) with EAP-Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2) can perform machine authentication using the machine password, which is known to each machine and to the active directory. PEAP with EAP-TLS and EAP-TLS can perform machine authentication using a machine certificate.

Note

It is not mandatory to configure machine authentication with AD. But if you don't configure machine authentication, it breaks group and system policies.


Authorization

Authorization provides the ability to enforce policies on identities. The most basic authorization in 802.1x, and IBNS is the ability to allow or disallow access to the network at the link layer by applying Dynamic VLAN assignment based on the identity or a group of identities. In addition, MAC-based filtering is also possible to provide more granular control.

Accounting

802.1x and RADIUS Accounting are similar to other accounting and tracking mechanisms that already exist using RADIUS, with the additional capability of operating through 802.1x as an L2 transport. Accounting and tracking information can include basic billing, usage, and various events related to any 802.1x ports.

The combination of 802.1x with RADIUS Accounting enhances the overall value of IBNS by providing the additional capabilities for network session awareness and the notion of an authenticated identity into an enterprise management infrastructure.

RADIUS Accounting Session Start/Stop Records

Accounting start records are sent only at the notification of an authenticated session. Accounting takes place after a RADIUS-Accept packet is sent by an authentication server toward an authenticator, and an EAPOL-Success frame is sent by an authenticator toward a supplicant. Start records for accounting are thus sent under the following conditions:

  • When an 802.1x authentication succeeds

  • When an 802.1x re-authentication succeeds

Note

When re-authentication succeeds, this changes the value of Attribute [40] (Acct-Status-Type) for all Cisco Catalyst switches. Instead of the value of this AV pair being Start, it becomes Interim Update. For more information on AV pairs, see the sections that follow.


Accounting stop records are sent under multiple conditions. More conditions can affect the determination of the end of a session than the beginning of a session, and the reliance on lower layer protocols (such as 802.1x). Accounting stop records are sent once the following conditions are met:

  • Explicit session termination EAPOL-Logoff processing of an authenticated session. Note that an EAPOL-Logoff frame originated by a supplicant in this condition must be received by a switch to successfully terminate the session and process a stop record.

  • Implicit session termination This can occur when a link-down event occurs on an 802.1x-enabled switch port, which includes one of the following scenarios:

    - Reboot of PC or supplicant

    - Switch port is administratively shut down

    - Cable is unplugged

Note

RADIUS Accounting stop records are not sent when a switch reloads for any reason. They are also not sent when 802.1x fails authentication or re-authentication.


RADIUS Accounting and Attribute-Value Pairs

RADIUS Accounting leverages information contained in start and stop records. The information contained in these packets is in the form of AV pairs. RADIUS Accounting contains AV pairs that provide information about an authenticated session that can be further used by the ACS or any network system. In addition to authentication and authorization, RADIUS was originally extended to provide a technique for collecting accounting information specific to end user communication sessions and storing it on an accounting server. If an 802.1x authenticator is configured and enabled for RADIUS Accounting, it forwards start records to the accounting server as soon as a connection is established, and then collects information about the session. When the session is terminated, the authenticator sends a stop record to the server indicating that the session is over. Both start and stop records are acknowledged by the RADIUS server.

Extension of IEEE 802.1x Standard by Cisco IBNS Initiative

Cisco supports the IEEE 802.1x standard completely and offers some important extensions with the help of RADIUS Authentication, Authorization, and Accounting. Some of these important features are explained in the following sections.

802.1x with VLAN Assignment

With the standard 802.1x implementation, authenticated users are placed in the preconfigured VLAN assigned to the port. Cisco IBNS offers the capability to dynamically assign VLANs to ports based on user identity. This feature lets you maintain a username-to-VLAN association with a RADIUS server. After successful 802.1x authentication, the RADIUS server sends the VLAN to the switch for a specific user or device, and the switch configures the attached port for the specified VLAN. Thus, 802.1x-authenticated ports are assigned to a VLAN based on the identity of the user or the device. In Native IOS, switches must be configured for RADIUS authorization, but in Cat OS, RADIUS authorization configuration is not required. RADIUS authentication is sufficient to apply the dynamically downloaded VLAN to the switch port.

802.1x with Port Security

Single host mode is the default for 802.1x implementation on the access port of the switch. So, after the supplicant is successfully authenticated, the MAC is known to the switch. Hence, additional devices trying to connect will result in port violation.

802.1x with Voice VLAN ID

Based on the default operation of 802.1x as explained in the section entitled "Standard 802.1x Operation," traffic from a single host is allowed on the wire. Thus, voice traffic would be not allowed, and this would break the deployment of IP phones. Cisco now allows voice traffic from an auxiliary VLAN without 802.1x authentication when the switch recognizes via CDP that a Cisco phone is attached to the port. This operation is designed to allow CDP from an IP phone, regardless of the 802.1x state on a port. This has changed the default operation of 802.1x on any Multi-VLAN Access Port (MVAP). CDP packets now are allowed to enter a switch port, regardless of the 802.1x state of the port. CDP frames are sent untagged by an IP Phone and arrive at a switch in the access VLAN. So, like EAPOL, CDP frames are then passed on for normal processing on the uncontrolled port.

802.1x Guest VLAN

Devices in the network that do not have the 802.1x client cannot authenticate on the switch; hence, these devices are assigned to the guest VLAN, if a guest VLAN is configured on the switch ports where these devices are connected. Examples of such devices are printers, IP phones, and so on. This feature also helps organizations migrate toward 802.1x implementations by allowing network access to devices that are not yet enabled for 802.1x. With this feature enabled, users trying to connect to the network that do not have an 802.1x-compatible device are placed in the guest VLAN.

High Availability for 802.1x

For modular switches (Cat 6500 series switches for example), this feature offers synchronization of run-time 802.1x port security information between active and standby supervisors. This maintains the state information of the port security, if the active supervisor engine fails, on the secondary engine.

802.1x with ACL Assignment

Based on 802.1x user's authentication, it is possible to dynamically assign an access control policy to an interface on the switch. You can use this feature to restrict users to certain segments of the network, limit access to sensitive servers, or even restrict the protocols and applications used. This feature is available on the selective switch, and requires RADIUS authorization to be turned on.

Access Restrictions for 802.1x

You can accomplish additional access restrictions with the flexibility of Access Restriction configuration on the CS ACS server. Following is the list of various methods available for the access restrictions:

  • Time-of-day and day-of-week restrictions

  • Network Access Server (NAS) IP filtering, which restricts user and port access based on the NAS IP address

  • MAC address filtering, which restricts device authentication based on the MAC address



Cisco Network Security Troubleshooting Handbook
Cisco Network Security Troubleshooting Handbook
ISBN: 1587051893
EAN: 2147483647
Year: 2006
Pages: 190
Authors: Mynul Hoda

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net