This time from the right address.
--- Begin Message ---
>>>>> "Glen" == Glen Zorn <[email protected]> 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://[email protected]] 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.
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. 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
--- End Message ---
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
