FreeRADIUS: Working with Authentication Methods

Exclusive offer: get 50% off this eBook here
FreeRADIUS Beginner's Guide

FreeRADIUS Beginner's Guide — Save 50%

Manage your network resources with FreeRADIUS.

£16.99    £8.50
by Dirk van der Walt | September 2011 | Beginner's Guides Networking & Telephony Open Source

Authentication is a process where we establish if someone is who he or she claims to be. The most common way is by a unique username and password. This article by Dirk van der Walt, author of FreeRADIUS Beginner's Guide, teaches authentication methods and how they work. Extensible Authentication Protocol (EAP) is covered later in a dedicated article.

In this article we shall:

  • Discuss PAP, CHAP, and MS-CHAP authentication protocols
  • See when and how authentication is done in FreeRADIUS
  • Explore ways to store passwords
  • Look at other authentication methods

 

(For more resources on this subject, see here.)

Authentication protocols

This section will give you background on three common authentication protocols. These protocols involve the supply of a username and password.

The radtest program uses the Password Authentication Protocol (PAP) by default when testing authentication. PAP is not the only authentication protocol but probably the most generic and widely used. Authentication protocols you should know about are PAP, CHAP, and MS-CHAP. Each of these protocols involves a username and password. The next article on Extensible Authentication Protocol (EAP) protocol will introduce us to more authentication protocols.

An authentication protocol is typically used on the data link layer that connects the client with the NAS. The network layer will only be established after the authentication is successful. The NAS acts as a broker to forward the requests from the user to the RADIUS server.

The data link layer and network layer are layers inside the Open Systems Interconnect model (OSI model). The discussion of this model is almost guaranteed to be found in any book on networking:
http://en.wikipedia.org/wiki/OSI_model

PAP

PAP was one of the first protocols used to facilitate the supply of a username and password when making point-to-point connections. With PAP the NAS takes the PAP ID and password and sends them in an Access-Request packet as the User-Name and User-Password. PAP is simpler compared to CHAP and MS-CHAP because the NAS simply hands the RADIUS server a username and password, which are then checked. This username and password come directly from the user through the NAS to the server in a single action.

Although PAP transmits passwords in clear text, using it should not always be frowned upon. This password is only in clear text between the user and the NAS. The user's password will be encrypted when the NAS forwards the request to the RADIUS server.

If PAP is used inside a secure tunnel it is as secure as the tunnel. This is similar to when your credit card details are tunnelled inside an HTTPS connection and delivered to a secure web server.

HTTPS stands for Hypertext Transfer Protocol Secure and is a web standard that uses Secure Socket Layer/Transport Layer Security (SSL/TLS) to create a secure channel over an insecure network. Once this secure channel is established, we can transfer sensitive data, like credit card details, through it. HTTPS is used daily to secure many millions of transactions over the Internet.

See the following schematic of a typical captive portal configuration.

FreeRADIUS Beginner's Guide

The following table shows the RADIUS AVPs involved in a PAP request:

FreeRADIUS Beginner's Guide

As you can see the value of User-Password is encrypted between the NAS and the RADIUS server. Transporting the user's password from the user to the NAS may be a security risk if it can be captured by a third party.

CHAP

CHAP stands for Challenge-Handshake Authentication Protocol and was designed as an improvement to PAP. It prevents you from transmitting a cleartext password.

CHAP was created in the days when dial-up modems were popular and the concern about PAP's cleartext passwords was high.

After a link is established to the NAS, the NAS generates a random challenge and sends it to the user. The user then responds to this challenge by returning a one-way hash calculated on an identifier (sent along with the challenge), the challenge, and the user's password. The user's response is then used by the NAS to create an Access-Request packet, which is sent to the RADIUS server. Depending on the reply from the RADIUS server, the NAS will return CHAP Success or CHAP Failure to the user.

The NAS can also request at random intervals that the authentication process be repeated by sending a new challenge to the user. This is another reason why it is considered more secure than PAP.

One major drawback of CHAP is that although the password is transmitted encrypted, the password source has to be in clear text for FreeRADIUS to perform password verification.

The FreeRADIUS FAQ discuss the dangers of transmitting a cleartext password compared to storing all the passwords in clear text on the server.

The following table shows the RADIUS AVPs involved in a CHAP request:

FreeRADIUS Beginner's Guide

MS-CHAP

MS-CHAP is a challenge-handshake authentication protocol created by Microsoft. There are two versions, MS-CHAP version 1 and MS-CHAP version 2.

The challenge sent by the NAS is identical in format to the standard CHAP challenge packet. This includes an identifier and arbitrary challenge. The response from the user is also identical in format to the standard CHAP response packet. The only difference is the format of the Value field. The Value field is sub-formatted to contain MS-CHAP-specific fields. One of the fields (NT-Response) contains the username and password in a very specific encrypted format. The reply from the user will be used by the NAS to create an Access-Request packet, which is sent to the RADIUS server. Depending on the reply from the RADIUS server, the NAS will return Success Packet or Failure Packet to the user.

