cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

802.1x Port Authentication and How It May Be Used in a Network

802.1x Port Authentication and How It May Be Used in a Network

The 802.1x standard provides a means of client or port authentication and is found in the 802.11 wireless environment (WPA & WPA2 for example) as well as the 802.3 switched environment.  The NetVanta 150 Access Point as well as the NetVanta switches support 802.1x authentication.  Note that NetVanta switches are limited to EAP MD5 authentication only.

The 802.1x standard provides definitions for devices participating in the authentication process. 

The Supplicant is the device that wants to gain access or become authenticated (a WiFi laptop).  The Authenticator is the device that controls access to the Supplicant (Ethernet switch or 802.11 Access Point).  The Authentication Server is a database that the Authenticator will use to verify Supplicant credentials.  The Authenticator will usually communicate with the Authentication Server using the RADIUS protocol.

During 802.1x authentication, the port (either a physical port on a switch or a logical port on an AP) will be in one of two states; Authorized or Unauthorized.  A port will begin in an unauthorized state and only respond to EAP frames.  EAP (Extensible Authentication Protocol) is part of the 802.1x standard and is the framework for the authentication process. There are several versions of EAP in which some are proprietary to the vendor.  A very popular type of EAP is Microsoft’s PEAP (Protected Extensible Authentication Protocol) which is commonly found in WiFi environments.

Let’s take a quick look at PEAP in an 802.11 WiFi environment.  A client computer will associate to an active WLAN identified by the SSID of the AP (NetVanta 150).  The AP (Authenticator) which is configured to use 802.1x then ends and EAP challenge/identity request to the client (Suppliant).  The AP will start the process of building a secure tunnel between the Authentication Server and the client.  This is done by relaying the EAP messages from the client to the Authentication Server via RADIUS.  PEAP will use an X.509 Certificate from the Microsoft Authentication Server to create this secure tunnel.

Prior to authentication a wireless user is classified as unauthenticated and will not have network access.  Once the 802.1x authentication process has begun, the user will receive a username and password challenge.  After responding correctly, the user will be authenticated and network access is granted.  If the user response is incorrect, they will stay in an unauthenticated state. 

Once the secure tunnel is built the client will provide a username and password or an X.509 certificate to authenticate itself to the Authentication Server.  If the client’s credentials are accepted, the Authentication Server will grant the client access and provide an encryption key to enable secure wireless transmission.

A key note here is that the Authenticator will relay the Supplicant’s EAP messages to the Authentication Server via RADIUS. This seems complicated but most of the configuration will take place on the Supplicant and the Authentication Server.  When using the NetVanta 150 AP as the Authenticator you will not need to specify that you are using PEAP.  In fact, when you select WPA/WPA2 Enterprise 802.1x is turned on automatically. 

EAP in a WiFi environment will tend to be more involved since security is a greater concern.  PEAP for example can be used for mutual authentication as well as providing individual encryption keys.  When using 802.1x in a wired environment there will typically not be as big of a security concern transmission is over a physical media.  Switches typically have specific features for port security that are independent of 802.1x such as a simple MD5 password hash for authenticating the wired user.

In NetVanta switches it is possible to run 802.1 x authentication using the internal database, rather than an external RADIUS server.  There is not a defined limit on the number of username entries in the switch’s internal database.  Because authentication is handled by the switch, a secure tunnel is not required for supplicant authentication.

Related:

Version history
Last update:
‎03-28-2012 05:20 PM
Updated by:
Anonymous
Contributors