Compaq Evo n800c Wireless Security - Page 25

There are three players in this topology. The Authenticator sits in the middle with both controlled

Get Compaq Evo n800c - Notebook PC PDF manuals and user guides View all Compaq Evo n800c manuals
Add to My Manuals
Save this manual to your list of manuals

Page 25 highlights

Wireless Security White Paper 25 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

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
Wireless Security White Paper
25
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