[Emu] [Errata Verified] RFC7170 (5775)

[RFC Errata System <[e-mail]>]

The following errata report has been verified for RFC7170,
"Tunnel Extensible Authentication Protocol (TEAP) Version 1". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5775

--------------------------------------
Status: Verified
Type: Technical

Reported by: Jouni Malinen <[e-mail]>
Date Reported: 2019-07-04
Verified by: Paul Wouters (IESG)

Section: 5.

Original Text
-------------
   For authentication methods that generate keying material, further
   protection against man-in-the-middle attacks is provided through
   cryptographically binding keying material established by both TEAP
   Phase 1 and TEAP Phase 2 conversations.  After each successful inner
   EAP authentication, EAP EMSK and/or MSKs are cryptographically
   combined with key material from TEAP Phase 1 to generate a Compound
   Session Key (CMK).  The CMK is used to calculate the Compound MAC as
   part of the Crypto-Binding TLV described in Section 4.2.13, which
   helps provide assurance that the same entities are involved in all
   communications in TEAP.  During the calculation of the Compound MAC,
   the MAC field is filled with zeros.

   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:


Corrected Text
--------------
[Append to the end of section 5.3] 

If no key generating inner method is run then no EMSK or MSK will be generated. If an IMSK needs to be generated then the MSK and therefore the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x00s).

Notes
-----
Section 5.3 does not describe how CMK is derived for the case where not inner EAP authentication method is executed (e.g., when Basic-Password-Auth is used at TLV level). Section 5.4 seems to address that case by implying that S-IMCK = session_key_seed (S-IMCK[0] does indeed have that value, but MSK/EMSK derivation uses S-IMCK[j], so use of S-IMCK here is slightly misleading). This seems to imply that MSK/EMSK derivation uses S-IMCK[0] and as such, Compound MAC derivation might use CMK[0], but CMK[0] is not defined (Section 5.2 defines CMK[j] for j=1..n-1, but not for j=0.

Furthermore, Section 4.2.13 is not clear on what Flags should be used in Crypto-Binding TLV when no inner EAP authentication method is executed. The only three values defined for Flags (1..3) all imply that either EMSK or MSK (or both) based Compound MAC is present, but there is no inner EAP method MSK/EMSK in this case since no such inner EAP method was executed. Maybe a new Flags value should be defined or alternatively, the MSK Compound MAC case could be extended to cover this no inner-EAP case with CMK[0] defined as proposed above to calculate the MSK Compound MAC.

Paul Wouters(AD): Corrected Text provided by the WG and in 7170bis

--------------------------------------
RFC7170 (draft-ietf-emu-eap-tunnel-method-10)
--------------------------------------
Title               : Tunnel Extensible Authentication Protocol (TEAP) Version 1
Publication Date    : May 2014
Author(s)           : H. Zhou, N. Cam-Winget, J. Salowey, S. Hanna
Category            : PROPOSED STANDARD
Source              : EAP Method Update
Stream              : IETF
Verifying Party     : IESG