Hi Alan, David,
I also strongly agree that all TLS-based EAP methods in use should be capable
of working with TLS 1.3. You make a very strong case that this need to happen
as soon as possible and that the most practical approach is to add the
information to draft-ietf-emu-eap-tls13. Just like with EAP-TLS, we must
absolutely avoid a situation where different TTLS / FAST / PEAP / TEAP
implementations with TLS 1.3 cannot talk with each other.
I am ok with adding this information to draft-ietf-emu-eap-tls13, but I would
like to have a go ahead from the chairs/ADs before doing so. My view is that
this can be done in the current charter if text about "EAP TLS" is interpreted
as TLS-based EAP methods. I would recommend that draft-ietf-emu-eap-tls13 then
formally updates the other RFCs to make sure as many people as possible looking
to implement e.g. EAP-TTLS finds the information on how to do the key
derivation with TLS 1.3.
Is information about key derivation the only thing that is needed? Should TTLS
/ FAST / PEAP / TEAP for instance use an TLS empty record in the same way as
EAP-TLS?
> On Jan 28, 2019, at 12:24 PM, Alan DeKok <al...@deployingradius.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.
Ok, let's do it like that.
Cheers,
John
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
