Enforcing Network Security on Connection pdf

White Paper
Intel Information Technology
Computer Manufacturing
Client Security
Enforcing Network Security
on Connection
In response to the rise in network security threats, Intel IT is taking advantage of new
industry standards to enhance its network security. Through 802.1x authentication, security
policy compliance enforcement, and remediation, each device and user is identified, verified,
and validated for compliance with security policies before being connected to our network.
Sagi Bar-Or, Intel Corporation
February 2007
IT@Inte
l
2
White Paper Enforcing Network Security on Connection
Executive Summary
As networking evolves to support both wired and wireless access, securing corporate
networks from attack becomes ever more essential. Intel IT is using a new security
method to authenticate devices, validate them against security compliance policies,
and remediate specific problems before they connect to Intel’s networks.
Our strategy includes:
Ensuring that network hardware, firmware, and software meet the IEEE
802.1x standard.
Authenticating all devices attempting to connect to our network.
Checking for compliance with Intel’s information security policies.
Cleaning infected systems and bringing their configuration into compliance
with security policies before they connect to our network.
Providing wired and wireless clients an assured connection to a known network.
Protecting mobile devices against unintentionally connecting to a hostile network.
A pilot program, which we began in September 2003, validated our approach by

protecting wired and wireless client systems in office and factory environments.
This is a promising new network security method. For example, it could enable our
IT managers to:
Ensure that all systems connecting to Intel’s networks meet specific
security requirements.
Enforce system states to meet security policies, for example, weekly
virus scanning.
Scan systems for recent worms and viruses and block connectivity until cleaned.
Protect mobile laptop PCs that have been unconnected from getting or
proliferating recently emerged viruses.
Intel IT has demonstrated how to use the capabilities of emerging open network
security standards to combine device authentication with security policy compliance
enforcement, enabling proactive remediation before a device is allowed on the network.
Today, we have completed many major milestones for on-connect authentication,
including configuration and deployment of the infrastructure and clients for LAN and
wireless LAN (WLAN). We are now working on the next stage: adding compliance
enforcement and protecting remote-access virtual private network (VPN).
•
•
•
•
•
•
•
•
•
•
Intel IT has
demonstrated how to
use the capabilities

of emerging open
network security
standards to combine
device authentication
with security
policy compliance
enforcement, enabling
proactive remediation
before a device
is allowed on the
network.
3
Enforcing Network Security on Connection White Paper
Contents
Executive Summary 2
Background 4
Network Security Risks 5
A New Security Paradigm 6
The Technologies Behind Our Solution 7
Authentication Protocols 7
Password-based Protocol 7
Certificate-based Protocol 8
Tunneling Protocol 9
Security Compliance Enforcement 9
Asset Registration Validation 10
Forming a Program Team 11
Gathering Requirements 11
Identifying Project Scope 11
Intel’s Security Enhancement Program 11
Piloting the Solution 12

Challenges 14
Conclusion 15
Authors 15
Acronyms 15
4
White Paper Enforcing Network Security on Connection
Facing this business need, Intel IT saw a solution
opportunity in three new standards of the Institute
of Electrical and Electronic Engineers (IEEE), all of
which offer advanced authentication capabilities:
802.1x for port-based security, next-generation
802.11i for networking, and Wi-Fi* protected
access (WPA).
Our solution needed to address all aspects of
Intel’s complex environment. Intel’s networking
environment includes a multitude of client
platforms: desktop PCs, laptops, personal digital
assistants (PDAs), and other small form-factor
devices, such as smartphones. These devices use
various operating systems, including Microsoft
Windows*, PocketPC*, Linux*, and UNIX*.
Our environment also presents a variety of
use cases, including office clients, servers, and
station controllers.
Intel has hundreds of sites worldwide and
approximately 100,000 employees (including
contractors), each of whom has at least one PC.
We’ve moved to a mobile environment in which
more than 70 percent of our knowledge workers
use mobile computers and more than 40 percent

