>And focusing on that "what to do here.." part and the unused IMCK-zero[j] in >the previous paragraph.. >How is this supposed to work when an inner EAP authentication method does not >derive either MSK or EMSK? >Intermediate result indication of success needs to be done and that implies >there needs to be Crypto-Binding TLV. >But that TLV does not have option of indicating that neither EMSK Compound MAC >nor MSK Compound MAC are present (Flags field has no value 0 defined to do so).
I agree the 0 value should be explicitly listed for this purpose. Given the design of the flags I think it is clear this was the intended usage and its omission was likely an oversight. >So what are those fields (or one of them) supposed to be set to? >And how is that selected for an inner EAP authentication method j? >Does this depends on what happened with method j-1 (if one was present)? >How would the correct IMCK[j] be determined by the peer and the server if one >of them derived MSK/EMSK but the other one did not derive either for inner EAP >method j? Assuming we use the value 0 to indicate the state where one of the peers did not derive either MSK or EMSK, then I believe the RFC addresses this as MSKi = 32 octets of 0x00s. So if one side calculated neither MSK nor EMSK, and both sides decided to continue the conversion, then both sides would use the zero-MSK for that IMSK[j], Jorge Vergara -----Original Message----- From: Jouni Malinen <j...@w1.fi> Sent: Thursday, April 16, 2020 3:25 AM To: Oleg Pekar <oleg.pekar.2...@gmail.com> Cc: Jorge Vergara <jover...@microsoft.com>; EMU WG <emu@ietf.org> Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion On Wed, Apr 15, 2020 at 07:25:08PM +0300, Oleg Pekar wrote: > For TEAP errata 5770: > Technically TEAP RFC suggests the implicit method of taking the > correct IMSK[j] and all the subsequent keys after each inner method > via negotiation taking place in Crypto-Binding TLV exchange. What is "the correct IMSK[j]" and where is this defined? > Let's say we are on the inner method number j that supports both MSK > and EMSK and we are server which implementation generates both MSK and > EMSK for this inner method. We generated keys according to the rules > below - two sets, for IMSK[j] derived from inner method EMSK and for > IMSK[j] equal to inner method MSK. Because we don't know whether > client implementation supports both MSK and EMSK. > > S-IMCK[0] = session_key_seed > For j = 1 to n-1 do > IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", > IMSK[j], 60) > S-IMCK[j] = first 40 octets of IMCK[j] > CMK[j] = last 20 octets of IMCK[j] > > > So we have two CMK[j] and we create Crypto-Binding TLV with both > Compound MAC for MSK and EMSK. The client sends Crypto-Binding TLV in > response and we can understand from it whether it supports EMSK for > this inner method or not. And here we can decide which version of > IMCK[j] to take for this inner method - derived from EMSK or MSK. This > is just not explicitly specified in the RFC. Is this the proposed definition of "the correct IMSK[J]"? In other words, is this to be understood to have two (or three since we have the no MSK/EMSK case as well) variants of IMSK[j] during an execution of an internal AP authentication method and a single one of those variants is selected as _the correct_ IMSK[j] at the successful conclusion of this inner authentication method? Would this single "correct IMSK[j]" then be used for deriving the different variants of IMSK[j+1] instead of using EMSK-based-IMSK[j] when deriving EMSK-based-IMSK[j+1]? In other words, is this to work by having all following inner authentication rounds and MSK/EMSK derivation to behave as if the other variants of IMSK[j] never really existed? > Could this method work? Should we make it more clearly specified? Or > should we change the protocol to arrive explicitly to the > understanding which type > (MSK/EMSK) of IMSK[j] to use? Regardless of what is done for the design, it will absolutely need to be specified more clearly. If I understood the proposed design correctly, this should be defined with something like following: For each successful inner EAP authentication method, derive IMCK-MSK[j] (if MSK was derived by the inner method), derive IMCK-EMSK[j] (if EMSK was derived by the inner method), derive IMSK-zero[j] (for all cases). Derive CMK-MSK[j] from IMCK-MSK[j] and CMK-EMSK[j] from IMCK-EMSK[j] (both: if available). Generate Crypto-Binding TLV with all available Compound MAC values. Also verify Crypto-Binding TLV with all available Compound MAC values. After both ends have transmitted and received Crypto-Binding TLV, set IMSK[j] to be IMCK-EMSK[j] if both ends included EMSK Compound MAC, or set IMSK[j] to be IMCK-MSK[j] if both ends included MSK Compound MAC but either end did not include EMSK Compound MAC, or <what to do here or can this even happen?>. Set S-IMCK[j] based on this IMSK[j]. This results in there being only a single S-IMCK[j] and MSK/EMSK derivation being well defined. And focusing on that "what to do here.." part and the unused IMCK-zero[j] in the previous paragraph.. How is this supposed to work when an inner EAP authentication method does not derive either MSK or EMSK? Intermediate result indication of success needs to be done and that implies there needs to be Crypto-Binding TLV. But that TLV does not have option of indicating that neither EMSK Compound MAC nor MSK Compound MAC are present (Flags field has no value 0 defined to do so). So what are those fields (or one of them) supposed to be set to? And how is that selected for an inner EAP authentication method j? Does this depends on what happened with method j-1 (if one was present)? How would the correct IMCK[j] be determined by the peer and the server if one of them derived MSK/EMSK but the other one did not derive either for inner EAP method j? -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
