I've posted a new revision of the document which should address all of your comments. Thanks again for the detailed review.
> On Jun 2, 2020, at 3:29 AM, Jorge Vergara > <jovergar=40microsoft....@dmarc.ietf.org> wrote: > > Hi all, > > I’ve attempted/completed a prototype implementation of EAP-TLS, PEAP, > EAP-TTLS, and TEAP clients using TLS 1.3. EAP-TLS went smoothly so this boils > down to a review of the subject line document which addresses the rest of the > EAP types. I am not necessarily an expert on all of TLS 1.3 so some of my > issues may just be a lack of understanding – please point this out if so. > > I had the following questions/issues that may need to be addressed in this > document: > > • PEAP Key Material when crypto binding is used. When PEAP uses crypto > binding, it uses a different key material calculation that consumes inner > method key material. This is not addressed in this document. If we fallback > to what is currently defined, we end up with PEAP’s definition of PRF+, which > despite the name is hardcoded to SHA1. Since it’s hard-coded to SHA1 and > doesn’t technically depend on the TLS-PRF, it technically could continue to > be used. But, is there a desire to update this key material calculation as > well to use the TLS-Exporter as with the rest of the calculations? If not, I > believe it’s still worth a mention, since I see it being a point of confusion. > > • TTLS Implicit Challenge. The TLS-PRF is currently used to calculate > the implicit challenge for CHAP, MS-CHAP, and MS-CHAP-V2 (non-EAP). This > isn’t currently covered in the document. In TTLS, differing amounts of > challenge material are needed based on whether CHAP, MS-CHAP, or MS-CHAP-V2 > is being used. It’s probably sufficient to define one exporter of a suitable > length for all three and truncate to the amount needed. > > • TEAP Compound MAC. The TEAP Compound MAC is currently defined in > terms of the “MAC function negotiated in TLS 1.2.” If TEAP is to remain in > this document, I believe this should be clarified. Here my familiarity with > TLS 1.3 becomes an issue as I am not sure whether this is a simple wording > update or if the calculation needs to be re-defined. (as an aside, I am in > favor of TEAP in this document but understand if the consensus is to separate > it) > > • TEAP Inner Method Session Key. When an inner authentication method > supports exporting an EMSK, the definition of the IMSK relies on the TLS-PRF > and so needs to be adjusted. > > • Section 5 of this document is out of date with the EAP-TLS document. > It mentions that an empty application record is used to indicate negotiation > has finished – this is now a size 1 0x00 application record. > > • Section 5 further mentions that methods which use inner tunnel > methods should instead begin their inner tunnel negotiation by sending type > specific application data. The inner tunnel is optional for PEAP, EAP-TTLS, > and TEAP, especially if resumption is used.. So it’s not clear to me how to > indicate negotiation has finished in these methods. I believe the 0x00 octet > from EAP-TLS is needed here as well. > > I appreciate the effort gone into this thus far. I believe the adjustments > needed are fairly simple and after the above issues are solved I could > complete my prototypes. > > Thanks, > Jorge Vergara > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
