Sam Hartman [mailto:[email protected]] writes:
> 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. Indeed; however, there are lots of ways to collect that data that are both secure and do not involve hacking up EAP. > > 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. s/within/at: if said proxy is even one AAA hop inside the border an invalid claim may be indistinguishable from a valid one. > > 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. You can. but in this context it's difficult to see how an intermediate proxy could filter on SSID (for example) w/o detailed knowledge of the topology of both the originating and destination networks. > > I'll take a specific example from Kerberos. I would be very careful making analogies between Kerberos & any IETF AAA protocol: they work in wildly different ways, particularly WRT cross-realm operation. For example, it is possible to source-route messages and to record (in a way that is _not_ tamper-proof) the route taken by a given message in Diameter the same capability doesn't exist in RADIUS. Most proxies simply forward messages (hopefully) toward the ultimate destination without regard for the path to be taken after the next hop. > 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
