Two-Factor Auth using FreeRADIUS

[Alan DeKok]

Ryon Day wrote:
> Hello all, long-time reader, first time poster to this list. I've watched many posters go down in flames on this list, so I'm going to try to learn from their mistakes and be as precise as possible; I'm also going to make it known at the outset that I have read all the documentation that I can get my hands on and I am running FreeRADIUS -X to start it in debug mode!

  It's easy to avoid "flames".  Be honest, be clear, and follow
instructions.

> The authentication mechanism that we are using for the second-factor authentication is a one-time password sent to the user via an out-of-band mechanism. Therefore, this requires two different interactions with the RADIUS server: 
> 
> 1: Access-Request: SSL-VPN -> FreeRADIUS. This sends the username (and another piece of data that I am currently putting in the password field) to the RADIUS server.
>   *At this point, I have written a JRadius component:
>     * On the SSL-VPN side I have PAP authentication selected. That is because as above, I am using the password field to transfer another piece of data (the delivery method) to RADIUS.
>     * It resides in the "authorize" stage of the "default" site in FreeRADIUS
>     * It looks the user up in LDAP (again) to obtain his/her E-Mail address to send. It then sends the OTP to the e-mail address. This part works perfectly!
>     * Then, I construct a new Access-Challenge packet in JRadius, creating a new State and copying the initial Access-Request packet's identifier, and return from the JRadius handler. This part also works perfectly.

  You can't create an Access-Challenge packet in jradius.  You can only
create a reply.  If the user isn't accepted, the reply is automatically
a reject.

> 2: Access-Challenge: FreeRADIUS -> SSL-VPN device
> This step is where the wheels are falling off the bus. FreeRADIUS does not seem to want to send out my Access-Challenge packet; it automatically changes it to an Access-Reject. I have even put another handler in the post-auth reject handler to change it BACK to a Access-Challenge. At that point if I do that, FreeRADIUS' debug mode reports that it is sending an Access-Request packet to the IP address of the NAS (or my RADIUS test program)! 

  You need to set the "request->reply->code = PW_ACCESS_CHALLENGE" for
challenges to work.  See rlm_example.

  It's just not set up to do manually created challenges.  The reason is
that 99.9999% of people get it wrong, and it's not necessary.

> 3: Access-Request (original Using state and Packet ID so I can identify the request on the back-end JRadius component)
>   * Compare passed OTP to stored OTP for that "session". Act accordingly.
>   * Obviously this step does not yet work!

  Does the SSL-VPN even support Access-Challenge?  Some don't.

> This leads me to believe that FreeRADIUS has a very rigid idea of what these packets should be depending on auth method. Is there really no use case at all for PAP where you would ever send an access challenge?  Are there any "dummy" auth methods that just, well, let me do whatever the hell I want? Is it possible to implement a new Auth method like this?

  There are many cases where you can send an Access-Challenge.
HOWEVER... most of them are mandated by the authentication method.  EAP,
MS-CHAP, etc.

> Questions:
> * Is there any way with current functionality, I can Implement a custom challenge flow like the one I am describing? 

  Yes.  See rlm_example.

  You *can't* do it via unlang.

> * Are there examples of this kind of functionality out there "in the wild" that I can look at and use as a model? 
> * I greatly enjoy working with JRadius in spite of its occasional wonkiness, but I can dust off my C if necessary. Is some sort of JRadius handler combined with C FreeRADIUS mods possible? I do not mind writing code if it is necessary, but of course I'd prefer not to if it's at all avoidable! (Is this a question better posed to the dev list?)

  See rlm_example.

  Alan DeKok.