Re: [Emu] Channel Binding: transitive trust
Sam Hartman [mailto:hartmans-i...@mit.edu] writes: > > "Glen" == Glen Zorn writes: > > 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. > > Glen> s/within/at: if said proxy is even one AAA hop inside the > Glen> border an invalid claim may be indistinguishable from a valid > Glen> one. > > The key word there is may. If that's the key word, then forget it ;-). In actual fact, it is impossible within either standard RADIUS or standard Diameter to securely determine where a message came from beyond the node from which it was sent. To be clear, if the filtering proxy is inside the corporate network, it will be incapable of securely determining whether the message originated outside that network or not. I used the word "may" because somebody somewhere may have devised a method for doing this; I make know claim of omniscience. > Depending on topology, configuration and > policy, it may be possible to distinguish things beyond the border. Policy & configuration cannot solve the problem, which is a protocol deficiency. > I agree the border is a logical place to make this distinction though. > > > >> > >> 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. > > Glen> You can. but in this context it's difficult to see how an > Glen> intermediate proxy could filter on SSID (for example) w/o > Glen> detailed knowledge of the topology of both the originating and > > I absolutely agree that the intermediate proxy needs sufficient > knowledge to perform the filtering. Depending on the specific filter, > it is definitely the case that the proxy will need information about the > origin and destination organizations and networks. That level of detail > is very often spelled out in business agreements for trading partners, > in the banking industry, and presumably in other industries I'm less > familiar with. I'm not aware of cases where AAA configuration was the > subject of these agreements, but I've also not been in a position where > I cared about the AAA infrastructure before. > > But yes, for a lot of filters you need to understand the routing > topology well enough to understand whether a particular proxy should > legitimately be on the path between you and a given origin. For RADIUS > at least, I do understand the difficulty in getting that information; > I'd rate it as higher than you'd probably want for most current network > access situations, but definitely not impossible. Nothing is impossible, but at the moment there is no way to do it and no clear way to accomplish it. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding: transitive trust
> "Glen" == Glen Zorn writes: 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. Glen> s/within/at: if said proxy is even one AAA hop inside the Glen> border an invalid claim may be indistinguishable from a valid Glen> one. The key word there is may. Depending on topology, configuration and policy, it may be possible to distinguish things beyond the border. I agree the border is a logical place to make this distinction though. >> >> 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. Glen> You can. but in this context it's difficult to see how an Glen> intermediate proxy could filter on SSID (for example) w/o Glen> detailed knowledge of the topology of both the originating and I absolutely agree that the intermediate proxy needs sufficient knowledge to perform the filtering. Depending on the specific filter, it is definitely the case that the proxy will need information about the origin and destination organizations and networks. That level of detail is very often spelled out in business agreements for trading partners, in the banking industry, and presumably in other industries I'm less familiar with. I'm not aware of cases where AAA configuration was the subject of these agreements, but I've also not been in a position where I cared about the AAA infrastructure before. But yes, for a lot of filters you need to understand the routing topology well enough to understand whether a particular proxy should legitimately be on the path between you and a given origin. For RADIUS at least, I do understand the difficulty in getting that information; I'd rate it as higher than you'd probably want for most current network access situations, but definitely not impossible. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding: transitive trust
Sam Hartman [mailto:hartmans-i...@mit.edu] 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 t
Re: [Emu] Channel Binding: transitive trust
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 Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
