RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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

Note: This RFC has been updated by RFC 9427

Source of RFC: emu (sec)

Errata ID: 5770
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Jouni Malinen
Date Reported: 2019-07-01
Held for Document Update by: Paul Wouters
Date Held: 2024-04-02

Section 5.4 says:

   TEAP authentication assures the Master Session Key (MSK) and Extended
   Master Session Key (EMSK) output from the EAP method are the result
   of all authentication conversations by generating an Intermediate
   Compound Key (IMCK).  The IMCK is mutually derived by the peer and
   the server as described in Section 5.2 by combining the MSKs from
   inner EAP methods with key material from TEAP Phase 1.  The resulting
   MSK and EMSK are generated as part of the IMCKn key hierarchy as
   follows:

      MSK  = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)
      EMSK = TLS-PRF(S-IMCK[j],
           "Extended Session Key Generating Function", 64)

   where j is the number of the last successfully executed inner EAP
   method.

Notes:

Section 5.4 claims that IMCK (and as such, also) S-IMCK[j] is derived by combining the MSKs from inner EAP methods while Section 5.2 talks about two different derivations: one based on MSK and the other one based on EMSK. Section 5.2 seems clear on both MSK and EMSK based values being used in Compound MAC (since both are actually included in the Crypto-Binding TLV). However, Section 5.2 does not clarify how a unique S-IMCK[j] should be derived since there can be two different IMSK[j] values based on whether the inner EAP method generates MSK and EMSK. This gets even more confusing if there is a series of inner EAP methods of which at least one generates both MSK and EMSK, at least one generates only MSK, and at least one does not generate either MSK or EMSK. How exactly would MSK/EMSK from TEAP be derived in those cases? Based on Section 5.4, these are based on S-IMCK[j], but it is not clear how that is derived due to Section 5.2 having three different ways of deriving the IMSK[j] and two different Compound MAC values (and consequently, two different ways of deriving S-IMCK[j] after each successfully completed EAP authentication method).

It does not look like this could work in practice. There needs to be a clear definition of how to derive a single S-IMCK[j] value for TEAP MSK/EMSK derivation. It would also be helpful to clarify how CMK[j] is derived for each inner EAP method in case of different MSK/EMSK derivation support between the EAP methods used in the sequence.

Paul Wouters(AD): This is curently all addressed in the 7170bis draft

Report New Errata



Advanced Search