Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

From: John Mattsson <[email-masked]>
Date: Tue, 1 Sep 2020 16:05:42 +0000

Hi,

I have reviewed draft-ietf-emu-tls-eap-types-01. Looks good. Two crypto related comments below:

- "MAC is the MAC function negotiated in TLS 1.3."

There is no MAC function negotiated in TLS 1.3. Also, a modern TLS implementation would not negotiate any MAC funtion in TLS 1.2 as they would use an AEAD. There is however a cipher suite hash algorithms that is used in HMAC mode. Maybe something like

   "Compound-MAC = HMAC( CMK, BUFFER )

   Where HMAC uses the Hash algorithm for the handshake."
   
   or

   "Compound-MAC = HMAC( CMK, BUFFER )

   Where the Hash function used by HKDF is the cipher suite hash algorithm"

This raises the question what TEAP TLS 1.2 implementations do today? Are they only using outdated and non-secure cipher suites or are they doing something unspecified to derive Compound-MAC with an AEAD cipher suite?

Anyway, how to calculate Compound-MAC with an AEAD algorithm needs to be specified for TLS 1.2 as well. I think the scope of the document need to be expanded slightly.

- "For PEAP, some derivation use HMAC-SHA1 [PEAP-MPPE].  There are no
   known security issues with HMAC-SHA1.  In the interests of
   interoperability and minimal changes, we do not change that
   definition here."

While it is true that there are no known practical attacks against HMAC-SHA1, most modern protocols like TLS 1.3 forbid all uses of SHA-1, governments are recommending phasing out use of HMAC-SHA1 in e.g. IKEv2, and many buyers of security equipment thinks that everything with SHA-1 is very weak. To me it feels strange to force future implementations to continue support of SHA-1 when it is completely removed from TLS 1.3. Enforcing SHA-256 when TLS 1.3 is used seems like the easy way forward. It is probably much harder to do at a later stage. 

Editorials:

- "in Section Those"
- formatting of the list in section 5

Cheers,
John

-----Original Message-----
From: Emu <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Reply to: "[email-masked]" <[email-masked]>
Date: Wednesday, 29 July 2020 at 23:04
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

    A New Internet-Draft is available from the on-line Internet-Drafts directories.
    This draft is a work item of the EAP Method Update WG of the IETF.

            Title           : TLS-based EAP types and TLS 1.3
            Author          : Alan DeKok
    	Filename        : draft-ietf-emu-tls-eap-types-01.txt
    	Pages           : 12
    	Date            : 2020-07-29

    Abstract:
       EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS].  Many
       other EAP [RFC3748] and [RFC5247] types also depend on TLS, such as
       FAST [RFC4851], TTLS [RFC5281], TEAP [RFC7170], and possibly many
       vendor specific EAP methods.  This document updates those methods in
       order to use the new key derivation methods available in TLS 1.3.
       Additional changes necessitated by TLS 1.3 are also discussed.

    The IETF datatracker status page for this draft is:
    https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/

    There are also htmlized versions available at:
    https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01
    https://datatracker.ietf.org/doc/html/draft-ietf-emu-tls-eap-types-01

    A diff from the previous version is available at:
    https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-tls-eap-types-01

    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.

    Internet-Drafts are also available by anonymous FTP at:
    ftp://ftp.ietf.org/internet-drafts/

    _______________________________________________
    Emu mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Tue, 1 Sep 2020 16:59:23 -0400

>   Where the Hash function used by HKDF is the cipher suite hash algorithm"

  OK.

> This raises the question what TEAP TLS 1.2 implementations do today? Are they only using outdated and non-secure cipher suites or are they doing something unspecified to derive Compound-MAC with an…

  It's not clear.  I'd have to double-check hostap, which is the only publicly available TEAP implementation I know of.

> Anyway, how to calculate Compound-MAC with an AEAD algorithm needs to be specified for TLS 1.2 as well. I think the scope of the document need to be expanded slightly.

  Or punt on TEAP entirely, and leave it to a TEAP-bis document.

> While it is true that there are no known practical attacks against HMAC-SHA1, most modern protocols like TLS 1.3 forbid all uses of SHA-1, governments are recommending phasing out use of HMAC-SHA1…

  Realistically, PEAP is a vendor-defined protocol.  It is not under the change control of the IETF.  If the vendor agrees to this change, then it's possible.  Otherwise we're stuck with what we have.

> - formatting of the list in section 5

  I'll fix that, thanks.

  Alan DeKok.

---

From: Jorge Vergara <[email-masked]>
Date: Wed, 2 Sep 2020 02:43:16 +0000

>  It's not clear.  I'd have to double-check hostap, which is the only publicly available TEAP implementation I know of.