The RADIUS server is not involved with the sending out of the challenge. If you sniff the RADIUS traffic between an NAS and a RADIUS server you can confirm that there is only an Access-Request followed by an Access-Accept or Access-Reject. The sending out of a challenge to the user and receiving a response from her or him is between the NAS and the user.

MS-CHAP also has some enhancements that are not part of CHAP, like the user's ability to change his or her password or inclusion of more descriptive error messages.

The protocol is tightly integrated with the LAN Manager and NT Password hashes. FreeRADIUS will convert a user's cleartext password to an LM-Password and an NT-Password in order to determine if the password hash that came out of the MS-CHAP request is correct. Although there are known weaknesses with MS-CHAP, it remains widely used and very popular.

Never say never. If your current requirement for the RADIUS deployment does not include the use of MS-CHAP, rather cater for the possibility that one day you may use it. The most popular EAP protocol makes use of MS-CHAP. EAP is crucial in Wi-Fi authentication.

Because MS-CHAP is vendor specific, VSAs instead of AVPs are part of the Access-Request between the NAS and RADIUS server. This is used together with the User-Name AVP.

FreeRADIUS Beginner's Guide

Now that we know more about the authentication protocols, let's see how FreeRADIUS handles them.

FreeRADIUS Beginner's Guide Manage your network resources with FreeRADIUS.
Published: September 2011
eBook Price: £16.99
Book Price: £27.99
See more
Select your format and quantity:

 

(For more resources on this subject, see here.)

FreeRADIUS—authorize before authenticate

It's time to see how FreeRADIUS handles incoming Access-Request packets.

Time for action – authenticating a user with FreeRADIUS

We continue with our exercise from the previous article on Getting Started with FreeRADIUS where we authenticate a user defined in the users file. Instead of looking at the feedback of the radtest command, we will now look at the output of the FreeRADIUS server running in debug mode.

  1. Ensure you are root in order to edit the users file.
  2. Define Alice as a FreeRADIUS test user. Add the following lines at the top of the users file. Make sure the second line is indented by a single tab character.

    "alice" Cleartext-Password := "passme"
    Reply-Message = "Hello, %{User-Name}"

  3. Start the FreeRADIUS server in debug mode. Ensure there is not already an instance running by shutting it down through the start-up script. We assume Ubuntu in this instance.

    $> sudo su

    #> /etc/init.d/freeradius stop

    #> freeradius -X

  4. Authenticate Alice using the following command:

    $> radtest alice passme 127.0.0.1 100 testing123

  5. The debug output of FreeRADIUS will show how the Access-Request packet arrives and how the FreeRADIUS server responds to this request.

What just happened?

You have sent an Access-Request packet to FreeRADIUS. You have received an Access-Accept packet back. Nothing exciting really, but it is quite interesting to observe the debug output of FreeRADIUS. This shows what is involved to return an Access-Accept packet.

If you want to make use of the terminal where FreeRADIUS runs in debug mode, while keeping it alive you can use Ctrl+Z to suspend the current job (radiusd -X) then execute the bg command to run it in the background. The terminal should now be available to you. To run FreeRADIUS again in the foreground simply execute the fg command.

Let's explore the debug output.

Access-Request arrives

When the packet arrives at the FreeRADIUS server it is indicated by the following part:

rad_recv: Access-Request packet from host 127.0.0.1 port 48698,
id=73, length=57
User-Name = "alice"
User-Password = "passme"
NAS-IP-Address = 127.0.1.1
NAS-Port = 100

We see that the incoming request contains four AVPs.

Although the AVP User-Password is shown here in clear text, it was not transmitted to the server in clear text. FreeRADIUS uses the shared secret to encrypt and decrypt the value of the User-Password AVP.

Authorization

After the request is received, the authorize section takes care of the request:

# Executing section authorize from file /etc/freeradius/sites-enabled/
default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[ suffix] No '@' in User-Name = "alice", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry alice at line 137
[files] expand: Hello, %{User-Name} -> Hello, alice
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
Found Auth-Type = PAP

The authorize section is defined inside a virtual server. Let's first look at some points about virtual servers in FreeRADIUS:

  • Virtual servers are defined under the sites-available directory, which resides under the configuration directory of FreeRADIUS.
  • Each virtual server is represented by a single text file.
  • Virtual servers are activated by creating a soft link from the file in the sites-available directory to a file in the sites-enabled directory with the same name.
  • This method is similar to that used by the Apache web server.
  • The virtual server named default handles all the typical requests.
  • Virtual servers are basically like having several RADIUS servers. One virtual server can even forward a request to another virtual server. This makes a FreeRADIUS installation extremely versatile and powerful.
  • Each virtual server, including default, has various sections. A virtual server can contain the following sections nested inside the virtual server definition: listen, client, authorize, authenticate, post-auth, pre-proxy, post-proxy, preacct, accounting, and session.
  • The Access-Request is first handled by the authorize section.

