RE: [LinkSec] 802.11 architecture and pre-auth paper
Jim, Bernard,
As I wasn't at the last 802.11 meeting, I'm not sure what may have
changed, so these comments are based on the situation before that
meeting. I'm sure someone will point out any errors!
Mike Moreton
Synad Technologies Ltd.
-----Original Message-----
From: Jim Burns [mailto:jeb@mtghouse.com]
Sent: 29 July 2003 00:36
To: Bernard Aboba; stds-802-1@ieee.org; stds-802-linksec@ieee.org
Subject: RE: [LinkSec] 802.11 architecture and pre-auth paper
Hi Bernard,
This document is helpful. It definitely gets the ball rolling
on defining pre-authentication for Link Security (or .1aa). I have
a few questions, some of which may be more for .1aa to answer rather
than .11i, but they will hopefully generate some discussion and keep
this issue active here.
1. I have a created a table which I believe summarized the transfer of
packets between the wireless medium (WM) and distribution system (DS).
Is this accurate?
012345678012345678901234567890123456789012345678901234567890123456789012
3456
789
Port Ether- ToDS FromDS 802.11
Received To MAC From type Field Field State Result
-------- -------------- ----- ----- ------ ------ -------
------------
-
--> WM port WM MAC <any> <any> <any> <any> <any>
Processed
by WM
port
######################################################
[Mike Moreton] Currently there is no special processing for data frames
addressed to the WM MAC address - they are handled just like any other
MAC address in the DS. That means that you have to be in state 3, and
they have to be sent with toDS=1 or they will get discarded by the
receiving MAC. I for one have suggested changing this in the past, but
it wasn't approved.
802.11 management and control frames can be passed in other states, but
they aren't currently used to transport any data, and hence don't have
an Ethertype.
######################################################
--> WM port <any> <any> <any> FALSE FALSE <any>
Processed
by WM
port
######################################################
[Mike Moreton] Any data frames received when not in state 3 are ditched
by the AP. Any data frames with toDS=0 are ditched by the AP.
######################################################
--> WM port <any> <any> <any> FALSE <any> <any> NOT sent
to
relay
agent.
--> WM port not WM <any> <any> TRUE <any> not 3 Discard
frame
--> WM port non-fwd mcast <any> <any> TRUE <any> 3
Processed
by WM
port
######################################################
[Mike Moreton] To show my ignorance, what's the definition of
non-forwardable multicast?
######################################################
--> WM port unicast on <any> <any> TRUE <any> 3
Processed by
wireless Relay
Agent,
sent
to WM
port,
sent
wireless
STA
######################################################
[Mike Moreton] To be pedantic, the relay agent functionality is part of
the DS. However, I think Bernard's separation makes the whole thing
more understandable.
######################################################
--> WM port unicast not <any> <any> TRUE <any> 3
Processed by
on wireless Relay
Agent,
sent
to DS
port,
sent
to DS.
--> DS port DS MAC <any> <any> <any> <any> na
Processed by
DS port
--> DS port broadcast <any> <any> <any> <any> na
Implementation
dependent.
May
forward
to
WM,
may not.
######################################################
[Mike Moreton] The protocol assumption is that broadcast and multicast
frames will be forwarded. Certain manufacturers may implement
non-standard filtering for security reasons, but it's not something you
have to worry about too much from a standards perspective.
######################################################
--> DS port unicast on <any> <any> <any> <any> na
Processed by
relay
wireless agent,
sent
to
WM port,
sent to
wireless
with
FromDS=TRUE,
ToDS=FALSE.
--> DS port WM MAC <any> <any> <any> <any> na
Processed by
relay
agent,
sent
to
WM port.
2. Under section 1.3 there is a sentence:
" An Access Point supporting 802.1X shall have a WM port supporting an
Authenticator
Port Access Entity (PAE), and may have a WM port supporting a Supplicant
PAE
"
I believe it would be more accurate if it read:
" An Access Point supporting 802.1X shall have a WM port that can create
logical
(virtual) ports which support an Authenticator Port Access Entity (PAE),
and
may
also support a Supplicant PAE"
3. In section 1.1 there is a sentence:
" Depending on the AP implementation, the WM port and DS port may or
may
not
have distinct MAC addresses."
It is not made clear in the document how an AP that has a single MAC
entity
for both the WM and DS will operate? If a frame is delivered to the
single
MAC entity how is it processed? Where is the relay agent (or is
there
none)?
Logical ports are created atop the MAC entity normally, so in the case
of
a
single WM/DS MAC entity that is running .1X on the WM, how are frames
from
the
DS differentiated from frames from the WM?
######################################################
[Mike Moreton]
Another way of looking at it:
STA A __________
-----------| |
| |
| DS |----------------- LAN
STA B | |
-----------| |
----------
|
|
|
__________
| |
Management | 802.11 |
-----------| Manage- |
Frames | ment |
-----------
[Note - the 802.11 management function is not identified in 802.11 -
it's pretty much the non-data handling parts of the MAC, plus some of
the system management function].
The DS is a multi-port switch with ports to the LAN, the 802.11
management function, and logical ports to the different STAs. The
802.11 management function controls (via an invisible link) the creation
and destruction of logical ports. Each logical port has a destination
MAC address, and the DS uses this information for forwarding rather than
the normal learning process.
The AP needs a MAC address for various reasons. To label the wireless
network it supports, to identify the AP in 802.11 internal protocol
frames, to receive 802.1X frames, and for management. In fact, in the
base 802.11 standard, there is no requirement for there to be a link
between the DS and the 802.11 management function to pass data frames if
you don't want to manage the AP. (Just like a bridge or switch doesn't
need any MAC addresses.)
However, all APs need to be managed, so all AP suppliers make the
connection. But you only need a single MAC address.
Many AP suppliers have two MAC addresses - one for the wireless side,
and one for the Ethernet side. There is no reason in the standards to
do this - but if your hardware uses a plug-in wireless interface card
(as many current APs do) it may seem a natural thing to do.
However, I'd be unhappy to see any changes that REQUIRED the AP to have
two MAC addresses. So I'd much prefer it if Bernard's description
didn't distinguish between the "WM MAC" and the "DS MAC".
######################################################
4. How do PAE logical ports created via preauthentication get removed if
the
station never roams to the access point? A station preauthenticates
to
the
target AP, and a logical PAE port is created (resources are used on
the
AP).
The station then fails to roam to the target AP. Will there be a
lifetime
associated with a logical PAE port?
######################################################
[Mike Moreton] This is really the same problem that APs deal with all
the time, in that 802.11 STAs do not normally announce their departure.
Whether the authentication was carried out over the DS or the wireless
medium doesn't really make any difference.
######################################################
5. Is there a contingency if a station roams too quickly? It begins the
preauthentication process through the current AP but arrives at the
target
AP before the preauthentication completes. Should the target AP try
to pick up the preauthentication it began on its DS port over the WM
port?
Or should it just do a full reauthentication of the station?
######################################################
[Mike Moreton] In the diagram I drew above, it's quite possible that the
802.1X authenticator wouldn't have a clue where the STA actually is. If
half-way through an authentication over the DS the STA MAC associated
with the AP, the frames would just get forwarded that way instead.
Note that that means frames can get reordered relative to each other.
If the protocol in use is a ping-pong protocol then that's not a
problem. I'm not sure if there are any 802.1X protocols that aren't
ping-pong based.
######################################################
6. In section 2, second paragraph, last sentence:
"Since the STA is in State 3 (authenticated and associated) with
respect
to the current AP, and since the frame has the 'From DS" FC bit set to
FALSE
and the 'To DS' FC bit set to TRUE, and the destination unicast address
does
not correspond to a STA associated with the WM port of the current AP,
the
frame is forwarded by the Relay Entity to the DS port of the current AP
and
transmitted on the DS."
The statement 'the destination unicast address does not correspond
to a
STA
associated with the WM port of the current AP' opens a potential
security
risk.
Namely, what if 'the destination unicast address *does* correspond to
a
STA'
because a rogue has altered their station so that it is spoofing the MAC
of
the
'target AP'. Won't the current AP deliver all roaming stations EAPOL
packets
to this rogue station?
######################################################
[Mike Moreton] Isn't this just a DOS attack, given that the
authentication frames are already carried in the clear for the non
pre-authentication case? 802.11 already has so many DOS attacks, that
one more isn't going to make any difference.
######################################################
Thanks,
Jim B.
-----Original Message-----
From: owner-stds-802-linksec@majordomo.ieee.org
[mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Bernard
Aboba
Sent: Thursday, July 24, 2003 6:21 PM
To: stds-802-1@ieee.org; stds-802-linksec@ieee.org
Subject: [LinkSec] 802.11 architecture and pre-auth paper
Here is the white paper requested by IEEE 802.1 in order to clarify the
802.11 architecture so as to allow a more detailed understanding
of pre-auth (and VLANs). Comments welcome.
http://www.drizzle.com/~aboba/IEEE/preauth.doc
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
http://join.msn.com/?page=features/virus