Antw: Re: EAP-PWD with wrong password

[Anja Ruckdaeschel]

"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