I can tell you what Windows is doing for TLS 1.2; and Windows interops with all the TEAP implementations that I know of, so others are likely doing the same. We're using the MAC function in the case of a CBC block cipher suite, or PRF hash function in the case of an AEAD cipher suite. Yes, it's unspecified, but I believe most TLS libraries abstracts the difference away, so it went unnoticed. I imagine it may have gone unnoticed by other implementations as well.

>  Realistically, PEAP is a vendor-defined protocol.  It is not under the change control of the IETF.  If the vendor agrees to this change, then it's possible.  Otherwise we're stuck with what we hav…

We agree to changes in this area to the extent that WG feels they are necessary. I don't have the cryptanalysis background to weight heavily in on what the right thing to do is, but have no objection to moving away from SHA1.

Rather than locking in another dependency such as SHA256, I wonder if this calculation should also use a hash function derived from the TLS handshake?

Jorge Vergara

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Alan DeKok
Sent: Tuesday, September 1, 2020 1:59 PM
To: John Mattsson <john.mattsson=[email-masked]>
Cc: [email-masked]
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

  OK.

  I'll fix that, thanks.

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=02%7C01%7Cjovergar%40microsoft.com%7C3beed6d0ea854ee4414c08d84eb9eec0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345907781097079&amp;sdata=%2Bs%2FarBWgPHSNgKG8rbLN0kB2hbr77aYRP35L9O2rgZc%3D&amp;reserved=0

---

From: John Mattsson <[email-masked]>
Date: Wed, 2 Sep 2020 07:30:15 +0000

> I can tell you what Windows is doing for TLS 1.2; and Windows interops with all the TEAP implementations that I know of, so others are likely doing the same. We're using the MAC function in the cas…

Should we document this behavior for TLS 1.2 in the draft? I.e. the PRF hash function in HMAC mode for AEAD cipher suites and the MAC function for non-AEAD cipher suites.

> Rather than locking in another dependency such as SHA256, I wonder if this calculation should also use a hash function derived from the TLS handshake?

That is a much better idea! It is not necessary to update any TEAP TLS 1.2 code, but it definitely feels like a worthwhile thing to do when the implementation is anyway updated for TLS 1.3.

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Alan DeKok
Sent: Tuesday, September 1, 2020 1:59 PM
To: John Mattsson <john.mattsson=[email-masked]>
Cc: [email-masked]
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

  OK.

  I'll fix that, thanks.

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]
https://protect2.fireeye.com/v1/url?k=1e1c2e57-40bcec12-1e1c6ecc-8692dc8284cb-890ef1f2fc081407&q=1&e=b42cb8cd-b2ad-4018-b532-f8328271bffc&u=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Femu%26amp%3Bdata%3D02%257C01%257Cjovergar%2540microsoft.com%257C3beed6d0ea854ee4414c08d84eb9eec0%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637345907781097079%26amp%3Bsdata%3D%252Bs%252FarBWgPHSNgKG8rbLN0kB2hbr77aYRP35L9O2rgZc%253D%26amp%3Breserved%3D0

---

From: Alan DeKok <[email-masked]>
Date: Wed, 2 Sep 2020 10:54:25 -0400

> Should we document this behavior for TLS 1.2 in the draft? I.e. the PRF hash function in HMAC mode for AEAD cipher suites and the MAC function for non-AEAD cipher suites.

  Yes.  Any suggested text?  I'm not overly familiar with TLS 1.3, so I don't want to suggest the wrong thing.

> That is a much better idea! It is not necessary to update any TEAP TLS 1.2 code, but it definitely feels like a worthwhile thing to do when the implementation is anyway updated for TLS 1.3.

  Can we use the same hash functions as above?  If so, what would the text look like?

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 2 Sep 2020 08:52:49 -0700

On Wed, Sep 2, 2020 at 7:54 AM Alan DeKok <[email-masked]> wrote:

> >> I can tell you what Windows is doing for TLS 1.2; and Windows interops
> with all the TEAP implementations that I know of, so others are likely
> doing the same. We're using the MAC function in the case of a CBC block
> cipher suite, or PRF hash function in the case of an AEAD cipher suite.
> Yes, it's unspecified, but I believe most TLS libraries abstracts the
> difference away, so it went unnoticed. I imagine it may have gone unnoticed
> by other implementations as well.
> >
> > Should we document this behavior for TLS 1.2 in the draft? I.e. the PRF
> hash function in HMAC mode for AEAD cipher suites and the MAC function for
> non-AEAD cipher suites.
>
[Joe]  I think you should treat them as 3 distinct cases to make sure it is
clear.  For TLS 1.3 I like John's second phrasing better as it aligns
better with TLS 1.3 terminology:

"For TLS 1.3 the hash function used is the same as the ciphersuite hash
function negotiated for HKDF in the key schedule."  (section 7.1 of 8446)

