Compaq 470012-741 - Armada 110 - Celeron 700 MHz Manual page 25

Wireless Security White Paper
The fundamental approach used by 802.1x is to authenticate users at the edge of the private
network. It would be conceivable to perform this processing at other points within the core of the
network, for example using MAC addresses. However, it would be difficult to protect all
authenticated end stations from unauthenticated stations, since intruders could bypass
authentication at least on their own segments. It is significantly less complex, and more scaleable,
to ensure security if the authentication is performed on the external boundary of the network. It is
possible to develop a tiered authentication scheme in which the public is able to access the
external network. All employees can access the corporate network, and individuals can access
their restricted departmental LANs.
A typical bridge would connect segments that are private and presumed to already be secure, such
as those on the corporate network. An 802.1x bridge can connect these segments, too, but its
added value lies in its ability to optionally authenticate a port before allowing it to connect.
What this means is that the bridge is configured with both controlled and uncontrolled ports.
Those that are uncontrolled do not need to authenticate and would see the device as though it
were a traditional bridge. Devices connecting to the controlled ports would not be able to access
any of the connected segments (neither the segments on the uncontrolled ports nor the segments
on authenticated controlled ports) until they were authenticated successfully.
The scenario sounds simple in principle. Where it becomes slightly more complicated is in the
actual authentication. Conceptually it would be feasible to let the bridge perform the
authentication using a cache of authentication information. However, that would be unnecessary
overhead for the bridge and would mean that authentication information would need to be
replicated to all bridges, which is neither efficient nor secure.
Instead, the bridge (called the Authenticator) may relay authentication requests from a client
(called the Supplicant) to an Authentication server. This is very similar to the RADIUS model of
authentication and, in fact, it is expected that many Authenticators will be RADIUS clients -- and
many Authentication servers therefore RADIUS servers.
There are three players in this topology. The Authenticator sits in the middle with both controlled
and uncontrolled ports. The Authentication server is connected to an uncontrolled port. The
Supplicant is connected to a controlled port.
The authentication process would run along these lines:
•
The Supplicant connects to a controlled port
•
Either the Authenticator or the Supplicant initiates authentication
•
A challenge is sent from the Authentication server to the Supplicant via the Authenticator
•
The Supplicant signs, or otherwise cryptologically processes, the challenge.
•
The Supplicant sends the result back to the Authentication server via the Authenticator
•
The Authentication server sends the status (success or failure) back to the Supplicant via the
Authenticator
•
The Authenticator intercepts the status and, if successful, opens the port.
There are a few issues to consider in this process:
•
The only traffic that the Authenticator may relay from/to a controlled port is authentication
requests/responses
25