On Sep 11, 2019, at 4:11 PM, <[hidden email]> <[hidden email]> wrote:
I have the challenge parameter set, but the user never seems to get prompted to enter their OTP password. Not sure if I have it set correctly.
It's pretty simple to configure.
The issue is likely that the supplicant is unable (or unwilling) to show prompts when using EAP-GTC. You can't change the supplicant, so you're stuck with however it behaves.
According to our security team, PAP uses a simple xor between the paasowrd and the hashed value of the shared secret.
If your security people want to educate themselves as to how it *actually* works, they can read RFC 2865 Section 5.2. It documents the process in detail.
They're close, but not correct.
According to them, this would make it easy to decrypt the user passwords in intercepted packets.
Your security people are stupid.
No one has published an attack on the password encryption mechanism in RADIUS. If they had, it would be international news. Every ISP on the planet would be upgrading in a panic. Every switch / AP manufacturer would be upgrading in a panic.
Since you haven't seen that, your security people are wrong.
This isn't rocket science. Either all of the RADIUS and IETF security people are wrong (and your security people are smarter than everyone else combined), OR the RADIUS and IETF security people are right, and your security people are wrong.
I've done this for ~25 years. They haven't. Amateurs shouldn't have opinions about security.
Regardless if this is true or not, I don't think I will be able to get them to approve us using PAP. This means I'm stuck using on of the other types.
Which don't work for other reasons.
Your security people are *preventing* you from using good security (OTP), because of ignorance about RADIUS security.
I am trying to follow the documentation, but I couldn't find any examples of how to do two factor authentication other then through PAP.
Because PAP is pretty much all that works. EAP-GTC works *sometimes*. But not always.
I found a few other posts that other users made who were having similar problems, but I
didn't see any replies where they were able to get it working or how they
did it. I have read through the documentation contained in the various config files and am doing my best to try an follow it, but I am having issues understanding how to do the two-factor authentication through GTC.
If EAP-GTC works, then the user is prompted with the challenge, and
enters their password.
BUT that requires the supplicant to follow the EAP-GTC spec. They often
don't. And, you can't change the supplicant implementation.
I'm not sure what I am missing that is preventing the users from getting prompted for the second factor.
Nothing. The supplicant doesn't support it.
The reason I think the issue is caused by something I misconfigured, and not a supplicant issue, is because the supplicant seems to be getting an access accept from RADIUIS which is why it is letting the user in instead of prompting them for the OTP. When I look at the debug it seems like it is setting the OTP Challenge Message first (as configed is eap config), then pressing the original request through ntlm_auth, and if ntlm_auth succeeds it sends a access accept back to the supplicant. Unless I am misunderstanding something, shouldn't the radius not send an access accept back to the supplicant unless all the auth conditions are met? The part I seem to be missing is where do I configure the radius server to require a second factor? In PAP I set this by returning an Access-Challenge in the authenticate section. Since this doesn't work the same way in PEAP-GTC, I seem to be missing some part of the config that tells it to request the second factor. Am I just misunderstanding how this works?