The following errata report has been held for document update for RFC7170, "Tunnel Extensible Authentication Protocol (TEAP) Version 1".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5770 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Jouni Malinen <j...@w1.fi> Date Reported: 2019-07-01 Held by: Paul Wouters (IESG) Section: 5.4 Original Text ------------- 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. Corrected Text -------------- 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] an d 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 -------------------------------------- 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