are wireless-enabled. Intel has 30,000 wireless
users, 4,000+ wireless access points, and over
50,000 wired switch ports.
To address security in this complex environment,
Intel IT conducted a pilot project to investigate
using state-of-the-art technologies to protect
network ports. We wanted to find out whether
we could provide required levels of security by
combining authentication to prevent unauthorized
network access with verification that each
device connecting to the network environment
is compliant with current security policies.
Background
In today’s networking world, companies are increasingly at risk for network attacks—
from hostile intruders, viruses, and worms to server impersonations. To reduce the
potential impact of such attacks at Intel, we needed to enhance security protection
in our environment.
5
Enforcing Network Security on Connection White Paper
But how do you deny network access to devices
that are contaminated or suspicious or not
compliant with current information security
policies? To detect that a device is non-compliant
after it is already on the network and then
disconnect it is not sufficient. Worms, for example,
propagate themselves very quickly in the network
layer. To maximize protection, the device should
not be granted access to the network at all unless
or until the problem can be remediated.
Wired networks have the advantage of requiring

physical access to connect to them. As a result,
they can be partially protected using physical
security measures such as guards or locked
doors. However, even with physical security,
wired networks still face the same risks from
viruses and worms that wireless networks
must deal with. And we must still protect the
LAN environment from authorized individuals
connecting unauthorized devices to the network
and from malicious activity by authorized users.
By their very nature, WLANs do not lend
themselves to physical protection, since they do
not require devices to physically connect to the
network. Incorporating wireless technology in a
large, global enterprise can potentially introduce
new risks into the environment if not carefully
managed. Wireless ports that are not sufficiently
protected can increase the risk of incursions
from unauthorized network access. When a
wireless network is unprotected, someone can
be out in the parking lot or blocks away and still
connect to the WLAN.
On the other hand, unprotected wireless clients
may be vulnerable. “Rogue” wireless devices can
also pose dangers to network security. They can
increase the risk of server impersonation, where
clients are lured onto hostile networks.
Network Security Risks
Today our networks face many security risks, whether wired or wireless. One of the
most common is unauthorized network access. In addition, we must also protect

against the threat of damage done by legitimate devices or people through the
spread of worms and viruses.
6
White Paper Enforcing Network Security on Connection
Intel IT’s proof-of-concept study demonstrated
that 802.1x-enabled device authentication,
combined with automated scanning and
enforcement of security policies, can give
us control over every device attached to
our network.
This new security paradigm is important to us
because it has the potential to dramatically
improve our ability to enforce security policy.
For example, using this new approach, Intel IT
managers could:
Ensure that only authorized devices and
users can connect to the network.
Ensure that systems they don’t own or
maintain meet minimum security requirements,
•
•
so they can make yes/no decisions on allowing
connection to the network.
Enforce system states—for example, if a full
system scan has not been performed on a
connecting system within the time period
specified by security policy, we could force
the scan prior to connection.
Arrange to quickly scan connecting systems
for a recent worm that can be detected based

on a signature file and block connectivity until
the system is cleaned.
Require mobile computers that are away from
the network for a period of time to update their
virus or signature file before they reconnect,
protecting laptop PCs from either getting or
proliferating a recently emerged virus.
•
•
•
A New Security Paradigm
In response to these security challenges, the IEEE has been working on 802.11i,
an emerging security standard for WLAN. This includes the existing port-based
authentication standard, 802.1x, which is also used for wired LANs.
7
Enforcing Network Security on Connection White Paper
Authentication Protocols
Authentication occurs when a device tries to
connect to the network, for example, through a
local wired port or a wireless access point (AP).
802.1x is based on the Extensible Authentication
Protocol (EAP) specifically developed to address
port-level authentication.
EAP allows authentication of devices before
they are granted access to the network. It is an
extension to the Point-to-Point Protocol (PPP)
for Ethernet networks and enables a variety of
authentication protocols. It passes through the
exchange of authentication messages, allowing
authentication software on the server to interact

