On Jan 28, 2019, at 9:58 AM, John Mattsson <[email protected]> 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 added your suggested text to the GitHub.
Thanks.
Another note is Section 2.3, which says:
All other parameters such as MSK and EMSK are derived as specified in
EAP-TLS [RFC5216], Section 2.3.
While I understand what is intended, that reference can be confusing. To
recap, the calculations referenced are:
Key_Material = TLS-PRF-128(master_secret, "client EAP encryption",
client.random || server.random)
MSK = Key_Material(0,63)
EMSK = Key_Material(64,127)
Where TLS-PRF-128 depends on the master secret, client random and server
random. This seems to contradict the previous paragraph in this draft, which
says:
By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation
without having to extract the Master Secret, ClientHello.random, and
ServerHello.random in a non-standard way.
The issue here is not the derivation of MSK and ESK from Key_Material, but
the implication that the Key_Material for MSK and EMSK is *different* than the
Key_Material define in this draft.
I suggest removing the sentence in this draft that references RFC 5216, and
replacing it with text that says:
MSK = Key_Material(0,63)
EMSK = Key_Material(64,127)
It's not any more text, and it removes a potential confusion.
Alan DeKok.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
