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