with its counterpart on the client before the
device is connected.
In our study, we considered the following three
protocol types for authentication:
Password-based
Certificate-based
Tunneling
Password-based Protocol
Password-based protocols authenticate using
passwords for both the device and the user.
Two examples of password-based protocols are
Protected EAP-Microsoft Challenge Handshake
Authentication Protocol version 2* (PEAP-MS
CHAP v2) and Cisco’s Lightweight Extensible
Authentication Protocol* (LEAP).
•
•
•
The Technologies Behind
Our Solution
The solution employed in our pilot combined authentication, security compliance,
and asset registration validation capabilities that are now possible to implement
through the 802.1x standard.
8
White Paper Enforcing Network Security on Connection
Clients that connect to a Microsoft Windows
domain already use device and user credentials
to authenticate to the domain. The same
credentials can be used to authenticate to
the network with 802.1x.

For a device, the domain credential is the host
name. The password is created when the device
joins the domain and its hash is cached both on
the client and in the directory. The password is
changed automatically, as required by company
policy (for instance, every 30 or 90 days).
For a user, the domain credential is the username
and password. The user password can be made
secure using domain-wide group policy objects
that require passwords to meet strong password
specifications and to be changed periodically.
A common industry definition of a strong
password specification is that passwords be at
least six characters long, and include letters and
digits in upper- and lowercase, with at least one
special character.
Using both device and user credentials provides
better protection, as they complement each
other’s vulnerabilities. For example, users’
passwords are susceptible to social engineering
(tricking a person into revealing their password)
and shoulder surfing (stealing a password by
looking over someone’s shoulder as they type it
in). The device password compensates for that,
as the user never uses and does not know the
device password. Unfortunately, the ability to
authenticate using two credentials in the same
session is not yet supported by the IEEE standard.
Another drawback of password-based protocols is
that the user password is cached on the local hard

drive to enable offline logon. This will compromise
security if a laptop is stolen. The optimal solution
is to not cache the logon credential. However, if
the password must be cached to enable offline
logon or roaming, it can still be protected with a
non-cached PIN, using a hardware module such
as a trusted platform module (TPM) to provide
tamper-resistant storage.
Certificate-based Protocol
Computer certificates significantly improve the
level of security and resistance to brute force
attacks. However, certificate-based protocols
such as EAP-Transport Layer Security (EAP-
TLS) require a public key infrastructure (PKI),
which adds a level of complexity and cost. A
certificate authority (CA) must be established
to generate the certificate, and a system put
in place for deployment and maintenance to
revoke, renew, and track certificates. Certificates
can be purchased from a commercial source, but
they still need to be deployed and maintained.
Nevertheless, once the PKI and certificate-based
authentication is established, it is a highly stable
and scalable service.
The optimum approach is to use separate
certificates for device and user authentication
and to require both forms of authentication
before allowing network access. However,
this may not be the best option for device
authentication, as the credential needs to be

associated with the device. One solution is to
store the certificate in the TPM on the computer,
if the ease of use for customers makes that
additional risk worthwhile.
9
Enforcing Network Security on Connection White Paper
Tunneling Protocol
Tunneling protocols enable a secure tunnel
between the client and authenticator, allowing
the authentication process to occur securely.
This protocol is said to “tunnel” because it pushes
through different types of packets, encapsulating
them at the peer level or below. Tunneling
protocols transport multiple protocols over a
common network and provide the vehicle for
encrypted VPNs. In the network authentication
case, the tunneling protocol is used to perform
the authentication session in a protected
way. Examples of tunneling protocols include
Protected EAP (PEAP) and Tunneled TLS (TTLS).
Security Compliance
Enforcement
Authentication is an important step in protecting
networks from unauthorized access, but it’s
only one piece of the puzzle. Gartner Group was
forecasting that, “by the first quarter of 2005,
enterprises that don’t enforce security policies
during network login will experience 200 percent
more network downtime than those that do (0.7
probability).”

