Understanding EAP-MD5 Authentication with RADIUS
Structure of the Document
1. Purpose of the document
2. Introduction
3. RADIUS
4. RADIUS Packet structure
5. EAP
6. EAP Packet structure
7. RADIUS EAP-MD5 authentication Process
8. Drawbacks of EAP-MD5
9. Possible EAP methods which addresses the weakness of EAP-MD5
10. Reference
Section 1:
Purpose of the Document
This document has been compiled as an effort to understand the process of
Authentication involved when using RADIUS with EAP-MD5. The document will look
into the details of the EAP-MD5 authentication process when used with RADIUS. We
shall see how RADIUS protocol can be extended to support third-party authentication
process. We shall also discuss the advantages and disadvantages of the protocol and look
at the alternatives that are available to address the shortcomings of the protocol.
Section 2:
Introduction
RADIUS, also known as Remote Authentication Dial-in User Service is an open standard
for a Remote Access Authentication System. It provides the functionalities of
Authentication, Authorization and Accounting commonly known as “AAA” that is very
much essential in any sort of Access Control environment. Though originally used for the
authentication of remote dial-up clients, and widely supported by almost all NAS devices,
RADIUS authentication can very well be extended to other applications with minimal
effort. Various applications are now coming up with plugin modules to authenticate their
users through a RADIUS Server. This is especially useful in heterogeneous environments
where users have access to so many applications all with different passwords for each of
them. Encouraging a Central Authentication System, which is an Open Standard, and
provides good Network Access Security, not only reduces administrative overhead, but
also helps organizations enforce a strong password policy. Users now shall have a choice
of selecting better passwords, and shall be more comfortable remembering them, without
violating organization policies by writing them down at odd places, which might be
vulnerable to Social Engineering Attacks. With a Central Authentication System in place,
user management becomes much easier and less error-prone. Synchronization of different
password databases is no longer needed, thus reducing the overhead of maintaining
redundant user account databases. RADIUS protocol is also flexible enough to support
other forms of Authentication even though support for these authentication protocols
doesn’t come up with the original distribution.
Though RADIUS by itself does provide very limited authentication methods, the
Extensible Authentication Protocol (EAP), can provide dynamic addition of new
authentication methods into RADIUS. This allows different vendors to introduce their
own proprietary authentication methods into RADIUS. Moreover, the RADIUS protocol
is also capable of supporting different authentication methods out of a single installation
as per the authorization variables of a particular user.
In the following Sections we will look into the process of RADIUS authentication and
how EAP can be used to extend its functionality. We shall also take up EAP-MD5
authentication protocol and look into its intricacies.
Section 3:
RADIUS
The RADIUS is a client-server protocol and software, which is used by NAS devices (or
applications), to authenticate remote users and authorize them to access network
resources. A server running the RADIUS service is commonly known as a RADIUS
server. RADIUS is typically used as a Central Authentication System providing
Authentication, Authorization and Accounting for Remote users. The RADIUS server
communicates on UDP port 1812 for handling Authentication and Authorization
requests, and port 1813 for handling Accounting requests from Clients.
NAS devices or applications, which pass on user authentication requests to RADIUS, are
known as clients of RADIUS. To verify the identity of these clients, RADIUS uses
shared secrets. These shared secrets are commonly used passwords, which are configured
for each client separately in a configuration file on the RADIUS server. Before
processing any requests from the client, a checksum of the packet is verified using the
configured Shared Secret for the client. This is to prevent replay attacks on the RADIUS
Server from unauthorized clients. Typically these Access-Request packets contain user
identification and credentials. The RADIUS server verifies these credentials from its
configured user database and checks to see the users authorization parameters in the
database. If all conditions are successfully satisfied, it sends an Access—Accept with
other configuration parameters for the user; else it sends an Access-Reject and the user is
denied Access.
The RADIUS server might also send back an Access-Challenge packet in reply to an
Access-Request. This is when RADIUS needs more clarification to verify the users
identity. This is typically done when the RADIUS server is configured for
Challenge/Response authentication like CHAP. The Access-Challenge packet contains an
attribute- value pair containing a random series of characters (preferably of 16 octets) as
the challenge value, which the user is expected to encrypt and sent back in a new AccessRequest packet. On receipt of the response to this challenge from the client, the RADIUS
server computes the value of the response independently using the agreed upon algorithm
and a reversibly encrypted shared secret of the user that is stored in the database. If the
RADIUS server arrives at the same value to that supplied in the response, the user is
considered to be valid and thus an Access-Accept is returned back to the client. If the
value doesn’t match, the server sends back an Access-Reject packet and the user is
denied Access.
On receipt of an Access-Accept packet, the NAS may want the RADIUS server to start
accounting for the respective user, and thus sends an Accounting Request packet to the
server. The RADIUS server in turn starts accounting for this user, either by
communicating with an external billing system or by maintaining appropriate information
in its own log files. It also sends back an Accounting-Response packet back to the client.
On the event of user closing a connection or getting disconnected by any other means the
NAS sends an Accounting-Request packet to the RADIUS server requesting it to stop
accounting for the respective user. The RADIUS then stops the accounting process for
the user at this point and sends back an Accounting-Response packet back to the NAS.
These two types of Accounting Request packets are sometimes known as Accounting
start bit and Accounting stop bits respectively.
Section 4:
RADIUS Packet Structure
Now having seen how a RADIUS authentication process works, let us try to find out a bit
more about the RADIUS packet structure. A typical RADIUS packet consists of a fixed
length RADIUS header of 20 bytes, and a variable length attribute-value pairs.
RADIUS Packet Header
The following fields are defined in the RADIUS header.
Code 1 Byte
The code defines the type of RADIUS packet. There can be the following types of code.
1
Access-Request
2
Access-Accept
3
Access-Reject
4
Accounting-Request
5
Accounting-Response
11
Access-Challenge
12
Status-Server (experimental)
13
Status-Client(experimental)
255
Experimental
Identifier
1 Byte
The identifier field is used to match requests and replies
Length
2 bytes
The length field denotes the size of the total RADIUS packet including the RADIUS
header and all the Attribute value pairs.
Authenticator
16 Bytes
The Authenticator field is used as a Checksum of the whole packet.
Attribute – Value Pairs
A single attribute value pair consists of three fields.
Type
1 Byte
This field specifies the code of a particular attribute. For example ‘1’ represents
‘username’.
Length
1 Byte
This field defines the Length of an attribute including Type, Length and Value. So the
size of the value field + 2 gives the value of the length field.
Value
Value of Length field – 2
Contains the value of the Attribute
Section 5:
Extensible Authentication Protocol
The EAP protocol was originally designed to provide a standard interface for additional
authentication options within PPP. Thus to provide the same support for EAP within the
RADIUS protocol, two new attributes were designed, the EAP Message attribute and
Message Authenticator (previously known as ‘Signature’). The EAP related information
is encapsulated within the value part of the EAP Message attribute and transmitted in a
RADIUS packet. The Message-Authenticator is a checksum to verify the integrity of
such a RADIUS packet. The Message-Authenticator attribute is mandatory within a
RADIUS packet if it contains a EAP-Message attribute.
By encapsulating the total EAP-Message in one or more EAP-Message attributes of a
RADIUS packet, any authentication method can be used except for the ones supported by
the original protocol. This gives the flexibility of RADIUS supporting arbitrary (and
possibly strong), authentication mechanisms without the need to know the intricacies of
each authentication mechanisms. Of course, the RADIUS server might have to depend on
third party software to interpret the proprietary authentication algorithms. But then again,
this has a considerable advantage since only a part of the code needs a change (if
needed), and not all entities in an Authentication chain.
Section 6:
EAP Packet Structure
Like any other Attribute – Value pair of a RADIUS packet, the EAP-Message attribute
can also be broken down into three parts. –



