Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
How to include the Trust Router functionality in v4.0 #2019
See here for debugging instructions and how to obtain backtraces.
NOTE: PATCHES GO IN PULL REQUESTS. IF YOU SUBMIT A DIFF HERE, THE DEVELOPMENT TEAM WILL HUNT YOU DOWN AND BEAT YOU OVER THE HEAD WITH YOUR OWN KEYBOARD.
This thread is intended to discuss how the existing Trust Router client functionality can be implemented in v4.0, where rlm_realm module is gone.
Initial ideas/thoughts can be found in #2007:
Introduction (in a really small nutshell)
The trust router is a service that allows establishing shared secrets between AAA entities based on the shared trust they have in an entity called the "trust router server". In practice (ie. Moonshot), it is used to dynamically negotiate TLS-PSKs between FreeRadius endpoints that had no knowledge of each other prior that negotiation.
In FR v4.0 rlm_realm has been removed, and the framework should allow for dynamic home servers.
Sounds like some kind of defined API is needed, where FreeRADIUS cycles through a list of "realm providers" asking them if they know a realm.
I think DNS has a good model for this. Realms could be returned with Expire/Minimum/Refresh/Retry values. I seem to recall v4 has some kind of event queue? Could this be used to fire an asymmetric realm lookup?
I hope so!
A lot of the issues we have would also be problems for radsec dynamic discovery (and more interesting things - realm lookups via http/sql?).
That's a module. :) And configurable in unlang.
When a home server is added, it can have it's own expire / refresh / etc. values. That should all be in the server core.
Yes. The goal is to allow dynamic realms / home-servers from any source. That will be much more flexible than v3
I guess this is a new type of module? Because typical modules do not have a interface to query realms, do they?
Yes, but every "realm" source may have different ways of handing expiration/refresh events. Will their "callbacks" be called upon these events. That'd be superb.
That's really great. A lot of flexibility will come from here. Indeed, I see two major options:
Benefits of 2) are decoupling, ability of using different languages (or even machines).
The point is that in v3 and earlier, realms were magic. They were welded into the server core and rlm_realm. In v4, there's no magic. There is no "proxying" in the server core. Instead, there's a RADIUS client module which queries home servers, just like the SQL module queries SQL databases.
At that point, dynamic home servers just becomes dynamic updates to a module. Realms lose all magic, and just become module configuration.
Probably not. The goal is to allow create / renew / expire with configurable timers. The RADIUS client module then just either expires the realm / home server, or gets told to keep it alive.
The point is to separate data sources from how that data is used. The more tightly they are tied together, the harder it is to change anything.
Perhaps you could explain what callbacks you need when a home server expires.
Both of those are the same option:
You're free to write a custom module to query your own DB, or you can use unlang to query SQL / REST / whatever, and get attributes that way.
Sounds like a good design and for sure a far less hackish approach for us.
What I need is to be able to renew the TLS keys associated to a particular realm before they expire. "Expire + get new one" procedure does not work well for us, since the establishment process is slow and hence some user authentications might seem really slow for the user with no reason.
So the callback would be something such as "renew_realm_info()", which will have a configurable timer < expiration_time. That is, a realm is not used beyond its expiration time, but say 60s beforehand I got notified so I can start doing negotiation and establish new keys before expiration (this would be indeed very similar to IKEv2/IPsec rekeying process). It is important that, while refreshing is being done, users can still use the old realm info for authenticating, creating no disruption for them.
In option 2), that is, having a external daemon that do the refreshing, this would not be needed, as upon expiration FR will query for the new keys that will be there already.
I see what you mean. Again, the main "challenge" I see is how you are going to handle expiration/renew of realms. It can be:
Obviously, my preferences are with 3). That is the "callback" I was referring to.
The short answer is that we need a "renewal" timer which is different from the "expiry" timer.
The new design has an event loop per thread. Modules can add events to that event loop. Which means that when the "dynamic home server" modules hits the "renew" timer, it can take action to (somehow) renew / refresh the data.
It seems pretty straightforward. I think implementing the TR client functionality in v4.0 will actually be easier than it was for v3.0.