Hi Alan,
>> Should all of the following be added to draft-ietf-emu-eap-tls13?
>>
>> MSK = Key_Material(0, 63)
>> EMSK = Key_Material(64, 127)
>> Enc-RECV-Key = MSK(0, 31)
>> Enc-SEND-Key = MSK(32, 63)
>> RECV-IV = IV(0, 31)
>> SEND-IV = IV(32, 63)
> I think
On Jan 28, 2019, at 11:22 AM, John Mattsson wrote:
>
> The intention with "All other parameters such as MSK and EMSK are derived as
> specified in EAP-TLS [RFC5216], Section 2.3." was to only mention changes
> compared to RFC 5216.
Sure. The confusion is that when reading RFC 5216, it defin
Hi Alan,
The intention with "All other parameters such as MSK and EMSK are derived as
specified in EAP-TLS [RFC5216], Section 2.3." was to only mention changes
compared to RFC 5216.
Avoiding potential confusion is a very important goal to avoid incompatible
implementations. I think we should m
On Jan 28, 2019, at 9:58 AM, John Mattsson wrote:
>
> Great news that you have done interoperability testing of EAP-TLS 1.3 and
> that you have not found any major issues.
>
> I think it is very good to inform implementors about the use of the length
> values to ensure combability. I have adde
Hi Alan,
Great news that you have done interoperability testing of EAP-TLS 1.3 and that
you have not found any major issues.
I think it is very good to inform implementors about the use of the length
values to ensure combability. I have added your suggested text to the GitHub.
https://github.c
