Hello,
This is what I have so far:
|
Identifiers |
Comment |
Proposed change |
|
CID 1273 Jouni MALINEN 12.7.2 3206.27 |
The current shall requirement for the Authenticator to change the GTK based on any authenticated EAPOL-Key Request frame with key type Group might be problematic in cases
where the associated stations/Supplicants cannot be fully trusted. This requirement would allow any Supplicant to force a GTK change at any point in time and arbitrarily frequently. That could result in reduced performance for group-addressed frame delivery
and undesired resource consumption for other associated STAs. The Authenticator should be in control on when the GTK is changed and while the Supplicants could be allowed to request changes, they should not be allowed to force this to happen. The current text
is as follows: "If the EAPOL-Key frame in which the Request bit is 1 has a key type of Group, the Authenticator shall change the GTK, initiate a 4-way handshake with the Supplicant, and then execute the group key handshake to all Supplicants." |
Replace "the Authenticator shall change the GTK" with "the Authenticator may change the GTK". Replace "execute the group key handshake to all Supplicants" with "execute the group key handshake to all Supplicants, if the GTK was changed" |
|
CID 1476 Mark RISON 12.7.2 3206.25 |
"If the EAPOL-Key frame in which the Request bit is 1 has a key type of Group, the Authenticator shall change the GTK, initiate a 4-way handshake with the Supplicant, and then execute the group key handshake to all Supplicants." has many issues |
Change to "If the EAPOL-Key frame in which the Request bit is 1 has a key type of Group, the Authenticator is not currently performing GTK rekeying and the requesting Supplicant
has not recently made such a request, the Authenticator shall generate a new GTK with a new key ID (see 12.7.10 (RSNA Authenticator key management state machine)) and then execute the group key handshake with all Supplicants that are not in WNM sleep mode
to deliver them, except a Supplicant for which it is currently performing PTK rekeying, in which case if it has not yet transmitted message 3 it shall deliver them in that message instead, and if it has already transmitted message 3 it shall perform the group
key handshake after the end of the 4-way handshake." |
|
CID 1848 Mark RISON 12.7.7.1 3226.45 |
"The Supplicant may trigger a group key handshake by sending an EAPOL-Key frame with the Request bit set to 1 and the type of the Group Key bit." -- doesn't say this causes a new GTK (cf. 12.7.2), and an equivalent statement for the 4WH is missing from 12.7.6 |
Change to "The Supplicant may trigger a group key handshake and obtain a new GTK by sending an EAPOL-Key request frame with a key type of Group (see 12.7.2)."
At 3216.41 add "The Authenticator may trigger a 4-way handshake and obtain a new PTK by sending an EAPOL-Key request frame with a key type of Pairwise (see 12.7.2)." |
|
CID 1449 Mark RISON 12.7.2 3206.25 |
"If the EAPOL-Key frame in which the Request bit is 1 has a key type of Group, the Authenticator shall change the GTK, initiate a 4-way handshake with the Supplicant, and then execute the group key handshake to all Supplicants." -- there's no need to execute a GKH if a 4WH has just been executed |
Change to "If the EAPOL-Key frame in which the Request bit is 1 has a key type of Group, the Authenticator shall change the GTK, initiate a 4-way handshake with the requesting Supplicant, and then execute the group key handshake to all other Supplicants." |
|
CID 1450 Mark RISON 12.7.2 3206.25 |
"If the EAPOL-Key frame in which the Request bit is 1 has a key type of Group, the Authenticator shall change the GTK, initiate a 4-way handshake with the Supplicant, and then execute the group key handshake to all Supplicants." is open to abuse |
Change to "If the EAPOL-Key frame in which the Request bit is 1 has a key type of Group, the Authenticator is not currently in the process of handling such a request and the requesting Supplicant has not recently made such a
request, the Authenticator shall change the GTK, initiate a 4-way handshake with the Supplicant, and then execute the group key handshake to all Supplicants." |
|
CID 1451 Mark RISON 12.7.2 3206.25 |
"If the EAPOL-Key frame in which the Request bit is 1 has a key type of Group, the Authenticator shall change the GTK, initiate a 4-way handshake with the Supplicant, and then execute the group key handshake to all Supplicants." -- there's no need to execute a 4WH |
Change to "If the EAPOL-Key frame in which the Request bit is 1 has a key type of Group, the Authenticator shall change the GTK and then execute the group key handshake to all Supplicants." |
|
CID 1452 Mark RISON 12.7.2 3206.25 |
"If the EAPOL-Key frame in which the Request bit is 1 has a key type of Group, the Authenticator shall change the GTK, initiate a 4-way handshake with the Supplicant, and then execute the group key handshake to all Supplicants." -- the GTK isn't changed per se, it's updated |
"If the EAPOL-Key frame in which the Request bit is 1 has a key type of Group, the Authenticator shall generate a new GTK with a new key ID (see 12.7.10 (RSNA Authenticator key management state machine)), initiate
a 4-way handshake with the Supplicant, and then execute the group key handshake to deliver this new GTK to all Supplicants." |
|
CID 1846 Mark RISON 12 3206.24 |
It is not clear whether an EAPOL-Key request (pairwise) necessarily causes the GTK to be changed |
At 3206.28 add "NOTE---The GTK is not necessarily changed in response to an EAPOL-Key request frame that has a key type of Pairwise." |
Discussion:
As these comments indicate, there are various issues with the current specification of EAPOL-Key request frames:
·
A requirement to rekey is open to abuse/misuse
·
There is no point doing a 4WH (see CID 1272, accepted in principle on 2022-03-09)
·
It’s not always clear whether the GTK is actually changed following a GTK rekeying request
·
It’s not made clear that GTK rekeying involves a new key ID
·
The behaviour if PTK or GTK rekeying is currently in progress isn’t clear
·
The behaviour w.r.t. STAs in WNM sleep mode isn’t clear
·
The effect of PTK rekeying on the GTK could be spelt out (viz. that the GTK isn’t changed)
Note that under CID 1571 "EAPOL-Key frame in which the Request bit is 1" becomes just "EAPOL-Key request frame".
Ditto CID 1440 and “EAPOL request message”
Related comments not addressed here: CIDs 1844/1845, 1942, 1944.
Proposed changes:
Change the para at 3206.24 (in 12.7.2 EAPOL-Key frames) as follows, (re)numbering NOTEs as appropriate:
If the Authenticator receives
an EAPOL-Key frame in which the Request bit is 1 haswith a key type of Pairwise and the Authenticator is not currently performing a 4-way handshake with the Supplicant, the Authenticator
shall should perform PTK rekeying by initiatinge a 4-way handshake with the Supplicant.
NOTE 1—The Authenticator might ignore the request if, for example, it has recently performed a 4-way handshake with the Supplicant.
NOTE 2—The GTK is not changed in response to an EAPOL-Key request frame with a key type of Pairwise.
<insert para break>
If the Authenticator receives
thean EAPOL-Key frame in which the Request bit is 1
haswith a key type of Group and the Authenticator is not currently performing GTK rekeying, the Authenticator
shall should perform GTK rekeying as follows:
·
change the generate a new GTK with a new key ID (see 12.7.10 (RSNA Authenticator key management state machine)), initiate a 4-way handshake with the Supplicant, and then
·
executeinitiate
thea group key handshake
towith alleach Supplicants that is not in WNM sleep mode, except a Supplicant with which it is currently performing a 4-way handshake, in which case if it has not yet transmitted message
3 it may deliver the GTK in that message instead, or otherwise it shall initiate the group key handshake after the end of the 4-way handshake.
NOTE 3—The Authenticator might ignore the request if, for example, it has recently performed GTK rekeying (whether on request from the Supplicant or otherwise).
Change the para at 3226.45 (in 12.7.7 Group key handshake; 12.7.7.1 General) as follows, (re)numbering NOTEs as appropriate:
The Supplicant may trigger request a group key handshake to obtain a new GTK by sending an EAPOL-Key
request frame with the Request bit set to 1 and the type of the Group Key bit a key type of Group (see 12.7.2).
NOTE—The Authenticator might ignore this request.
At 3216.47 (in 12.7.6 4-way handshake; 12.7.6.1 General) add a para, (re)numbering NOTEs as appropriate:
The Supplicant may request a 4-way handshake to obtain a new PTK by sending an EAPOL-Key request frame with a key type of Pairwise (see 12.7.2).
NOTE—The Authenticator might ignore this request.
Change 3186.43 (in 12.6.21 RSNA rekeying) as follows:
A sSupplicant may send an EAPOL request message to the
aAuthenticator to request rekeying (see 12.7.2).
NOTE—The Authenticator might ignore this request.
At 1956.53 change “a group rekeying” to “GTK rekeying”.
Proposed resolution:
REVISED
Make the changes shown under “Proposed changes” for CID 1273 et al. in <this document>.
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
Innovation Park, Cambridge CB4 0DS Fax: +44 1223 434601
ROYAUME UNI WWW:
http://www.samsung.com/uk
To unsubscribe from the STDS-802-11-TGM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGM&A=1