Access RADIUS Attributes via ctrl interface?

[Michael Baird]

Hi,

I have implemented a solution that allows admins to select what RADIUS 
attributes (only Access-Accept) should be stored. Lookup is done via the 
attribute and if it is a Vendor-Specific attribute an optional 
Vendor-Id, Vendor type, and syntax (for printing) can be given.

If only Vendor-Specific attribute is specified then all matching 
attributes will be saved.

On receiving a RADIUS Packet the previous Access-Accept Attributes are 
removed, regardless of the type of RADIUS packet.

All stored RADIUS attributes are added to the string produced by 
"ieee802_1x_get_mib_sta", using the 'syntax' if specified in the 
configuration, otherwise a hexdump.


If you would like me to submit a patch I will do so.

One thing I'm not sure on is where to free the memory on the struct 
sta_info.


Thanks,
Michael


On 26/09/17 07:30, Michael Baird wrote:
> Thank you Jouni & Alan, at this stage just the Access-Accept.
>
> At the moment I have added a configuration option (runtime) to specify 
> which fields (from Access-Accept) should be stored. The code will be 
> compile time.
>
>
> Couple of implementation questions.
> Would the struct 'sta_info' (ap/sta_info.h) be the correct place for 
> storing this data?
>
> And returning via ctrl interface with "ieee802_1x_get_mib_sta" 
> (ap/ieee802_1x.c), or a different command?
>
>
> Thanks,
> Michael.
>
> On 26/09/17 06:53, Alan DeKok wrote:
>> On Sep 25, 2017, at 1:45 PM, Jouni Malinen <j at w1.fi> wrote:
>>> I guess it would be reasonable to add option to save such information
>>> for the duration of an association. That said, this can use quite a bit
>>> of memory, so it probably make sense to make this configurable 
>>> behaviour.
>>    My $0.02 here would be just to cache the raw attributes from the 
>> Access-Accept.
>>
>> * skip the RADIUS header (20 bytes)
>> * skip the various MPPE keys (~40 bytes each)
>> * skip EAP-Message (4 bytes for Success)
>> * skip Message-Authenticator (18 bytes)
>>
>>    The rest of the data will be small, typically ~100 bytes or so.  
>> If the RADIUS server is sending lots of filter rules (i.e. 4K), well, 
>> tell the administrator to stop doing that.
>>
>>    If you care, max out the cache at 256 bytes, rounded down to the 
>> nearest attribute.  Discard everything after that.  That should cover 
>> 99.999% of the sane cases.
>>
>>> Are you thinking of mainly (only?) information from Access-Accept or
>>> would there be need to store attributes from Access-Challenge as well?
>>    Access-Challenge packets contain only authentication information, 
>> Proxy-State, and State.  PLEASE don't cache them.
>>
>>    I've seen people do all kinds of crazy things with 
>> Access-Challenge.   The less they're allowed to do that, the better.
>>
>>    Alan DeKok.
>>
>>
>