| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Ah, and one more thing: As far as I can see, the last paragraph of 11.11.2.3 has nothing to do with "Key derivation with FILS authentication" and hence should be moved elsewhere (don't know where). Furthermore, as I understand it, the only AKM selectors used by FILS are AKM is 00-0F-AC:<ANA-1> and 00-0F-AC:<ANA-2>, so the "If the negotiated AKM is 00-0F-AC:<ANA-1> or 00-0F-AC:<ANA-2>," should be deleted. (The text I am referring to is: If the negotiated AKM is 00-0F-AC:<ANA-1> or 00-0F-AC:<ANA-2>, FILS requires an additional element: a 13 octet AEAD counter to be part of the newly created PTKSA. The STA shall set the AEAD counter to 13 octets of zero and the AP shall set the first octet to the value 128 and the remaining octets to zero (i.e. the first bit of the AEAD counter is 1 and the rest of the bits in the counter are 0). To allow for proper processing, each side shall include the AEAD counter of the other as a peer's AEAD counter (see 11.11.2.5 (AEAD cipher mode)). AEAD counters are processed per 11.11.2.5 (AEAD cipiher mode for FILS). CID 4394 points out the grammar is poor, but then only fixes a minor deficiency. My attempt at rewording this would be something like: If FILS authentication is used, the PTKSA shall include two 13-octet AEAD counters, one for the local STA and the other for the peer STA. On PTKSA creation, the non-AP STA shall set the AEAD counter for the local STA to 13 octets of zero and the AP shall set the first octet of the AEAD counter for the local STA to the value 128 and the remaining octets to zero (i.e. the first bit of the AEAD counter is 1 and the other bits are 0); in both cases the AEAD counter for the peer STA shall be set to zero. See 11.11.2.5 (AEAD cipiher mode for FILS). In turn, and if my understanding that there are in fact two AEAD counters is correct, I think some tweaks are needed elsewhere (these may already have been caught by a commenter): 11.6.2 EAPOL-Key frames When the AKM is 00-0F-AC-<ANA-1> or 00-0F-AC-<ANA-2> the current value of the AEAD counter for the local STA from the PTKSA is copied to the left-most 13 octets of this field and the right-most 3 octets of this field are set to zero. 11.11.2.4.1 Association Request for FILS key confirmation The plaintext passed to the AEAD encryption algorithm is the data that would follow the FILS session element in an unencrypted frame. If the AEAD cipher requires a unique counter, the current value of the AEAD counter for the local STA from the PTKSA shall be passed to the AEAD encryption algorithm. The ciphertext output by the AEAD encryption operation becomes the data that follows the FILS session element in the encrypted and authenticated 802.11 Association Request frame. The resulting Association Request frame shall be transmitted to the AP. The AP decrypts and verifies the received Association Request frame with KEK. The AAD is reconstructed as defined in this section above and is passed 11.11.2.4.2 Association response for FILS key confirmation The plaintext passed to the AEAD encryption algorithm is the data that would follow the FILS session element in an unencrypted frame. If the AEAD cipher requires a unique counter, the current value of the AEAD counter for the local STA from the PTKSA shall passed to the AEAD encryption algorithm. The ciphertext output by the AEAD encryption operation becomes the data that follows the FILS session element in the encrypted and authenticated Association Response frame. The resulting Association Response frame shall be transmitted to the STA. The STA decrypts and verifies the received Association Response frame with KEK. The AAD is reconstructed as defined in this section above and is passed, with the ciphertext of the received frame to the AEAD decrypt operation. If the AEAD cipher mode requires an AEAD counter, the STA implicitly uses the AP's initial AEAD counter of the value 128 followed by 12 octets of zero to decrypt and verify the received frame. 11.11.2.5 AEAD cipiher mode for FILS When the AEAD cipher mode used is CCM, the nonce, N, shall be set to the AEAD counter for the local or peer STA (as defined in the subclause invoking the AEAD algorithm) — M=16; — L=2 Each successive invocation of the encryption operation of CCM shall increment the AEAD counter by one (1). Processing of a received EAPOL-Key frame shall include verification that the received frame contains a counter that is strictly greater than the counter in the last received frame, and shall update But then this leads to further issues: - Why the stuff in 11.11.2.4.1/2 about the implied AEAD counter? Shouldn't it be using the actual counter, i.e. the peer STA counter from the PTKSA? Isn't the point of the AEAD counter to protect against replay attacks? - I don't understand "the data that would follow the FILS session element in an unencrypted frame". That data would be some other element (or perhaps the FCS, if there are no more elements). - Similarly, I'm having trouble with "The ciphertext output by the AEAD encryption operation becomes the data that follows the FILS session element in the encrypted and authenticated 802.11 Association Request frame." Does this mean that the Association Request MMPDU is encrypted, then the AEAD cipher output is spliced into this at the octet position after the FILS session element? This sounds a bit grotesque. - So Association Request/Response are encrypted in FILS? This would appear to contradict 8.2.4.1.9 of the baseline, which states that "The Protected Frame field is set to 1 if the Frame Body field contains information that has been processed by a cryptographic encapsulation algorithm. The Protected Frame field is set to 1 only within Data frames and within Management frames of subtype Authentication, and individually addressed robust Management frames. The Protected Frame field is set to 0 in all other frames, except in Control frames of subtype Control Frame Extension where this field is reserved.". - I don't understand "If the AEAD cipher mode requires an AEAD counter,". As far as I can determine (from 11.11.2.5), there's only one AEAD cipher mode, namely CCM, and it requires an AEAD counter. - 11.11.2.5 only mentions encryption -- what about decryption, as referred to in 11.11.2.4.1/2? - "cipiher" - "The resulting Association Request/Response shall be transmitted" -- well, duh! I'm going to stop picking at the scab for now. ) 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 From: *** 802.11 TGai - Fast Initial Link Set-Up *** [mailto:STDS-802-11-TGAI@xxxxxxxx] On Behalf Of Mark Rison I have timed out and uploaded 14/0692r2. If you run out of things to talk about tomorrow, and security people are in attendance, then feel free to talk about this (I may not be able to attend). It's probably best to view the "Final" (i.e. changes not shown) version first, and if this seems right, then go through the change tracking and the comments. 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 From: *** 802.11 TGai - Fast Initial Link Set-Up *** [mailto:STDS-802-11-TGAI@xxxxxxxx] On Behalf Of Mark Rison In the absence of specific information to the contrary, I am going to assume that 14/0692r1 was in error when it removed the nonces from the PTKSA KDF, and that what it should have done was (in addition to swapping the first and third arguments) to *add* the STA and AP addresses to the context, i.e. end up with: KCK || KEK || TK = KDF-X (PMK, “FILS PTKSA Derivation”, SPA || AA || SNonce || ANonce) Unfortunately, I have yet another question! 11.6.1.3 of the baseline (11mc/D2.0) says that: The PTK shall be derived from the PMK by PTK <- PRF-X (PMK, “Pairwise key expansion”, Min (AA, SPA) || Max (AA, SPA) || Min (ANonce, SNonce) || Max (ANonce, SNonce)) (Why) are min/max not needed for PTKSA key derivation for FILS? (And doesn't "Except when preauthentication is used, the pairwise key hierarchy utilizes PRF-384 or PRF-512 to derive session-specific keys from a PMK" at the start of 11.6.1.3 need "or FILS authentication" added?) 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 From: *** 802.11 TGai - Fast Initial Link Set-Up *** [mailto:STDS-802-11-TGAI@xxxxxxxx] On Behalf Of Mark Rison I have an additional question: What does "Regardless of whether PMKSA caching is used or not, a PTKSA shall be generated with each FILS authentication exchange" mean? Now (i.e. given the changes in 14/0692r1) the FILS PTK key derivation is a factor of the PMK and of constants (a constant string, and the MAC addresses of the AP and STA). So if PMKSA caching is used, and hence the PMK does not change, won't the PTKSA be the same as for the previous FILS authentication exchange? 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 From: *** 802.11 TGai - Fast Initial Link Set-Up *** [mailto:STDS-802-11-TGAI@xxxxxxxx] On Behalf Of Mark Rison My question to the TGai regulars is: Is the following the context is: — rMSK if shared key authentication is being used without PFS — rMSK || ss if shared key authentication is being used with PFS — ss if public key authentication is being used a) complete (i.e. there are no cases other than 1) shared w/o PFS, 2) shared w/ PFS and 3) public) b) correct (i.e. the three cases have the right context for the KDF) ? 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 From: Mark Rison [mailto:m.rison@xxxxxxxxxxx] Here is text which may address the syntactical issue in 14/0692r0. As is my wont, I've made various other editorial changes along the way. I have made my best efforts to keep my understanding of the desired technical outcome but I cannot make any strong promises. 11.11.2.3.1 PMK key derivation with FILS authentication For PMKSA generation, the inputs to the KDF are: — the two nonces, NSTA and NAP — a constant label — the EAP-RP secret result, rMSK, if shared key authentication is being used — the Diffie-Hellman shared secret, ss, if PFS is being used or public key authentication is being used The KDF produces a PMK and a PMKID which is used to uniquely identify the PMKSA. The length of the PMK shall be 256 bits, and the length of the PMKID shall be 128 bits: PMKID || PMK = KDF-384(NSTA || NAP, "FILS PMKSA Derivation", context) where the context is: — rMSK if shared key authentication is being used without PFS — rMSK || ss if shared key authentication is being used with PFS — ss if public key authentication is being used Upon completion of PMK generation, ss and rMSK, if derived, shall be irretrievably destroyed. Note that I have used || for concatenation rather than |, since that seems to be the baseline usage. This should, if adopted, be done in 11.11.2.3.2 too. 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 From: *** 802.11 TGai - Fast Initial Link Set-Up *** [mailto:STDS-802-11-TGAI@xxxxxxxx] On Behalf Of Dan Harkins Hello, I have generated resolutions for the CIDs from LB201 related to the key derivation section 11.11.2.3. Please take a look at document 11-14/0692r0 for the submission and text changes being proposed and document 11-14/0694r0 for the proposed resolution spreadsheet changes. Both are on mentor. regards, Dan. _______________________________________________________________________________ IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand. SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button. Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________ IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this CLOSED reflector. We use this valuable tool to communicate on the issues at hand. SELF SERVICE OPTION: Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and then amend your subscription on the form provided. If you require removal from the reflector press the LEAVE button. Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html _______________________________________________________________________________ |