RADIUS - Remote Authentication Dial-In User Service
ABSTRACT
For wireless association, Cisco Meraki MR access point which is designed to use advanced Wi-Fi 6 technologies allow a variety of authentication mechanism, including the external authentication servers to support WPA2-Enterprise. Using free Radius authentication, the Radius server can secure wireless networks from spoofing MAC address and WEP/WPA exploiting. Another thing is that access point control in the region is still performed manually by IT administrators. Using the Radius server, which is a Wi-Fi pass application, we can monitor all the access points by its access controller. This assignment outlines information about the RADIUS server, its use for authentication, its requirements, benefits and configuration for it.
INTRODUCTION
RADIUS
RADIUS stands for Remote Authentication Dial-In User Service. It is an Internet Security Networking Protocol that runs on the Application layer but it can also use TCP or UDP for transport. It is also used for registering users to provide access to the network. It is a client-server protocol that uses RADIUS Server and RADIUS Clients. It was developed by Livingston Enterprises. It was accepted as standard into the IETF — Internet Engineering Task Force. This protocol is developed for providing security management and statistics collection in remote computing environments and distributed networks. For 802.1X authentication, RADIUS is usually used in the back-end part. It works on 1812 and 1813 ports. RADIUS provides Authentication, Authorization and Accounting which is also known as the AAA framework for users who wants to connect to the network or wants to use services centrally. RADIUS is now pretty widely used for authentication cases. It improves protection by allowing an organisation to set up a policy that can be implemented at a single network point that is managed.
- RADIUS Client: It is also known as Network Access Server which is a networking system that authenticates users for devices such as a router, VPN concentrator or switch.
- RADIUS Server: It is a service that runs on the computer in the background on a WINDOWS or UNIX server. It contains the details of user profiles in a central database and allows access to all remote servers. As a result, if we have a RADIUS server then we can monitor activity that who has access to our system.
- RADIUS Packet Structure:
The RADIUS Packet data format is shown below:
Starting with the code, the identifier, the length, the authenticator, and the attributes, the fields are transmitted from left to right.
BACKGROUND OF RADIUS
Computer networking was becoming more common than it had ever been in the late 1980s. Merit networks won a contract to begin work on the NSFNET project. But one of the conditions set by the National Science Foundation for NSFNET was that no proprietary dial-in servers can be used; they had to be commercial. So, Merit sent an RFI and Livingston Enterprises contacted them after 6months in 1991.
Livingston’s proposal basically represented the 1st RADIUS–like servers with remote authentication capabilities. Lucent purchased Livingston Enterprises, and along with Merit, they worked to gain market recognition for RADIUS as a protocol. Radius server was offered at no charge. It was first implemented in the state of Michigan to dial-in and remotely authenticating to access MichNet and NSFNET network. As well as, demand increased of RADIUS. It was described in RFC 2058 and RFC 2059 with respect to the authentication aspect and accounting aspect of RADIUS in 1997 in January and after that in April, RFC 2138 and RFC 2139 w.r.t. authentication and accounting. Current versions of it are RFC 2865 and RFC 2866.
RADIUS SERVICES
Authentication, authorization, and accounting, or AAA, are three network services provided by RADIUS.
· Identify remote users and manage who has access to the network (authentication)
· Monitor access to network resources (authorization) to define what each user can do.
· Track what resources each user consumes in order to charge them for services (accounting).
- AUTHENTICATION:
The process by which the network validates a dial-in user’s identity — separating a legitimate user from a malicious or mischievous hacker. Authentication is simply a login protocol involving a username and password: the process by which the network validates a dial-in user’s identity — distinguishing a legitimate user from a malicious or mischievous hacker. Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP) (RFC 1994) are two of the authentication protocols supported by RADIUS, as well as Unix login. The Point-to-Point Protocol (PPP) authentication procedures define PAP and CHAP (RFC 1661). RADIUS encrypts user passwords for transmission between client and server to avoid detection by network snoopers.
Requests from known clients are handled by a RADIUS Authentication Server, while requests from unknown clients are ignored. The NAS must first verify its own identity by authenticating with the RADIUS server using a common shared secret before authenticating any users. The mutual secret is a text string that is configured on both the RADIUS client and server, but it is never transmitted through the network in its entirety. During authentication, the RADIUS server sends a random number to the NAS, which is then combined with the shared secret and sent back to the RADIUS server using a hash-code algorithm (RSA Message Digest Algorithm MD5).
The RADIUS server will decode the received message and compare it to its own copy of the shared secret for verification. Users that fail to authenticate with the RADIUS server will be disconnected by the NAS.
- TWO FACTOR AUTHENTICATION
Remote access protection is further enhanced by two-factor authentication. Two-factor authentication relies on two factors: something you own and something you know. The user is expected to submit a time-dependent password while using two-factor authentication. This is often an answer to a server request (the server issues a challenge).challenge, and the client generates a hashed answer (via the token). Occasionally, the user will have a token with a code that varies on a regular basis, and this code will be in accordance with a code on the device the webserver With their ACE Server, Security Dynamics is a major player in this area.
- AUTHORIZATION:
The process of restricting and allowing what each user may do is known as authorization. When a user successfully authenticates, RADIUS servers determine which services and privileges the user has access to (for example, PPP, SLIP, Telnet, and login), and return that information to the communications server.
- ACCOUNTING:
The method of gathering and publishing data is known as accounting. The RADIUS Accounting server receives and stores statistics submitted by RADIUS clients, as well as responding to statistics requests from clients. The RADIUS protocol’s accounting functionality can be used without RADIUS authentication or authorization. The RADIUS accounting functions allow data to be sent at the start and end of sessions, showing how much time, packets, bytes, and other resources were used during the session. These data can be used for billing, traffic which performance analysis, and troubleshooting etc.
HOW IT WORKS
- RADIUS is divided into three parts as shown below:
- Client/Supplicant: The computer and user attempting to connect to a network.
- NAS stands for Network Access Server, and it is used to link a user to a network.
RADIUS Server: A server that verifies whether or not a user is authorised to access the network and what permissions they have. Accounting features such as billing, time monitoring, and device/connection information can all be provided by the server.
1. The user attempts to log in using either a browser-based HTTPS link to the computer over port 4100 or a Mobile VPN with an IPSec connection. The user name and password are read by the computer.
2. The computer generates an Access-Request response, which it sends to the RADIUS server. In the message, the computer uses the RADIUS mutual secret. In the Access-Request message, the password is always encrypted.
3. The RADIUS server verifies that the Access-Request message originates from a trusted recipient (the Firebox). If the RADIUS server is not configured to acknowledge the device as a client, the Access-Request message is ignored and no response is sent.
4. The server looks at the authentication method requested in the Access-Request message whether the device is a known client to the RADIUS server and the shared secret is right.
5. If an allowed authentication method is used in the Access-Request document, the RADIUS server extracts the user credentials from the message and searches a user database for a match. If the user name and password match an entry in the database, the RADIUS server can access the user database for more details (such as remote access approval, group membership, logon hours, and so on).
6. The RADIUS server looks through its configuration to see if it has an access policy or profile that fits all of the information it has about the user. The server sends an answer if such a policy exists.
7. If any of the above conditions are not met, or if the RADIUS server does not have a policy that matches, an Access-Reject message is sent, indicating that authentication has failed. The user is refused access after the RADIUS transaction is completed.
8. RADIUS sends an Access-Accept message to the device if the Access-Request message meets all of the previous criteria.
9. The mutual secret is used by the RADIUS server in any answer it sends. The system rejects the RADIUS answer if the shared secret does not fit.
10. To view authentication diagnostic log messages, click here. Adjust the log level for the Authentication group and set the Diagnostic Log Level. Any FilterID attribute in the message is read by the system. To place the user in a RADIUS category, it connects the user name with the FilterID attribute.
11. In the Access-Accept message, the RADIUS server may provide a lot of extra details. The system ignores the majority of this data, including the protocols that the user is permitted to use (such as PPP or SLIP), the ports that the user is permitted to access, idle timeouts, and other attributes.
12. Only the FilterID attribute is required by the device (RADIUS attribute number 11). The FilterID is a text string that the RADIUS server is configured to include in the Access-Accept message. This attribute is required for the system to assign the user to a RADIUS category, but it can also be used to help other Radius attributes including Session-Timeout (RADIUS attribute number 27) and Idle-Timeout (RADIUS attribute number 28).
- Access Reject
The user is refused access to all requested network services without exception. Failure to provide evidence of identity or an unknown or inactive user account may be the cause.
- Access Challenge
Asks the user for more details, such as a secondary password, PIN, token, or wallet. In more complicated authentication dialogues, Access-Challenge is used to create a secure tunnel between the user machine and the Radius Server, hiding the access credentials from the NAS.
- Access Accept
Access is given to the individual. The RADIUS server will often verify that the user is allowed to use the network service requested after they have been authenticated. For example, a user can be permitted to use a company’s wireless network but not its VPN service. This information may either be stored locally on the RADIUS server or retrieved from an external source like LDAP or Active Directory.
- Time OUT and Retry Values
When the primary RADIUS server does not respond, an authentication failure occurs. After three failed authentication attempts, Fireware OS switches to the backup RADIUS server. This is referred to as failover. The number of authentication attempts and the number of retries is not the same. The number of authentication attempts needed before failover cannot be changed.
The first RADIUS server on the list receives an Access-Request response from the Firebox. If the system receives no answer, it waits for the number of seconds specified in the Timeout text box before sending another Access-Request. This is repeated as many times as the Retry text box indicates (or until there is a valid response). Fireware OS counts this as one failed authentication attempt if the RADIUS server does not react or if the RADIUS shared secret does not match.
After three failed authentication attempts, Fireware OS switches to the secondary RADIUS server for the next attempt. After three failed authentication attempts on the secondary server, Fireware OS waits for the Dead Time period (10 minutes by default) to expire. Fireware OS attempts to use the primary RADIUS server again after the Dead Time period has passed. The default Dead Time value in Fireware v12.5.3 and earlier is 3 minutes. The default Dead Time value in Fireware v12.1.1 and earlier is 10 minutes.
Check out the next blog for RADIUS configuration.