RFC compliance in sanitizing Access-Reject responses

[Mike]

All,

  First, thank you for an excellent server.  Within a few hours we
went from google-ing for a radius server to having a proxy up which
does (almost) everything we needed to make a third party device/server
learn many cool new tricks.

  Unfortunately last night I had to spend 3 hours (maybe "only" 3
hours, attesting to high code quality) in trying to figure out why
Access-Reject messages were loosing all but the Reply-Message
attribute.  Eventually I did find, first a hint on the mailing lists,
then the RFC, and then finally after quite a bit of digging, the code
in util.c :

  case PW_AUTHENTICATION_REJECT:
    pairmove2(&vps, &(packet->vps), PW_EAP_MESSAGE);
    pairmove2(&vps, &(packet->vps), PW_MESSAGE_AUTHENTICATOR);
    pairmove2(&vps, &(packet->vps), PW_REPLY_MESSAGE);
    break;

  I would like to suggest at least two small changes to make
freeradius an even better tool than it already is.  The first is
really simple and would take practically no work at all: can we please
have a log message here that notifies the user of this operation when
running with -X?  This would have saved me most of the time I've spent
digging through mailing lists and the rlm_attr_filter code, and
allowed me to quickly find the above culprit.  This is actually quite
necessary, since any "detail" logs that can be inserted on the proxy
reply path happily show all attributes - the attributes magically
disappear right before packet is sent.

  The second request is also trivial to implement: make the above code
configurable/optional.  Yes, there is a great deal of strength and
respect in supporting the RFC to the dot - and without a doubt, that
should be the default out-of-the-box configuration.  But not all
devices are  created equal - and in my case, as I'm sure in some
others, useful information is passed in the Access-Reject message in
attributes other than Reply-Message.  Obviously this is not compliant
- but all the devices I have are quite happy accepting those "extra"
arguments, and a third party server is certainly very happy to send
them.  Making this code "optional" with a config file switch saves me
from hacking the sources.  Code change can be achieved simply by
moving up case PW_AUTHENTICATION_REJECT: above the default: case and
wrapping the 4 line body (including break;) inside of an if statement,
so this change is also quite triviail.

  The third "request" or "option" perhaps, is a bit more complex.  I
would propose that the above code is actually a hack to comply with
RFC, and that the appropriate mechanism of accomplishing this effect
is through an appropriate set of attribute filters (enabled by
default).  This would require extending the attr_filters module to
consider the request/response type being filtered.  The default
configuration can point out the RFC in the comments and filter out
everything with the three exceptions.  This of course allows for
maximal flexibility, while still respecting the standard in the
default configuration.  I think this one is quite a bit more work, so
I do not put too many hopes into it, but I figured I would throw it
out on the table.

  Again, thanks for a great server.  The above "hickup" is hardly
worth mentioning when compared to the overall experience we've had in
setting up the proxy and getting it to do what we want.