This has been explained before in this list and it's how RADIUS works. The Even though the secret is incorrect the authentication can be correct. The server returns an Access-Accept. Why? The server trusts the client (it's in the accepted NAS list) and performs the authentication. The server then signs the response packet with it's version of the secret. The client doesn't trust the server and checks the signature. If the signature is not correct the client rejects the packet. The opposite is true with accounting packets - the client signs the request and the server checks the signature. The Message-Authenticator attribute can be used to sign the Access-Request packet which will cause the server to reject a packet with the an incorrect MA signature. David Goodenough wrote:
I just hit a really odd problem with a secrets.
We were asked to use FreeRadius to provide IP addresses to an Ericsonn NAS. We set up the server and have some test clients with simple secrets. If those are right it works, if they are wrong it fails.
Then we put in the secret for the Ericsonn (I can not put it in this note as it is someone else's secret and I do not know what else it might be the secret for, but privately I could make it available for testing).
This secret is 13 digits long, mixed numbers and letters, looks reasonably random, and in the proper secret all the letters were upper case. However somehow one of the letters (an O) got put into the server in lower case.
The server happily accepts Access-Request packets with an authenticator built from the all upper case secret, even though its secret was different, it was only the client which rejected the Access-Accept. Diagnosing this however was very difficult as we had no access to the Ericsonn box and any console messages it might log (we could only see what went on the wire and whether the connection succeeded).
A quick look at the code did not find anywhere where the secret gets folded to all upper case (but I might have missed it) and if there were such folding it would be unfortunate if this was only done on checking the received packet not on generating the reply.
I am new to RADIUS, and I could not find any rules about case folding for secrets, but I might have missed them.
It could simply be one of those freak places where the MD5 checksum happens to be the same for the request but not the response, but that does not feel right.
I am using 1.1.1 (I am also using JRadius which last time I looked only produced patches for 1.1.1, not 1.1.2).
David - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html