On Mon, Jan 28, 2019 at 08:30:00AM -0500, Alan DeKok wrote: > On Jan 28, 2019, at 5:29 AM, Jouni Malinen <j@xxxxx> wrote: > > 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. I prefer to do such implementation changes with something that could be referenced as a justification for the change. An internet draft would be sufficient for such a reference and it looks like the discussion you initiated in EMU WG seems to point at the direction of getting such a document available.. > > 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. I added EMSK derivation for PEAP now to enable use with ERP (and FILS). That takes care of this 128 octet MSK+EMSK key derivation output length as well. > 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. draft...-00.txt and some discussion in EMU is enough for me, so no need to wait for those years to get something more formal out from the end of the process. > 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. As noted above, I'd prefer the reverse order here, i.e., something that I can use as justification in the commit message (that draft-*-00.txt).. As far as the use of TLS-Exporter is concerned, the label/context_value pair should be unique for each EAP method. I guess encoding the EAP type (but with support for expanded types as noted on EMU mailing list) would be sufficient for that. That said, I kind of like the idea of mixing in the MSK derived by the inner method (if one was used) similarly to how the Inner Session Key (ISK) is used in PEAPv0 with crypto binding or how EMSK or MSK from the inner method is used in TEAP. Adding that inner method key (when available) into the TLS-Exporter context_value in the encapsulating TLS-based EAP method would be one way of achieving this. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