1
By introducing security compliance
at Layer 2 of the network stack, devices can be
identified as authorized to access the network as
well as compliant with information security policies.
To become security compliant, the device must
pass a series of checks, according to predefined
policies. For example, security patches, virus
definitions, and other security-related configuration
components can be checked against a database
1 “Scan, Block and Quarantine to Survive Worm Attacks.” Gartner
Group. Paper ID T21-7-7550.
for compliance. This compliance scanning can also
verify that critical security services, such as virus
protection, are running on the device.
Security compliance can be enforced in several
ways before a device is allowed to connect to
the production network. Here are three examples:
Do not enter. When detected as non-
compliant, the device is not allowed access.
This method is elegant in its simplicity;
however, users need the ability to contact a
support center when access is denied.
Partial access. When detected as non-
compliant, the device gains partial access
to the network. That is, it is issued a valid IP
address, but can only access limited resources.
Remediation. When detected as non-compliant,
the device is redirected to a non-production
(remediation) network. In this network, the

device’s security compliance is updated.
Remediation can be done using various levels
of automation. Once the device (known as a
supplicant) is verified to be compliant, it can be
assigned an IP address and allowed to access
the network, as shown in Figure 1.
There are several technologies in the domain of
compliance enforcement on connect. They can
be divided into three main types, according to the
policy enforcement point (PEP):
The client as the enforcement point. Typically
achieved by a personal firewall or another
low-level device driver at the network driver
interface (NDI) level, which controls network
access for the device.
•
•
•
•
10
White Paper Enforcing Network Security on Connection
A network service as the enforcement point.
In this technology, a network device limits
network access per device. This is achieved by
a network access server (NAS), or, for example,
Dynamic Host Configuration Protocol (DHCP).
A proprietary network appliance as the
enforcement point. In this method, a specific
network appliance captures the packets and
controls them accordingly.

•
•
Asset Registration
Validation
A third condition for allowing a device to be
connected to the network is verifying that the
device is registered. Verification can be done
with an existing database in the organization.
The approach is similar to compliance scanning
enforcement, described above.
Figure 1. Device authentication and compliance enforcement process.
2
3
1
2
3
2
2
2
3 3
1
Client
(Supplicant)
Network
Switch
Authentication
Server
Compliance
Server
Remediation

Zone
Remediation
Services
Production
Network
ID? OK?
STOP
NO NO
YES YES
Step 1: Authentication (Identity—Layer 2)
Step 2: Compliance with Policies (Layer 2)
Step 3: Open Port, Assign IP Address, Grant Network Access (Layer 3)
Remediation
Not Possible
2
3
1
Wireless
Access Point
Client
(Supplicant)
2
3
1
2
1
3
1
1 3
11

Enforcing Network Security on Connection White Paper
Forming a Program Team
We began by bringing together Intel IT managers
who had a vested interest in the problem and
the solution, including IT client, network, security,
and server infrastructure groups. We defined
a core team who would participate in mapping
requirements and use cases, then architect a
solution, as well as a management review council
(MRC) to make decisions as we proceeded. As the
program progressed, we added additional team
members to develop, test, and certify the solution.
Gathering Requirements
To build the right solution, we had to fully
understand the business needs and customer
requirements. We spent time gathering
requirements from Intel’s business units—the
customers for our IT solution—to understand their
specific business needs and requirements for the
solution. We defined use cases and brainstormed
about the technologies and possibilities.
Identifying Project Scope
To determine the scope of our project, we identified
which networks needed defending and which
platforms and operating systems needed to access
those networks. We decided on key use cases.
Phased Implementation
Due to the complexity of deployment and
number of new technologies in the pilot,
we decided to take a phased approach to

implementation. Each phase gradually raises
the technology level, as well as the opportunity
to study more varied use cases. Later phases
incorporate more use cases and enhanced
security methods.
Mission Statement
The outcome of our first brainstorming was a
mission statement:
Every device attempting to become a node
on the network must pass authentication,
security policy compliance enforcement, and
asset registration validation to gain access.
Designing the Solution
We evaluated the available network and client
technologies for authentication, security
compliance, and asset registration validation.
We knew we wanted to incorporate appropriate
authentication and compliance scanning
hardware tools, but realized that not all required
technologies existed or were mature at the time
of our program’s inception. Based on the initial
exploration, we developed long-term, medium-
•
Intel’s Security
Enhancement Program
Our investigations were prompted by a combination of business need and emerging
technologies. Intel’s business units were calling for next-generation authentication
and security methods to address the increase in security threats to the corporate
network. At the same time, the 802.11i networking standard promised port-based
authentication technology to address these needs.

