>>>>> "Jim" == Jim Schaad <[log in to unmask]> writes:

    >> All Moonshot acceptors can do is talk to a AAA proxy.
    >> 
    >> IDP-AAA-TR is really two things IDP-AAA-TIS and IDP-AAA-TIC.
    >> (temporary identity server and client) TR talks to IDP-AAA-TIS.
    >> IDP-AAA-TIS talks to some RADIUS server probably IDP-AAA as an
    >> RP.  IDP-AAA talks to IDP-AAA-TIC to get a key for TR-IDP.
    >> 
    >> so it really doesn't make sense to reverse the flow and re-use
    >> the
    Jim> connection
    >> to TR.  Also, in the more than one TR in the world model, it's
    >> not at all clear
    Jim> that the
    >> incoming TR is required to be the TR that IDP-AAA-TIC will choose
    >> to use.  It's probable because IDP-AAA-TIS probably has a short
    >> ACL.

    Jim> Given that I think the IDP-AAA-TIS and IDP-AAA-TIC are so
    Jim> closely connected, I don't see a problem with reversing the
    Jim> flow on the TID channel, but it does not really matter that
    Jim> much.

My major point is that IDP-AAA-TIS and IDP-AAA-TIC are not as closely
connected as you seem to think.

Sure, we could write code that worked that way. However, let's take a
look at the code we have.

IDP-AAA-TIS is a gss acceptor.  It links against the existing mech_eap.
That has a configured set of RADIUS servers it's going to talk to in a
failover pattern.  Even if IDP-AAA-TIS, IDP-AAA and IDP-AAA-TIC are all
running in different threads in the same process, there are going to be
sockets involved.

IDP-AAA-TIS needs to talk to a RADIUS server whose identity is
independent of the realm.
Which RADIUS server that is will be configured in radsec.conf.
It's probably IDP-AAA, but need not be.
That's going to involve a socket.

Similarly, a TIC talks to a preconfigured set of trust routers
independent of the target_realm and community.
That will be configured probably in the freeradius configuration.


Or to look another way at how losely coupled this all is, imagine if
IDP-AAA-TIS used another gss-api mechanism than mech_eap.

Sure we could add a bunch of special cases for tightly coupled TIS and
TIC. In fact some people might implement it that way.
In terms of protocol, though, supporting the loosly coupled
implementation seems desirable.
In terms of implementation it seems easier because it promotes code
reuse and because we already have a mech_eap that works that way.

--Sam