Created on 2008-10-10.15:24:34 by pcalhoun, last changed 2008-10-10.15:43:23 by pcalhoun.
|
| msg627 (view) |
Author: pcalhoun |
Date: 2008-10-10.15:43:23 |
|
Well... You've unfortunately (or fortunately) found another problem, and
that's not just that the figures are incorrect, but the way they represented
the message element was inconsistent with the current draft.
I've taken the liberty to clean up the figure, and the associated text that
describes what needs to be included in each message.
<proposed text>
2.2.1. Split MAC
[...]
Client WTP AC
Beacon
<-----------------------------
Probe Request
----------------------------( - )------------------------->
Probe Response
<-----------------------------
802.11 AUTH/Association
<--------------------------------------------------------->
Station Configuration Request
[Add Station (Station MAC
Address), IEEE 802.11 Add
Station (WLAN ID), IEEE
802.11 Session Key(Flag=A)]
<-------------------------->
802.1X Authentication & 802.11 Key Exchange
<--------------------------------------------------------->
Station Configuration Request
[Add Station(Station MAC
Address), IEEE 802.11 Add
Station (WLAN ID), IEEE 802.11
Station Session Key(Flag=C)]
<-------------------------->
802.11 Action Frames
<--------------------------------------------------------->
802.11 DATA (1)
<---------------------------( - )------------------------->
Figure 2: Split MAC Message Flow [...]
o Once the association is complete, the AC transmits a Station
Configuration Request message, which includes an Add Station
message element, to the WTP (see Section 4.6.8 in
[I-D.ietf-capwap-protocol-specification]). In the above example,
the WLAN was configured for IEEE 802.1X, and therefore the IEEE
802.11 Station Session Key is included with the flag field's 'A'
bit set.
[...]
o If the WTP is providing encryption/decryption services, once the
client has completed the IEEE 802.11 key exchange, the AC
transmits another Station Configuration Request message, which
includes:
- An Add Station message element.
- An IEEE 802.11 Add Station message element, which includes the
WLAN Identifier the station has associated with.
- An IEEE 802.11 Station Session Key message element, which
includes the pairwise encryption key.
- An IEEE 802.11 Information Element message element which
includes the obust Security Network Information Element (RSNIE)
to the WTP, stating the security policy to enforce for the
client (in this case AES-CCMP).
o If the WTP is providing encryption/decryption services, once the
client has completed the IEEE 802.11 key exchange, the AC
transmits another Station Configuration Request message, which
includes:
- An Add Station message element.
- An IEEE 802.11 Add Station message element, which includes the
WLAN Identifier the station has associated with.
- An IEEE 802.11 Station Session Key message element, which
includes the pairwise encryption key.
- An IEEE 802.11 Information Element message element which
includes the Robust Security Network Information Element
(RSNIE) to the WTP, stating the security policy to enforce for
the client (in this case AES-CCMP).
o If the AC is providing encryption/decryption services, once the
client has completed the IEEE 802.11 key exchange, the AC
transmits another Station Configuration Request message, which
includes:
- An Add Station message element.
- An IEEE 802.11 Add Station message element, which includes the
WLAN Identifier the station has associated with.
- An IEEE 802.11 Station Session Key message element with the
flag fields' 'C' bit enabled (indicating that the AC will
provide crypto services).
[...]
2.2.2. Local MAC
[...]
Client WTP AC
Beacon
<-----------------------------
Probe
<---------------------------->
802.11 AUTH
<-----------------------------
802.11 Association
<---------------------------( - )------------------------->
Station Configuration Request
[Add Station (Station MAC
Address), IEEE 802.11 Add
Station (WLAN ID), IEEE
802.11 Session Key(Flag=A)]
<-------------------------->
802.1X Authentication & 802.11 Key Exchange
<--------------------------------------------------------->
Station Configuration Request
[Add Station(Station MAC
Address), IEEE 802.11 Add
Station (WLAN ID), IEEE 802.11
Station session Key (Key=x),
IEEE 802.11 Information
Element(RSNIE(Pairwise
Cipher=CCMP))]
<-------------------------->
802.11 Action Frames
<--------------------------------------------------------->
802.11 DATA
<----------------------------->
Figure 5: Local MAC Message Flow [...]
o Once the association is complete, the AC transmits a Station
Configuration Request message, which includes the Add Station
message element, to the WTP (see Section 4.6.8 in
[I-D.ietf-capwap-protocol-specification]). In the above example,
the WLAN was configured for IEEE 802.1X, and therefore the IEEE
802.11 Station Session Key is included with the flag field's 'A'
bit set.
[...]
o The AC transmits another Station Configuration Request message,
which includes:
- An Add Station message element, which MAY include a Virtual LAN
(VLAN) [IEEE.802-1Q.2005] name, which when present is used by
the WTP to identify the VLAN on which the user's data frames
are to be bridged.
- An IEEE 802.11 Add Station message element, which includes the
WLAN Identifier the station has associated with
- An IEEE 802.11 Station Session Key message element, which
includes the pairwise encryption key.
- An IEEE 802.11 Information Element message element which
includes the RSNIE to the WTP, stating the security policy to
enforce for the client (in this case AES-CCMP).
2.3. Roaming Behavior
[...]
Figure 6 shows an example of a currently associated station moving
from its "Old WTP" to a "New WTP". The figure is valid for multiple
different security policies, including IEEE 802.1X and Wireless
Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA].
In the event that key caching was employed, the 802.1X Authentication
step would be eliminated. Note that the example represents one where
crypto services are provided by the WTP, so in a case where the AC
provided this function the last Station Configuration Request would
be different.
Client Old WTP New WTP AC
Association Request/Response
<--------------------------------------( - )-------------->
Station Configuration Request
[Add Station (Station MAC
Address), IEEE 802.11 Add
Station (WLAN ID), IEEE
802.11 Session Key(Flag=A)]
<---------------->
802.1X Authentication (if no key cache entry exists)
<--------------------------------------( - )-------------->
802.11 4-way Key Exchange
<--------------------------------------( - )-------------->
Station Configuration Request
[Delete Station]
<---------------------------------->
Station Configuration Request
[Add Station(Station MAC
Address), IEEE 802.11 Add
Station (WLAN ID), IEEE 802.11
Station session Key (Key=x),
IEEE 802.11 Information
Element(RSNIE(Pairwise
Cipher=CCMP))]
<---------------->
Figure 6: Client Roaming Example
</proposed text>
|
| msg626 (view) |
Author: pcalhoun |
Date: 2008-10-10.15:42:58 |
|
Figures 2, 5, and 6 also mention "PTK", and should be changed to either "TK"
or just "key" (since these figures are just illustrative examples, they don't
really have to contain all the details)
|
| msg625 (view) |
Author: pcalhoun |
Date: 2008-10-10.15:42:18 |
|
Looking into this issue deeper, we agreed that we do not need to include the
KEK and KCK. In fact, the spec should have said TK, not PTK. That said, I
believe that in addition to that change, we could improve the spec to ensure
interoperability. I would therefore recommend the following changes:
<proposed text>
6.1. IEEE 802.11 Add WLAN
[...]
Key: A Session Key, whose length is known via the key length field,
used to provide data privacy. For encryption schemes that employ
a separate encryption key for unicast and multicast traffic, the
key included here only applies to multicast frames, and the cipher
suite is specified in an accompanied RSN Information Element. In
these scenarios, the key and cipher information is communicated
via the Add Station message element, see Section 4.6.8 in
[I-D.ietf-capwap-protocol-specification] and the IEEE 802.11
Station Session Key message element, see Section 6.15. When used
with WEP, the key field includes the broadcast key. When used
with CCMP, the Key field includes the 128-bit Group Temporal Key.
When used with TKIP, the Key field includes the 256-bit Group
Temporal Key (which consists of a 128-bit key used as input for
TKIP key mixing, and two 64-bit keys used for Michael).
6.15. IEEE 802.11 Station Session Key
[...]
Key: The pairwise key the WTP is to use when encrypting traffic to/
from the station. The format of the keys differ based on the
crypto algorithm used. For unicast WEP keys, the Key field
consists of the actual unicast encryption key (note, this is used
when WEP is used in conjunction with 802.1X, and therefore a
unicast encryption key exists). When used with CCMP, the Key
field includes the 128-bit Temporal Key. When used with TKIP, the
Key field includes the 256-bit Temporal Key (which consists of a
128-bit key used as input for TKIP key mixing, and two 64-bit keys
used for Michael).
6.21. IEEE 802.11 Update WLAN
[...]
Key: A Session Key, whose length is known via the key length field,
used to provide data privacy. For static WEP keys, which is true
when the 'Key Status' bit is set to one, this key is used for both
unicast and multicast traffic. For encryption schemes that employ
a separate encryption key for unicast and multicast traffic, the
key included here only applies to multicast data, and the cipher
suite is specified in an accompanied RSN Information Element. In
these scenarios, the key, and cipher information, is communicated
via the Add Station message element, see Section 4.6.8 in
[I-D.ietf-capwap-protocol-specification]. When used with WEP, the
key field includes the broadcast key. When used with CCMP, the
Key field includes the 128-bit Group Temporal Key. When used with
TKIP, the Key field includes the 256-bit Group Temporal Key (which
consists of a 128-bit key used as input for TKIP key mixing, and
two 64-bit keys used for Michael).
</proposed text>
|
| msg624 (view) |
Author: pcalhoun |
Date: 2008-10-10.15:24:34 |
|
When TKIP or CCMP encryption is used, and WTP does the encryption, it
obviously needs the key (TK) for TKIP or CCMP. However, currently the
AC also sends two other keys, the EAPOL Key Confirmation Key (KCK) and
Key Encryption Key (KEK), to the WTP, even though the WTP does not
seem to need these keys for anything. The principle of least
privilege would suggest that the AC shouldn't send these keys. Why
not send just the needed keys? Or does the WTP need the KCK/KEK
for something?
|
|
| Date |
User |
Action |
Args |
| 2008-10-10 15:43:23 | pcalhoun | set | messages:
+ msg627 |
| 2008-10-10 15:42:58 | pcalhoun | set | messages:
+ msg626 |
| 2008-10-10 15:42:18 | pcalhoun | set | status: unread -> chatting
messages:
+ msg625 |
| 2008-10-10 15:24:34 | pcalhoun | create | |
|