On Oct 15 Alan DeKok wrote:
Matt Bernstein wrote:
So saith FreeRADIUS 2.1.1, but I wasn't trying to do multiple levels of TLS nesting. I'm trying to use virtual servers so that a single radiusd can terminate TTLS/PEAP for multiple subrealms, _and_ use the inner-tunnel trick, keeping the configs completely independent for each subrealm.
If you have one server certificate for TTLS, you don't need this extra layer of nesting.
We will have multiple server certificates; our departments are rather independent here.
This allows me to hook up different departments with different AAA infrastructures into one radius set-up for our eduroam service.
My "default" server has a pair of listen{} blocks, and little else:
authorize { suffix
update control { Virtual-Server = "%{Realm}" }
What does this achieve? Does it avoid the first layer of proxying? My set-up is working without it, AFAICT: server default { +- entering group authorize {...} [suffix] Looking up realm "dcs.qmul.ac.uk" for User-Name = "username@dcs.qmul.ac.uk" [suffix] Found realm "dcs.qmul.ac.uk" [suffix] Adding Realm = "dcs.qmul.ac.uk" [suffix] Proxying request from user username to realm dcs.qmul.ac.uk [suffix] Preparing to proxy authentication request to realm "dcs.qmul.ac.uk" ++[suffix] returns updated } # server default
Sending proxied request internally to virtual server. server dcs { +- entering group authorize {...} [dcs-eap] EAP packet type response id 3 length 149
..etc..
..and "dcs" has its own EAP config, which references a virtual_server "dcs-inner" for the PEAP/TTLS innards, which has _its_ own EAP config.
That's... complicated.
A famous aphorism of Butler Lampson goes: All problems in computer science can be solved by another level of indirection... Kevlin Henney's corollary to this is, "...except for the problem of too many layers of indirection." (from <http://en.wikipedia.org/wiki/Abstraction_layer>) Maybe the inner eap config can be the same for the "inner" virtual servers, but the server{} blocks will necessarily be different. I'm trying to normalise it, rather than complicate it.
My problem is that eap.c (line 219), as called by "dcs-inner", notices the request has a grandparent, and assumes it's multiple layers of TLS nesting. Interestingly, the comment omits the magic word "TLS". I think perhaps that the virtual servers appear to count as layers. Anyway, this braindead patch makes it work for me:
Which pretty much removes the limits on nested queries. I understand
I agree; I put the great-grandparent check in there to catch runaway loops. I never said my fix was right.
why you're doing this, but I'm not sure what the side effects are.
Sure. If you're not, I haven't a prayer. ;) My guess is that the eap.c code predates the virtual servers, so when eap.c was written its assumption that the nesting must be TLS could well have been true, but today newer code-paths exist which weird hairy people expect to work.. I have run into another bug: if I instantiate rlm_ldap in my servers "dcs-inner" and "maths-inner", it seems to use the base DN for "maths-inner" (instantiated second) for queries from "dcs-inner". Am I just being too weird and hairy? Or should I use a separate radiusd and raddb for each subrealm, as is the case with my production FreeRADIUS 1.1 set-up? Cheers Matt