On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok <al...@deployingradius.com> wrote:
> On Jan 3, 2021, at 10:44 PM, Martin Thomson <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. > > 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 > https://www.ietf.org/mailman/listinfo/emu >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
