>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". >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). - I assume the other methods should use the same labels (e.g. "EXPORTER_EAP_TLS_Key_Material") as EAP-TLS - 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. - PAEP is widely deployed but not an RFC /John _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
