Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt
On Sep 2, 2020, at 2:18 PM, Jorge Vergara wrote:
> 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?
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.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt
>>[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. 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 On Behalf Of Jorge Vergara Sent: Wednesday, September 2, 2020 9:48 AM To: Joseph Salowey ; Alan DeKok Cc: emu@ietf.org Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt >[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 mailto:j...@salowey.net>> Sent: Wednesday, September 2, 2020 8:53 AM To: Alan DeKok mailto:al...@deployingradius.com>> Cc: John Mattsson mailto:john.matts...@ericsson.com>>; Jorge Vergara mailto:jover...@microsoft.com>>; emu@ietf.org<mailto:emu@ietf.org> 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 mailto:al...@deployingradius.com>> wrote: On Sep 2, 2020, at 3:30 AM, John Mattsson mailto:john.matts...@ericsson.com>> 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. Yes. Any suggested text? I'm not overly familiar with TLS 1.3, so I don't want to suggest the wrong thing. [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. Can we use the same hash functions as above? If so, what would the text look like? [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 Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu=02%7C01%7Cjovergar%40microsoft.com%7Cb048c31e4ebd4573320308d84f5ff56e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346620851549851=jLdzGHqKrWNlsjKbBiscOzWRWmXd8pvgkBg6KgEWHmA%3D=0> ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt
>[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 Sent: Wednesday, September 2, 2020 8:53 AM To: Alan DeKok Cc: John Mattsson ; Jorge Vergara ; emu@ietf.org 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 mailto:al...@deployingradius.com>> wrote: On Sep 2, 2020, at 3:30 AM, John Mattsson mailto:john.matts...@ericsson.com>> 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. Yes. Any suggested text? I'm not overly familiar with TLS 1.3, so I don't want to suggest the wrong thing. [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. Can we use the same hash functions as above? If so, what would the text look like? [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 Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu=02%7C01%7Cjovergar%40microsoft.com%7Ce9ca671b636744277cb408d84f58487c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346587886062328=l8ieJEByAeR%2F4Nvmhs0heTW900Gx9Q1i%2BvoF1rDUPII%3D=0> ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt
On Wed, Sep 2, 2020 at 7:54 AM Alan DeKok wrote: > On Sep 2, 2020, at 3:30 AM, John Mattsson > 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. > > Yes. Any suggested text? I'm not overly familiar with TLS 1.3, so I > don't want to suggest the wrong thing. > > [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. > > Can we use the same hash functions as above? If so, what would the text > look like? > > [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 > 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] I-D Action: draft-ietf-emu-tls-eap-types-01.txt
On Sep 2, 2020, at 3:30 AM, John Mattsson 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. Yes. Any suggested text? I'm not overly familiar with TLS 1.3, so I don't want to suggest the wrong thing. >> 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. Can we use the same hash functions as above? If so, what would the text look like? Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt
>>> 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? >> 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. 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. >> 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. > 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? 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 On Behalf Of Alan DeKok Sent: Tuesday, September 1, 2020 1:59 PM To: John Mattsson Cc: emu@ietf.org Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt On Sep 1, 2020, at 12:05 PM, John Mattsson wrote: > > 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" 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 AEAD cipher suite? 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. > - "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. 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. > Editorials: > > - "in Section Those" > - formatting of the list in section 5 I'll fix that, thanks. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://protect2.fireeye.com/v1/url?k=1e1c2e57-40bcec12-1e1c6ecc-8692dc8284cb-890ef1f2fc081407=1=b42cb8cd-b2ad-4018-b532-f8328271bffc=https%3A%2F%2Fnam06.safelinks.protection.outl
Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt
>> 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? > 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 have. 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 On Behalf Of Alan DeKok Sent: Tuesday, September 1, 2020 1:59 PM To: John Mattsson Cc: emu@ietf.org Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt On Sep 1, 2020, at 12:05 PM, John Mattsson wrote: > > 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" 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 AEAD cipher suite? 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. > - "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. 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. > Editorials: > > - "in Section Those" > - formatting of the list in section 5 I'll fix that, thanks. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=02%7C01%7Cjovergar%40microsoft.com%7C3beed6d0ea854ee4414c08d84eb9eec0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345907781097079sdata=%2Bs%2FarBWgPHSNgKG8rbLN0kB2hbr77aYRP35L9O2rgZc%3Dreserved=0 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt
On Sep 1, 2020, at 12:05 PM, John Mattsson wrote: > > 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" 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 AEAD cipher suite? 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. > - "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. 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. > Editorials: > > - "in Section Those" > - formatting of the list in section 5 I'll fix that, thanks. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt
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 on behalf of "internet-dra...@ietf.org" Reply to: "emu@ietf.org" Date: Wednesday, 29 July 2020 at 23:04 To: "i-d-annou...@ietf.org" Cc: "emu@ietf.org" 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 Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
