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: 1. PEAP Key Material when crypto binding is used. When PEAP uses crypto binding, it uses a different key material calculation<https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-PEAP/e75b0385-915a-4fc3-a549-fd3d06b995b0> 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+<https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-PEAP/0de54161-0bd3-424a-9b1a-854b4040a6df>, 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. 1. TTLS Implicit Challenge. The TLS-PRF is currently used to calculate the implicit challenge<https://tools.ietf.org/html/rfc5281#section-11.1> 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. 2. TEAP Compound MAC. The TEAP Compound MAC<https://tools.ietf.org/html/rfc7170#section-5.3> 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) 3. TEAP Inner Method Session Key. When an inner authentication method supports exporting an EMSK, the definition of the IMSK<https://tools.ietf.org/html/rfc7170#section-5.2> relies on the TLS-PRF and so needs to be adjusted. 4. 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. 5. 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
