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


    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
    Jim> a
    >> federation operating two APCs at different levels of assurance.
    >> I think
    Jim> of a
    >> federation as a legal entity like thing and as an APC as a
    Jim> 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
    Jim> in to the a document so that we can be sure that we have the
    Jim> same definition and thus the same security properties
    Jim> associated with each object.

A technical definition of APC is probably relatively easy.

An APC is a set of IDP and RP realms. Trust routers carrying routes
valid for a given APC are responsible for maintaining integrity for
temporary identity messages within the APC and for assigning mappings
between names in the APC and entities (RP proxies and AAA servers) in
the APC.


    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
    Jim> privileged
    >> relationship with TR-IDP because it can create temporary
    >> identities in
    Jim> TR-IDP.
    >> 
    >> TISes don't answer questions; they create identities.

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

I think we're in agreement here.
A TIS is responsible for authorization of connecting TRs.

That does involve deciding that the TR is permitted to claim a
particular name (handled through GSS authentication) and authorization
(handled local to the TIS).

    >> 

If you have a trust router who talks to other trust routers but never to
a TIS (a  core rather than edge trust router) it will be privileged for
no TIS.

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

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

I'm talking about AAA proxies near the RP.

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

    Jim> There is a difference between you are not planning to support
    Jim> it as oppose to the protocol is not going to be able to handle
    Jim> it.

We do not plan on including the necessary protocol support for this in
the documents that are produced.
Obviously people could propose either before or after this enters the
IETF that support be added.
I believe protocol support is added. In particular, you need to re-map
communities at such a boundary.
As a result you'll need to do something to the loop detection.


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

Sorry. Janet would like there to be one APC for a compatible set of
usecases--for example one APC for the basic policy across their
community and their peer communities.
If you have different LOAs or other different technical trust
requirements, then having different APCs is desirable.
However, you wouldn't want to connect two APCs that ran at different
levels of assurance or that had different accreditation requirements.

    >> >>

I'd expect that most APCs would require the COI be sent as a RADIUS
attribute.  I think registering an attribute for this and recommending
it as best practice in the trust router documents would be desirable.