On Jun 2, 2020, at 3:29 AM, Jorge Vergara <jovergar=40microsoft....@dmarc.ietf.org> wrote: > > 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.
Thanks. Is the source available somewhere? It would be good to have multiple implementations for interoperability testing. > 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. I'm happy to leave the PRF+ calculation alone. It uses HMAC-SHA1, which seems fine. > > • 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. I don't see that this needs to change, but it is worth a mention in the document. i.e. TTLS uses the TLS-PRF with a label of "ttls challenge". The length of the challenge material can simply be taken from the requirements. So we don't need to define multiple exporters. > • 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) I'm not sure here. > • 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. OK. I'm less sure of what should be done here. I'll take a look. > • 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. Good point. I'll update the doc. > • 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 think so, yes. > 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. I'll take a look this week. I also hope to have FreeRADIUS updated for TLS 1.3, too. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
