Sam Hartman [mailto:hartm...@mit.edu] writes:
> >>>>> "Glen" == Glen Zorn <g...@net-zen.net> 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 approach of allowing the client to authenticate the network to which it is attached & use that data to decide by itself. This can be done today using EAP-TTLS. > > The channel binding approach is option 1. We tell the corporate > infrastructure what policy we're using as a channel-binding attribute in > the EAP exchange. If we indicate we're using the corporate policy on an > other network, then the corporate AAA infrastructure sends an > access-reject. Otherwise if we're planning to use the other policy on > the corporate network then the infrastructure sends an > access-reject. Finally, if the policies match, then the infrastructure > returns a result based on existing practice--if everything goes well, an > access-accept. > > So, in this design, we communicate the policy we wish to use to the > corporate infrastructure so that our decision can be validated. No > amount of configuration could allow the client to validate this decision > on its own: it has no secure way to distinguish access points. > > I've specifically constructed this example so that transitive roaming > issues do not pop up. Note that transitive trust issues are irrelevant if EAP-TTLS is used. > They were discussion in your thread with > Alan. I'll get to that in the second of three messages I plan to write > in response. > > --Sam _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
