During the discussion between Glen and Alan there was a lot of discussion about transitive trust.
Alan gave a case where a user might be wanting to choose between two vendors, X and Y. They charge different prices. If they are directly connected to the user's home AAA realm, then the home AAA realm might be in a position to validate a claim about which identity is involved. Glen points out that if there are additional proxies then the home AAA realm cannot make this validation. Another argument tends to come up around this point: such matters should be handled by business agreements, not by technical means. If someone lies, sue them or terminate your business relationship. I've been thinking a lot about transitive trust recently and have been studying this problem in the Kerberos context for many years. I have a few responses. First, the technical system needs to support auditing of the business agreements: when you want to file an action or terminate a relationship because of fraud, you want the data necessary to make that stick. Business agreements are a good defense against fraud on the part of the party you have a business agreement with. However business agreements are a dreadful way of dealing with compromised systems or social engineering attacks. You want to limit the damage that a problem at one of your business partners can cause and you do not want to trust them more than you need to. Technical measures are important in establishing this. Also, technical measures allow you to establish pockets of greater trust in systems of lesser trust. Without technical measures you have to expect all your business partners to run their infrastructure at a level sufficient to meet your strongest requirements, even if they are not involved in that. Put another way, without technical safeguards to limit what statements you will allow a trusted third party to make, then your overall level of trust decreases to the least trusted of your trusted third parties. Let's take the corporate network example from my first message as a case in point. The corporation has two levels of trust: internal and everyone else. Internal entities may claim to be corporate access points. People who are part of "everyone else," are not permitted to make this statement. The corporation need not worry about what happens if a roaming partner claimed in AAA attributes to be the corporation's network: such a statement would simply be rejected by some proxy within the corporate border. More general, at each level in a proxy chain, you can consider whether the party you receive a message from is permitted to claim the attributes that are claimed in the proxy request. I'll take a specific example from Kerberos. In Kerberos, it's important to understand what realm should be used for a given host and what the set of realms should be traversed between a source and destination. Vendors have found it important to limit the trust claims that can be made. For example, Microsoft establishes a distributed database between communicating realms to carry the trust information. That way, to the extent possible, trust can be evaluated even for multi-hop situations. Obviously if legitimate traffic would involve a particular realm, then that realm can generate similar illegitimate traffic. However, realms are not trusted more than they need to be. We're looking at similar mechanisms for the non-network-access federation project I'm involved in. Is every AAA operator going to go out and deploy distributed databases to make channel binding more useful? Absolutely not. However I do expect that enterprises will filter AAA traffic to establish zones of trust. I also expect that operators faced with customer demand (and revenue) would be happy to do the same. So, yes, transitive trust is not as good as direct trust. However,it doesn't mean throwing things completely open in all environments. Next, I'll cover tunnel issues. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
