"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@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