Alan DeKok <aland@deployingradius.com> writes:
But it's still good practice to add Message-Authenticator to *all* Access-Accept / Reject / Challenge.
Yes. Or that's what I thought as well until yesterday. Unsurprisingly, many router vendors are still trying to implement the BlastRADIUS recommendations in their RADIUS clients. With "interesting" effects as a result. I got a complaint yesterday that vendor A now requires M-A in the Accept-Accept, or the session is rejected. I guess that's good. We were running 3.2.2 on the servers in question. An upgrade was obviously long overdue in any case, so I upgraded to 3.2.6. And everything was fine. For several minutes. Then it turned out that vendor C also must have been working on their BlastRADIUS implementation. Unfortunately, it seems that they only got as far as to make the authentication process crash if the Access-Accept includes M-A. Nice work! How are we supposed to handle real world vendors like that? It would be nice to have some fine grained M-A enable/disable knobs. E.g. by client or account (virtual internal attribute?). By client will not work well for proxied requests, so that's probably not sufficient. Will of course also work with the vendor, but that takes time. And we have a number of routers to upgrade before it's done. Testing is a bit of a hassle when we have to switch FR versions to enable/disable M-A (unless we cheat with a proxy filter). Bjørn