EAP-PWD with wrong password
Hi there, 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. Thank you very much Kind regards Anja
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
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@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
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
"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
hi, Maybe the RFC can be expanded?
good luck with that . ;-)
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....
whilst the number of clients that support it is low...that didn't stop us - what did was the backend requirements and a move to EAP-TLS anyway - along with our deployment tools not supporting EAP-PWD for auto-configuration of correct settings on the clients that COULD do EAP-PWD (measured on one fish hand....) [as for EAP-FASTv2 ...... do any of the standard makers even consider how to bootstrap the requiring support ecosystem do these things actually get used in large scales and enterprise environments???] alan
I thought about a lot getting "at least something" logged in radius.log, when as user TRIES/STARTS to do a Request with EAP-PWD..... I came up with this and perhaps someone can use this as some kind of base idea for logging .... The idea behind this is: Find the stage in the whole EAP-PWD-thing where the server sends his last packet (Challenge) and is waiting for the client who never answers. Log this. So, if there is noch Second Log Line with Auth:OK you can see at least "User X tried/begun to use EAP-PWD" First you need a policy to "identify" the "stage": logpwdtry { if (&request:EAP-Type && &request:EAP-Type == "PWD") { if (&EAP-Message) { if (&EAP-Message =~ /^0{1}x{1}[a-f0-9]{10}0{1}([123]{1})[a-f0-9]{1,}$/ ) { #We are in the PWD-Exch-Commit if ("%{1}" == "2") { linelogpwd } } } } } Call the policy in default in Auth-Type eap: Auth-Type eap { eap { handled = 1 } logpwdtry } Have a linelog instance "linelogpwd" like that: linelog linelogpwd { filename = ${logdir}/radius.log escape_filenames = no permissions = 0600 format = "This is a log message for %{User-Name}" reference = "messages.%{%{reply:Packet-Type}:-default}" messages { default = "Unknown packet type %{Packet-Type}" Access-Accept = "Accepted user: %{User-Name}" Access-Reject = "Rejected user: %{User-Name}" #THIS IS THE LOG-MESSAGE- Perhaps something like this: Access-Challenge = "%t : Auth: (%n) Login TRY: [%{User-Name}] (from client %{Client-Shortname} port %{NAS-Port} cli %{Calling-Station-Id}) EAP-Type:%{EAP-Type} / Sent challenge to client ... Waiting ..." } } Suggestions for improvement are welcomed :-) Ciao Anja
Alan Buxey <alan.buxey@gmail.com> 13.09.2018 13:37 >>> hi,
Maybe the RFC can be expanded?
good luck with that . ;-)
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....
whilst the number of clients that support it is low...that didn't stop us - what did was the backend requirements and a move to EAP-TLS anyway - along with our deployment tools not supporting EAP-PWD for auto-configuration of correct settings on the clients that COULD do EAP-PWD (measured on one fish hand....) [as for EAP-FASTv2 ...... do any of the standard makers even consider how to bootstrap the requiring support ecosystem do these things actually get used in large scales and enterprise environments???] alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan Buxey -
Anja Ruckdaeschel -
Stefan Winter