Subject: [Emu] Proposed Resolution for TEAP errata 5768

From: Joseph Salowey <[email-masked]>
Date: Sat, 24 Oct 2020 14:45:31 -0700

Errata 5768:  https://www.rfc-editor.org/errata/eid5768
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.

---

From: Oleg Pekar <[email-masked]>
Date: Sun, 25 Oct 2020 01:29:37 +0200

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

---

From: Joseph Salowey <[email-masked]>
Date: Sat, 24 Oct 2020 17:19:53 -0700

> protection against cross protocol attacks if Crypto-Binding TLV was reused

[Joe]  That's more of an editorial comment that we would hold for a
document revision.  I think we should try to keep the revision text at a
minimum, but we certainly can include this information in the errata
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.
>>
>