Authorize set Auth-Type

When the request is handled by the authorize section, various FreeRADIUS modules look at the AVPs contained in the Access-Request. These modules try to determine the mechanism and module to be used for authenticating the user. In our example authorize sets the Auth-Type to PAP.

If the Access-Request contained MS-CHAP attributes instead of the User-Password for instance, the mschap module would have detected this and set Auth-Type = MS-CHAP.

Authorization in action

The authorize section may decide to reject a request outright based on a decision on the presence or the value of a specified AVP. This will result in an Access-Reject packet returned to the client. There would then be no need for authentication.

Authentication

After the value of Auth-Type is set, the request is passed to the authenticate section:

# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group PAP {...}
[pap] login attempt with password "passme"
[pap] Using clear text password "passme"
[pap] User authenticated successfully
++[pap] returns ok

Here we see that the pap subsection in the authenticate section is taking care of this request and returns ok.

Post-Auth

The post-auth section is done after authentication. You may use it to execute something:

# Executing section post-auth from file /etc/freeradius/sites-
enabled/default
+- entering group post-auth {...}
++[exec] returns noop

Finish

The result is now sent back to the client:

Sending Access-Accept of id 73 to 127.0.0.1 port 48698
Reply-Message = "Hello, alice"
Finished request 3.

Conclusion

Remember the following points when looking at the debug output:

  • Main sections like authorize, authenticate, and post-auth start with a # Executing.
  • These sections also indicate in which virtual server they reside.
  • The authorize section sets the value of Auth-Type. This in turns determines which module inside the authenticate section will be used.
  • The debug output of FreeRADIUS modules can be divided in two types. They are debug messages and return values.
  • Debug messages are preceded by the module name, for example

    [files] users: Matched entry alice at line 137.

  • Return values are preceded by ++[module_name] for example ++[files] returns ok.

Have a go hero – using other authentication protocols

Since version 2.1.10 of FreeRADIUS the radtest client program allows you to specify an authentication protocol to use.

If your FreeRADIUS installation is newer than 2.1.10 you can use the -t option to specify chap and mschap and do the authenticate request again. Note how the debug feedback from FreeRADIUS is now different when using the other authentication protocols.

The next article will look at different formats in which we can store a user's password.

Summary

This article looked at authentication in FreeRADIUS. Specifically, we have covered:

  • Authentication protocols: There are three popular authentication protocols, namely, PAP, CHAP, and MS-CHAP. PAP is the least secure in certain situations but also the most versatile.
  • How FreeRADIUS handles Access-Requests: When an Access-Request reaches the FreeRADIUS server the authorize section defined in the virtual server determines which authentication method will be used. The value of Auth-Type indicates which authentication section will be used.

Further resources on this subject:


FreeRADIUS Beginner's Guide Manage your network resources with FreeRADIUS.
Published: September 2011
eBook Price: £16.99
Book Price: £27.99
See more
Select your format and quantity:

About the Author :


Dirk van der Walt

Dirk van der Walt is an Open Source Software Specialist from Pretoria, South Africa. He is a firm believer in the potential of Open Source software. Being a Linux user for almost 10 years it was love at first boot. From then on Dirk has spent his available time sharing his knowledge with others equally passionate about the freedom and affordability Open Source software gives to the community.

In 2003 Dirk started coding with Perl as his language of choice and gave his full attention to functional and aesthetic user interface design. He also compiled an on-line Gtk2-Perl study guide to promote the advancement of Perl on the desktop.

As Rich Internet Applications (RIA) became more popular, Dirk added the Dojo toolkit and CakePHP to his skills-set to create an AJAX-style front-end to a FreeRADIUS MySQL database. His latest work is YFi Hotspot Manager. Today YFi Hotspot Manager is used in many localities around the globe. With many contributors to the project it proves just how well the Open Source software model can work.

Books From Packt


Understanding TCP/IP
Understanding TCP/IP

Cacti 0.8 Beginner's Guide
Cacti 0.8 Beginner's Guide

OpenVPN 2 Cookbook
OpenVPN 2 Cookbook

FreeSWITCH 1.0.6
FreeSWITCH 1.0.6

Building Telephony Systems with OpenSER
Building Telephony Systems with OpenSER

Tcl 8.5 Network Programming
Tcl 8.5 Network Programming

Rhomobile Beginner's Guide
Rhomobile Beginner's Guide

Zabbix 1.8 Network Monitoring
Zabbix 1.8 Network Monitoring


Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software