[PATCHv3 3/3] radius: report taxonomy assoc/probe IEs
aland at deployingradius.com
Thu Aug 19 13:52:27 PDT 2021
On Aug 19, 2021, at 4:10 PM, Jouni Malinen <j at w1.fi> wrote:
> That should be clearly mentioned in the commit message to make this
> clear. The FreeRADIUS dictionary example is fine to include, but it is
> really confusing without there being first a clear indication that this
> patch defines those new vendor attributes and reserves the specified
> values for this purpose and only after that, giving an example on how
> this could be used on the RADIUS server side.
My preference would be to also include the files with FreeRADIUS. If every vendor did that, they wouldn't need to have documentation saying "please edit the dictionaries".
> As far as unconditional inclusion of these new attributes in RADIUS
> messages is concerned, I'm a bit concerned about potential
> interoperability issues with old deployed RADIUS servers. Maybe it would
> be safer to do this only based on a new explicit hostapd configuration
I would agree.
> Or is there clear data available to believe that the RFC 6929
> design has no issues without deployed servers?
I suspect a large number of legacy RADIUS servers don't support the RFC 6929 attributes. Worse, the numbers were used "illegally" by many vendors, so legacy RADIUS servers may in fact try to interpret the extended VSAs as some older format.
I also don't see why the RFC 6929 extended format is being used. If there's no existing "hostap" RADIUS dictionary, just use the normal Vendor-Specific space. That way the attributes will work with all possible RADIUS servers.
More information about the Hostap