On Mon, Jan 28, 2019 at 10:50:29AM +0700, Arran Cudbard-Bell wrote: > In previous TLS versions (<= 1.3) the output of the PRF used for key derivation did not vary depending on the number of bytes generated. > > i.e. if 32 bytes were requested from the PRF, then 64 bytes were requested, provided the other inputs were the same, the first 32 bytes of both values generated would be the same. > With TLS 1.3 and HKDF, this is no longer the case. > This means when the EAP client and EAP server are deriving keying material, they must request the same number of bytes from the PRF. And that's one of the reasons why PEAP and EAP-TTLS (or any other TLS-based EAP method for that matter) needs to disable use of TLS 1.3 until the needed changes to the EAP method has been defined.. Another significant issue of uncertainty here is in which labels to use in the PRF taken into account that draft-ietf-emu-eap-tls13 proposed different labels to be used for EAP-TLS with TLS 1.3 and the design in PEAP and EAP-TTLS was originally close to the one used in EAP-TLS. > For PEAPv0 The current FreeRADIUS code requests 128 bytes from the PRF to generate both a MSK and EMSK. > For PEAPv0 wpa_supplicant requests 64 bytes and does not generate MSK and EMSK values. wpa_supplicant derives only MSK for PEAP since I could not find a definition of EMSK for PEAP (v0 or v1) when working on the ERP changes. I did address a similar issue with other TLS-based EAP methods, though, between hostapd and wpa_supplicant implementations when going through the needed ERP and TLS 1.3 changes. In other words, if the EAP method has a clear definition of EMSK derivation, wpa_supplicant will derive both MSK and EMSK together to avoid this issue with different PRF result. > Because of the differing number of bytes requested from HKDF, the output of HKDF differs on the EAP-Client and EAP-Server. > > Does anyone have any thoughts on solving this interoperability issue? The only robust option today seems to be to disable TLS 1.3 for PEAP.. It would be nice to get an updated definition of PEAP v0/v1 to clear spell out the rules for deriving MSK, EMSK, and Session-Id and also the labels to be used in all various cases to address this type of interoperability issues. I'm not planning on enabling TLS 1.3 for PEAP any time soon, so this should not show up in practical cases as an interoperability issue. That said, if there is desire to get some testing done in experimental settings with TLS 1.3, I guess I could be convinced to try to extrapolate the PEAPv0 specification (both draft-josefsson-pppext-eap-tls-eap and MS-PEAP) to imply that the MSK derivation uses PRF to extract 128 octets of Key_Material in all cases and that this applies to TLS 1.3 as well. And maybe remaining with the same label string that was originally used in EAP-TLS (instead of the one used in draft-josefsson-pppext-eap-tls-eap or the one that is misspelled in MS-PEAP or the one that is proposed in draft-josefsson-pppext-eap-tls-eap). -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
