802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman © 2006 www.netcerebral.com Final Version 1.0
Oct 08, 2014
802.1x Port Authentication
Feasibility Study / Proposed Plan
Gary Freeman © 2006
www.netcerebral.com
Final Version 1.0
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 2
Table Of Contents
1 EXECUTIVE SUMMARY ..................................................................................................... 3
1.1 OVERVIEW .............................................................................................................................. 3 1.2 PURPOSE ................................................................................................................................. 3 1.3 SCOPE OF THIS REPORT: ......................................................................................................... 3 1.4 THE BENEFITS OF EXISTING “OPEN” SWITCH PORT ACCESS ................................................. 4 1.5 THE DRAWBACK OF EXISTING “OPEN” SWITCH PORT ACCESS ............................................. 4 1.6 EXISTING THREATS TO CORPORATE NETWORK: .................................................................... 4 1.7 ACRONYMS AND ABBREVIATIONS .......................................................................................... 5
2 TECHNOLOGY SUMMARY ................................................................................................ 6
2.1 THE 802.1X SOLUTION:........................................................................................................... 6 2.2 PROS AND CONS OF METHODS FOR SECURING LAN ACCESS ............................................... 6 2.3 802.1X DEVICE ROLES ............................................................................................................ 7 2.4 BENEFITS OF DEPLOYING 802.1X ........................................................................................... 7 2.5 DIAGRAM: PORT AUTHENTICATION WITH 802.1X .................................................................. 8 2.6 HOW PORT AUTHENTICATION WITH 802.1X WORKS ............................................................. 8 2.7 PEAP OVERVIEW .................................................................................................................... 9 2.8 MS-CHAP V2 OVERVIEW ...................................................................................................... 9 2.9 PEAP WITH MS-CHAP V2 OPERATION................................................................................ 10 2.10 PEAP SUPPORT IN WINDOWS ............................................................................................. 10
3 FEASIBILITY STUDY ......................................................................................................... 11
3.1 FUNCTIONAL OBJECTIVE ...................................................................................................... 11 3.2 ASSUMPTIONS AND CONSTRAINTS ....................................................................................... 11 3.3 MATERIALS AND METHODS .................................................................................................. 12
4 RECOMMENDATIONS AND CONCLUSION ................................................................. 18
4.1 RECOMMENDATION SUMMARY ............................................................................................ 18 4.2 PILOT IMPLEMENTATION BEST PRACTICES .......................................................................... 18 4.3 RESOURCE ROLES AND RESPONSIBILITIES ........................................................................... 18 4.4 OPERATIONAL REQUIREMENTS ............................................................................................ 19 4.5 PRODUCTION CONFIGURATION REQUIREMENTS .................................................................. 20 4.6 PRODUCTION IMPACT: PILOT ................................................................................................ 21 4.7 FUTURE CONSIDERATIONS FOR 802.1X ................................................................................ 21 4.8 REFERENCES ......................................................................................................................... 22
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 3
1 Executive Summary
1.1 Overview
COMPANY-IT Network Services has worked diligently to provide ongoing support and
availability to the numerous workgroups within the Company Group of Companies. This is
achieved by replacing hubs with Cisco switches in areas with a large end-user population,
providing DHCP, DNS and WINS services to a majority of LAN users nationally and ensuring
that all workgroup switch ports remain open to accommodate the ease of connectivity to the
corporate LAN for Field Services.
However, security has been a challenge for LAN segments, as rogue equipment can be
connected to the network and can thwart efforts to contain viruses and other attacks as they
themselves can be infected and roam with users making it impossible to track.
The latest open standard protocol for port-based authentication, 802.1x, provides a roadmap
for implementing improved switch port security. Not surprisingly, an authentication server -
long a cornerstone of remote access security - plays a pivotal role in securing an 802.1x port
authentication.
1.2 Purpose
The purpose of this document is to:
• Outline the specific issues with COMPANY-owned switch port access, and describes
how 802.1x addresses them,
• Describes the role of an authentication server and 802.1x security methods in
securing user access to the corporate network,
• Propose in detail the necessary equipment, versions of code and the required roles
and responsibilities to support an 802.1x environment,
• Define other purposes for 802.1x in the COMPANY-IT Network environment.
1.3 Scope of This Report:
The scope of this report is to report findings in the feasibility of 802.1x Port Authentication
within the existing COMPANY-IT LAN architectures, associated requirements, summary of
costs and any other information specific to a corporate implementation of a 802.1x standard.
This document is limited to 802.1x Port Authentication on Cisco Access Layer Workgroup
Switches used by employees to access the corporate LAN. This report does no address any of
the access layers used in the corporate data centers for server connectivity. Other security
measures by way of administrative policies will address switch port access in the data
centers. The integrated 802.1x support is currently only available in the Windows XP Home
and Professional Editions Operating Systems and all other Windows, UNIX and MAC
Operating Systems require additional client software.
Although Cisco has a phrase for their latest initiatives for IEEE 802.1x call Identity-Based
Networking Services, this is out of scope for the testing as it requires all Cisco components
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 4
including the Cisco ACS RADIUS server to enforce the policies on the switch and at for the
user.
Also, although there will be some mention of tests which involved both Cisco Switches and
Avaya 802.11b/g Access Points, this recommendation will address Cisco Switches specifically.
1.4 The Benefits of Existing “Open” Switch Port Access
With the current deployment of workgroup switches in all of the Company environments that
are managed by COMPANY-IT, the access-layer switches facing users in Call Centers and
business offices are configured to accept any network attached device. This allows the users
to connect to floor jacks at their workstations, which in turn connects them to the network
and then they are given a DHCP server IP address so that they can use the resources available
to them with the Company Corporate Network (fondly referred to as “Black”).
This ease of connectivity allows various business offices to shuffle their users from pod to pod
or even to different floors in places like 85x York Mills or the 333/OMP Campus.
This current feature in our network also allows visitors and vendors to connect to our
network without any pre-authorization and connect via VPN to their offices or check there
email over the Internet.
1.5 The Drawback of Existing “Open” Switch Port Access
The predominant security concerns with the existing corporate access to the Local Area
Network design is the lack of Authentication, Authorization and Accounting (AAA) at the port
level. Rogue equipment can be connected to the network and can subsequently receive a
DHCP-offered address and access any resource across the WAN (providing it’s within the
trusted Black network).
This sort of “open” access method lends itself to excessive administration overhead during
Security Incidents where network virus attacks are concerned as there is no accounting for
what’s actually connected to the COMPANY-owned WAN and Field Services must be
deployed to locate the device and its owner.
1.6 Existing Threats to Corporate Network:
• Users connecting rogue equipment to the corporate LAN.
• No alerts are generated for rogue connections to the network and unauthorized users
are allowed access to all VLANs.
• Vendor laptops infected by viruses cannot be quarantined or even located before the
malicious payload is released into the WAN.
• Users can create their own workgroups on the “Black” network and not have to
authenticate against the Active Directory to have file shares, print spools or any other
service controlled by COMPANY.
• Users can move themselves from switch to switch without any audit trail of where
they’ve been connected to the network in the past.
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 5
1.7 Acronyms and Abbreviations
EAP – Extensible Authentication Protocol
PEAP – Protected EAP
Dot1x – Cisco’s command line abbreviation for 802.1x
AAA – Authentication, Authorization and Accounting
WINS – Windows Naming Services
DNS – Domain Name Service
DHCP – Dynamic Host Configuration Protocol
RADIUS – Remote Authentication Dial-In User Service
MSCHAPv2 – Microsoft Challenge/Handshake Authentication Protocol
PKI – Public Key Infrastructure
EAPOL – EAP over LAN
TLS – Transport Layer Security
POC – Proof Of Concept
Company – ACME Corporate XP desktop
VLAN – Virtual LAN segment partitioned on a switch
IOS – Cisco’s Internetworking Operating System
CatOS – Cisco’s Catalyst switch Operating System
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 6
2 Technology Summary
2.1 The 802.1x Solution:
IEEE 802.1x is an open-standards-based protocol for authenticating network clients (or ports)
on a user-ID or device-ID basis. This process is called “portlevel authentication”. The
authentication is done with RADIUS and separates it into three distinct groups: the
Supplicant, Authenticator, and Authentication Server (RADIUS).
IEEE 802.1X provides automated user identification, centralized authentication, key
management, and provisioning of LAN connectivity. It even provides support for roaming
access for LAN, Wireless and VPN users.
Cisco’s marketing term for the combined technologies that authenticates users’ equipment
with the IEEE802.1x through Cisco LAN switches or WLAN equipment is referred to as
Identity-Based Network Services (IBNS). In the open-standards community 802.1x is fondly
referred to as “AUTH-X”.
2.2 Pros and Cons of Methods for Securing LAN Access
Product Pros Cons
Access
control lists
Using Layer 3 and Layer 4 information, switches
can block or allow network access based on server
and client IP addresses. Lets administrators assign
roles to users based on their access needs.
Can be hard to manage,
requiring configurations to be
set across many network
devices.
Virtual LANs Virtual LANs can be used to segregate users into
groups, allowing only users to see resources they
need on the network.
Not completely secure and
inter-VLAN routing can cause
network congestion.
802.1x An IEEE authentication protocol that can be used
to force network clients to log on to the network
before accessing any devices or resources.
While widely adopted on
switch gear, only Microsoft
Windows XP clients support the
protocol.
Rate limiting The technology lets users throttle bandwidth to an
Ethernet switch port. It can be used to limit
certain types of traffic — such as peer-to-peer
traffic, or denial-of-service attack patterns — to
levels that don’t affect network performance.
Mostly a proprietary
technology that’s supported on
more expensive LAN gear.
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 7
2.3 802.1x Device Roles
• Supplicant—Requests access to the LAN and switch services and responds to requests
from the switch. The workstation must be running 802.1x-compliant software.
• Authentication server—Performs the actual authentication of the host. The
authentication server validates the identity of the host and notifies the switch
whether or not the host is authorized to access the LAN and switch services. Because
the switch acts as the proxy, the authentication service is transparent to the host. The
Remote Authentication Dial-In User Service (RADIUS) security system with Extensible
Authentication Protocol (EAP) extensions is the only supported authentication server
to use with 802.1x. The RADIUS server has the ability to use a local user database,
LDAP or Active Directory.
• Switch—Controls the physical access to the network based on the authentication
status of the host. The switch acts as an intermediary (proxy) between the host and
the authentication server, requesting identity information from the host, verifying
that information with the authentication server, and relaying a response to the host.
The switch interacts with the RADIUS client. The RADIUS client encapsulates and
decapsulates the EAP frames and interacts with the authentication server.
2.4 Benefits of Deploying 802.1x
• 802.1x wired LAN connectivity forces all PCs and Laptops connecting to the Black
network to provide authentication with RADIUS or else they can’t connect.
• 802.1x wireless LAN connectivity offers constant EAP key exchange to ensure the
encryption keys change and aren’t subject to the same weaknesses as WEP
encryption.
• With RADIUS and Active Directory integration, users’ System Identifiers (SIDs) will
already be stored in the Active Directory and users will not be prompted for Dot1x
authentication while their computer exists in the AD. If the user is not a part of the
ACME Directory, they will have to provide username and password credentials for
802.1x after logging in locally to get the port activated.
• User accounting and auditing with AAA gives COMPANY the ability to track and
monitor user behavior inside the Black Network or on wireless networks.
• High Availability for 802.1X and port security (Cisco Catalyst 6500 Series Only) by
synchronization of runtime 802.1X port security information between active and
standby supervisors modules.
• Identity-based access control lists (ACLs) would allow COMPANY to dynamically assign
an access control policy to an interface based on the user’s authentication. This
would allow control of non-privileged LAN users to only be able to connect to the
networks that they need (i.e. local subnet, printers, servers, etc.)
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 8
• Unauthorized users are placed into guest VLANs that can alert administrators of their
presence.
2.5 Diagram: Port Authentication with 802.1x
2.6 How Port Authentication with 802.1x Works
The IEEE 802.1x standard controls network access by creating two distinct virtual access
points at each switch port. 802.1x authenticates each user device that is connected to a
switch port and assigns the port to a VLAN before making available any services that are
offered by the switch or the LAN. Until the device is authenticated, 802.1x access control
allows only Extensible Authentication Protocol over LAN (EAPOL) traffic through the port to
which the device is connected. Protected EAP or PEAP is designed to carry EAP types within a
secured channel protected by Transport Layer security (TLS). After authentication is
successful, normal traffic can pass through the port. You can restrict traffic in both directions,
or you can restrict just incoming traffic.
The switch or the host can initiate authentication. If you enable authentication on a port by
using the set port dot1x mod/port port-control auto command, the switch must initiate
authentication when it determines that the port link state transitions from down to up. The
switch sends an EAP-request/identity frame to the host to request its identity (typically, the
switch sends an initial identity/request frame that is followed by one or more requests for
authentication information). When the host receives the frame, it sends an EAP-
response/identity frame using the local computer System Identifier (SID) first. If the RADIUS
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 9
server passes this on to the Active Directory and the Active Directory does not have a policy
for that SID, then the host can initiate authentication by sending an EAPOL-start frame that
prompts the switch to request the host's identity after the user has logged in locally.
More information on Cisco’s implementation of 802.1x on Catalyst 6500 series switches can
be found at
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_c
hapter09186a008019f00a.html#25114
2.7 PEAP Overview
IEEE 802.1X uses EAP to authenticate network clients before allowing access to the network.
Originally designed for Point-to-Point Protocol (PPP) connections, EAP allow you to create
arbitrary authentication schemes to validate network access. The requesting access client and
the authenticating server must first negotiate the use of a specific EAP authentication
scheme, which is known as an EAP type. After the EAP type is agreed upon, EAP allows for an
open-ended conversation between the access client and the authenticating server (usually a
RADIUS server). The conversation consists of requests for authentication information by the
authenticating server and responses from the client. The length and detail of the
conversation depends on the EAP type.
Although EAP provides authentication flexibility, the entire EAP conversation might be sent as
clear text (unencrypted). A malicious user with access to the media can inject packets into the
conversation or capture the EAP messages from a successful authentication for analysis. This
is especially problematic for wireless connections, where the malicious user can be located
outside of your business.
PEAP is an EAP type that addresses this security issue by first creating a secure channel that is
both encrypted and integrity-protected with Transport Level Security (TLS). Then, a new EAP
negotiation with another EAP type occurs, authenticating the network access attempt of the
client. Because the TLS channel protects EAP negotiation and authentication for the network
access attempt, password-based authentication protocols that are normally susceptible to an
offline dictionary attack can be used for authentication in wireless environments.
2.8 MS-CHAP v2 Overview
MS-CHAP v2 is a password-based, challenge-response, mutual authentication protocol that
uses the industry-standard Message Digest 4 (MD4) and Data Encryption Standard (DES)
algorithms to encrypt responses. The authenticating server challenges the access client and
the access client challenges the authenticating server. If either challenge is not correctly
answered, the connection is rejected. MS-CHAP v2 was originally designed by Microsoft as a
PPP authentication protocol to provide better protection for dial-up and virtual private
network (VPN) connections. With Windows XP SP1 and the Windows Server 2003 family, MS-
CHAP v2 is also an EAP type.
Although MS-CHAP v2 provides better protection than previous PPP-based challenge-
response authentication protocols, it is still susceptible to an offline dictionary attack. A
malicious user can capture a successful MS-CHAP v2 exchange and methodically guess
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 10
passwords until the correct one is determined. Using the combination of PEAP with MS-CHAP
v2, the MS-CHAP v2 exchange is protected with the strong security of the TLS channel.
2.9 PEAP with MS-CHAP v2 Operation
The PEAP authentication process occurs in two parts. The first part is the use of EAP and the
PEAP EAP type to create an encrypted TLS channel. The second part is the use of EAP and a
different EAP type to authenticate network access. This section examines PEAP with MS-
CHAP v2 operation, using as an example, a wireless client that attempts to authenticate to a
wireless access point (AP) that uses a RADIUS server for authentication and authorization.
2.10 PEAP Support in Windows
PEAP with MS-CHAP v2 is provided with Windows XP Service Pack 1, as part of enhanced EAP
and IEEE 802.1X support. This allows Windows XP wireless clients to use PEAP with MS-CHAP
v2 for secure wireless access—with passwords rather than certificates. The IAS networking
component provided with the Windows Server 2003 family also supports PEAP with MS-CHAP
v2, allowing an IAS server authenticate wireless clients running Windows XP Service Pack 1.
PEAP with MS-CHAP v2 requires certificates on the IAS servers but not on the wireless clients.
IAS servers must have a certificate installed in their Local Computer certificate store. Instead
of deploying a PKI, you can purchase individual certificates from a third-party CA to install on
your IAS servers. To ensure that wireless clients can validate the IAS server certificate chain,
the root CA certificate of the CA that issued the IAS server certificates must be installed on
each wireless client.
Windows XP includes the root CA certificates of many third-party CAs. If you purchase your
IAS server certificates from a third-party CA that corresponds to an included root CA
certificate, no additional wireless client configuration is required. If you purchase your IAS
server certificates from a third party CA for which Windows XP does not include a
corresponding root CA certificate, you must install the root CA certificate on each wireless
client.
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 11
3 Feasibility Study
3.1 Functional Objective
The objective of the study is to demonstrate the effectiveness of 802.1x Port Authentication
and Company Corporate Company Desktop with the following criteria:
• Assess ease of deployment
• Develop project specifications
• Evaluate 802.1x performance
• Determine dependencies
3.2 Assumptions and Constraints
• The 802.1x testing will be conducted in a “proof-of-concept” lab environment that
simulates the ACME corporate network, but the equipment will NOT be connected to
the live production network.
• The desktop image used in this test environment is experimental and does not include
Outlook or access to other business applications on the ACME Intranet.
• The RADIUS server is built upon procedures set forth by Microsoft and has not been
completely tuned to meet the final production standards.
• The testing of 802.1x Port Authentication will only be tested on a spare 2950 24 Port
switch provided by Network running version 12.1(20EA1) of IOS and no testing of
Dot1x will be performed on Catalyst switches running CatOS.
• No testing will be conducted for the creation of Guest VLANs or dynamic ACLs due to
lab constraints.
• Protected EAP (PEAP) combined with MSCHAPv2 secure password challenge must be
used as this only requires one certificate per RADIUS server and there is no
requirement for client side certificates, as is the case with EAP-TLS.
• EAP-TTLS is a proprietary EAP encryption method developed by Funk Software for
support of their Steel-Belted Radius server and requires a proprietary 802.1x client to
be installed to use it. For this reason it will not be used.
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 12
3.3 Materials and Methods
3.3.1 Lab Setup
The testing was conducted in the COMPANY-IT Desktop Services area on the 3rd
floor of
OMP with the assistance of the Desktop team. This was a joint effort to test 802.1x for
Wireless Networking as well as Cisco Switch Port Authentication.
3.3.2 Description of Lab Environment:
The Desktop Lab is an isolated Proof-Of-Concept (POC) environment that has been outfitted
with servers and equipment that simulates the Company Active Directory domain for
desktop Research and Development.
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 13
3.3.3 List of Lab Components Used :
• Microsoft Server 2003 running Internet Authentication Services (IAS) and Certificate
Services.
• Microsoft Server 2000 running as Domain Controller with Active Directory and a
simulation of the ACME.COMPANY.CA domain.
• Microsoft Server 2000 file server for startup scripts, patch repository and user’s share
directories.
• Cisco 2950 switch upgraded to version 12.1(20EA1) of IOS with one port configured
for Dot1x.
• 2 x Avaya AP-3 Wireless Access Points upgraded to version 2.4.5 of firmware each
equipped with 2 x Avaya Wireless PCMCIA Gold Cards.
• Toshiba Laptop running Company with SP1, Ethernet adapter and built-in wireless
802.11b adapter.
• Microsoft Server 2003 running Internet Authentication Services and Certificate
3.3.4 Test Methodology
Since this lab was setup to provide feasibility for both wireless and wired access
authentication using 802.1x, test plans were devised from the following sources:
http://www.microsoft.com/downloads/details.aspx?FamilyId=CDB639B3-010B-47E7-B234-
A27CDA291DAD&displaylang=en
http://www.microsoft.com/WindowsXP/pro/techinfo/deployment/wireless/80211corp.doc
http://www.cisco.com/en/US/products/hw/switches/ps5213/products_configuration_guide_ch
apter09186a00801cdf84.html
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 14
3.3.5 Test Procedures: Lab Setup
3.3.5.1 Build IAS RADIUS and Certificate Authority per Microsoft’s guidelines.
3.3.5.2 Connect IAS RADIUS to the Active Directory (POC domain).
3.3.5.3 Create an Avaya Wireless and Cisco Switch access policy on the IAS RADIUS (defines the
EAP type and NAS device enrollment).
3.3.5.4 Create Remote Access policy on the IAS RADIUS server.
3.3.5.5 Generate root certificate on the CA and install it. CA will be ready for enrollments of x.509
certificates.
3.3.5.6 Enroll and generate a x.509 certificate for the IAS using the instructions provided in
Microsoft’s Enterprise 802.11 Network Deployment guide.
3.3.5.7 Upgrade Cisco switch to version 12.1(20EA1).
3.3.5.8 Laptops need to ensure that 802.1x authentication is enabled with “Protected EAP”
selected under the “Authentication” tab of the network properties for the respect
interface. To ensure that the machine is authenticated before the user is challenged,
select the “Authenticate as computer when computer information is available” check-box
as well.
3.3.5.9 Under the “Protected EAP Options” dialog make sure “Secured Password (EAP-MSCHAP-
V2)” is selected under the advanced properties of the Authentication tab and ensure that
“Validate Certificate” option is turned off.
3.3.5.10 Configure the Cisco Switch, VLAN1 with an IP address assigned on the Desktop “POC” lab
network.
3.3.6 Test Procedures: Cisco Switch / Laptop 802.1x Test
3.3.6.1 Start debugging of DOT1X ALL, RADIUS and AAA on switch through a console session with
terminal monitoring on.
3.3.6.2 Connect XP workstation to designated switch port with Dot1x enabled and attempt to
login and authenticate against the Active Directory via the 802.1x port authentication
method.
3.3.6.3 If unsuccessful, capture debug logs from switch and check IAS logs for possible trace of
failure.
3.3.6.4 If successful proceed to step 3.3.5.5
3.3.6.5 Verify the following functionality (input from Desktop would be appreciated here):
• Ping default gateway specified from the IPCONFIG /ALL output
• Verify public and shared folder functionality
• Verify wireless client can send and receive email on the configured Outlook client
• Scan network with NMAP and analyze detected hosts.
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 15
• Open a web browser and ensure that client can connect to the certificate authority
website (optional)
3.3.6.6 Force re-authentication on the client and ensure it’s transparent and doesn’t require
manual intervention from the client.
3.3.7 Test Procedures: Roaming From Cisco Switch to Wireless Test
3.3.7.1 Disconnect laptop from Cisco switch and enable the wireless network adapter.
3.3.7.2 Ensure that the wireless card gets authenticated with the cached username / password or
by the System Identifier (SID) and no credentials are required by the MSCHAPv2 after
leaving the wired network for the wireless.
3.3.7.3 Verify that there is still connectivity to file shares and Internet access. If not check to
make sure that the wireless card obtained a DHCP address upon authentication.
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 16
3.3.8 Test Results: Cisco Switch / Laptop 802.1x Test
All tests where successful according to the scope and test plan when the entire
configuration was complete and the PC was rebooted. The switch port became active after
a 24 second delay and the RADIUS logs showed that the machine name was authenticated
against the POC domain and granted the EAP-Access-Accept message back to the switch. At
this point the PC was still loading XP and starting the network services. Immediately
afterward, the startup scripts ran and the PC then presented the login dialog. The PC logged
in successfully to the POC domain, obtained all of the appropriate shares and proved
flawless during all of our tests.
3.3.9 Test Results: Roaming From Cisco Switch to Wireless Test
Testing the ability to roam from the wired LAN to the WiFi LAN was successful. The client PC
immediately authenticated successfully using the user domain credentials transparently
instead of the machine name and in tests that had an administrator logged in locally to the
local PC, the machine name was used instead for 802.1 x WiFi authentications. The client
retained all of its network resources after roaming to another network adapter with a
different IP address on the same subnet.
3.3.10 Test Results: Problems Encountered
• Access policy on the IAS would not accept EAP frames from the Cisco switch even
though we had set up the policy to expect EAP frames from a Cisco Ethernet NAS-
PORT-TYPE with the same pre-shared secret at either end. Finally we saw that the
RADIUS was reporting the Cisco NAS-PORT-TYPE as “Async” and we modified the
access policy to allow “Async(modem)” and the switch immediately connected
successfully when we save the changes.
• The client PC Ethernet adapter didn’t have the option enabled under the “Network
Properties / Authentication / Authenticate as computer when computer information
is available” and could not send the machine’s SID as the response to the MSCHAP
challenge. This forced us to login locally to authenticate with the username /
password but this would mean the user doesn’t get startup scripts and can’t log into
the domain.
• Since the PKI certificate that was generated for the RADIUS server wasn’t from a valid
CA, the option “Validate Certificate” within the client 802.1x settings had to be
disabled otherwise the client would not respond to the EAP-MSCHAPv2 challenge.
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 17
3.3.11 Feasibility Testing Conclusion
The conclusion for the testing that was done for 802.1x with Cisco Port Authentication is as
follows:
PROS
• Flexible configuration on the switch ports with adjustable frequency settings for re-
authentication and EAP start frames
• Simple configuration of the IAS RADIUS server and associated policies for device and
client authentication
• Expandable solution allowed for Wireless and Wired lab testing (roaming between
each on same subnet)
• Authentication of the desktop PC against the AD without user intervention allowed
startup scripts to run and seamless integration of authentication methods (AD and
802.1x single sign-on)
CONS
• MS IAS RADIUS doesn’t appear to have the Cisco device listed properly for EAP frame
type and there doesn’t appear to be too many options for Cisco EAP frames (had to
specify an Async Modem)
• Wasn’t able to test advanced Cisco features such as dynamic VLANs, Guest VLAN
quarantines or ARP traffic inspection do to documentation from Cisco that was geared
toward their authentication server
• Not able to validate the RADIUS server certificate because the PKI wasn’t a trusted
source
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 18
4 Recommendations and Conclusion
4.1 Recommendation Summary
Given the successful outcome of the study for 802.1x Port Authentication with Cisco IOS it
would be my recommendation to implement 802.1x with Cisco switches in a “pilot”
scenario. The pilot would familiarize the COMPANY-IT staff from Network Services, Intel
Services and Field Services with the production demands and learning curves that are
associated with locking down switch port access to the LAN in this manor. The pilot can be
used to develop technical standards, support procedures and measure performance and
identify any production issues that may arise in a “real-world” scenario.
4.2 Pilot Implementation Best Practices
To make the pilot implementation a success and minimize the impact on the pilot users
here are some key design and implementation points to consider:
• Implement a redundant RADIUS solution on separate subnets (perhaps one at Primary
Site and one at DR Site) to mitigate the risk of locking users out should the RADIUS
server be unavailable.
• Engage COMPANY-IT operational staff in the pilot so that any impacts can be resolved
without undo escalations with the helpdesk or other Company support departments.
• Implement a phased, simple and predictable architecture for the pilot that doesn’t
attempt to utilize all of the possibilities that are available to the Cisco IBNS and layer
the features on to the pilot in phases.
• Ensure that other departments that are required to support this have the skills and
have been included in labour costs.
4.3 Resource Roles and Responsibilities
• COMPANY-IT Network Services will provide configuration of the switches, migration of
pilot users and ongoing pilot support.
• COMPANY-IT Security Operations will administer the addition of ACME domain users
and equipment to a new group policy on the Active Directory.
• COMPANY-IT Intel Services will assist in the build, configuration and support of the
RADIUS server(s) and create initial device policies that will integrate with the Active
Directory.
• COMPANY-IT Field Services will assist in configuring pilot users’ 802.1x settings under
Company.
• COMPANY-IT Desktop Services will assist in the build of the RADIUS server and
integration to the Active Directory.
• COMPANY-IT Pilot users will assist in testing and identifying any network problems.
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 19
4.4 Operational Requirements
4.4.1 Cisco Switches
802.1x Port Authentication is available on the following Cisco Catalyst Switches: Platform Code Supporting 802.1x Our Current Code Versions
Catalyst 3550/2950
IOS 12.1(13EA) or higher We run IOS ver. 12.0(5) up to 12.1(13)
Catalyst 4000/4500
IOS 12.1(13E) or higher and CAT OS 6.2 or higher
We run CatOS ver. 5.3(5a) up to 8.1(1)
Catalyst 6500 IOS 12.1(13E) or higher and CAT OS 6.2 or higher
We run CatOS ver. 5.4(2) up to 7.6(2)
NOTE:
• Cisco Catalyst 2924, 5000, and 5500 do not fully support 802.1x and there are known
bugs for what implementation support there is for the Catalyst 5000 with this field
notice:
http://www.cisco.com/en/US/products/products_security_advisory09186a00800b13
8d.shtml
• Cisco Identity-Based Network Services (IBNS) implies that all of the components used
to implement the Dot1x policies are Cisco products, including the RADIUS server.
4.4.2 Client Workstation
Although the Cisco implementation of 802.1x will work with a majority of Operating
Systems including all versions of Windows, Windows CE, MAC OS and Linux, only Windows
XP SP1 and Windows Server 2003 have integrated support that does not require any
additional client software.
4.4.3 RADIUS Authentication Server
The RADIUS Authentication server must support the following to qualify:
• Supports the PEAP authentication protocol
• Ability to install a server-side x.509 certificate from a valid PKI source
• Supports MSCHAPv2 secure password EAP method
• Connect either directly or through LDAP to the Microsoft Active Directory to validate
authentication of the domain user and their workstations.
• Provides future support for pushing configuration policies to Cisco switches for
dynamic VLANs and other Cisco security features (this may require modifications to
the Active Directory as this is where the initial policy would be stored).
• Should provide ability to integrate the 802.11a/b/g Wireless Networking
authentication in adherence to IT Security’s Wireless Networking Standards.
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 20
4.4.4 Certificate Authority (CA)
It is a recommendation that the certificate to be used on the RADIUS servers be generated
by a trusted Certificate Authority such as Soltrus (a.k.a. Verisign). This way the client option
to validate the server certificates can be used with greater confidence especially if the same
RADIUS server is used for future implementations of 802.1x with Wireless Networking.
4.5 Production Configuration Requirements
4.5.1 Active Directory
Active Directory provides the computer and user accounts and groups to manage the IAS
access policies. The default computer and user accounts were used and no modifications
were made to the AD during the testing so it is unclear whether this will be a requirement
for enterprise implementation. Again, the pilot will help define the policy requirements
with respect to Active Directory.
4.5.2 Desktop Clients
The Company client PCs will need to have 802.1x enabled under network properties with
the following options:
• Protected EAP (PEAP)
• Validate server certificate option
• Secured Password (EAP-MSCHAP v2)
• Authenticate as computer when computer information is available (SID)
4.5.3 Cisco Switches: Access Layer Configuration
The Cisco “dot1x” configuration options for IOS-based switches should have the following
values:
• AAA enabled with authentication set to dot1x
• RADIUS server IP address, UDP port and pre-shared key
• Global dot1x system-auth-control enabled
• Configure each switch port with 802.1x to force authentication (this can only be done
on layer 2 static-access ports and layer 3 routed ports – will not work on Trunk,
Dynamic, Dynamic-Access, EtherChannel, LRE, or SPAN ports)
• On each interface make sure dot1x port-control is set to auto. If set to “force-
authorized” the port will allow anyone to connect without sending the EAP start
frame; if set to “force-unauthorized” the port will stay closed and will not initiate an
EAP start frame
• To minimize the dot1x overhead on a large number of dot1x ports the periodic re-
authentication of the client and the re-authentication frequency is disabled by
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 21
default. This option would really benefit an EAP re-authentication on wireless
networks as the data needs to be encrypted.
4.5.4 Cisco Switches: Multi-Host (Hub) Configuration
In locations that are still using workgroup hubs such as the Synoptic ninety-six port hubs
(85x York Mills) there is a feature with Cisco dot1x that allows more than one client to
access the same 802.1x enabled port. Cisco claims that only one of the clients needs to
connect and authenticate to activate the port in this state and then all remaining clients can
access the port without authenticating. Cisco suggests that Port Security is to be used with
a static list of MAC addresses to manage network access for the remaining clients. This is
not preferable as the administrative overhead in Port Security on a LAN segment would be
far too unmanageable.
4.6 Production Impact: Pilot
Although the intent of the pilot is to minimize the impact on production systems there is
still the risk that users in the pilot could be affected by any of the following incidents should
they occur:
• Authentication server becomes unavailable – In this instance the Cisco switch will
simply block all ports configured with 802.1x indefinitely until the RADIUS server
returns to production. This is the primary reason that redundant RADIUS servers need
to be configured in each switch.
• Non-compliant Devices - Vendors, visitors or other equipment such as printers will not
be able to authenticate against the Active Directory and as such will not be able to
connect to the network unless the port they are connecting to is left open without
802.1x. Printers can be provisioned without 802.1x using Cisco Port Security whereby
the device MAC address is hard-coded into the switch by Network Services. This will
pose as a significant administrative overhead in the beginning but once configured,
will pose as a secure method of connectivity. Otherwise, anyone would be able to
unplug the printer and plug in a non-standard device onto the network, by-passing
802.1x.
• Desktop Patches – Future Windows XP service packs or patches, particularly those
that address TCP/IP or other networking components, have the potential for resetting
the 802.1x configuration back to the Microsoft defaults (EAP type: Smart Card or
other Certificate) and thus disrupting a client’s ability to properly authenticate the
switch port for access to the network. This may require some lab testing on the
COMPANY-IT Desktop team for this very condition prior to rolling out the patches
nationally.
4.7 Future Considerations for 802.1x
There are a number of future implementation enhancements that can be leveraged with an
enterprise solution for 802.1x such as:
• 802.1x Dynamic VLAN assignment using RADIUS
802.1x Port Authentication Feasibility Study / Proposed Plan Gary Freeman
Page 22
• 802.1x DHCP authentication
• 802.1x Quarantine VLAN for guests
• 802.1x Guest VLAN for access to the Internet
• 802.1x Wireless Networking Security
4.8 References
PEAP with MS-CHAP Version 2 for Secure Password-based Wireless Access -
http://www.microsoft.com/technet/community/columns/cableguy/cg0702.mspx
Configuring 802.1x Authentication on Catalyst 6500 Series Switches -
http://www.cisco.com/en/US/products/hw/switches/ps708/25114
IEEE 802.1x Standards Publication
http://standards.ieee.org/getieee802/download/802.1X-2001.pdf
Microsoft Windows 2003: Internet Authentication Service -
http://www.microsoft.com/windowsserver2003/technologies/ias/default.mspx
Enterprise Deployment of Secure Wired Networks Using Microsoft® Windows® -
http://www.microsoft.com/downloads/details.aspx?FamilyID=05951071-6b20-4cef-9939-
47c397ffd3dd&DisplayLang=en
Network Access Quarantine Control in Windows Server 2003 -
http://www.microsoft.com/windowsserver2003/techinfo/overview/quarantine.mspx
The Advantages of Protected Extensible Authentication Protocol (PEAP) -
http://www.microsoft.com/windowsserver2003/techinfo/overview/peap.mspx
Obtaining and Installing a VeriSign WLAN Server Certificate for PEAP-MS-CHAP v2 Wireless
Authentication –
http://download.microsoft.com/download/9/f/d/9fd73f17-2fdf-4409-b2d2-
31437c7f29f3/WLANCertEnroll.doc
PACKET: “Hardened" Cisco AAA appliance joins identity-based networking -
http://www.ieng.com/en/US/about/ac123/ac114/ac173/ac224/about_cisco_packet_technology0900ae
cd800b19a3.html
Cisco: Identity Based Networking Services Solution FAQ - http://www.stratacom.com/en/US/products/hw/switches/ps708/products_qanda_item09186a008012dc81.shtml