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

[Alan DeKok]

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

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

[Jorge Vergara]

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

On Jun 2, 2020, at 3:29 AM, Jorge Vergara 
 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

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

[Alan DeKok]

On Jun 2, 2020, at 3:29 AM, Jorge Vergara 
 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

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

[Jorge Vergara]

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



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

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

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

  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