EAP module changes
From FreeRADIUS Wiki
This page lists some changes to the EAP module that I'd like to do/see done to the EAP module:
- Fully break out EAP-TLS code into libeaptls
- This will allow modules that rely on EAP-TLS to each have their own SSL_CTX
- The libeaptls code can look for the same option names in each module's config, allowing for modules to have different CA certificates, etc.
- Allow multiple instances of each EAP type module to be configured
- Allows for "EAP virtual hosting"
- Modules will be called by their name2 just like other modules
- Users can be made to use a certain list of modules (called by name2) by the presence of an Allowed-EAP-Types attribute in the config_items. This way, usera can be made to use peap_module_a while userb can be made to use peap_module_b, allowing for systems who may have different CA certs, etc.
- This way, only one EAP module needs to be configured, but users can be made to use a different set of EAP options/types within the EAP module.
- Implement "EAP Autz Wrapping"
- The EAP module would call an autz block (configured in the EAP module configuration from within its code to perform authorization lookups
- Allows the EAP module to perform both pre and post authorization functions, ie:
- Add missing User-Name attribute before calling the autz block
- By caching the request and output from the autz block, EAP processing can be optimized.
- Allows us to call the autz block only once if non-EAP-related attributes don't change (Since all attributes should be present in the first request, only one autz call after the first request should be required in most cases)
- Furthermore, this allows us to only have to make a single call to any external (LDAP, SQL, etc) databases instead of one per round trip in an EAP conversation, removing unnecessary calls and speeding up EAP authentications
- Finally, Autz caching will also allow us to much more easily implement EAP Notifications based on Reply-Message attributes present in the Autz output
- Alternative to "EAP Autz Wrapping"
- Update the EAP handlers so that they set a flag when they expect that the *next* EAP packet from the client will require the username && password.
- This matters most for the TLS types.
- Looking at debug logs from various machines, the server finishes the TLS tunnel setup in one packet, and the next packet contains the data in the tunnel.
- The TLS modules can have a flag "tunnel not done", and the EAP module can return "ok" (not currently used by eap autz) in the authorize section.
- Then, configurable failover can do eap {ok = return} in authorize.
- The modules needing to do DB lookups, etc. can be listed *after* the EAP module, which means that they won't be called until the TLS tunnel is set up