Mick,
I
think that is exactly what I'm proposing for the Handoff group. 2 entities,
one on the controlled port and one on the uncontrolled port. They may actually
be the same entity with an attachment to both LSAPs, that is
TBD.
The
reasoning is that it benefits from all the goodness that EAPoL benefits from.
802 Media independence and a clear definition of the security state of the
system (port open/ port closed).
In
my model, it would be a policy decision as to what information or services
were available on which port. Obviously some information would need to be
secured and some information, such as say service advertisments ("Come to my
base station, Cheap bandwidth here!") would be better unsecured and available
expediently.
The
answer to the question of whether we can retrofit such a clean architecture
into 802[11] is I believe 'yes' and yes its definition should be orthogonal to
linksec. If it is not possible, watch the handoff group crash and burn
:-).
Regards,
DJ
David Johnston
Intel Corporation
Chair, IEEE 802 Handoff
ECSG
Email : dj.johnston@intel.com
Tel : 503 380 5578
(Mobile)
Tel : 503 264 3855 (Office)
The general solution to this class of issues seems
fairly clear. Provide/define a protocol entity that attaches to the/an
Uncontrolled Port that is providing the attachment point for the roving
station.
Apart from the fact that that entity appears to
need to be able to read the current status of the Authorized/Controlled Port
(really as an optimization so that it doesn't have to conduct its own
further checks to guide its behavior - another and possibly better solution
might be to partition the overall functionality between such an entity and a
companion one that ataches to the Authorized Port, or to define an entity
which attaches to both), its definition ought to be orthogonal to
LinkSec.
Clearly with a roving type technology where ports
come and go an association (also quite properly known as a Port) needs to be
in place for such an entity to communicate with the roving station. That
association doesn't have to be secure however.
Wired world:
Uncontrolled
Authorized
Port \ /
Port (secured association)
\ /
SecY
|
Port
(lower MSAP)
|
Unwired world:
Uncontrolled
Authorized
Port \ /
Port
\ /
SecY
|
Association
|
Mick
[I'm not saying that one can retrofit such a clean
architecture to 802.11 as currently defined.]
On Behalv of Dave Johnston: