0

• The figure shows a generic network access diagram.

• A variety of different ARs seek access to an enterprise network by applying to some

type of NAS.

• The policy server and the NAS cooperate to authenticate the Ars, and decide data ARs
can access and actions they can perform.
• The following figure shows the typical process of Authentication and authorization in
RADIUS.

• On behalf of a user, the NAS acts as a client and communicates with the RADIUS
server to authenticate the user.
• The figure describes the accounting process.
• The RADIUS packet data format is shown in the figure.

• The Code field is one octet, and identifies the type of RADIUS packet. Common RADIUS
Codes (decimal) and as follows:

• Access-Request

• Access-Accept

• Access-Reject

• Accounting-Request

• Accounting-Response

• Access-Challenge

• The Identifier field is one octet, and aids in matching requests and replies.

• The Length field is two octets. It indicates the length of the packet including the Code,
Identifier, Length, Authenticator and Attribute fields.

• The Authenticator field is sixteen (16) octets.

• The Attribute field is variable in length, and carry the specific authentication,
authorization, information and configuration details for the request and reply.
• The figure illustrates the protocol layers that form the context for EAP.

• The top layer lists various authentication methods that EAP can support, including TLS,
PSK, IKEv2 and so on. The EAP layer defines a set of messages to encapsulate various
authentication methods. The Data link layer defines a variety of network and link level
facilities, including point-to-point links, LANs, and other networks that EAP can operate
on.
• The figure indicates a typical arrangement in which EAP is used. The following
components are involved:

• EAP peer: Client computer that is attempting to access a network.

• EAP authenticator: An access point or NAS that requires EAP authentication prior to
granting access to a network.

• Authentication server: A server that negotiates the use of a specific EAP method with
an EAP peer, validates the EAP peer’s credentials, and authorizes access to the network.
Typically, the authentication server is a Remote Authentication Dial-In User Service
(RADIUS) server.

• The authentication server functions as a backend server that can authenticate peers as
a service to a number of EAP authenticators. The EAP authenticator then makes the
decision of whether to grant access. This is referred to as the EAP passthrough mode.
Less commonly, the authenticator takes over the role of the authentication server; that
is, only two parties are involved in the EAP execution.
• The above figure shows the structure of EAP messages, which include the following
fields, as:

• Code: The Code field is one octet and identifies the Type of EAP message.

• Identifier: The Identifier field is one octet and used to match Responses with Requests.

• Length: The Length field is two octets and indicates the length, in octets, of the EAP
packet including the Code, Identifier, Length, and Data fields.

• Data: This field contains information related to authentication, determined by the

Code field. The Request and Response message include a Data field, but the Success
and Failure messages do not. Typically, the Data field consists of a Type subfield, which
is 1 octet and indicates the type of data carried, and a Type-Data field, which consists
of more octets.
• First, the EAP peer signals the authenticator, requesting an EAP exchange to grant
network access. Followed is a pair of EAP Request and Response messages of Type
identity, in which the authenticator requests the peer’s identity, and the peer returns its
claimed identity in the Response message. This Response is passed through the
authenticator to the authentication server. Subsequent EAP messages are exchanged
between the peer and the authentication server.

• Upon receiving the identity Response message from the peer, the server selects an EAP
method and sends the first EAP message with a Type field related to an authentication
method. If the peer supports and accepts the selected EAP method, it replies with the
corresponding Response message of the same type. Otherwise, the peer sends a NAK,
and the EAP server either selects another EAP method or aborts the EAP execution
with a failure message. The selected EAP method determines the number of
Request/Response pairs. During the exchange the appropriate authentication
information, including key material, is exchanged.

• The exchange ends when the server determines that authentication has succeeded or
that no further attempt can be made and authentication has failed.
• IEEE 802.1X Port-Based Network Access Control was designed to provide access control
functions for LANs.

• The figure depicts the general idea of 802.1X. In the context of IEEE 802.11 standard,
the terms supplicant, network access point, and authentication server correspond to
the EAP terms peer, authenticator, and authentication server, respectively.

• Until the AS authenticates a supplicant using an authentication protocol, the 802.1X

uncontrolled port is unblocked, which is used by the authenticator to pass control and
authentication messages between the supplicant and the AS. However, the 802.11
controlled port is blocked. As a result, data other than control and authentication
information from the supplicant will be blocked. Once a supplicant is authenticated
and keys are provided, the controlled port is unblocked, and the authenticator can
forward data from the supplicant, subject to predefined access control limitations for
the supplicant to the network.
• The figure shows an example of exchange using EAPOL, assuming that the
authentication method is EAP-MD5. The exchange proceeds as following.

• First, the EAP peer sends a start message to the authenticator, requesting to grant
network access.

• The authenticator replies with an EAP-Request/Identity message, asking the EAP peer
to provide identity.

• The EAP peer sends an EAP-Response/Identity message, which includes the identity of
the peer, to the authenticator.

• The authenticator encapsulates the received identity with a RADIUS Access-Request

message, and sends it to the RADIUS server.

• The RADIUS server finds the key material of the peer, generates a challenge, and sends
the challenge in a RADIUS Access-Challenge message to the authenticator.

• The authenticator forwards the challenge by sending an EAP-Request/MD5 Challenge

message to the EAP peer;

• The EAP peer processes the challenge using her key material, and forms an EAP-
Response/ MD5 challenge message to the authenticator;

• The authenticator encapsulates the response with a RADIUS Access-Request message,

and sends it to the RADIUS server.

• The RADIUS server authenticates the EAP peer using the response. If successful, the
server sends a RADIUS Access-Accept message to the authenticator, which translates it
to an EAP-Success message to the EAP peer. At this time, the controlled port is
unblocked.
• The user tries to logon to the network, providing her username and password. The
NAS forwards the user information to the HWTCACS server. If user information is
correct, the server sends a “authentication passed” message to the NAS. Then the NAS
then requests a certain level of access, on behalf of the client.
• The differences between HWTACACS and RADIUS are listed in the table.

• For transport, HWTCACAS uses TCP, while RADIUS uses UDP.

• In HWTCACAS, for every message, the entire message body is encrypted. In Radius,
only the password field in the authentication message is encrypted. As a result,
HWTCACS provides stronger protection than RADIUS.

• In RADIUS, authentication and authorization are achieved in the same step. In

HWTCACAS, authentication and authorization are separated into two different steps.

• HWTCACS focuses on control the access to a corporate network. In RADIUS,

accounting also plays an important role.