On Fri, Sep 23, 2016 at 8:46 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Sep 23, 2016, at 3:40 PM, Richard Perrin <rcp@sentientmeat.ca> wrote: [...]
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.
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. I'm familiar with configuring and implementing PAM modules, but this is the first time I haven't had a pre-deployed RADIUS server to test against. So, I'm setting freeradius server up and configuring it for the first time. Thus, I'll re-iterate my original request: 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). An additional detail is that I'm using the radius pam module for the login and ssh services. 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_yubikey, rlm_securid, and rlm_smsotp require devices or infrastructure I don't currently have, but could obtain if warranted. 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. Is there one that seems like the winner for ease of configuration for Challenge/Response? - Richard