Subject: [Emu] jovergar review of draft-dekok-emu-tls-eap-types-02

From: Jorge Vergara <[email-masked]>
Date: Tue, 2 Jun 2020 07:29:14 +0000

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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 2 Jun 2020 09:09:28 -0400

On Jun 2, 2020, at 3:29 AM, Jorge Vergara <jovergar=[email-masked]> 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.

> 	• 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.

---

From: Jorge Vergara <[email-masked]>
Date: Tue, 2 Jun 2020 18:50:31 +0000

-----Original Message-----
From: Alan DeKok <[email-masked]> 
Sent: Tuesday, June 2, 2020 6:09 AM
To: Jorge Vergara <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] jovergar review of draft-dekok-emu-tls-eap-types-02

>  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'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.

>  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.

>  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.

>  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