| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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 _______________________________________________________________________________ |