Hi all. Somehow I'm new in freeradius. and beacuse I live in Iran I can't access this mail archive from web easy.(They are censored whole mail archive and I don't know why!!) So I ask this here and sorry if its a duplicate message :) using mikrotik RuterOS and any thing is OK, the problem is Dissconnect. I use this script to disconnect a user : #!/bin/bash radwho -r -i -U $1 > /tmp/tmp-users-$1.txt LOGIN=`cat /tmp/tmp-users-$1.txt |cut -d, -f1` SECTIONID=`cat /tmp/tmp-users-$1.txt |cut -d, -f2` NASADDR=`cat /tmp/tmp-users-$1.txt |cut -d, -f6` rm /tmp/tmp-users-$1.txt echo "Acct-Session-Id="$SECTIONID > /tmp/packet-$LOGIN.txt echo "User-Name="$LOGIN >> /tmp/packet-$LOGIN.txt cat /tmp/packet-$LOGIN.txt | radclient -x -r 1 $NASADDR:1700 disconnect testing1234 rm /tmp/packet-$LOGIN.txt work fine, Mikrotik dissconnect user with successs BUT i get this : Sending Disconnect-Request of id 107 to 192.168.0.6 port 1700 Acct-Session-Id = "81400001" User-Name = "testuser" rad_recv: Disconnect-ACK packet from host 192.168.0.6 port 1700, id=107, length=36 rad_verify: Received Disconnect-ACK packet from client 192.168.0.6 port 1700 with invalid signature (err=2)! (Shared secret is incorrect.) radclient: no response from server for ID 107 socket 3 and then its try again (so I use -r 1 to prevent try again, just once).Some said it woirks with 1.x (at mikrotik forum where I get this script) What happend to FreeRadius Client 2.X and I got this error? need to check the result since its critical for my usage and I should retry on fail but how can find this was a success or not??? Sorry if my English is very BAD :(
f0rud wrote:
work fine, Mikrotik dissconnect user with successs BUT i get this :
Sending Disconnect-Request of id 107 to 192.168.0.6 port 1700 Acct-Session-Id = "81400001" User-Name = "testuser" rad_recv: Disconnect-ACK packet from host 192.168.0.6 port 1700, id=107, length=36 rad_verify: Received Disconnect-ACK packet from client 192.168.0.6 port 1700 with invalid signature (err=2)! (Shared secret is incorrect.) radclient: no response from server for ID 107 socket 3
So... fix the shared secret. Nothing else will solve the problem.
Sorry if my English is very BAD :(
Better than my Farsi. Alan DeKok.
I had the same problem with FR 2.x and the shared secret is correct. FR 1.x works fine, clients.conf is correct, .... I didn't had much time to deal with this problem so I didn't want to bother you on this list. .. Alan DeKok wrote:
f0rud wrote:
work fine, Mikrotik dissconnect user with successs BUT i get this :
Sending Disconnect-Request of id 107 to 192.168.0.6 port 1700 Acct-Session-Id = "81400001" User-Name = "testuser" rad_recv: Disconnect-ACK packet from host 192.168.0.6 port 1700, id=107, length=36 rad_verify: Received Disconnect-ACK packet from client 192.168.0.6 port 1700 with invalid signature (err=2)! (Shared secret is incorrect.) radclient: no response from server for ID 107 socket 3
So... fix the shared secret. Nothing else will solve the problem.
Sorry if my English is very BAD :(
Better than my Farsi.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Wed, 2010-06-09 at 13:53 +0200, Alan DeKok wrote:
So... fix the shared secret. Nothing else will solve the problem.
It is "fixed" The Mikrotik report that OK and Disconnect the user and log the entry as a success. 20:25:11 pppoe,ppp,info <pppoe-f0rud>: terminating... - administrator request 20:25:11 pppoe,ppp,info <pppoe-f0rud>: disconnected And in Request log (Incoming radius dialog in winbox), I have : Requests : 1 Bad Requests : 0 Acks : 1 Naks : 0 So Mikrotik accept this (and then I can say shared secret is OK), but radclient report this as failed. how its possible? in this case server is NAS and accept the request , why client return it as failed?
f0rud <fzerorubigd@gmail.com> writes:
So Mikrotik accept this (and then I can say shared secret is OK),
Sure? Did you try deliberately using a wrong secret to verify that the NAS validates the request?
but radclient report this as failed. how its possible? in this case server is NAS and accept the request , why client return it as failed?
Because the Ack can't be validated. Either because the NAS sends an invalid Ack or because radclient does something wrong when verifying it. Given the amount of testing each of those probably have had when it comes to CoA, I would suspect the NAS... Bjørn
Hello, I use LDAP groups for EAP-PEAP Authentication in wifi WPA context. For now, I used a DEFAULT line in "users" file like this : DEFAULT ldap_1x-Ldap-Group != "radius" , Auth-Type := Reject Reply-Message = "ACCES REFUSE" I have a LDAP Group named "radius" but I don't know howto permit another one LDAP Group Somebody could help me ? G.VALET
On Wed, 2010-06-09 at 15:16 +0200, Bjørn Mork wrote:
f0rud <fzerorubigd@gmail.com> writes:
So Mikrotik accept this (and then I can say shared secret is OK),
Sure? Did you try deliberately using a wrong secret to verify that the NAS validates the request?
Yes, with wrong secret , NAS add my request to bad request(I check this at Winbox/Radius/Incoming ) and the result is : Sending Disconnect-Request of id 179 to 192.168.0.6 port 1700 Acct-Session-Id = "81500000" User-Name = "f0rud" radclient: no response from server for ID 179 socket 3 if the secret is wrong there is no answer at all.
but radclient report this as failed. how its possible? in this case server is NAS and accept the request , why client return it as failed?
Because the Ack can't be validated. Either because the NAS sends an invalid Ack or because radclient does something wrong when verifying it. Given the amount of testing each of those probably have had when it comes to CoA, I would suspect the NAS...
There is 4 Number : Requests : All requests (with correct secret) Bad Requests : Requests with wrong secret Acks : Accepted request Naks : Rejected request in this case, Acks means the request that the router accept and disconnect user.
Hi all I found the "calc_replydigest" function in radius.c always return 2 (digest_cmp failed) Since this function is new in code , then its the problem and the diff. with version 1.x For fixing my problem, I just by pass this test for PW_DISCONNECT_ACK (not a good idea I know but what else I can do?) and now its fine for my problem. I see the code for another messages (for ex: PW_AUTHENTICATION_REQUEST) you just ignore the code, so why this one(PW_DISCONNECT_ACK) "must" be checked? if some one want to do "timing attack" then can use this message(PW_AUTHENTICATION_REQUEST) so by checking just some message its not "safe".
f0rud wrote:
I found the "calc_replydigest" function in radius.c always return 2 (digest_cmp failed) Since this function is new in code , then its the problem and the diff. with version 1.x
The "digest_cmp" is failing because the packet is wrong. Try the old code from an earlier version of radius.c. It will *also* fail to authenticate the packet.
For fixing my problem, I just by pass this test for PW_DISCONNECT_ACK (not a good idea I know but what else I can do?) and now its fine for my problem.
Or, you could ask the NAS vendor to implement RADIUS properly.
I see the code for another messages (for ex: PW_AUTHENTICATION_REQUEST) you just ignore the code,
Uh... no. It does not do that.
so why this one(PW_DISCONNECT_ACK) "must" be checked? if some one want to do "timing attack" then can use this message(PW_AUTHENTICATION_REQUEST) so by checking just some message its not "safe".
That is not true. Alan DeKok.
On Thu, 2010-06-10 at 14:12 +0200, Alan DeKok wrote:
f0rud wrote:
I found the "calc_replydigest" function in radius.c always return 2 (digest_cmp failed) Since this function is new in code , then its the problem and the diff. with version 1.x
The "digest_cmp" is failing because the packet is wrong.
Try the old code from an earlier version of radius.c. It will *also* fail to authenticate the packet.
Thats the problem, version 1.1.8 have no problem!(This time I check this myself. with the code from download page.)
For fixing my problem, I just by pass this test for PW_DISCONNECT_ACK (not a good idea I know but what else I can do?) and now its fine for my problem.
Or, you could ask the NAS vendor to implement RADIUS properly.
In Mikrotik forum they said to ask your team (not to me they said this is radclient problem.) thats I love : infinite loop :))
I see the code for another messages (for ex: PW_AUTHENTICATION_REQUEST) you just ignore the code,
Uh... no. It does not do that.
So check this at radius.c about line 2110 /* * Calculate and/or verify digest. */ switch(packet->code) { int rcode=0; char buffer[32]; case PW_AUTHENTICATION_REQUEST: case PW_STATUS_SERVER: /* * The authentication vector is random * nonsense, invented by the client. */ break; and after this break, the function return 0 that means OK , so where the code take care of this messages digest?
so why this one(PW_DISCONNECT_ACK) "must" be checked? if some one want to do "timing attack" then can use this message(PW_AUTHENTICATION_REQUEST) so by checking just some message its not "safe".
That is not true.
This timing attack (I read the comment on the code) so bypassing this function (rad_verify) means some one can do this attack, and If yo don't believe me, check the code, any PW_AUTHENTICATION_REQUEST package will pass this function. so what difference, and why this pass exist at all when there is some exception?
f0rud wrote:
Thats the problem, version 1.1.8 have no problem!(This time I check this myself. with the code from download page.)
OK... you haven't said which version of FreeRADIUS you're using. Let me guess: it's not 2.1.9.
I see the code for another messages (for ex: PW_AUTHENTICATION_REQUEST) you just ignore the code, Uh... no. It does not do that.
So check this at radius.c about line 2110
<sigh> Please read the text you post to the list.
case PW_AUTHENTICATION_REQUEST: case PW_STATUS_SERVER: /* * The authentication vector is random * nonsense, invented by the client. */
What do you think that means?
and after this break, the function return 0 that means OK , so where the code take care of this messages digest?
It doesn't. It's not *supposed* to. Read the RFCs.
This timing attack (I read the comment on the code) so bypassing this function (rad_verify) means some one can do this attack,
Nonsense. The timing attack is being able to tell the difference between comparing 8, or 16 bytes for equality. "Bypassing the function" means it always compares *zero* bytes for equality. How do you do a timing attack by telling the difference between comparing zero, or zero bytes for equality? The answer is: you don't.
and If yo don't believe me, check the code, any PW_AUTHENTICATION_REQUEST package will pass this function. so what difference, and why this pass exist at all when there is some exception?
I suggest reading the code *and* the RFCs before leaping to conclusions. Alan DeKok.
On Thu, 2010-06-10 at 16:39 +0200, Alan DeKok wrote:
f0rud wrote:
Thats the problem, version 1.1.8 have no problem!(This time I check this myself. with the code from download page.)
OK... you haven't said which version of FreeRADIUS you're using. Let me guess: it's not 2.1.9.
No its exactly 2.1.9 from GIT(last update 1 or 2 days ago after you fix some problem.) and I'm happy with ignoring the check. so leave it be. And after that, in this case radius should be client and NAS is server. so there is no harm at all. (as long as the NAS do its job and disconnect user, its ok) thanks.
participants (5)
-
Alan DeKok -
Bjørn Mork -
f0rud -
Génaël VALET -
Marinko Tarlac