On Jan 5, 2021, at 10:05 AM, Mohit Sethi M <mohit.m.se...@ericsson.com> wrote: > This sounds reasonable. I was initially hesitant to change because we have > working implementations.
Nothing has been published in an official release. So we have some time. But I'm at the point now where I'd like to release the next version of FreeRADIUS. We've implemented the current draft. If there's still uncertainty, then I will disable TLS 1.3 support before the release. It's better to forbid something than to do it wrong. > But after a brief glance at the current hostap implementation: > https://w1.fi/cgit/hostap/tree/src/eap_server/eap_server_tls.c#n356; I am > convinced that using separate labels for MSK and EMSK is better. The current > implementation seems incorrect. IIRC hostap has EAP-TLS working for TLS 1.3. The PEAP and TTLS patches have not yet been merged. > About the IV: RFC 5247 (published after RFC 5216) says the following > (https://tools.ietf.org/html/rfc5247#section-1.2): > >> As a result, its use has been deprecated and it is >> OPTIONAL for EAP methods to generate it. However, when it is >> generated, it MUST be unpredictable. >> > Should we still export it in EAP-TLS with TLS 1.3? I don't recall any uses of it. > And the same question for Enc-SEND-Key and Enc-RECV-Key. They are defined in > RFC 2548: https://tools.ietf.org/html/rfc2548, but not exported or used in > hostap/freeradius implementations. It could be that they are still used by > Microsoft but I am unsure? I'm not sure what is meant by Enc-SEND-Key. RFC 2548 Section 2.4.2 defines MS-MPPE-Send-Key. That and MS-MPPE-Recv-Key are used everywhere in WiFi. FreeRADIUS and hostap both export and use these fields. Removing MS-MPPE-Send-Key and/or MS-MPPE-Recv-Key will destroy global WiFi. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
