Rapid Prototyping Without Any Networking Equipment Part 2.

Rapid Prototyping RADIUS Server Policies Part 2

 

This is part 2 of my blog series on rapid prototyping without any real networking equipment. In part 1 I covered PAP and CHAP authentication.

Let's get more creative and look at testing some EAP methods. The most common method found in enterprises is probably EAP-PEAP with MS-CHAPv2 inner authentication. Typical real-world use case examples include Windows/OSX/Android supplicants where the credentials are typically looked up in Active Directory or LDAP.

There is a great test utility from the wpa_supplicant suite (a suite of tools to test EAP methods, and simulate a supplicant and/or wireless access points).  You can do amazing things with wpa_supplicant when combined with a real wireless access point.  But what if you just want to simulate the EAP authentication without all the nuts and bolts of a wireless infrastructure?  Let's face it, our AAA server ultimately processes Radius packets which are the result of the interactions of the supplicant and NAD (authenticator).  Keep reading to find out how to mimic a real EAP conversation to a Radius server.

 

EAP Framework in wpa_supplicant

As mentioned in the introduction, the wpa_supplicant package contains the tools we need, and this suite is available in most Linux distributions - in the Redhat/CentOS distribution it can be installed with yum

yum install wpa_supplicant

In this blog we’re only interested in the utility called eapol_test contained in the package.

 

EAP-PEAP Example Using eapol_test

There is a command line component as well as a configuration file. The configuration file (let's call it mschap.conf) should contain the following text - edit it appropriately - however the only thing you should need to edit are the identity (MSCHAP username) and the password, which are the credentials stored in your AAA or AD. The ca_cert is a nice to have and it will be used during the TLS setup to validate the Radius Server certificate.

network={
        ssid="example"
        key_mgmt=WPA-EAP
        eap=PEAP
        identity="bob"
        anonymous_identity="anonymous"
        password="AbCd123"
        phase2="autheap=MSCHAPV2"
        # Line below performs server certificate validation.
        # It is optional - just comment it out if you have no certificate
        ca_cert="/home/someuser/Downloads/MegaRootCert.cer"
}

Now you can execute a PEAP authentication as follows

eapol_test -c mschap.conf -s RadiusS3cret -a 192.168.21.101 -M '00:00:00:00:00:10' -N '6:d:2'

 

The Radius server in my example is Cisco ISE but it could be any Radius product that supports EAP.  In my example the Radius server listens on 192.168.21.101

We shall pretend to be a Wi-Fi client with MAC address (Calling-Station-Id) of 00:00:00:00:00:10

The -N '6:d:2' is a handy argument to add additional Radius attributes to the request. The effect of the argment is to send a Service-Type=Framed attribute (see RFC2865 section 5.6). The value 6 is the radius attribute value that specifies 'Service-Type', and 2 is the decimal constant that defines 'Framed'.

The output of the command is quite verbose and mostly not needed. We generally look out for the last few lines of the command’s output, to reveal a success or failure.

MPPE keys OK: 1  mismatch: 0
SUCCESS

 

Conclusion

The ISE server and the eapol_test utility enter into the usual EAP exchange and the result is true to the real world. You can test your Radius server’s EAP policy logic without ever having to touch a real networking device! This is a real productivity boost. But be aware that there is no substitute for the real experience since the real devices may not always do the right thing.

©IPTel Solutions .