RFC compliance in sanitizing Access-Reject responses
Alan DeKok
aland at deployingradius.com
Sat Sep 2 02:17:29 CEST 2006
Nicolas Baradakis <nbk at sitadelle.com> wrote:
> 1. Allowing VSA in the reply packets is really a bug: if you have an
> existing username with a wrong password, the VSA useful to set up a
> connection were pulled from the database during autorize and are send
> in the reject packet.
That's more of a bug that the return attributes are set up before
the user is fully authentication. They should be configured *after*
authentication.
> 2. Making the option user-defined may bring more confusion. Too many
> options make the server more difficult to configure. Moreover the
> administrator may not figure out easily that turning this option
> on will hit the bug in (1).
I don't have a problem with using the attr_filter module.
> 3. Moving the function to a module is a bit dangerous. The modules
> are optional, and I don't want the server to do something crazy
> when removing one of the modules.
I agree But doing something dumb is different than doing something
crazy. Sending attributes in an Access-Reject won't affect 99.9% of
the clients, so there's no problem.
Making the validation of Message-Authenticator optional is, however,
not going to happen. Ever.
> 4. I like software that figure out themselves what to do ;-)
> Apparently the users complaining about the problem are using FreeRADIUS
> as a proxy for RFC-ignorant third party servers. That's why I think
> we could relax the filter on proxy replies *only*.
attr_filter should be able to do that.
> The rationale is when FreeRADIUS is acting as a home server, it's hard
> to configure it to intentionally reply VSA in access-reject, therefore
> the current behaviour should be fine. When FreeRADIUS is acting as
> proxy, we are not really responsible if the incoming packets are not
> RFC-compliant. Then perhaps it makes sense to allow the VSA in the
> latter case.
Sure. But some NASes (rhymes with "bisco") need attributes in the
Access-Reject, even locally.
I'm not set on changing it, but I'm not set on the existing method,
either.
Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
More information about the Freeradius-Devel
mailing list