On Jan 28, 2019, at 5:29 AM, Jouni Malinen <j@xxxxx> wrote: > > 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. I agree. What we're doing is putting all of the fixes in to FreeRADIUS. TLS 1.3 will then the enabled *only* if the administrator requests it. That allows for the common case to work, but also for testing if people want to do that. > 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. The EAP-TLS draft won't change TTLS or PEAP. So that issue will remain open for the foreseeable future. My $0.02 is to just agree on something, so that hostap / wpa_supplicant and FreeRADIUS can interoperate. And separately work something through the IETF. >> 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. Hmm... good point. In FreeRADIUS, we just use one key derivation function for all TLS-based EAP methods. The only thing that's different is the PRF label. We just ask for 128 bytes of data. The first 64 is the MSK, and the second 64 is the EMSK. > 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. That makes sense. The EAP-TLS draft mandates always asking for 128 bytes of data, so there's that. > 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. Realistically, no one else will update TTLS or PEAP at this point. We should just agree on something to allow *us* to interoperate. If we want it to be semi-official, I can write it up and add it to the ERP draft I've been meaning to write for a while. That will take ~2 years to standardize, of course. But we could definitely implement something now. > 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. Yes. > 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). For TLS 1.2 and earlier, yes. For TLS 1.3, I'd be happy with just using the labels defined for EAP-TLS and TLS 1.3. I don't really see any benefit to using method-specific labels. RFC 8446 defines the TLS exporter as: TLS-Exporter(label, context_value, key_length) For EAP-TLS 1.3, the context_value is "". I'd just say that for TTLS and PEAP, the context value is a one-byte string that contains the EAP type. If you're in agreement, we can put some patches together for hostap && FreeRADIUS. And I'll find time to write it all up for the IETF. Alan DeKok. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
