Antw: Re: EAP-PWD with wrong password

[Anja Ruckdaeschel]

Dear Stefan,
thank you for your answer.

"When their talk ends nowhere all that can be said is that the two
parties disagree about what the password is.
"
I understand that it is like that by design:

EAP-PWD RFC says in 2.8.5.3 EAP-pwd-Confirm-Exchange: "If the value of
Confim_S i incorrect, the peer MUST terminate the exchange"
... I think this could be the point where it happens (I'm not too deep into
EAP-PWD).
I understand, that the freeradius-module is written like in the RFC defined.


RADIUS RFC says: If any value of the received Attributes is not acceptable,
then the RADIUS Server MUST transmit a packet with the Code field set to 3
(Access-Reject).
I think, that does not match here, because it is not the server who does not
accept the packet ,but:

"Upon receipt of an Access-Request from a valid client, an appropriate reply
MUST be transmitted."
So, the question is for me: Is this a "valid" client or not? MUST there be a
reply?


Wouldn't it be an idea, the EAP-PWD peer sends back an explizit "I disagree
with you, let us stop talking" (some kind of NAK)? Just asking :-)

Ciao Anja









>>> Stefan Winter <stefan.winter at restena.lu> 11.09.2018 13:51 >>>
Hello,

> Is there a way to determine that a user tried to log in with a "wrong
password" with eap-pwd?
> Setup is as recommended by comments in config with an inner-tunnel.
> 
> EAP-PWD against edir with a correct password works fine and it produces a
log line on Access-Accept in the radius-Logfile.
> 
> But EAP-PWD with the user using a wrong password, does nothing.
> In debug it just looks like an unfinished eap-request with eap returning
handled instead of ok for the last packet.
> 
> Problem is, that we cannot see  "normal" entry in radius.log  and trigger
some other actions on a reject.

Two guys who know nothing about each other talk about a password they
hold close to their chest, not showing to the other side.

When their talk about the passwords shows that they actually have the
same password in front of them then both are happy, knowing that the
respective other side is genuine.

When their talk ends nowhere all that can be said is that the two
parties disagree about what the password is.

There is then no "wrong" and "right" password. They are just different.
And so, both ends walk away.

I.e. the user cannot know if his password is wrong, or if he is maybe
connected to a rogue server which doesn't actually know the password and
is trying to impersonate the server (failing miserably).

The server, which at some point sends the Commit message based on what
it thinks is the password, never gets a reply because the other end went
away. But it can't know whether the other end went away because the
password talk went sideways, or if the other end simply closed the
laptop's lid and never received and acted upon the message.

So, what should the server log? It can't be sure it was about a bad
password. All it knows is that it sent something but noone replied.

Should it maybe log that, instead of just doing nothing? How long should
it wait before doing so?

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66