802.11i authentication, if enabled, provides mutual authentication, but
that's only between the client and the _home_ network. You know that the
home network trusts the access network because it was given the session
key, but you have no idea if the access network is, say, CheapAccessInc
There are extensions of network access authentication methods where you
also get some form of an authenticated identity for the access network.
3GPP LTE access authentication or EAP-AKA', for instance. Not yet widely
deployed, of course.
(But I'm digressing from the original stop.)
Ralph Droms wrote:
Yup ... there is currently no way to provide authenticated, meaningful
identification of the network(s) to which a host is attached. Without
that identification, it's pretty hard to write any reasonable policies.
On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote:
On 2009/4/13 Ralph Droms <rdroms(_at_)cisco(_dot_)com> wrote:
For example, would a host process
information received from a Starbucks network over its 802.11
interface differently from information received a home network over
the 802.11 interface?
It's even more fun than that. How do we reliably know that we are at
Starbucks, and not at home? The SSID? That's not an authenticated
token. Currently Windows makes security decisions based on the SSID.
You could call this the best answer they could come up with for a
problem with no good answers. Or you could say that it instills the
user with a false sense of security. Either way, it's not something
I'd be comfortable seeing in a protocol spec, so if the client is in
fact to make decisions as you've suggested, we'd need a secure way of
doing this. I don't know enough about WPA Enterprise to know if
there's a bidirectional authentication going on there - from the UI
perspective it looks like it's one-way.
dhcwg mailing list
Ietf mailing list