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@xxxxx> 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.
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
