Two-Factor Auth using FreeRADIUS

[Ryon Day]

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!

I am attempting to implement two-factor authentication with LDAP combined with FreeRADIUS. As you probably know at this point, many SSL-VPN and network control devices only offer both LDAP/AD and RADIUS authentication for their devices (some have native SecurID support as well). The client is authenticating users with Active Directory as the first-level auth. It is on the second-level auth that I have questions.

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.

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)! 


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!

I have tried many permutations of Auth-Methods. Since I am using PAP authentication on the SSL-VPN side, I initially chose that module, however it really does not like my sending that Access-Challenge packet out. I have tried commenting lots of things out, even using jradius in the 'PAP' handler of the authentication section. At that point, even though the PAP module is not running, FreeRADIUS puts the kibosh on my Access-Challenge packet.

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?

Questions:
* Is there any way with current functionality, I can Implement a custom challenge flow like the one I am describing? 
* 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?)


Thank you for any help or guidance you can give me in this matter!