On Mon, Jun 22, 2020 at 9:06 PM Jorge Vergara <jover...@microsoft.com> wrote:
> >[Joe] (catching up) With respect to the case that the method is an MSK > generating mechanism and and MSK is not generated/used. I think the > original intention was that this case would be a protocol violation, ie if > a method generates an MSK it should be available for crypto-binding. I'm > concerned that allowing the fallback to 0 MSK actually will cause a > security vulnerability in compound binding. Do we know if this method > mismatch is a problem in practice? > > > > [jovergar] I agree that if a method generates an MSK it should generally > be used for crypto-binding. But this does not eliminate the need for a > mechanism for each party (client/server) to communicate what kind of > crypto-binding they are sending. The client/server is free to reject the > crypto-binding if the peer is unable to produce a crypto-binding that > satisfies the minimum policy of the implementation. > > > For example, if EAP-TLS is used as an inner method, and a client sends a > zero-MSK, I would fully expect the server to reject the connection – not > fallback to zero-MSK. I would expect a client to have similar minimum > security policies it would accept for each method. > > > [Joe] I agree that there will be some policy needed on the client and server, but I think the policy for this specific case (method supports MSK but it is not used) could be built into the protocol and simplify things. > As to whether method mismatch is a problem in practice – yes, to an > extent. Windows does not generate EMSK for EAP-TLS despite it being > specified in the RFC, so the crypto-binding sent to the server is MSK > based. If a server’s policy requires EMSK, then Windows can’t connect. This > is certainly a Windows feature gap – but servers are free to decline the > connection if they do not want to downgrade to an MSK based crypto binding. > [Joe] Yes, and I'm sure this is not the only case where EMSK is defined for a method but not implemented. While it would be better if everyone implemented and used the EMSK, the MSK is better than using 0. I agree clients and servers will need some policy in this case. The policy does complicate the protocol and implementation. > > *From:* Joseph Salowey <j...@salowey.net> > *Sent:* Monday, June 22, 2020 8:53 PM > *To:* Oleg Pekar <oleg.pekar.2...@gmail.com> > *Cc:* Jorge Vergara <jover...@microsoft.com>; Jouni Malinen <j...@w1.fi>; > EMU WG <emu@ietf.org> > *Subject:* Re: [Emu] draft-dekok-emu-tls-eap-types discussion > > > > > > > > On Tue, Apr 21, 2020 at 11:02 AM Oleg Pekar <oleg.pekar.2...@gmail.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, Jouni, agree with the approach. > > > > Jorge, please note that the same problem exists in PEAP Crypto-Binding TLV > as specified in its documentation > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs..microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-peap%2Febb2b12b-cd53-4f3a-afed-36588566c7c2&data=02%7C01%7Cjovergar%40microsoft.com%7Cf691061f596040be882d08d81728fe5f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637284812133625099&sdata=9B%2BrGF9AduXXuERXbDh4tTTT4I%2BnVjOI1GrLwWJNPkY%3D&reserved=0> > - when one side has an inner method that provided MSK and another side has > this inner method that didn't provide MSK. > > > > [Joe] (catching up) With respect to the case that the method is an MSK > generating mechanism and and MSK is not generated/used. I think the > original intention was that this case would be a protocol violation, ie if > a method generates an MSK it should be available for crypto-binding. I'm > concerned that allowing the fallback to 0 MSK actually will cause a > security vulnerability in compound binding. Do we know if this method > mismatch is a problem in practice? > > > > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7170%23section-5.2&data=02%7C01%7Cjovergar%40microsoft.com%7Cf691061f596040be882d08d81728fe5f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637284812133635093&sdata=7xmEq1rNHYSq7qqa%2FSt4Z4XESqCc2FXTy%2F5X8Kob%2FBg%3D&reserved=0>*. > 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 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&data=02%7C01%7Cjovergar%40microsoft.com%7Cf691061f596040be882d08d81728fe5f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637284812133635093&sdata=sJ8Kt2EB%2Fj4fa8bErJvVs3koLowqr%2FD0LsOEB2wiwN8%3D&reserved=0> > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
