On Sep 2, 2020, at 2:18 PM, Jorge Vergara <jover...@microsoft.com> wrote: > After some more thought a concern came to me about reaching into TLS 1.3 and > using the HKDF. These dependencies on TLS versions are why all the EAP > methods are currently needing updates. Would using the HKDF directly create a > similar situation for the future? Would it be better to define these > calculation in terms of the TLS-Exporter instead?
I suspect so. https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-PEAP/0de54161-0bd3-424a-9b1a-854b4040a6df Says in part: In generating IPMK and CMK, 60 bytes are required. Therefore, LEN=60 in this case. PRF+(K, S, LEN) = T1 | T2 | ... |Tn Where: T1 = HMAC-SHA1 (K, S | 0x01 | 0x00 | 0x00) T2 = HMAC-SHA1 (K, T1 | S | 0x02 | 0x00 | 0x00) It looks like there's no particular need to use HMAC-SHA1 here. It's using HMAC-SHA1 as an "ad hoc" stream cipher, and isn't doing hashing (as such). I suggest then that we simply use the TLS-Exporter, as you suggest. Perhaps: IPMK = TLS-Exporter("EXPORTER: Inner Methods Compound Keys", ISK, 60) Which then mirrors the derivation used for TEAP. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
