BlastRADIUS

[Bjørn Mork]

Alan DeKok <aland at 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