Chapter 1 802.1x
Configuration
When configuring 802.1x, go to these
sections for information you are interested in:
l
Introduction
to 802.1x
l
Introduction
to 802.1x Configuration
l
Basic
802.1x Configuration
l
Advanced
802.1x Configuration
l
Displaying
and Maintaining 802.1x Configuration
l
Configuration
Example
The 802.1x protocol (802.1x for short) was developed
by IEEE802 LAN/WAN committee to address security issues of wireless LANs. It was
then used in Ethernet as a common access control mechanism for LAN ports to address
mainly authentication and security problems.
802.1x is a port-based network access
control protocol. It authenticates and controls devices requesting for access
in terms of the ports of LAN access devices. With the 802.1x protocol employed,
a user-side device can access the LAN only when it passes the authentication. Those
fail to pass the authentication are denied when accessing the LAN.
This section covers these topics:
l
Architecture
of 802.1x Authentication
l
The
Mechanism of an 802.1x Authentication System
l
Encapsulation
of EAPoL Messages
l
802.1x
Authentication Procedure
l
Timers
Used in 802.1x
l
802.1x
Implementation on an S5600 Series Switch
As shown in Figure 1-1, 802.1x adopts a client/server
architecture with three entities: a supplicant system, an authenticator system,
and an authentication server system.
Figure 1-1 Architecture of 802.1x authentication
l
The supplicant system is an entity residing at one
end of a LAN segment and is authenticated by the authenticator system at the
other end of the LAN segment. The supplicant system is usually a user terminal
device. An 802.1x authentication is triggered when a user launches client
program on the supplicant system. Note that the client program must support the
extensible authentication protocol over LAN (EAPoL).
l
The authenticator system is another entity
residing at one end of a LAN segment. It authenticates the connected supplicant
systems. The authenticator system is usually an 802.1x-supported network device
(such as a H3C series switch). It provides the port (physical or logical) for
the supplicant system to access the LAN.
l
The authentication server system is an entity
that provides authentication service to the authenticator system. Normally in
the form of a RADIUS server, the authentication server system serves to perform
Authentication, Authorization, and Accounting (AAA) services to users. It also
stores user information, such as user name, password, the VLAN a user belongs
to, priority, and the Access Control Lists (ACLs) applied.
The four basic concepts related to the
above three entities are PAE, controlled port and uncontrolled port, the valid
direction of a controlled port and the way a port is controlled.
I. PAE
A port access entity (PAE) is responsible
for implementing algorithms and performing protocol-related operations in the
authentication mechanism.
l
The authenticator system PAE authenticates the
supplicant systems when they log into the LAN and controls the status (authorized/unauthorized)
of the controlled ports according to the authentication result.
l
The supplicant system PAE responds to the authentication
requests received from the authenticator system and submits user authentication
information to the authenticator system. It also sends authentication requests and
disconnection requests to the authenticator system PAE.
II. Controlled port and uncontrolled
port
The authenticator system provides ports for
supplicant systems to access a LAN. Logically, a port of this kind is divided
into a controlled port and an uncontrolled port.
l
The uncontrolled port can always send and
receive packets. It mainly serves to forward EAPoL packets to ensure that a supplicant
system can send and receive authentication requests.
l
The controlled port can be used to pass service
packets when it is in authorized state. It is blocked when not in authorized
state. In this case, no packets can pass through it.
l
Controlled port and uncontrolled port are two
properties of a port. Packets reaching a port are visible to both the
controlled port and uncontrolled port of the port.
III. The valid direction of a
controlled port
When a controlled port is in unauthorized
state, you can configure it to be a unidirectional port, which sends packets to
supplicant systems only.
By default, a controlled port is a
unidirectional port.
IV. The way a port is controlled
A port of a H3C series switch can be
controlled in the following two ways.
l
Port-based authentication. When a port is
controlled in this way, all the supplicant systems connected to the port can
access the network without being authenticated after one supplicant system
among them passes the authentication. And when the authenticated supplicant
system goes offline, the others are denied as well.
l
MAC-based authentication. All supplicant systems
connected to a port have to be authenticated individually in order to access
the network. And when a supplicant system goes offline, the others are not
affected.
IEEE 802.1x authentication system uses the Extensible
Authentication Protocol (EAP) to exchange information between the supplicant
system and the authentication server.
Figure 1-2 The mechanism of an 802.1x
authentication system
l
EAP protocol packets transmitted between the supplicant
system PAE and the authenticator system PAE are encapsulated as EAPoL packets.
l
EAP protocol packets transmitted between the authenticator
system PAE and the RADIUS server can either be encapsulated as EAP over RADIUS
(EAPoR) packets or be terminated at system PAEs. The system PAEs then communicate
with RADIUS servers through Password Authentication Protocol (PAP) or Challenge-Handshake
Authentication Protocol (CHAP) packets.
l
When a supplicant system passes the
authentication, the authentication server passes the information about the
supplicant system to the authenticator system. The authenticator system in turn
determines the state (authorized or unauthorized) of the controlled port
according to the instructions (accept or reject) received from the RADIUS
server.
I. The format of an EAPoL packet
EAPoL is a packet encapsulation format
defined in 802.1x. To enable EAP protocol packets to be transmitted between
supplicant systems and authenticator systems through LANs, EAP protocol packets
are encapsulated in EAPoL format. The following figure illustrates the
structure of an EAPoL packet.
Figure 1-3 The format of an EAPoL packet
In an EAPoL packet:
l
The PAE Ethernet type field holds the protocol
identifier. The identifier for 802.1x is 0x888E.
l
The Protocol version field holds the version of
the protocol supported by the sender of the EAPoL packet.
l
The Type field can be one of the following:
00: Indicates that the packet is an EAP-packet, which carries
authentication information.
01: Indicates that the packet is an EAPoL-start packet, which initiates
the authentication.
02: Indicates that the packet is an EAPoL-logoff packet, which sends
logging off requests.
03: Indicates that the packet is an EAPoL-key packet, which carries
key information.
04: Indicates that the packet is an EAPoL-encapsulated-ASF-Alert
packet, which is used to support the alerting messages of Alerting Standards
Forum (ASF).
l
The Length field indicates the size of the
Packet body field. A value of 0 indicates that the Packet Body field does not
exist.
l
The Packet body field differs with the Type
field.
Note that EAPoL-Start, EAPoL-Logoff, and EAPoL-Key
packets are only transmitted between the supplicant system and the authenticator
system. EAP packets are encapsulated by RADIUS protocol to allow them
successfully reach the authentication servers. Network management-related
information (such as alarming information) is encapsulated in EAPoL-Encapsulated-ASF-Alert
packets, which are terminated by authenticator systems.
II. The format of an EAP packet
For an EAPoL packet with the value of the Type
field being EAP-packet, its Packet body field is an EAP packet, whose format is
illustrated in Figure 1-4.
Figure 1-4 The format of an EAP packet
In an EAP packet:
l
The Code field indicates the EAP packet type,
which can be Request, Response, Success, or Failure.
l
The Identifier field is used to match a Response
packet with the corresponding Request packet.
l
The Length field indicates the size of an EAP
packet, which includes the Code, Identifier, Length, and Data fields.
l
The Data field carries the EAP packet, whose format
differs with the Code field.
A Success or Failure packet does not
contain the Data field, so the Length field of it is 4.
Figure 1-5 shows the format
of the Data field of a Request packet or a Response packet.
Figure 1-5 The format of the Data field
of a Request packet or a Response packet
l
The Type field indicates the EAP authentication
type. A value of 1 indicates Identity and that the packet is used to query the
identity of the peer. A value of 4 represents MD5-Challenge (similar to PPP
CHAP) and indicates that the packet includes query information.
l
The Type Date field differs with types of
Request and Response packets.
III. Newly added fields for EAP
authentication
Two fields, EAP-message and
Message-authenticator, are added to a RADIUS protocol packet for EAP
authentication. (Refer to the Introduction to RADIUS protocol section in the AAA
Operation for information about the format of a RADIUS protocol
packet.)
The EAP-message field, whose format is shown
in Figure 1-6,
is used to encapsulate EAP packets. The maximum size of the string field is 253
bytes. EAP packets with their size larger than 253 bytes are fragmented and are
encapsulated in multiple EAP-message fields. The type code of the EAP-message
field is 79.
Figure 1-6 The format of an EAP-message field
The Message-authenticator field, whose
format is shown in Figure
1-7, is used to prevent unauthorized interception to access
requesting packets during authentications using CHAP, EAP, and so on. A packet
with the EAP-message field must also have the Message-authenticator field. Otherwise,
the packet is regarded as invalid and is discarded.
Figure 1-7
The format of an Message-authenticator field
A H3C S5600 series Ethernet switch can authenticate
supplicant systems in EAP terminating mode or EAP relay mode.
I. EAP relay mode
This mode is defined in 802.1x. In this
mode, EAP packets are encapsulated in higher level protocol (such as EAPoR) packets
to enable them to successfully reach the authentication server. Normally, this
mode requires that the RADIUS server support the two newly-added fields: the
EAP-message field (with a value of 79) and the Message-authenticator field
(with a value of 80).
Four authentication ways, namely EAP-MD5,
EAP-TLS (transport layer security), EAP-TTLS (tunneled transport layer
security), and Protected Extensible Authentication Protocol (PEAP), are
available in the EAP relay mode.
l
EAP-MD5 authenticates the supplicant system. The
RADIUS server sends MD5 keys (contained in EAP-request/MD5 challenge packets)
to the supplicant system, which in turn encrypts the passwords using the MD5
keys.
l
EAP-TLS allows the supplicant system and the
RADIUS server to check each other’s security certificate and authenticate
each other’s identity, guaranteeing that data is transferred to the right
destination and preventing data from being intercepted.
l
EAP-TTLS is a kind of extended EAP-TLS. EAP-TLS
implements bidirectional authentication between the client and authentication
server. EAP-TTLS transmit message using a tunnel established using TLS.
l
PEAP creates and uses TLS security channels to
ensure data integrity and then performs new EAP negotiations to verify
supplicant systems.
Figure 1-8 describes the
basic EAP-MD5 authentication procedure.
Figure 1-8 802.1x authentication procedure (in EAP relay mode)
The detailed procedure is as follows:
l
A supplicant system launches an 802.1x client to
initiate an access request by sending an EAPoL-start packet to the switch, with
its user name and password provided. The 802.1x client program then forwards
the packet to the switch to start the authentication process.
l
Upon receiving the authentication request
packet, the switch sends an EAP-request/identity packet to ask the 802.1x
client for the user name.
l
The 802.1x client responds by sending an
EAP-response/identity packet to the switch with the user name contained in it. The
switch then encapsulates the packet in a RADIUS Access-Request packet and forwards
it to the RADIUS server.
l
Upon receiving the packet from the switch, the
RADIUS server retrieves the user name from the packet, finds the corresponding
password by matching the user name in its database, encrypts the password using
a randomly-generated key, and sends the key to the switch through an RADIUS
access-challenge packet. The switch then sends the key to the 802.1x client.
l
Upon receiving the key (encapsulated in an
EAP-request/MD5 challenge packet) from the switch, the client program encrypts
the password of the supplicant system with the key and sends the encrypted
password (contained in an EAP-response/MD5 challenge packet) to the RADIUS
server through the switch. (Normally, the encryption is irreversible.)
l
The RADIUS server compares the received encrypted
password (contained in a RADIUS access-request packet) with the
locally-encrypted password. If the two match, it will then send feedbacks
(through a RADIUS access-accept packet and an EAP-success packet) to the switch
to indicate that the supplicant system is authenticated.
l
The switch changes the state of the corresponding
port to accepted state to allow the supplicant system to access the network.
l
The supplicant system can also terminate the
authenticated state by sending EAPoL-Logoff packets to the switch. The switch
then changes the port state from accepted to rejected.
In EAP relay mode,
packets are not modified during transmission. Therefore if one of the four ways
are used (that is, PEAP, EAP-TLS, EAP-TTLS or EAP-MD5) to authenticate, ensure
that the authenticating ways used on the supplicant system and the RADIUS
server are the same. However for the switch, you can simply enable the EAP
relay mode by using the dot1x authentication-method eap command.
II. EAP terminating mode
In this mode, EAP packet transmission is
terminated at authenticator systems and the EAP packets are converted to RADIUS
packets. Authentication and accounting are carried out through RADIUS protocol.
In this mode, PAP or CHAP is employed
between the switch and the RADIUS server. Figure 1-9 illustrates the authentication
procedure (assuming that CHAP is employed between the switch and the RADIUS
server).
Figure 1-9 802.1x authentication procedure (in EAP terminating mode)
The authentication procedure in EAP
terminating mode is the same as that in the EAP relay mode except that the
randomly-generated key in the EAP terminating mode is generated by the switch,
and that it is the switch that sends the user name, the randomly-generated key,
and the supplicant system-encrypted password to the RADIUS server for further
authentication.
In 802.1 x authentication, the following
timers are used to ensure that the supplicant system, the switch, and the
RADIUS server interact in an orderly way.
l
Handshake timer (handshake-period). This
timer sets the handshake period and is triggered after a supplicant system
passes the authentication. It sets the interval for a switch to send handshake
request packets to online users. You can set the maximum number of transmission
attempts by using the dot1x retry command. An online user will be considered
offline when the switch has not received any response packets after the maximum
number of handshake request transmission attempts is reached.
l
Quiet-period timer (quiet-period). This
timer sets the quiet-period. When a supplicant system fails to pass the
authentication, the switch quiets for the set period (set by the quiet-period
timer) before it processes another authentication request re-initiated by the
supplicant system. During this quiet period, the switch does not perform any
802.1x authentication-related actions for the supplicant system.
l
Re-authentication timer (reauth-period). The
switch initiates 802.1x re-authentication at the interval set by the
re-authentication timer.
l
RADIUS server timer (server-timeout). This timer sets the server-timeout period. After sending an
authentication request packet to the RADIUS server, the switch sends another
authentication request packet if it does not receive the response from the
RADIUS server when this timer times out.
l
Supplicant system timer (supp-timeout).
This timer sets the supp-timeout period and is triggered by the switch after the
switch sends a request/challenge packet to a supplicant system. The switch
sends another request/challenge packet to the supplicant system if the switch
does not receive the response from the supplicant system when this timer times
out.
l
Transmission timer (tx-period). This
timer sets the tx-period and is triggered by the switch in two cases. The first
case is when the client requests for authentication. The switch sends a unicast
request/identity packet to a supplicant system and then triggers the
transmission timer. The switch sends another request/identity packet to the
supplicant system if it does not receive the reply packet from the supplicant
system when this timer times out. The second case is when the switch
authenticates the 802.1x client who cannot request for authentication actively.
The switch sends multicast request/identity packets periodically through the
port enabled with 802.1x function. In this case, this timer sets the interval
to send the multicast request/identity packets.
l
Client version request timer (ver-period).
This timer sets the version period and is triggered after a switch sends a
version request packet. The switch sends another version request packet if it
does receive version response packets from the supplicant system when the timer
expires.
In addition to the earlier mentioned 802.1x
features, an S5600 series switch is also capable of the following:
l
Checking supplicant systems for proxies, multiple
network adapters, and so on (This function needs the cooperation of a CAMS
server.)
l
Checking client version
l
The guest VLAN function
H3C's CAMS Server is
a service management system used to manage networks and to secure networks and
user information. With the cooperation of other networking devices (such as
switches) in the network, a CAMS server can implement the AAA functions and
rights management.
I. Checking the supplicant system
An S5600 series switch checks:
l
Supplicant systems logging on through proxies
l
Supplicant systems logging on through IE proxies
l
Whether or not a supplicant system logs in
through more than one network adapters (that is, whether or not more than one
network adapters are active in a supplicant system when the supplicant system
logs in).
In response to any of the three cases, a
switch can optionally take the following measures:
l
Only disconnects the supplicant system but sends
no Trap packets.
l
Sends Trap packets without disconnecting the
supplicant system.
This function needs the cooperation of 802.1x
client and a CAMS server.
l
The 802.1x client needs to be capable of
detecting multiple network adapters, proxies, and IE proxies.
l
The CAMS server is configured to disable the use
of multiple network adapters, proxies, or IE proxies.
By default, an 802.1x client program allows
use of multiple network adapters, proxies, and IE proxies. In this case, if the
CAMS server is configured to disable use of multiple network adapters, proxies,
or IE proxies, it prompts the 802.1x client to disable use of multiple network
adapters, proxies, or IE proxies through messages after the supplicant system
passes the authentication.
l
The client-checking function needs the support
of H3C’s 802.1x client program.
l
To implement the proxy detecting function, you
need to enable the function on both the 802.1x client program and the CAMS
server in addition to enabling the client version detecting function on the
switch by using the dot1x version-check command.
II. Checking the client version
With the 802.1x client version-checking function
enabled, a switch checks the version and validity of an 802.1x client to
prevent unauthorized users or users with earlier versions of 802.1x client from
logging in.
This function makes the switch to send
version-requesting packets again if the 802.1x client fails to send
version-reply packet to the switch when the version-checking timer times out.
The 802.1x client version-checking
function needs the support of H3C’s 802.1x client program.
III. The guest VLAN function
The guest VLAN function enables supplicant
systems that are not authenticated to access network resources in a restrained
way.
The guest VLAN function enables supplicant
systems that do not have 802.1x client installed to access specific network
resources. It also enables supplicant systems that are not authenticated to upgrade
their 802.1x client programs.
With this function enabled:
l
The switch sends authentication triggering request
(EAP-Request/Identity) packets to all the 802.1x-enabled ports.
l
After the maximum number retries have been made
and there are still ports that have not sent any response back, the switch will
then add these ports to the guest VLAN.
l
Users belonging to the guest VLAN can access the
resources of the guest VLAN without being authenticated. But they need to be
authenticated when accessing external resources.
Normally, the guest VLAN function is
coupled with the dynamic VLAN delivery function.
Refer to AAA
Operation for detailed information about the dynamic
VLAN delivery function.
IV. Enabling 802.1x re-authentication
802.1x re-authentication is timer-triggered
or packet-triggered. It re-authenticates users who have passed authentication. With
802.1x re-authentication enabled, the switch can monitor the connection status
of users periodically. If the switch receives no re-authentication response
from a user in a period of time, it tears down the connection to the user. To
connect to the switch again, the user needs to initiate 802.1x authentication
with the client software again.
l
When re-authenticating a user, a switch goes
through the complete authentication process. It transmits the username and
password of the user to the server. The server may authenticate the username
and password, or, however, use re-authentication for only accounting and user
connection status checking and therefore does not authenticate the username and
password any more.
l
An authentication server running CAMS
authenticates the username and password during re-authentication of a user in
the EAP authentication mode but does not in PAP or CHAP authentication mode.
Figure
1-10 802.1x re-authentication
802.1x re-authentication can be enabled in one
of the following two ways:
l
The RADIUS server has the switch perform 802.1x
re-authentication of users. The RADIUS server sends the switch an Access-Accept
packet with the Termination-Action attribute field of 1. Upon receiving the
packet, the switch re-authenticates the user periodically.
l
You enable 802.1x re-authentication on the
switch. With 802.1x re-authentication enabled, the switch re-authenticates
users periodically.
802.1x
re-authentication will fail if a CAMS server is used and configured to perform
authentication but not accounting. This is because a CAMS server establishes a
user session after it begins to perform accounting. Therefore, to enable 802.1x
re-authentication, do not configure the accounting none command in the
domain. This restriction does not apply to other types of servers.
1.2 Introduction
to 802.1x Configuration
802.1x provides a solution for
authenticating users. To implement this solution, you need to execute 802.1x-related
commands. You also need to configure AAA schemes on switches and specify the
authentication scheme (RADIUS or local authentication scheme).
Figure 1-11 802.1x configuration
l
802.1x users use domain names to associate with
the ISP domains configured on switches
l
Configure the AAA scheme (a local authentication
scheme or a RADIUS scheme) to be adopted in the ISP domain.
l
If you specify to use a local authentication
scheme, you need to configure the user names and passwords manually on the
switch. Users can pass the authentication through 802.1x client if they provide
user names and passwords that match those configured on the switch.
l
If you specify to adopt the RADIUS scheme, the
supplicant systems are authenticated by a remote RADIUS server. In this case, you
need to configure user names and passwords on the RADIUS server and perform
RADIUS client-related configuration on the switches.
l
You can also specify to adopt the RADIUS
authentication scheme, with a local authentication scheme as a backup. In this
case, the local authentication scheme is adopted when the RADIUS server fails.
Refer to the AAA Operation for
detailed information about AAA scheme configuration.
1.3.1 Configuration
Prerequisites
l
Configure ISP domain and the AAA scheme to be
adopted. You can specify a RADIUS scheme or a local scheme.
l
Ensure that the service type is configured as lan-access
(by using the service-type command) if local authentication scheme is
adopted.
Follow these steps to configure basic 802.1x functions:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enable 802.1x globally
|
dot1x
|
Required
By default, 802.1x is disabled globally.
|
|
Enable 802.1x for specified ports
|
In system view
|
dot1x interface
interface-list
|
Required
By default, 802.1x is disabled on all
ports.
|
|
In port view
|
interface interface-type
interface-number
|
|
dot1x
|
|
quit
|
|
Set port access control mode for
specified ports
|
In system view
|
dot1x port-control
{ authorized-force | unauthorized-force | auto } [ interface
interface-list ]
|
Optional
By default, an 802.1x-enabled port
operates in the auto mode.
|
|
In port view
|
interface interface-type interface-number
|
|
dot1x port-control { authorized-force | unauthorized-force | auto }
|
|
quit
|
|
Set port access method for specified
ports
|
|
dot1x port-method
{ macbased | portbased } [ interface interface-list
]
|
Optional
The default port access method is
MAC-address-based (that is, the macbased keyword is used by default).
|
|
|
interface interface-type interface-number
|
|
dot1x port-method
{ macbased | portbased }
|
|
quit
|
|
Set authentication method for 802.1x
users
|
dot1x authentication-method
{ chap | pap | eap }
|
Optional
By default, a switch performs CHAP
authentication in EAP terminating mode.
|
|
Enable online user handshaking
|
dot1x handshake enable
|
Optional
By default, online user handshaking is
enabled.
|
|
Enter Ethernet port view
|
interface interface-type interface-number
|
—
|
|
Enable the handshake packet protection
function
|
dot1x handshake secure
|
Optional
By default, the handshake packet
protection function is disabled.
|
Caution:
l
802.1x configurations take effect only after you
enable 802.1x both globally and for specified ports.
l
The settings of 802.1x and MAC address learning
limit are mutually exclusive. Enabling 802.1x on a port will prevent you from
setting the limit on MAC address learning on the port and vice versa.
l
The settings of 802.1x and aggregation group
member are mutually exclusive. Enabling 802.1x on a port will prevent you from
adding the port to an aggregation group and vice versa.
l
When a device operates as an authentication
server, its authentication method for 802.1x users
cannot be configured as EAP.
l
With the support of the H3C proprietary client, handshake
packets are used to test whether or not a user is online.
l
As clients that are not of H3C do not support
the online user handshaking function, switches cannot receive handshake
a
