Home / server / Questions / 591676
In Process
Sirex
Asked: 2014-04-28 18:12:51 +0800 CST

freeradius two factor without factor concatenation

  • 772

I have a cisco router providing an SSL VPN server which is talking to freeradius, which in turn uses pam and two pam modules (sss & yubico) to provide two factor authentication for the VPN.

All is good in the world and it does work, except that for this to work i need to concatenate the user's password and the yubikey token together into one response. My users would prefer a two stage password and challenge response (mostly for reasons of 'its too confusing'). Can this be done ?

At the moment i've got one radius authentication config section which specifies to use the pam radius module as backend. I'm very new to radius but i think i could use the pam module twice in two separate "phases" and give a differing pam_auth each time, so that two different pam config files are used, with each backed onto a single pam module (IPA on one, yubikey on the other) ? I'd be relying on pam twice because freeradius supports neither yubikey nor sss out the box (i know it supports ldap but i want sss to gain dns SRV record failover etc).

I'm not sure if this is even possible, and i've not had any luck finding somewhere that it's documented ?

freeradius obviously has a lot of config files, but if any are crucial to know i can post them up.

authentication

2 Answers

  1. After having tried to get a yubikey setup to do this for some time (though not with OpenVPN) I came to the conclusion that if this is to work, it has to be supported both by the application and by PAM. That is, the application has to know to ask for three things (instead of the usual two) and the underlying PAM library has to know to expect three things to be passed to it (and to use them appropriately).

    The yubikey PAM library doesn't seem to have that support, or at least it didn't have it reliably while I was still trying to make this work.

    Instead, I decided to change to using my yubikey in OATH mode, and I found that proper three-phase authentication was handled much better by both sshd and the underlying pam_oath library.

    I can't say whether OpenVPN support this better, as I haven't tried it, but you may wish to investigate it as an option if you can't get yubikey mode working properly. It has the added advantage that if any of your users can't use a yubikey for some reason (eg, OpenVPN from an endpoint with no USB port) there are a number of other OATH implementations which can be used e.g. on a smartphone to bail those particular users out without having to completely overhaul your two-factor infrastructure.

    In case it's of any interest to you, my writeup on sshd/yubikey/OATH/two-factor/three-phase authentication can be found here.

    Edit: no, by application I meant OpenVPN. OpenVPN must know to ask for (effectively) two separate passwords and a username, and the backing PAM module must know to expect those three tokens, and to combine them in a way that is agreeable to FreeRADIUS. It's almost immaterial what that agreed-on method is, as long as the tokens are validated; what's important is that the client-facing side of the whole authentication engine knows how to ask for, and how to deal with, the three different tokens.

    Trying to roll your own by suborning PAM into calling the RADIUS plugin twice, with different arguments each time, and hoping that it will somehow magically come out in the wash, seems doomed to failure to me (as well as fraught with potential security holes).

    My bigger-picture point was that you were more likely to find a designed-in solution using OATH than the yubikey-specific token handlers, since I know from what I tried that the yubikey-specific handlers didn't seem to like three-token approaches, preferring the catenate-password-and-OTP approach (which I also don't like).

    • 1

  2. RADIUS offers challenge response. That is you could first provide the password to the radius server, the RADIUS server would check the password and if the password is right not repond with an Access-Accept but with an Access-Challenge. THe Radius client (pam_module) would then ask for the second authentication and the OTP value could be sent to the RADIUS server. If the second part (OTP value) was right the RADIUS server finally would answer with ACCESS-Accept.

    privacyIDEA offers challenge response for several OTP tokens (HOTP, Yubikey) and a FreeRADIUS module that support challenge response.

    Looking at the freeradius code it looks like pam_radius_auth also support challenge response, but I have not tested it yet.

    • 1