Subject: Re: [Emu] Proposed Resolution for TEAP errata 5768

From: Jorge Vergara <[email-masked]>
Date: Thu, 10 Dec 2020 17:53:12 +0000

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 <[email-masked]>
Sent: Sunday, November 22, 2020 9:24 PM
To: Jorge Vergara <[email-masked]>
Cc: Oleg Pekar <[email-masked]>; EMU WG <[email-masked]>; Jouni Malinen <[email-masked]>
Subject: Re: Proposed Resolution for TEAP errata 5768

On Thu, Nov 19, 2020 at 8:53 PM Jorge Vergara <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>>
Sent: Saturday, October 24, 2020 4:30 PM
To: Joseph Salowey <[email-masked]<mailto:[email-masked]>>
Cc: EMU WG <[email-masked]<mailto:[email-masked]>>; Jouni Malinen <[email-masked]<mailto:[email-masked]>>; Jorge Vergara <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> 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.