FW: How to send a challenge request via PEAP-GTC

[ngoetz24 at gmail.com]

>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?