|
Correct,
In
802.1x, the port is the port. Data can arrive any time and the 802.1x port
entities are associated with a physical port. In
the 802.11 case the port is defined to be an
association, so nothing can pass to an uncontrolled port entity (E.G. EAPoL or
the hypothetical handoff thing) until an association exists. This slows down the
process of scanning for a suitable network attachment by inserting
association/disassociation pairs into the sequence.
This
is the basis for the incresingly popular argument in 802.11 that the AID-port
binding is incorrect and it should actually be a binding to a tx/rx
address tuple, possibly with rules on the dynamic creation and
destruction of port entities as new tuple paired packets arrive. This would
address the pre-auth problem and optimize the 802.11 case for inter
ESS/network/admin domain handoff.
A
similar state exists in 802.16. The sequence goes RNG-REQ, RNG-RSP, REG-REG,
REG-RSP, followed by the transfer of x.509 certs, an RSA based PKCS #1
transfer of the AK and a 3DES transfer of a KEK before you get to
EAPoL-Start. Not swift!
It
would be nice to have a situation where I could fire EAPoL (or 802 handoff
defined) messages as a first probe of a potential network attachment point
and move on quickly if the response is not to my liking without going through
all the 802.11 specific association messages.
This
is a discussion I wanted to have in Sacramento, but here is an equally good
spot.
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)
So
the big question for me is, how do we deal with the port in the roaming
wireless world if it needs to be instantiated before the association actually
exists? Does the port you are talking about fit this model?
In other words, before I roam to the new AP, the association doesn't exist
yet, so neither does the port. How do I create it before the
association takes place, so I can quickly open the controlled port
part when the supplicant finally does show up and associate? This
is the pre-auth problem...
Paul
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:
|