Re: [PATCH] libradius: Always Include Authenticator

From: Brian Candler <B.Candler_at_pobox.com>
Date: Wed, 6 Jul 2005 11:08:29 +0100
On Tue, Jul 05, 2005 at 12:32:58PM -0700, Paul Querna wrote:
> The attached patch will always include the Authenticator Field, in all 
> RADIUS packets, not just accounting packets.  This is a SHOULD violation 
> from the RFC.

I don't understand this. If you're talking about RFC 2865, which bit exactly
are you referring to?

As far as I can see, the function insert_request_authenticator() generates
the authenticator by hashing all the attributes within the request plus the
shared secret. This is the correct behaviour for accounting requests (only).
Your patch wrongly applies this to Access-Request as well.

In Access-Request packets, the Request Authenticator should be a *random*
number (RFC2865 section 3, page 15), and this is already done by
rad_create_request()

So, can you describe more precisely how and why you think the current
behaviour is wrong?

> I found this problem fixing a bug for my mod_auth_xradius[1].  It 
> appears that some commercial RADIUS authentication servers will reject 
> packets with identical Authenticator fields as duplicates.

But these RADIUS servers, even if they detect a duplicate, are required to
send the same response as they did to the original request.

Is the packet actually a duplicate, or is it a different authentication
request? If it's different, then it should have a different random
authenticator. Are you saying that the random number generator is giving the
same answer each time? If so then it's a seeding problem. I see that
srandomdev() is called in rad_auth_open though.

> This also 
> has some security implications, since without unique Authenticator field 
> values, it could allow the spoofing of a reply message.

I'm still confused. Are you talking about Access-Request or Access-Accept
now? The Response Authenticator of Access-Accept is defined in the RFC.

Regards,

Brian.
Received on Wed Jul 06 2005 - 08:08:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:38 UTC