Apologies for a second round of feedback after some more time reviewing the document contents.
Section 3 of the document describes how tunneled methods should the possibility of Post-Handshake messages in TLS 1.3. As discussed on this mail thread: https://mailarchive.ietf.org/arch/msg/emu/0MeocWZQLCv1pST5_2jW_ABlpMo/ it is possible for the methods in this discussion to skip the phase 2 "tunnel" completely. Thus it seems that a similar approach as is being taken for EAP-TLS would be needed here, since there may be no application data exchanged after the TLS handshake completes. Jorge Vergara -----Original Message----- From: Alan DeKok <al...@deployingradius.com> Sent: Sunday, April 19, 2020 9:17 AM To: Jorge Vergara <jover...@microsoft.com> Cc: EMU WG <emu@ietf.org> Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion On Apr 7, 2020, at 5:09 PM, Jorge Vergara <jover...@microsoft.com> wrote: > On the document contents themselves, I have this review: The key derivation > proposed for TEAP/FAST uses the definition from FAST, which is not identical > to the TEAP derivation. Namely, FAST used MSK[j] in the derivation, but TEAP > uses IMSK[j], which may be equivalent in some cases, but may not in others > where the inner method exports an EMSK. > > Specifically, I believe this line of section 2.2 should change from > IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound > Keys", S-IMCK[j-1] | MSK[j], 60) To > IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound > Keys", S-IMCK[j-1] | IMSK[j], 60) For TEAP. I've made the change, thanks. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
