Forum

How do stations that want to have a direct link between them through a stakey handshake negotiate the cipher suite which they will use. Because there is no field in the eapol-key packets to do this the only option is to use the group cipher suite used in the BSS because the pairwise cipher suites selected by the two stations could be different.
What do you think ?

Sorry now that i am sober and have read the amendment.

The originating STA requests the STAkey by sending an EAPOL-key frame to the AP, with the KeyType set to 0, Request bit set to 1, and with the MAC address KDE in the key Data field. The cipher used with STAkey shall be the cipher indicated in the Key Descriptor Version subfield in the EAPOL-key frame.

not sure if this helps or hurts

Rico

Maybe I did not explain myself as I should have.
If you go through 802.11i it is clear that the Stakey is chosen by the AP and the AP distributes it to both of the stations involved. But in this comunication between the two stations and the AP there is no message with the purpose of negotiating the cipher suite the two stations should use to exchange traffic. For this reason I think that they will default to using the group wise cipher suite that MUST be supported by all stations in the BSS.

I probably commited the faux pas of posting by reposting above.
What i added above was from 802.11i amendment. Please let me know if you have contention with this quote applying to the solution, or further insight on how this process takes place.

Regards,
Rico

Hi Rico,
the Key Descriptor Version in any EAPOL-frame specifies both the encryption method used to protect the EAPOL Key Data field and the algorithm used to calculate the Hashed Message Authentication Code ( the MIC field in the EAPOL-frame ). IT DOES NOT SPECIFY THE ENCRYPTION METHOD USED TO PROTECT ANY DATA FRAMES EXCHANGED BETWEEN THE TWO PARTIES BECAUSE THAT IS NEGOTIATED THROUGH RSN INFORMATION ELEMENTS.
Now let's go back to the STAkey exchange. In Message 1, when the AP sends an EAPOL-frame to the peer station with the Initiator MAC address and the key used for encryption between the initiating station and the peer station, the Key Descriptor Version field basically says that the MIC in that EAPOL-frame has been calculated with HMAC-MD5 ( for example ) and that the Key Data field ( which contains the Init station MAC address and the key ) has been encrypted with RC4 ( for example ).
Now lets suppose you have two stations A and B that after associating to the AP have the following config:
A: unicast traffic --> TKIP / broadcast --> TKIP
B: unicast traffic --> CCMP / broadcast --> TKIP
The only way these stations can communicate directly between them is by using TKIP which must be supported by all stations associated to the same AP. So, why do you need to negotiate the cipher suite used for direct links between two Stations when you already know that they all support TKIP ( or in general they all support the same group cipher suite ).
I know that my explanation has been a bit twisted but I hope you got the point.

Hi Rico,
I have just finished searching through the net for a thorough explanation about stakey and Direct Link Setup protocol. I have not found much but apparently Stakey handshake is not the best thing that has ever been invented. A few web sites say that stakey is broken and, as far as I know, has never been implemented. There might be a new protocol which is supposed to replace stakey called peerkey handshake.
check out this link.

http://www.ieee802.org/11/DocFiles/05/11-05-1258-00-000m-normative-text-peerkey-handshake-proposal.doc