On Sep 23, 2016, at 1:15 PM, Richard Perrin <rcp@sentientmeat.ca> wrote:

Any pointers on how to do the unlang challenge-response?

You need to manage the State attribute, and the challenge-response.

I've build and run 3.0.11, and have successful authentication happening with the following minimalistic config file in sites-enabled:

server port18121 { listen { ipaddr = * port = 18121 type = auth } authorize { update control { Cleartext-Password := "radiuspass" } pap } authenticate { pap } }

Not sure what's simplest to replace pap with in order to generate the challenges.

You need to do EVERYTHING to manage the challenge yourself. You need to understand how challenge-response works in RADIUS. authorize { if (!State) { update reply { Reply-Message := "this is the challenge" } update control { Cleartext-Password := "response" } challenge } else { if (&User-Password != &session-state:Cleartext-Password) { reject } accept } } Of course, this presumes that the NAS understands challenge-response. Which it might not. To be honest, there's pretty much no reason to invent your own challenge-response mechanism. Using an existing one is much preferred. Alan DeKok.

On Sep 23, 2016, at 3:40 PM, Richard Perrin <rcp@sentientmeat.ca> wrote:

When I add in a State value, that config successfully gets a challenge and response from the pam module on Linux (libpam-radius-auth-1.3.17). Surprisingly, it didn't prompt there though. Largely this highlights, much like you said, that I don't sufficiently understand how challenge-response works in RADIUS.

Then I suggest you shouldn't try to implement your own challenge-response.

Which of the existing methods would you select for least friction in configuring?

You can't just pick something and implement it. You need *reasons* to implement challenge-response. If you don't have reasons, you don't need it. Alan DeKok.

On Sep 24, 2016, at 9:43 AM, Richard Perrin <rcp@sentientmeat.ca> wrote:

My reason is that I'm integrating the pam-radius-auth client into a product and need to verify the full client functionality. I need to create a lasting test-bed that simulates a target deployment that would be using Challenge/Response authentication.

If you're just doing Unix logins, pam-radius-auth has done RADIUS challenge-response correctly since 1998... when I wrote it.

I'm seeking a simple as possible config for freeradius server (now version 3.0.11) that would allow me to exercise the Challenge/Response path in the pam client (packaged on Ubuntu 14.04 as libpam-radius-auth-1.3.17).

The simplest thing is to re-use an existing challenge-response system. i.e. something your clients will use.

An additional detail is that I'm using the radius pam module for the login and ssh services.

Then the pam-radius-auth module should work. It's worked since 1998.

I looked at the rlm_otp module, but found the otpd codebase is dormant. rlm_eap may be where I end up, but the breadth of options there seems like I'll spend a lot of time figuring out the configuration.

rlm_otp might work. rlm_eap won't. EAP is an authentication method entirely different from normal password challenge-response. You can't just pick random things and expect them to work. You have to *understand* what the protocols are doing.

rlm_yubikey, rlm_securid, and rlm_smsotp require devices or infrastructure I don't currently have, but could obtain if warranted.

TBH, Yubikey systems are cheap. Get one, and test it. It will work.

Of the other modules that grep for CHALLENGE, rlm_preprocess, rlm_example, rlm_replicate don't seem suitable. So rlm_cram, rlm_mschap, rlm_chap or rlm_eap seem like the best candidates. EAP has documentation, which the others lack.

Trying random things is entirely the wrong approach.

Is there one that seems like the winner for ease of configuration for Challenge/Response?

Yubikey. If you don't understand how MS-CHAP and EAP are different from normal challenge-response, you will have a VERY bad time trying to implement your own challenge-response mechanism. Alan DeKok.