-----Original Message----- From: Alan DeKok <al...@deployingradius.com> Sent: Tuesday, June 2, 2020 6:09 AM To: Jorge Vergara <jover...@microsoft.com> Cc: EMU WG <emu@ietf.org> Subject: Re: [Emu] jovergar review of draft-dekok-emu-tls-eap-types-02
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. Unfortunately I use code from the Windows operating system and so am not able to share my source at this time. I understand an open source implementation would be better but am happy to test against any server implementations that become available. I'm currently testing against hostapd. >> 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. Works for me, I just wanted to raise the question. >> >> • 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. Sure, this works too, as long as TLS-Exporter replaces the TLS-PRF. >> • 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. I reached out to a colleague on the Windows TLS team. He mentioned that the HKDF also has a hash function that is similar to the TLS 1.2 PRF function. So at first glance, he did not see a need to redefine this entirely; just reword the text. He suggested something like "hash function associated with the cipher suite negotiated for the TLS session." e.g., for TLS_AES_128_GCM_SHA256, EAP uses SHA256. Hoping others with more TLS experience can chime in here or spend more time on the wording, but a first pass would seem to indicate this is mostly okay. >> • 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. Thanks for the work and looking forward to the update. Jorge Vergara _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
