Understanding eap-md5 Authentication with radius

Understanding EAP-MD5 Authentication with RADIUS

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.

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.

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

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

Length 2 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.

This field specifies the code of a particular attribute. For example ‘1’ represents ‘username’.

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.

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.

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.

Identifies the type of EAP-Packet. The following types are defined for an EAP-Message

1. 
   Request
   
2. 
   Response
   
3. 
   Success
   
4. 
   Failure
   

Matches response with requests

Indicates the length of the total EAP-Packet. This includes Code, id, length, type and type-data.

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
   

This depends on the Authentication protocol being used.

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.
   

1. 
   It sets the code field to ‘2’ indicating it as a response.
   
2. 
   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.
   
3. 
   The Length field has a value of the total length of the EAP packet.
   
4. 
   The type field is ‘1’ indicating it as an ‘identity’ type.
   
5. 
   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.
   
   1. 
      The code field of this RADIUS packet is set to ‘1’ indicating an Access-Request.
      
   2. 
      The ID field contains a sequenced number to identify future correspondence of this request with RADIUS.
      
   3. 
      The total length of the packet including header and attributes is appended.
      
   4. 
      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.
      
   5. 
      Other attributes as relevant to the request (for e.g. Framed Protocol, NAS IP-Address etc.) are inserted in the packet.
      
   6. 
      The two most important attributes i.e. the EAP-Message and Message Authenticator are also added to this packet.
      
   7. 
      The EAP-Message attribute has a code of 79, and the value contains the EAP identity response packet which was received from the client.
      
   8. 
      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.
      

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:
   
   1. 
      A code value of ‘1’ indicating it as a Request
      
   2. 
      An ID field which is usually the value of response ID + 1
      
   3. 
      Length field indicating the total length of the EAP Message,
      
   4. 
      A type code field of 4 indicating an MD5 Challenge
      
   5. 
      Type–data field containing the challenge value.
      

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 Request-Authenticator 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.
    

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. 
   Vulnerable to Man-in-the-middle attacks
   
5. 
   In case of large installations, management of shared secrets becomes an overhead.
   
6. 
   No Integrity protection
   
7. 
   Minimum protection against replay attacks.
   
8. 
   No support for Confidentiality
   

1. RFC 2284 - PPP Extensible Authentication Protocol (EAP)

2. 
   RFC 2865 – Remote Authentication Dial-In User Service (RADIUS)
   
3. 
   RFC 2869 – RADIUS Extensions
   
4. 
   RFC 1994 – PPP Challenge Handshake Authentication Protocol (CHAP)
   

Compiled By: