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:
|