12
White Paper Enforcing Network Security on Connection
term, and short-term architectures based on
the 802.1x standard for port-based network
access control (part of the 802.11i standard).
We designed solutions that would align with
that architecture and support the business
and customer requirements, and also defined
integration requirements.
Defining Core Components
We defined reference designs for core
components of the Phase 1 pilot, based on
the architecture. Among the core components
were switch configuration, network ports,
authentication, authorization and accounting
(AAA) server infrastructure, PKI, wireless access
points, dynamic account management, and
client operating systems and configuration. We
established engineering sub-teams for each core
component reference design to develop, test, and
certify solutions.
We developed reference designs for core
components of the authentication and security
compliance enforcement system, based on the
architecture, and established a sub-team for
each core component reference design. We
tested individual components and certified
them for use within our environment. We then
integrated components to make sure they
worked as a system.

Upgrading the Network
We began with the important task of upgrading
all ports involved in Phase 1 to the 802.1x
standard. We mapped all network ports, including
LAN and WLAN, identifying all switches and
access points on the network that would need
firmware or hardware upgrades to support
802.1x. This upgrade would be necessary to
afford us control over every port that attaches
devices to the network.
Identifying Use Cases and Clients
We decided on two use cases for Phase 1:
office user and factory user. We selected user
platforms for Phase 1 based on Intel® Centrino®
mobile technology.
Piloting the Solution
With the design in place for Phase 1, we
began engineering the solution. This involved
establishing the back-end infrastructure and
arranging for the required network firmware
and hardware upgrades, then preparing for
client updates.
To test the viability and usability of our solution,
we sought and received management approval
to begin an initial proof of concept. In September
2004, we demonstrated our solution at the Intel
Developer’s Forum. We showed how it could work,
using Intel Centrino mobile technology-based
client laptops running EAP, Intel® PROSet/
Wireless software, and our custom compliance

enforcement software for the demo.
Getting Certification
Intel has rigorous processes for certifying any
solution that could potentially be deployed in the
enterprise. To ensure we had a valid pilot, we are
using the pilot data to get both the components
and the entire system certified by our IT
standards body.
13
Enforcing Network Security on Connection White Paper
Steps to Developing a New Security Method
Our experiences with this pilot and other security and compliance
projects have led us to craft a 10-step plan for developing new
security methods.
Identify the need. Explorations of new security methods
are typically driven by a combination of business need for
enhanced network security and emerging technologies.
Identify the players and form the team. In response to
the identified need, Intel IT initiates a program to investigate
possible solutions. When launching this type of program,
we initiate a core team to participate in developing and
engineering the solution and an MRC to make decisions.
Gather requirements and identify the project scope. We
begin by gathering requirements from the Intel business units,
our IT customers. We scope the project to determine which
networks, platforms, and operating systems our solution needs
to support. We identify the ports that need protecting. We decide
whether to approach the problem with a phased deployment.
Explore the technologies and design the solution. We
evaluate the available technologies, determine which will best

meet our needs, and develop an architecture. We then design
solutions in alignment with that architecture, which support the
business requirements.
Determine the components. We define reference designs
for core system components, based on the architecture, and
establish a project sub-team for each component. We test
1.
2.
3.
4.
5.
individual components and certify them for use within our
environment, then integrate components to make sure they
work as a system.
Pilot the solution. To test the success and usability of our
security enforcement solution, we perform a proof-of-concept
test and a series of pilots for each phase of our deployment.
Deploying each pilot involves establishing the back-end
infrastructure and arranging for network upgrades, then
preparing for client updates.
Certify the solution. We use the pilot data to get the
components and the entire system certified by our standards
body for deployment throughout the enterprise.
Prepare the budget. While the pilot and certification efforts
are ongoing, we prepare a deployment budget.
Get management approval. As we proceed with our program,
we seek and get management approval at major milestones
before advancing to each next activity. When the pilot is
complete, we submit the pilot results, certifications, and
deployment budget to the MRC for approval to deploy.

