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