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

    >> In the current architecture, trust routers basically need the
    >> full routing
    Jim> table.
    >> 
    >> However, a temporary identity client (coupled with the RP proxy)
    >> and a temporary identity server (coupled with the IDP) never need
    >> the full
    Jim> 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> Ok - first, having a term for an object is helpful so I will
    Jim> start using TIC and TIS as well as TR in this discussion.

    Jim> I am not as sure as you are that the TIS will never need a
    Jim> subset of the routing table, and that flooding might be the
    Jim> best way to supply that.  But until I have a discovered a
    Jim> reason that is incontrovertible I will not argue the case.

I'm sure only because it's a semantic distinction and Margaret is
defining the semantics:-)

If you need the routing table you're a TR.
If you don't you're a TIC.
Conceptually at least a TIC talks to one trust router.
You could imagine a TIC being co-resident in the same process space with
a trust router; that would be a fine way to handle a TIC that had
complex enough policy it needs the routing table.

So, are there deployments where you need an entity with the routing
table very close to an RP RADSEC proxy?
Yes.
We claim that the entity that ends up with a routing table is a trust
router, not a TIC.


    >> 
    >> 
    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
    Jim> 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
    Jim> ACL
    >> includes only a small number of trust routers who are directly
    >> connected
    Jim> to
    >> the TIS.

    Jim> I have decided that while I have a good idea of what a COR is
    Jim> (but not necessarily what you had previously labeled as one), I
    Jim> have absolutely no idea what the actual definition of an APC
    Jim> is.  Please tell me the difference between an APC and a
    Jim> federation.

Thinking of an APC as a federation is not entirely wrong.  I could
imagine a federation operating two APCs at different levels of
assurance.  I think of a federation as a legal entity like thing and as
an APC as a business/technical entity belonging to a federation.  Josh
would certainly argue I'm over-simplifying and urge we never use the
term federation.

Note that APC replaced COR as a terminology update but not as far as we
intended a semantic update.

    Jim> So you are saying that the TIS attached to the TR-IDP has a
    Jim> privileged relationship for trust routers in that it can answer
    Jim> the question - do I know the IDP to validate this TR with an
    Jim> affirmative as oppose to a negative.  However as you stated in
    Jim> the previous message a TR is always completely distinct from an
    Jim> IDP.


No, I'm saying that there is almost always at least one TIS that has a
privileged relationship with TR-IDP because
it can create temporary identities in TR-IDP.

TISes don't answer questions; they create identities.

    >> 
    >> So, there are privileged trust routers in the sense that they are
    Jim> authorized to
    >> create temporary identities in the APC realm.  I'd expect a small
    >> number of these per APC realm.

    Jim> I have a problem with this.  It is a TIS that creates temporary
    Jim> identities in the APC realm not the TR.  TRs merely act as
    Jim> trusted introducers from the TIC to the TIS but do not create
    Jim> the temporary identity.

To be more correct: there are privileged trust routers in that there are
trust routers who are authorized to talk to the privileged TISes.

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

    Jim> What is an RP realm?  I don't understand this statement.

A trust router is a GSS-EAp acceptor.
A GSS-EAp acceptor has a relationship with exactly one realm where it
will send access-request messages for incoming authentications.

    >> 
    >> That is, there's one realm worth of RADSEC servers that a trust
    >> router can
    Jim> talk
    >> to.  That realm is responsible for connecting the trust router's
    >> acceptor components to the rest of the universe.

    Jim> I think that this is an incorrect statement.  A trust router
    Jim> can sit on the border between two different APCs and route
    Jim> requests between them.  Such a router would by definition be
    Jim> able to talk to RADSEC servers in both realms - at least
    Jim> indirectly if not directly.


No. We have no plans to support routing between APCs.
If a trust router does not flood an APC, you cannot reach it.

I expect that APC remapping and thus routing across APC boundaries will
be a feature that comes into existence at some point in the future.
Janet wants to encourage minimizing the number of APCs and so they have
not added this feature to the implementation road map.

Now, there's a different statement.
A trust router can sit on the boundary between two APC realms in the
same APC and facilitate identity exchange across that boundary within
the same APC.

However, the gss-eap acceptor side of the trust router can only talk to
one realm.
This is a limitation of the current Moonshot code.
We don't see a good reason to relax it.
Because of the Freeradius limitations, handling this type of boundary
condition gets a bit ugly.
A trust router can have *client* identities in multiple realms. It
simply needs a server identity in one realm.


    >> 
    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
    Jim> 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
    Jim> is
    >> important to track.  Lifetime as well once that becomes finite.

    Jim> I think that a temp key can only be used for a single COI
    Jim> unless we are going to start sending the COI information as a
    Jim> RADIUS attribute.  Since the trust protocol currently is
    Jim> carrying and validating for a single COI rather than a group,
    Jim> the returned identity is only going to be good for that one
    Jim> COI.  Doing more is not covered.

The challenge is all the Freeradius limitations.
It needs to happen to be the case that  you can use the  same key to
contact a particular home server every time you contact it.
So,  a TIS needs to combine  authorizations from entities using the same
DH public key.
It's ugly and I'd love to not have this issue.