> > >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, Jouni, agree with the approach.
Jorge, please note that the same problem exists in PEAP Crypto-Binding TLV as specified in its documentation <https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-peap/ebb2b12b-cd53-4f3a-afed-36588566c7c2> - when one side has an inner method that provided MSK and another side has this inner method that didn't provide MSK. There is also a case where no inner method is executed. For example, when client certificate was received during TEAP outer tunnel establishment. In this case we also need to use zero-MSK. For such case both values of the flag work - "0 for zero-MSK" and "2 for MSK". This creates unnecessary ambiguity and thus would be better to request using flag's value "0" for zero MSK in such case (today we use value "2" and it doesn't create ambiguity). However there's a question here: in case of TEAP certificate based authentication that is typically done by running inner method EAP-TLS, should we allow in sending client certificate during TEAP tunnel establishment or inside the tunnel and this way skipping EAP-TLS inner method? On one hand it makes authentication shorter. On the other hand it causes switching from MSK/EMSK exported by the inner method EAP-TLS to zero-MSK. If we do allow skipping any inner method then we need explicitly say that zero-MSK should be used in such case. I've started rebuilding section "5.2 <https://tools.ietf.org/html/rfc7170#section-5.2>. Intermediate Compound Key Derivations" of the RFC according to the proposal on this thread and will post it here shortly. ~ Oleg On Mon, Apr 20, 2020 at 3:57 AM Jorge Vergara <jover...@microsoft.com> wrote: > >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
