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*

> 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,

  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