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
