Antw: Re: EAP-PWD with wrong password
Anja Ruckdaeschel
Anja.Ruckdaeschel at rz.uni-regensburg.de
Thu Sep 13 10:36:17 CEST 2018
"Unfortunately, nothing like that is foreseen in the RFC. And if such a
message doesn't even exist, then it is asked a bit much from a client to
send it :-)
"
That's true, but of course this was an enhancement request :-)
Maybe the RFC can be expanded?
It's still a new one and I think, a lot of people would be happy about that
and would happily deploy EAP-PWD in their eduroam environments ... ;-)
It's never too late....
Ciao Anja
>>> Stefan Winter <stefan.winter at restena.lu> 11.09.2018 14:20 >>>
Hi,
> "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.
Yes, I believe it was even written by the RFC author himself :-)
> 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
Exactly: the server *does* send something back. Its last message is the
Confirm.
> ,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?
There is nothing to reply to because there is no Access-Request. The
client receives a Confirm, and walks away.
The server just sits there waiting for an incoming Access-Request which
never comes.
> 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 :-)
Yes. In that case, it would be up to the client to send such a message
to the server, because it evaluated the Confirm and it didn't compare
well to its own expectation.
Unfortunately, nothing like that is foreseen in the RFC. And if such a
message doesn't even exist, then it is asked a bit much from a client to
send it :-)
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
More information about the Freeradius-Users
mailing list