The type having a code of 79 signifying the EAP message,
The Length, and
The Value.
However, the Value actually contains the EAP-Message details and can be broken down
into the following parts.
Code 1 Byte
Identifies the type of EAP-Packet. The following types are defined for an EAP-Message
1.
Request
2.
Response
3.
Success
4.
Failure
Identifier
1 Byte
Matches response with requests
Length
2 Bytes
Indicates the length of the total EAP-Packet. This includes Code, id, length, type and
type-data.
Type
1 Byte
Defines the type of Authentication protocol in use. The following are the few common
types
1.
Identity
2.
Notification
3.
NAK
4.
MD5-Challenge
5.
One Time password
6.
Generic Token Card
Type-Data
variable Length (Length - 5)
This depends on the Authentication protocol being used.
Section 7:
RADIUS EAP-MD5 Authentication process
Now that we have understood RADIUS and EAP protocols, let us find out how the EAPMD5 authentication protocol works. The major steps are described in the following flowchart. We shall be taking each step and try to analyze the events that are taking place.
1
NAS
PPP LCP Phase attempts EAP
Authentication
2
Dial-Up Client
EAP negotiation
complete. Sends
LCP/ACK to NAS
3
NAS
EAP identity Request issued.
4
Dial-Up Client
EAP Identity response
generated.
5
NAS
RADIUS Access-Request packet
generated with encapsulated EAP
identity response received from
client.
8
Dial-Up Client
Response to the
Challenge generated
using MD5 of EAPMessage ID + Challenge
+ Password. The EAP
MD5 Challenge response
packet is sent to NAS.
7
NAS
PPP EAP MD5 Challenge request
sent to client.
13
Dial-Up Client
PPP Authentication phase
completed and client is
given Access to the
remote network.
16
Dial-Up Client
PPP Authentication phase
completed and client is
denied Access.
9
NAS
RADIUS Access-Request issued
encapsulating the EAP MD5
Challenge Response received
from client.
12
NAS
PPP EAP-Success packet is issued
and client is given Access.
15
NAS
PPP EAP-Failure packet is issued
and client denied Access.
6
RADIUS
User identity verified and
authorization parameters checked.
Access-Challenge packet is
generated encapsulating an EAP
MD5 Challenge request.
10
RADIUS
Response to the Challenge is
verified.
11
RADIUS
Access-Accept packet
encapsulated with EAPSuccess is issued if
Verification is successful.
14
RADIUS
Access-Reject packet
encapsulated with EAPFailure is issued if Verification
fails.
1. When a user dials up a remote connection to a NAS server, PPP negotiation takes
place. Amongst other things, Authentication protocol is negotiated. In this case
the EAP method shall be negotiated at this phase.
2. The client acknowledges the use of EAP authentication method to the NAS
Server.
3. The NAS server now issues an EAP Identity request back to the client asking the
user to identify himself. This is done by assigning an EAP Message ID to the
request and by setting the code field to ‘1’indicating a request packet. The length
field contains the total length of the EAP packet and the Type field has a value of
‘1’ indicating the EAP-Message type ‘identity’.
4. The client on receiving this packet issues a response to the EAP identity request.
a. It sets the code field to ‘2’ indicating it as a response.
b. The ID field contains the same identity as was sent from the NAS, which
will enable it to match the response to the request it had sent earlier.
c. The Length field has a value of the total length of the EAP packet.
d. The type field is ‘1’ indicating it as an ‘identity’ type.
e. The Type-data contains the name of the user. This packet is then sent back
to the NAS server.
5. On receipt of this Packet, the NAS server creates an Access-Request packet for
the RADIUS server.
a. The code field of this RADIUS packet is set to ‘1’ indicating an AccessRequest.
b. The ID field contains a sequenced number to identify future
correspondence of this request with RADIUS.
c. The total length of the packet including header and attributes is appended.
d. The Request Authenticator field is calculated on the whole RADIUS
packet using the shared secret of the NAS and the RADIUS server. This
value is then inserted into the packet.
e. Other attributes as relevant to the request (for e.g. Framed Protocol, NAS
IP-Address etc.) are inserted in the packet.
f. The two most important attributes i.e. the EAP-Message and Message
Authenticator are also added to this packet.
g. The EAP-Message attribute has a code of 79, and the value contains the
EAP identity response packet which was received from the client.
h. The Message Authenticator is calculated as an HMAC MD5 of the whole
packet using the shared secret as the key. This is inserted into the value
portion of the Message Authenticator attribute.
Once this packet is created it is then transmitted on the Destination UDP port
1812 of the configured RADIUS server.
6. The RADIUS server first checks the request authenticator field to verify that the
packet has come from an authentic NAS device. If EAP conversation is detected,
the Message Authenticator is also checked. If both the checks are found to be
correct, the user identity is extracted from the EAP – Message attribute and
processed for authorization checks. If the authorization check returns true, an
MD5 challenge is generated for this request. An EAP packet structure is created
with the following structure:
a. A code value of ‘1’ indicating it as a Request
b. An ID field which is usually the value of response ID + 1
c. Length field indicating the total length of the EAP Message,
d. A type code field of 4 indicating an MD5 Challenge
e. Type–data field containing the challenge value.
This packet is then assigned into the value part of the EAP – Message attribute
and encapsulated in an Access-Challenge packet. The code of the AccessChallenge packet is ‘11’ and the packet ID is that of the request this challenge is
in reply to. This packet is then be sent back to the NAS server.
7. The NAS server on receipt of this packet checks the Response – Authenticator
and the Message – Authenticator fields to determine the authenticity and integrity
of the packet. After this it extracts the EAP message value and crafts an EAP
Challenge packet of type MD5 Challenge and sends it back to the Client.
8. On receiving this packet the client extracts the value of the Challenge and the ID
of the EAP message. It then calculates the response value of this challenge by
performing an MD5 hash of the following: EAP-Message Id + User Password +
the Challenge value. This is inserteds into an EAP Message of type 4, ID as that
of the request and code ‘2’ indicating a response EAP packet of type MD5
challenge. The packet is again transmitted back to the NAS server.
9. The NAS server forwards this EAP response packet by encapsulating it in an
Access-Request Packet to the RADIUS server.
10. The radius server verifies the Message-Authenticator and the RequestAuthenticator values to check the authenticity and integrity of the packet.It then
extract the Challenge/Response value from the EAP-Message attribute. The
response to the challenge is identified by matching the EAP Message ID which
was issued at the time of generating the Access-Challenge packet. The server now
performs a similar MD5 hash of the EAP-Message id + challenge issued + user
password from the user database.
11. If both the Values match, an Access-Accept packet with other configuration
parameters and an EAP Message attribute of type EAP – Success is created and
sent to the NAS.
12. The NAS in turn performs the usual checks on the Request–Authenticator and the
Message-Authenticator attributes and on success forwards the EAP-Success
message to the client.
13. The Client at this point is connected to the remote network or further negotiations
on Network Core Protocol (NCP) layer might take place.
14. If both the Values do not match, an Access-Reject packet with an EAP Message
attribute of type EAP-Failure is created and sent to the NAS.
15. The NAS in turn performs the usual checks on Request–Authenticator and
Message Authenticator attributes and on success forwards the EAP-Failure
message to the client.
16. The Client at this point is denied access to the remote network and a suitable
message describing the error is displayed to the user as per the error code returned
by NAS.
Section 8: Drawbacks of EAP-MD5
EAP-MD5 Authentication protocol closely resembles the PPP-CHAP protocol. When
used with RADIUS, it provides a limited protection against replay attacks and does not
send clear text passwords over the transmitting media. However a lot of other
disadvantages do exist. While EAP-MD5 might be considered as an authentication
protocol over non-promiscuous channel, like dial-up access, other forms of utilization do
impose a considerable amount of risk in exposing user credentials. Here are some of the
issues we should consider before using EAP-MD5.
1. No mutual Authentication
2. No Protection against offline brute-force/Dictionary based attacks on user
passwords.
3. User passwords need to be stored in clear or reversibly encrypted format.
4.
5.
6.
7.
8.
Vulnerable to Man-in-the-middle attacks
In case of large installations, management of shared secrets becomes an overhead.
No Integrity protection
Minimum protection against replay attacks.
No support for Confidentiality
Section 9: Possible EAP methods which addresses the weakness of EAP-MD5
EAP-MD5 is a legacy authentication protocol for PPP based systems. Though it is
convenient for the user and provides better security than PAP, the number of
disadvantages it has in the present computing environment outnumber its advantages. It is
highly desirable to move onto stronger authentication techniques to address the
drawbacks of this protocol as described in the previous section. Certificate based
authentication is highly desirable in vulnerable remote access environments, dealing with
sensitive user identities. EAP-TLS, EAP-PEAP, EAP-TTLS, Cisco-LEAP etc, are the
protocols which offer much better security than the legacy EAP-MD5. A thorough
discussion of these protocols is outside the scope of this document. Please refer to the
corresponding RFC’s for further discussion on these protocols.
Section 10: References
1.
2.
3.
4.
RFC 2284 - PPP Extensible Authentication Protocol (EAP)
RFC 2865 – Remote Authentication Dial-In User Service (RADIUS)
RFC 2869 – RADIUS Extensions
RFC 1994 – PPP Challenge Handshake Authentication Protocol (CHAP)
Compiled By:
Sudipto Chakraborty
ISmart International Limited