> -----Original Message-----
> From: Sam Hartman [mailto:[log in to unmask]]
> Sent: Friday, February 15, 2013 12:54 PM
> To: Jim Schaad
> Cc: [log in to unmask]
> Subject: Re: It's Trust Routers all the way down: obtaining RADSEC
credentials
> for TRs and TIDRs
> 
> >>>>> "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.
> 

I think that between you, Josh and Rhys, you need to get a good definition
in to the a document so that we can be sure that we have the same definition
and thus the same security properties associated with each object.

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

But in this case the TIS at the TR-IDP needs to be able to either answer or
get an answer to the question - is the TR who he says he is.  This is doable
because it is the one associated with the TR-IDP and thus it does not need
to also be a TIC to get that information back.

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

Are you implying that there are non-privileged trust routers as well?  Or
are there only trust routers that are not privileged to talk to some TIS
entities?

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

Are you talking about a realm in terms of a AAA proxy or in terms of a AAA
server? (or EAP server)

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

There is a difference between you are not planning to support it as oppose
to the protocol is not going to be able to handle 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.

Even more I need a good set of terms and what they mean.  Why should there
only be one APC?  I can understand that it makes life easier, but it may
also place burdens on the APC that not everyone will want to agree to.

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

I think this may then require that the COI become a RADIUS attribute as
well.