RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 7170, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", May 2014

Source of RFC: emu (sec)

Errata ID: 5768
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Jouni Malinen
Date Reported: 2019-06-29

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:

Notes:

This definition of how Compound MAC is computed is not compatible with the definition of Compound MAC fields in the Crypto-Binding TLV. Those fields have a fixed length of 20 octets based on Section 4.2.13 (and that TLV is claimed to have a fixed length of 76 octets). However, the MAC function negotiated in TLS have variable mac_length (e.g., MAC=SHA256 used HMAC-SHA256 with mac_length=32).

How is this supposed to work? Is Section 4.2.13 wrong in claiming that the Compound MAC fields are 20 octets? Or is Section 5.3 wrong in not specifying MAC() function to truncate the output to 20 octets? One of those need to be changed since the current design would work only with the mac_length=20 case (i.e., MAC=SHA with HMAC-SHA1).

Furthermore, that "TLS 1.2" part should not be hardcoding this to not allow TLS 1.3 or newer versions from being used.

It is also a bit strange to see the BUFFER include "The EAP Type sent by the other party in the first TEAP message." since that can only be EAP Type=TEAP, i.e., 55. If that is indeed a fixed value, it does not seem to add any protection for a negotiated parameter as a part of the crypto binding. Regardless, it would be good to be clearer in the text on how this "EAP Type" is to be encoded here (assumable it is a single octet field with value 0x37).

Report New Errata