On Wed, May 08, 2019 at 09:44:10AM -0700, James Prestwood wrote: > I noticed this comment in the hwsim tests (test_fils.py): > > # FIX: FT-FILS-SHA256 does not currently work for FT protocol due to > not > # fully defined FT Reassociation Request/Response frame MIC use in FTE. > # FT-EAP can be used to work around that in this test case to confirm > the > # FT key hierarchy was properly formed in the previous step. That is an obsolete comment. This IEEE 802.11 standard issue has been addressed in REVmd and the following test case (fils_and_ft_over_air) in the file is actually going through the full test sequence. I just have not yet had a chance to clean up the older fils_and_ft test case to see if it should be removed completely or fixed to use the now functional FT protocol sequence after FILS authentication. > When testing FILS-FT, I was able to establish matching FT keys as > hostapd, but when it came time to do the actual transition I get this > when hostapd is processing my authentication frame: > > FT: No PMK-R1 available in local cache for the requested PMKR1Name > > It appears the PMKR1Name is being derived with a new R1KH that does not > match the R1KH used in the initial mobility association using FILS. I > know the above comment describes association, but if FILS-FT does not > work at any level I would rather just put this on the back burner for > now. FILS-FT does work in the current snapshot and there has been successful interoperability testing with other implementations. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
