Hi Joe, On 1/5/21 8:44 AM, Joseph Salowey wrote:
On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok <al...@deployingradius.com<mailto:al...@deployingradius.com>> wrote: On Jan 3, 2021, at 10:44 PM, Martin Thomson <m...@lowentropy.net<mailto:m...@lowentropy.net>> wrote: > # Key Schedule > > The other thing I observe is the way that this slices up the exporter output. > This was something that old versions of TLS did, but TLS 1.3 did away with. > Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to. This could - > and should - do the same. All it means is having more exporter labels. That's easy enough to change at this state. The question is what are those labels? And, we're getting very close to needing an implementation soon. RFC 8446 is over two years old. Web services have started serious migration to TLS 1.3. But we still don't even have a standard for EAP. I suggest that this is an issue. At this point, we have inter-operability of TLS 1.3 for EAP-TLS, with the major EAP peer / server implementations. This code is alpha, and not in any major release. But we need to decide fairly soon what we're doing, as testing and releases take time. The alternative is to dither around for another year or two, all the while relying on legacy TLS versions for 802.1X / WiFi authentication. i.e. packets which are trivially monitored by anyone with a WiFi card. > I appreciate that this uses exporters now rather than abusing the internal > PRF. That's good. The next step is to dispense with the intermediate values > (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS > exporter for each of the six values that the protocol requires. I also note > that the 0x0D value is used multiple times, unnecessarily, both as a context > strong to the exporter and as a prefix to the session ID. If EAP-TLS was the only TLS-based EAP method, I would agree with you. But it's not. Historically, each TLS-based EAP method uses it's own key derivations, using method-specific strings. This practice made implementations more difficult and error-prone. [Joe] It may be worth having separate exporter tags for EMSK and MSK. (EXPORTER_EAP_TLS_MSK and EXPORTER_EAP_TLS_EMSK). I believe current applications define the use EAP key material based on the MSK or EMSK. The mechanism for splitting the MSK into Enc-RECV-Key and Enc-SNED-Key I believe is only used in specific legacy cases (WEP, MPPE?) and may still be the radius attributes used in some deployments, so I don't think we should alter that derivation. I'm not sure where the IV is used, but I don't think splitting it up more will be helpful. This sounds reasonable. I was initially hesitant to change because we have working implementations. 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. 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? 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? --Mohit The use of 0x0D is to allow standard key derivations across TLS-based EAP methods. The other methods replaced the 0x0D byte with their own EAP type value. This practice greatly simplifies implementations. See https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 for more information. Alan DeKok. _______________________________________________ Emu mailing list e...@ietf.org<mailto:e...@ietf.org> https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list e...@ietf.org<mailto:e...@ietf.org> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