> >> Rather than locking in another dependency such as SHA256, I wonder if
> this calculation should also use a hash function derived from the TLS
> handshake?
> >
> > That is a much better idea! It is not necessary to update any TEAP TLS
> 1.2 code, but it definitely feels like a worthwhile thing to do when the
> implementation is anyway updated for TLS 1.3.
>
[Joe] Moving away from SHA-1 is a good idea as it will only raise questions
moving forward.  For TLS 1.3 I think you could use the same text, but I
would look to Jorge to make sure we get it correct for PEAP.   TEAP should
also use the Hash from HKDF in TLS 1.3.

---

From: Jorge Vergara <[email-masked]>
Date: Wed, 2 Sep 2020 16:47:34 +0000

>[Joe] Moving away from SHA-1 is a good idea as it will only raise questions moving forward.  For TLS 1.3 I think you could use the same text, but I would look to Jorge to make sure we get it correct for PEAP.   TEAP should also use the Hash from HKDF in TLS 1.3.

I am not a TLS terminology expert so please go with whatever the group thinks is best. If for TEAP we are using "For TLS 1.3 the hash function used is the same as the ciphersuite hash function negotiated for HKDF in the key schedule.", then I’d be fine with something similar for PEAP.

Jorge

From: Joseph Salowey <[email-masked]>
Sent: Wednesday, September 2, 2020 8:53 AM
To: Alan DeKok <[email-masked]>
Cc: John Mattsson <[email-masked]>; Jorge Vergara <[email-masked]>; [email-masked]
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

On Wed, Sep 2, 2020 at 7:54 AM Alan DeKok <[email-masked]<mailto:[email-masked]>> wrote:

[Joe]  I think you should treat them as 3 distinct cases to make sure it is clear.  For TLS 1.3 I like John's second phrasing better as it aligns better with TLS 1.3 terminology:

"For TLS 1.3 the hash function used is the same as the ciphersuite hash function negotiated for HKDF in the key schedule."  (section 7.1 of 8446)

[Joe] Moving away from SHA-1 is a good idea as it will only raise questions moving forward.  For TLS 1.3 I think you could use the same text, but I would look to Jorge to make sure we get it correct for PEAP.   TEAP should also use the Hash from HKDF in TLS 1.3.

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=02%7C01%7Cjovergar%40microsoft.com%7Ce9ca671b636744277cb408d84f58487c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346587886062328&sdata=l8ieJEByAeR%2F4Nvmhs0heTW900Gx9Q1i%2BvoF1rDUPII%3D&reserved=0>

---

From: Jorge Vergara <[email-masked]>
Date: Wed, 2 Sep 2020 18:18:22 +0000

>I am not a TLS terminology expert so please go with whatever the group thinks is best. If for TEAP we are using "For TLS 1.3 the hash function used is the same as the ciphersuite hash function negot…

After some more thought a concern came to me about reaching into TLS 1.3 and using the HKDF. These dependencies on TLS versions are why all the EAP methods are currently needing updates. Would using the HKDF directly create a similar situation for the future? Would it be better to define these calculation in terms of the TLS-Exporter instead?

Jorge

From: Emu <[email-masked]> On Behalf Of Jorge Vergara
Sent: Wednesday, September 2, 2020 9:48 AM
To: Joseph Salowey <[email-masked]>; Alan DeKok <[email-masked]>
Cc: [email-masked]
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

Jorge

From: Joseph Salowey <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, September 2, 2020 8:53 AM
To: Alan DeKok <[email-masked]<mailto:[email-masked]>>
Cc: John Mattsson <[email-masked]<mailto:[email-masked]>>; Jorge Vergara <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/emu<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=02%7C01%7Cjovergar%40microsoft.com%7Cb048c31e4ebd4573320308d84f5ff56e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346620851549851&sdata=jLdzGHqKrWNlsjKbBiscOzWRWmXd8pvgkBg6KgEWHmA%3D&reserved=0>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 2 Sep 2020 16:03:55 -0400

> After some more thought a concern came to me about reaching into TLS 1.3 and using the HKDF. These dependencies on TLS versions are why all the EAP methods are currently needing updates. Would usin…

  I suspect so.

https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-PEAP/0de54161-0bd3-424a-9b1a-854b4040a6df

  Says in part:

In generating IPMK and CMK, 60 bytes are required. Therefore, LEN=60 in this case.
 PRF+(K, S, LEN) = T1 | T2 | ... |Tn
 Where:
 T1 = HMAC-SHA1 (K, S | 0x01 | 0x00 | 0x00)
 T2 = HMAC-SHA1 (K, T1 | S | 0x02 | 0x00 | 0x00)

  It looks like there's no particular need to use HMAC-SHA1 here.  It's using HMAC-SHA1 as an "ad hoc" stream cipher, and isn't doing hashing (as such).

  I suggest then that we simply use the TLS-Exporter, as you suggest.  Perhaps:

	IPMK = TLS-Exporter("EXPORTER: Inner Methods Compound Keys", ISK, 60)

  Which then mirrors the derivation used for TEAP.

  Alan DeKok.