There was a discussion today under CIDs 426/428/429 regarding
the Supplicant state variable holding the replay counter for EAPOL-Key
PDUs. There are some hints about such a variable, though the wording
is vague, using words like "local" and "last-seen" and "update".
My proposal was to be explicit in all cases where the Supplicant
has to decide whether to discard an EAPOL-Key PDU from the Authenticator,
that the Supplicant checks the KRC is greater than in any previous
valid PDU. In this way you don't have to have discussion of such a
variable.
There was a concern that this was losing a requirement, so I'd like
to present the proposal on the reflector to see if such loss of
requirement can be identified.
The proposal is (I highlight deletions and additions of relevant
"shall"s and "update"s and "local"s etc.):
d) Key Replay Counter. This field is represented as an unsigned integer, and is initialized to 0 when the PMK is established. The Supplicant shall use the key replay counter in the received EAPOL-Key PDU when
responding to an EAPOL-Key PDU. It carries a sequence number that the protocol uses to detect replayed EAPOL-Key PDUs.
The Supplicant and Authenticator shall track the key replay counter per security association. The key replay counter shall be initialized to 0 on (re)association. The Authenticator shall increment the key replay
counter on each successive EAPOL-Key PDU.
When replying to a message an EAPOL-Key PDU from the Authenticator, the Supplicant shall use the Key Replay Counter field value from the last valid EAPOL-Key PDU received from the Authenticator.
The Authenticator shall use the key replay counter to identify invalid messages silently discard EAPOL-Key PDUs with a Key Replay Counter field value that is not the same as in an outstanding EAPOL-Key PDU. The Supplicant
shall also use the key replay counter and ignore silently discard EAPOL-Key PDUs with a Key Replay Counter field value smaller than or equal to any
previously received in a valid message an EAPOL-Key PDU with a MIC that was. The
local key replay counter variable shall not be
updated until after the EAPOL-Key PDU MIC is checked and is found to be valid,
or for which AEAD decryption steps succeeded.
NOTE 8—In other words, the Supplicant does not
update take account of the key replay counter for message 1 in the 4-way handshake, as it includes no MIC and is not subject to AEAD. This implies the Supplicant needs to allow for retransmission
of message 1 when checking for the key replay counter of message 3.
…
On reception of message 1 [of 4WH],
the Supplicant determines whether the Key Replay Counter field value has been used before with the current PMKSA checks that the key replay counter is greater than that received in all prior EAPOL-Key
PDUs with a MIC that was found to be valid, or for which AEAD decryption steps succeeded. If the Key Replay Counter field value is less than or equal to the
current local value not, the Supplicant
shall silently discards the message
…
On reception of message 3 [of 4WH],
the Supplicant shall silently discard the message if the Key Replay Counter field value has already been used or if checks that the key replay counter is greater than that received in all prior
EAPOL-Key PDUs with a MIC that was found to be valid, or for which AEAD decryption steps succeeded, and that the ANonce value in message 3
differs fromis the same as the ANonce value in message 1. If not, the Supplicant shall silently discard the message.
…
d)
Update the
last-seen value of the Key Replay Counter field.
…
On reception of message 1 [of GKH], the Supplicant:
a) Verifies that the Key Replay Counter field value has not yet been seen before, i.e., its value is strictly larger than that in any other EAPOL-Key PDU
received thus far during this session the key replay counter is greater than that received in all prior EAPOL-Key PDUs with a MIC that was found to be valid, or for which AEAD decryption steps succeeded. If not, the Supplicant shall silently
discard the message.
b) If dot11RSNAOperatingChannelValidationActivated is true and Authenticator RSNE indicates OCVC,
the Supplicant shall silently discard message 1 if any of the following are true:
— OCI KDE is missing in the message
— Channel information in the OCI KDE does not match current operating channel parameters (see 12.2.10 (Requirements for Operating Channel Validation))
c) Verifies that the MIC is valid, i.e., it uses the PTK-KCK that is part of the PTK to verify that there is no data integrity error, or that the AEAD decryption steps succeed. If not, the Supplicant shall
silently discard the message.
Thanks,
Mark
--
Mark RISON, Standards Architect, WLAN English/Esperanto/Français
Samsung Cambridge Solution Centre Tel: +44 1223 434600
1 Cambridge Square, Cambridge CB4 0AE 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