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