Weird situation proxying accounting packets

Michael Lecuyer mjl at theorem.com
Thu Jul 28 19:21:40 CEST 2005


The reason is that the shared secret is wrong.

RADIUS accounting packets are signed by the client and the signature is 
checked by the server. The authenticator is generated by the client from 
the packet contents and forms this signature. The server checks this 
signature.

Authentication packets are not signed so no problem is detected by the 
server. The client checks for the response packet signature. The 
authenticator is a random number generated by the client. The packet is 
not signed, but the response packet is signed for the client to check.

Why is this so?

Authentication packets are trusted by the server. It's the client that 
must determine if the packet is signed correctly before it accepts 
authentication. The client doesn't trust the server.

The server trusts accounting packets because they are correctly signed.

Loris Fadda wrote:
> Hello guys,
> 
> We use freeradius on a Debian 3.1 system, I've created an hybrid distro using packets from the testing tree to use the FR release 1.0.4 (deb revision 2). This box needs to proxy both auth and acct requests to a customer server that runs Cisco ACS 2.6. The NAS is Cisco AS5300. 
> 
> Proxyied authentication requests are satisfyed correctly, while accounting requests are sent back with a "shared secret is incorrect" from the customer radius server.
> 
> Now, why if the secret is verified correctly on authentication I get this error on the accounting requests.
> Have you ever seen something like this?
> 
> Notice that we checked out the secrets 10000 times and they match perfectly, also, in my proxy.conf as well as in the clients.conf(the equivalent on FR ... I donno what the hell ACS uses) of the customer the shared secret is defined just once, I mean the same directive "secret" is used both for auth and acct . 
> 
> Is there any library or dictionary issue I've missed to check?
> 
> Thanks for your attention any help will be really appreciated.
> 
> Loris 
> 
> 
> ------------------------------------------------------------------------
> 
> - 
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html




More information about the Freeradius-Users mailing list