Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Sam Hartman [mailto:hartm...@mit.edu] writes: > > "Glen" == Glen Zorn writes: > Hi. I have read the later messages on this thread, but it sounded like > you and Alan were talking past each other a bit, so I want to come back > to where I think the disagreement is introduced. > > > Glen> Sam Hartman [mailto://hartmans-i...@mit.edu] writes: > > >> Consider a corporation that has an internal network and that also > >> has agreements with WIFI hotspots to provide its employees > >> connectivity. Policy requires that people use a different set of > >> firewall rules and VPN configuration when connecting at the WIFI > >> hotspots than when connecting to the home network. Typically > >> clients determine which network is in use by the SSID. They use > >> the same EAP credentials in both cases. > >> > >> You can imagine that the corporation would know the identities of > >> its own access points. In particular, a combination of > >> configuration on the AAA servers and at the boundary firewall > >> could mean that the AAA servers know whether a given request for > >> access is coming from the corporate network or a WIFI hotspot. > >> Today, however, the corporate AAA infrastructure does not know > >> what the client thinks it is connecting to. If the client > >> disclosed the SSID it sees then the corporation would be in a > >> position to enforce the security policy. > >> > >> Glen agreed that channel binding could address this. > > Glen> Indeed it could, but all you really seem to be asking for is a > Glen> way for the corporation to be able to control the > Glen> configuration of the client. As you point out, it is > Glen> reasonable to expect that the corporation knows the identity > Glen> of its own access points; why does it matter what the client > Glen> _thinks_ (for lack of a better word) that it is attached to? > Glen> I cannot see any purpose for the client sending the SSID of > Glen> the network to which it attached. In fact, it seems that all > Glen> that is necessary is the ability to remotely modify the > Glen> configuration of a client; why is the job of EAP, again? > > > > The client has two different policies both of which have been configured > by the corporate infrastructure. > > The first policy is a policy to be used when connected directly to the > corporate network. The second policy is a policy to be used when > connected to more open networks. > > The client knows both policies. The client needs to choose which one to > use. > The client needs a procedure for connecting to the network such that on > success: > > 1) The client uses the corporate policy on the corporate network and the > other policy on other networks > 2) The client has an authenticated EAP and 802.11I association; the EAP > association to the EAP server and the 802.11I association to the access > point > 3) No attacker can convince the client to use the corporate policy when > connecting to other networks or the other policy when connecting to the > corporate network without the cooperation of the corporate AAA > infrastructure > > So, somehow the client needs to discover which policy to use. We could > use an insecure discovery mechanism and validate the results of that > discovery with a secure protocol later. Alternatively we could use a > secure discovery mechanism and bind the results of that mechanism to the > rest of our protocol. As far as I can tell binding secure discovery to > the later stages of the protocol is exactly as hard as validating > insecure discovery, so I'll design a solution for insecure discovery. I > propose that the client discover which policy to use by looking at the > SSIDs advertised by the APs. I understand SSIDs may not be unique; as a > consequence our client will end up being unable to connect to a > non-corporate network that happens to have chosen the same SSID as the > corporate network. If you design a better discovery mechanism we can > remove this defect; in practice if the corporate SSID is well-chosen > this is not a significant problem. > > So, based on the SSID, we have discovered what policy we will try to > use. Since our discovery approach is entirely insecure, an attacker can > give us the wrong policy to try. If our overall approach is secure, > then we must fail at a later step if that happens. > > In this system, we've posited that the corporate AAA infrastructure > knows whether a given AP is corporate or other. So, we want to take > advantage of that information. We need to change the corporate AAA > behavior to do that as it doesn't provide that service today. We could: > > 1) We can tell the corporate AAA infrastructure what policy we plan to > use and have it validate that decision. > 2) The corporate AAA infrastructure can tell us what policy we should > be using. Or we could use the more direct & much simpler a
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 Discussion at IETF 77: why bother
> "Glen" == Glen Zorn writes: Glen> Or we could use the more direct & much simpler approach of Glen> allowing the client to authenticate the network to which it is Glen> attached & use that data to decide by itself. This can be Glen> done today using EAP-TTLS. How? I'd appreciate an answer in approximately similar level of detail as I have given you the answer on the channel binding approach. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Channel Binding Discussion at IETF 77: why bother
Glen Zorn wrote: > Note that transitive trust issues are irrelevant if EAP-TTLS is used. I agree with Sam here. I'd like to see more explanation behind this assertion. Alan DeKok. ___ 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
