Well, it's trust routers all the way down until you start mining the
elephant at least.

A couple of weeks ago, I noted that we don't currently have a  solution
for obtaining credentials for RADSEC  clients that are trust router
entities.
In particular, a trust router needs a RADSEC credential in order to act
as a Moonshot acceptor so other trust routers and TIDCs can connect to
it.
A TIDRS needs to have RADSEC credentials in order to act as a Moonshot
acceptor so TRs and TIDCs can connect to it.

In that message, I pointed out that we could potentially use the TID
protocol to obtain temporary identities in a realm associated with the
APC.

Margaret thought that sounded a lot like a special case.
"How does this work for a normal Moonshot acceptor?"
"Uh. Hmm. It's not really different at all. That's kind of messy too."

Within a realm we have a couple of options:

1) You can use self-signed certificates.

2) You can use that single PSK key that Freeradius supports.

Margaret then asked why we couldn't hook a trust router or TIDRs up to
an AAA proxy just like we would anything else.

Hmm, I bet that creates a loop of some kind. Let's see if it has a base
case.

Turns out if you configure things right  it just works.

Let's take an example.
RPP1: RP proxy 1
TR: The single trust router
IDP1: an IDP realm and AAA server in that realm
APC: The AAA server and realm associated with the APC
tid(a,b): TIDR with target_realm a from source b

IDP1, TR and RPP1 all have credentials in APC.  In the following we
assume everything is done in the context of the APC.  I'll argue at the
end we probably want a COI for trust router internal messaging.

RPP1 gets an authentication from [log in to unmask] It discovers it has no
key for IDP1.

SO, RPP1 sends a TIDR for IDP1 to TR.  to do that, RPP1 opens a gss
connection using its credential in APC1 to TR.  TR is run by the same
folks as APC1 so it shares the PSK or a self signed cert with APC1 and
can accept this connection.

TR attempts to forward the TIDR to IDP1. To do that it opens a GSS
connection to IDP1 using its identity within APC1.

IDP1's TIDRS contacts its RP proxy (IDP1). IDP1 discovers it doesn't
have a RADSEC key with APC1. 
So, it initiates a TIDR with target_realm APC1 from IDP1.

To do this IDP1 opens a GSS connection with TR. It does have an EAP
credential in APC1 so it can act as a client.
TR does have a RADSEc key for APC1 so it can accept the connection.

TR forwards tid(APC1,IDP1) to APC1. To do this, it opens a GSS
connection. TR has an EAP credential in APC1 so it can do this. APC1's
TIDRs is closely associated with APC1 (same machine) so it has a RADSEc
key with APC1 and can accept the connection.
A response to TID(APC1,IDP1) is responded.
This makes its way back to IDP1, which now has a key for APC1.

Now, IDP1 can accept that connection from TR to process tid(IDP1,RPP1).

See, there is a base case!  It will "work."  This is really nice because
we didn't need more must-haves for the upcoming beta or pilot releases.

I'm a bit concerned about the scaling and performance. There's a fair
bit of recursion involved that all needs to resolve itself before the
client behind RPP1 gives up on RPP1's ability to get an access-request
to IDP1.  If that fails, then the user behind RP1 will get a timeout and
authentication failure.  If they try again it will work better, but that
provides bad usability, especially for automated authentications.

If the trust router is good about connection caching, holds open TID
connections to popular TIDRS, etc, then I suspect we can make this work
with reasonable performance.
Currently that sort of caching is not part of the plan.
So, I expect that things may be a bit slow for the first
version. Especially since we don't expire temporary identities right
now, I think it will work out OK.
However, I think that this will give us some pressure post-April to
improve our performance. 


I had originally hoped that the APC realm would not be routable from the
normal AAA proxies. My hope was to avoid having normal users be able to
connect to trust router infrastructure for better isolation of the trust
plane than the normal authentication plane.  I think we can gain the
same isolation by having a COI in which these requests are made. The
APC1 AAAserver only accepts requests with this orig_coi. Similarly  the
trust router and TIDRs will make their requests in this COI, and only
the APC1 realm will be an IDP realm in that COI.

In many ways this ends up being  an excellent architectural validation:

1) I proposed introducing a special case at the protocol level. It turns
out it's easier to do it using existing tools treating the recursive
authentication just as another case of Moonshot.

2) I thought the trust router internal infrastructure was "special
enough" that it didn't want to use the one APC. It turns out it works
better if we do use the APC and just use COIs to provide isolation
exactly the way we're asking people to do for their resources.