Hi Alan, Thanks for bringing this up. I agree that we should take this opportunity to fix other EAP methods which rely on TLS for the outer tunnel. I think that these updates merit a separate document. But I am not certain why the two documents need to be published simultaneously?
--Mohit On 1/28/19 7:24 PM, Alan DeKok wrote: > On Jan 28, 2019, at 12:10 PM, John Mattsson <john.matts...@ericsson.com> > wrote: >>> Sure. The question then becomes one of encoding. For types < 256, 1 octet >>> is >enough. For others, it should be a 32-bit number in network byte order. >> Maybe we can state that it is the EAP Method Type value in network byte >> order with any leading bytes of value zero removed? Then 13 is encoded as >> "0D", 256 is encoded as "0100", and 4294967295 is encoded as "FFFFFFFF". > Hmm... I think 8/32-bit numbers would be simpler. > >>> Thanks. My only remaining nit here is that there should really be a >>> sentence >alluding to other TLS-based EAP methods. So we don't have to rev >>> all of those >documents, too. I'm not sure that this document is the best >>> place to do it, but it's >only 1-2 sentences. >> That is doable but maybe not completely trivial as: >> >> - draft-ietf-emu-eap-tls13 should then probably formally update the RFCs for >> the other methods, e.g. EAP-TTLS (RFC 5281). > Maybe... that's up to the ADs, > >> - I assume the other methods should use the same labels (e.g. >> "EXPORTER_EAP_TLS_Key_Material") as EAP-TLS > Yes. > >> - EAP-FAST (RFC 4851) derives a 112 byte long key_block and TEAP (RFC 7170) >> derives an 40 byte long session_key_seed instead of the 128 byte long >> key_material in EAP-TLS. > <shrug> Truncating 128 bytes to 112 or 40 bytes would be fine. The goal > is to have *something* that people can use. > >> - PAEP is widely deployed but not an RFC > Some guidance would still be useful. > > My $0.02 is that the worst thing we could do is to publish EAP-TLS for TLS > 1.3, and to give no guidance for other TLS-based EAP methods. I have a > strong preference that *all* TLS-based EAP methods be capable of working with > TLS 1.3. > > Maybe this document isn't the place for these updates. But IMHO, any > updates to TTLS, FAST, etc. MUST be published simultaneously with this spec. > Otherwise implementors will have no guidelines, and TTLS / FAST / PEAP / TEAP > will be broken for *years*. > > Alan DeKok. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
