[awful patch] "Multiple levels of TLS nesting is invalid."

[Matt Bernstein]

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 at 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