Deploy the solution across the enterprise. Once we have
management approval, the final step is deploying the solution in
our corporate environment. This involves establishing the back-
end infrastructure, arranging for network upgrades, preparing
clients, and setting up maintenance and sustaining activities.
6.
7.
8.
9.
10.
14
White Paper Enforcing Network Security on Connection
Components that have not yet been released,
such as some used in our pilot studies, can
introduce short-term issues that disappear
when that component is released. For corporate-
wide deployment, all components must be in
production.
However, the benefit of an early pilot is that
we can submit our requirements and concerns
to component manufacturers in the early stages
of their products, making it more likely that we
get the features we need when the component
is released.
Another challenge is the need to update each
and every component. A well-known slogan is
“your network is as secure as the weakest link.”
This reflects the need to cover all the access
points to the corporate network, for example,
all the LAN switches.

Applying a new security scheme to the network
poses the classic challenge of security versus
usability, so we must find the path between
security and manageability. We don’t want to
lock legitimate users out, even if they are
not 100 percent compliant. For example, if a
computer has anti-virus detection turned off,
we must prevent access. But if it is missing a
non-critical security patch, we can grant access
along with a prompt to the user to install the
patch. The solution is to clearly define policies.
We must also address wavers and exceptions.
In large organizations, there will always be
devices and users that must be treated
differently, for example, printers, network
detection devices, and lab computers. We must
also have a process in place to identify and
address wavers and exceptions.
Lastly, working on this type of program requires
cross-organizational cooperation within the
organization. This is a comprehensive solution
that covers client, network equipment, and back-
end servers. In our program, excellent cooperation
between all teams was a key success factor.
Challenges
One of the major challenges for the program was that not all required technologies
existed or were mature when we began our study. Initially, authentication was the
only available technology. Today, numerous products are offered, or will be offered
soon, that include asset registration, validation, or compliance enforcement.
15

Enforcing Network Security on Connection White Paper
Our best defense against unauthorized network
access and other security threats is combining
security compliance scanning and enforcement
with state-of-the-art authentication. Through
authentication and asset registration validation,
we can ensure that only authorized devices are
allowed on the network. By applying security
policy compliance checks, we can ensure that
infected or vulnerable devices do not gain access
to networks to allow propagation of worms and
viruses. Through this combination of methods, we
are reducing our security risk.
Conclusion
During our pilot program to implement improved security methods at Intel, we
identified the necessary infrastructure (hardware, firmware, and software)
to support secure network access, enforced as devices connect to our LANs
and WLANs. Our approach authenticates the device and user to the network,
authenticates the network server to the client, checks the client for compliance to
the current security policies, and provides remediation for non-compliant devices.
Authors
Sagi Bar-Or is a systems engineer with Intel Information Technology
Acronyms
AAA authorization and accounting
AP access point
CA certificate authority
EAP Extensible Authentication Protocol
IEEE Institute of Electrical and Electronic Engineers
LEAP Lightweight Extensible Authentication Protocol
NAS network access server

NDI network driver interface
PDA personal digital assistant
PEAP Protected EAP
PEP policy enforcement point
PKI public key infrastructure
PPP Point-to-Point Protocol
MRC management review council
MS CHAP Microsoft Challenge Handshake Authentication Protocol
TKIP Temporal Key Integrity Protocol
TLS Transport Layer Security
TPM trusted platform module
TTLS Tunneled TLS
VPN virtual private network
WLAN wireless LAN
www.intel.com/IT
This paper is for informational purposes only. THIS DOCUMENT IS
PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING
ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT,
FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY
OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR
SAMPLE. Intel disclaims all liability, including liability for infringement
of any proprietary rights, relating to use of information in this
specification. No license, express or implied, by estoppel or otherwise,
to any intellectual property rights is granted herein.
Intel, the Intel logo, Intel. Leap ahead. and Intel. Leap ahead. logo, and
Centrino are trademarks or registered trademarks of Intel Corporation
or its subsidiaries in other countries.
* Other names and brands may be claimed as the property of others.
Copyright 2007, Intel Corporation. All rights reserved.
Printed in USA Please Recycle

0207/ARM/RDA/PDF ITAI Number: 06-4705w