| Re: Clarification of Issue 43: IEEE 802.11i Considerations | <– Date –> <– Thread –> |
From: Bob O'Hara (boohara) (boohara cisco.com)
|
|
| Date: Mon, 19 Jun 2006 20:14:18 -0700 (PDT) | |
|
This can be done with the current messages. It is
already being done in shipping products using the LWAPP protocol, from which
these messages were derived.
-Bob From: Saravanan Govindan [mailto:Saravanan.Govindan [at] sg.panasonic.com] Sent: Monday, June 19, 2006 6:37 PM To: Bob O'Hara (boohara); capwap Subject: RE: [Capwap] Clarification of Issue 43: IEEE 802.11i Considerations Consider the 4-way handshake in
architecture designs where the WTP maintains the Key-RSC and the AC constructs
EAPOL messages (this is one of the major designs brought out in the Architecture
Taxonomy). Now, to construct Message 3 of the 4-way handshake, the AC computes
the Key-MIC based on the prevailing Key-RSC. Since the Key-RSC is maintained by
the WTP, there needs to be some way to transfer this information to the AC.
I am open to a different way of
doing this from what I’ve suggested earlier – using of separate Key
Configuration message. My concern is only to see that this can be accomplished
in the CAPWAP protocol. Saravanan From: Bob
O'Hara (boohara) [mailto:boohara [at] cisco.com] I believe that Mike is
correct. There is no need to transfer the sequence counter from the WTP to
the AC, if the AC is where the EAPOL messages are constructed and the WTP is
where the sequence counters are maintained. A careful read of 802.11i
on the use of that field will make this clear. -Bob From:
Hi Mike,
There are a number of designs for
IEEE 802.11i. And I believe the description you noted below is one of them. In
other designs, the sequence counter is maintained at the point where encryption
is performed. From my understanding of the update
you mention to Add WLAN, the assumption seems to be the AC manages the transmit
sequence counter. So by using the updated Add WLAN, the AC informs the WTP about
the prevailing sequence counter value. Have I understood this right? I’d appreciate if you could post the
text relating to the update you mention for Add WLAN. This can help better
understand how the update address both the designs.
Cheers, Saravanan From: Michael
Montemurro [mailto:montemurro.michael [at] gmail.com] Saravanan, I have looked through IEEE 802.11i as well as talked
with others who had implemented IEEE 802.11i. The treatment of the KeyRSC
setting is not explained as well as it could be in the IEEE 802.11i draft. In
many implementations, the Authenticator sets the transmit sequence counter with
the new GTK and passes them both down to the MAC. The Authenticator then
transmits this information to the STA as part of the GTK1 EAPoL message. Both
the STA and the WTP will then begin using the new TSC and the group key to
encrypt broadcast/multicast traffic. To address this in CAPWAP I have updated the AddWLAN
message to include the transmit sequence counter for the GTK. That should
address any issues with counters and key
states. Cheers, Mike
On 6/7/06, Hi Mike,
Following from my earlier
note, this is the suggestion for handling KeyRSC maintained in a WTP.
The suggestion is to
include a new IEEE 802.11 specific CAPWAP control messages called "IEEE 802.11
Key Configuration". Following from CAPWAP
Specifications-01; CAPWAP Control
Message
Message Type
Value IEEE 802.11 Key
Configuration
3398914 IEEE 802.11 Key
Configuration Response 3398915 The suggested text
follows; [START OF SUGGESTED
TEXT] 11.7.3. IEEE 802.11 Key
Configuration The IEEE 802.11 Key
Configuration CAPWAP message is used in WTP designs in which IEEE 802.11i
authenticator functions are performed by the AC and IEEE 802.11i cryptographic
functions (encryption/decryption) are performed by the WTPs.
This CAPWAP message is
sent from the AC to the WTP. It must contain either of the following 2 message
elements. 11.7.3.1 IEEE
802.11 4-way Handshake The IEEE 802.11 4-way
Handshake message element is sent by the AC to the WTP during the 4-way
handshake. It contains Message-3 of the 4-way handshake with unassigned values
as the AC is unaware of the prevailing KeyRSC sequence counter maintained by the
WTP. Message-1, Message-2 and
Message-4 of the 4-way handshake are transported within CAPWAP data packets
between AC and WTP. The IEEE 802.11 4-way
Handshake message element contains the following
values:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GTK-Flag |
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Encryption-Data
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
EAPoL-Frame
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GTK-Flag: An 8-bit flag
that determines the type of KeyMIC calculation
0 – New GTK, KeyMIC is calculated with KeyRSC = 0
1 – Existing GTK, KeyMIC is calculated with prevailing KeyRSC
value Encryption-Data: Contains
PTK and/or GTK EAPoL-Frame: Contains
Message-3 of 4-way handshake with unassigned fields Upon receipt of the Key
Configuration message from the AC, the WTP performs the following
operations:
i.
Assigns the corresponding
value to the KeyRSC field of the EAPoL-Frame ii.
Calculates KeyMIC with
Encrytion-Data and KeyRSC iii.
Updates Message-3 of
4-way handshake iv.
Continues regular 4-way
handshake with wireless terminals 11.7.3.2 IEEE
802.11 Group Key Handshake The IEEE 802.11 Group Key
Handshake message element is sent by the AC to the WTP during the group key
handshake. It contains Message-1 of the group key handshake with unassigned
values as the AC is unaware of the prevailing KeyRSC sequence counter maintained
by the WTP. Message-2 of the group
key handshake is transported within a CAPWAP data packet between AC and WTP.
The IEEE 802.11 Group Key
Handshake message element contains the following
values:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GTK-Flag |
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Encryption-Data
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
EAPoL-Frame
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GTK-Flag: An 8-bit flag
that determines the type of KeyMIC calculation
0 – New GTK, KeyMIC is calculated with KeyRSC = 0
1 – Existing GTK, KeyMIC is calculated with prevailing KeyRSC
value Encryption-Data: Contains
PTK and/or GTK EAPoL-Frame: Contains
Message-1 of group key handshake with unassigned
fields Upon receipt of the Key
Configuration message from AC, the WTP performs the following
operations:
i.
Assigns the corresponding
value to the KeyRSC field of the EAPoL-Frame ii.
Calculates KeyMIC with
Encrytion-Data and KeyRSC iii.
Updates Message-1 of
group key handshake iv.
Continues regular group
handshake with wireless terminals 11.7.4
IEEE 802.11 Key Configuration Response The IEEE 802.11 Key
Configuration Response CAPWAP message is sent by the WTP to the AC as an
acknowledgement of the receipt of an IEEE 802.11 Key Configuration Request.
[END OF SUGGESTED
TEXT]
|
- Re: Clarification of Issue 43: IEEE 802.11i Considerations, (continued)
- Re: Clarification of Issue 43: IEEE 802.11i Considerations Michael Montemurro, June 16 2006
- Re: Clarification of Issue 43: IEEE 802.11i Considerations Saravanan Govindan, June 18 2006
- Re: Clarification of Issue 43: IEEE 802.11i Considerations Bob O'Hara (boohara), June 19 2006
- Re: Clarification of Issue 43: IEEE 802.11i Considerations Saravanan Govindan, June 19 2006
- Re: Clarification of Issue 43: IEEE 802.11i Considerations Bob O'Hara (boohara), June 19 2006
-
Re: Clarification of Issue 43: IEEE 802.11i Considerations Saravanan Govindan, June 19 2006
- Re: Clarification of Issue 43: IEEE 802.11i Considerations Michael Montemurro, June 20 2006
-
Re: Clarification of Issue 43: IEEE 802.11i Considerations Saravanan Govindan, July 2 2006
- Re: Clarification of Issue 43: IEEE 802.11i Considerations Michael Montemurro, July 4 2006
Results generated by Tiger Technologies using MHonArc.