>>>>> "Jim" == Jim Schaad <[log in to unmask]> writes:
Jim> QUESTIONS:
Jim> 1. To what degree do the trust router components tightly
Jim> coupled to the AAA proxy on the Relying Party and the IdP need
Jim> to get the Trust Route flooding information? If the trust
Jim> router next to the RP needs to talk to different trust
Jim> infrastructures based on COI, then it needs to know what COIs
Jim> are in each Trust Router. In a private mail to Sam & Margaret,
Jim> I suggested a reason why the trust router next to the IdP might
Jim> need to get the same information.
In the current architecture, trust routers basically need the full
routing table.
However, a temporary identity client (coupled with the RP proxy) and a
temporary identity server (coupled with the IDP) never need the full
routing table.
a TIC only talks to one trust router or possibly to multiple ones for
redundancy.
TICs never make routing policy decisions.
If you need routing policy decisions, introduce a real trust router.
Jim> 2. To what degree does a Trust Router in the system have a
Jim> special relationship with the IdP(s) that authenticate the
Jim> Trust Route infrastructure. It is my opinion that there will
Jim> be one (or more) TRs that are "privileged" in that they will
Jim> have a pre-configured existing relationship with the trust
Jim> router IDP entity (TR-IDP). If there are multiple TRs in a
Jim> web, not all of the TRs may have this "privileged" relationship
Jim> and if there are multiple "clones" of TR-IDP or multiple IDPs
Jim> that can allow access to the TR COI then 1) every IDP has some
Jim> TR which is in a privileged relationship and 2) a single TR may
Jim> have a privileged relationship with zero or more IDPs.
Well, a TR doesn't directly have a privileged relationship with the
TR-IDP, or what I'm calling an APC realm.
However, the APC realm does run some TIS.
Generally, a TIS has a small ACL for who can talk to it. Generally that
ACL includes only a small number of trust routers who are directly
connected to the TIS.
So, there are privileged trust routers in the sense that they are
authorized to create temporary identities in the APC realm.
I'd expect a small number of these per APC realm.
Note that there can be more than one APC realm per APC. I haven't
explained that yet, although Josh and I did a walk through of how that
works after my message Tuesday.
I'll write that up soon.
Note there's another form of privilege: each trust router has a
privileged relationship with exactly one RP realm--the realm in which it
accepts authentications.
That is, there's one realm worth of RADSEC servers that a trust router
can talk to.
That realm is responsible for connecting the trust router's acceptor
components to the rest of the universe.
Jim> 3. What information does the RP AAA proxy need for indexing of
Jim> the temp ids for a given IdP's AAA proxy server? At a minimum
Jim> I think this is the COI, the APC, the IdP Server Realm..
Jim> Additionally one would have the keys, the temp id and the
Jim> lifetime of the temp id.
For indexing? There's a key identifier that's part of TLS PSK. I think
the IDP realm and TLS PSK ID should be sufficient to look up a key on an
RP proxy.
However, the set of communities (both APCs and COIs) that key is valid
for is important to track.
Lifetime as well once that becomes finite.
