[RADIATOR] Can AuthBy FAILUREPOLICY used together with EAP?

[Ralf Wenk]

Hello,

thank you for your fast answer.

On 2020-02-20 at 15:29 +0200 Heikki Vatiainen wrote:
> On 18.2.2020 15.57, Ralf Wenk wrote:
> 
> [...]
> > Do I miss/misunderstand something or can FAILUREPOLICY not used in EAP
> > authentication (yet)?
> 
> I think the main reason is that it knows nothing about EAP. Using it 
> with EAP-MSCHAP-V2 will also create an additional problem: with this 
> method the server can not just tell the client that the request was 
> accepted. It also has to prove that it knows the correct password (v2 
> part in the method). To be more specific: it's reponse needs to be 
> derived from the same password the client is attempting to use.

Now I do understand what the underlying problem is.
Even if I manage to call FAILUREPOLICY in some EAP context, the
same (here: wrong) password the client is attempting to use will
never be known to the server.

Meanwhile I stumbled over the 2nd Tip to AuthBy INTERNAL on page 237
and played with it till there was some (un)successful authentication.

% DEBUG: Radius::AuthFILE ACCEPT: Fixed by AuthResult: 'DEFAULT'
  [u at test-karlsruhe.de]
% WARNING: Empty password for u at test-karlsruhe.de from user database
  in check_mschapv2, rejecting
% DEBUG: EAP Failure, elapsed time 0.094198

> Currently the failurepolicy authby just acts if the reason is bad 
> password and does not understand about EAP. Our plan is to make it more 
> EAP aware. However, trying to accept a failed authentication can be 
> problematic with protocols such as (EAP-)MSCHAP-V2. With EAP-TTLS/PAP, 
> for example, this would be easier.

I will keep that in mind.

> Thanks for letting us know how you'd like to use this AuthBy. While 
> MSCHAPv2 is problematic, it's useful to know what other requirements 
> there are apart from simple username/password authentication.

As my current idea of "send EAP users with typos in authentication data
into a captive network to inform them and silence their clients" will
not work, I have to rethink the whole approach.

Regards, Ralf