This change looks good to me. Would appreciate a sanity check of another implementation by Oleg to make sure I have my facts straight here.
From: Joseph Salowey <j...@salowey.net> Sent: Sunday, November 22, 2020 9:24 PM To: Jorge Vergara <jover...@microsoft.com> Cc: Oleg Pekar <oleg.pekar.2...@gmail.com>; EMU WG <emu@ietf.org>; Jouni Malinen <j...@w1.fi> Subject: Re: Proposed Resolution for TEAP errata 5768 On Thu, Nov 19, 2020 at 8:53 PM Jorge Vergara <jover...@microsoft.com<mailto:jover...@microsoft.com>> wrote: Sorry for the last minute comment on this one before the meeting. I would like to mark this as a “discuss” - I have some compat concern about making the TLV length variable. Current implementations truncate the MAC field at 20 octets. Although I agree in spirit with the direction of this change, I think it would require changing the version of the Crypto-Binding TLV. I recognize that most probably won’t have time to review this concern before the meeting and so the discussion may not be able to occur there. Apologies again as I only realized this concern as I was giving everything a final pass-over. [Joe] Thanks for catching this. If this is the case then we should have the errata resolution reflect what implementations do and leave the rest of the change for a document update. For this I suggest that we leave section 4.2.13 unchanged and make changes to 5.3. Section 5.3 Says: The Compound MAC computation is as follows: CMK = CMK[j] Compound-MAC = MAC( CMK, BUFFER ) where j is the number of the last successfully executed inner EAP method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and BUFFER is created after concatenating these fields in the following order: 1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK Compound MAC fields zeroed out. 2 The EAP Type sent by the other party in the first TEAP message. It Should say: The Compound MAC computation is as follows: CMK = CMK[j] Compound-MAC = MAC( CMK, BUFFER ) where j is the number of the last successfully executed inner EAP method, MAC is HMAC [RFC2104] using the hash function negotiated in TLS [RFC5246]. If the output of the HMAC is greater than 20 bytes then it is truncated to 20 bytes. The BUFFER is created after concatenating these fields in the following order: 1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK Compound MAC fields zeroed out. 2 The EAP Type sent by the other party in the first TEAP message. This is a single octet encoded as (0x37) Jorge Vergara From: Oleg Pekar <oleg.pekar.2...@gmail.com<mailto:oleg.pekar.2...@gmail.com>> Sent: Saturday, October 24, 2020 4:30 PM To: Joseph Salowey <j...@salowey.net<mailto:j...@salowey.net>> Cc: EMU WG <emu@ietf.org<mailto:emu@ietf.org>>; Jouni Malinen <j...@w1.fi<mailto:j...@w1.fi>>; Jorge Vergara <jover...@microsoft.com<mailto:jover...@microsoft.com>> Subject: Re: Proposed Resolution for TEAP errata 5768 > 2 The EAP Type sent by the other party in the first TEAP message. This is a > single octet encoded as (0x37) Shouldn't we clarify the motivation for placing the octet with TEAP type 0x37 into the BUFFER? Joe, I remember you explained that it is for protection against cross protocol attacks if Crypto-Binding TLV was reused (e.g. from PEAP). On Sun, Oct 25, 2020 at 12:45 AM Joseph Salowey <j...@salowey.net<mailto:j...@salowey.net>> wrote: Errata 5768: https://www.rfc-editor.org/errata/eid5768<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5768&data=04%7C01%7Cjovergar%40microsoft.com%7C7011142d26864049db1808d88f6ffe5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637417058458652454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=J2HkST0fETP%2Fu5CJ789InRFFiI9OtX1awuKUhhDfBSQ%3D&reserved=0> Proposed State: Verified Revision: Section 4.2.13. Says: Length 76 It should say: Length 36 plus the length of the 2 MAC fields Section 4.2.13. Says: EMSK Compound MAC The EMSK Compound MAC field is 20 octets. This can be the Server MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC is described in Section 5.3. MSK Compound MAC The MSK Compound MAC field is 20 octets. This can be the Server MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC is described in Section 5.3. It Should Say: EMSK Compound MAC The computation of the MAC is described in Section 5.3. This can be the Server MAC (B1_MAC) or the Client MAC (B2_MAC). MSK Compound MAC The computation of the MAC is described in Section 5.3. This can be the Server MAC (B1_MAC) or the Client MAC (B2_MAC). Section 5.3 Says: The Compound MAC computation is as follows: CMK = CMK[j] Compound-MAC = MAC( CMK, BUFFER ) where j is the number of the last successfully executed inner EAP method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and BUFFER is created after concatenating these fields in the following order: 1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK Compound MAC fields zeroed out. 2 The EAP Type sent by the other party in the first TEAP message. It Should say: The Compound MAC computation is as follows: CMK = CMK[j] Compound-MAC = MAC( CMK, BUFFER ) where j is the number of the last successfully executed inner EAP method, MAC is HMAC [RFC2104] using the hash function negotiated in TLS [RFC5246]. The output length is the length of the output of the HMAC function. The BUFFER is created after concatenating these fields in the following order: 1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK Compound MAC fields zeroed out. 2 The EAP Type sent by the other party in the first TEAP message. This is a single octet encoded as (0x37) Notes: This corrects the problem that the MAC output will vary depending upon the TLS hash function. It clarifies that HMAC is used with the hash function negotiated in TLS. It also clarifies that the EAP Type used in the TLS message is the TEAP EAP type encoded as a single byte.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
