>[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. 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. 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<mailto: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<mailto: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<mailto:j...@w1.fi>> Sent: Thursday, April 16, 2020 3:25 AM To: Oleg Pekar <oleg.pekar.2...@gmail.com<mailto:oleg.pekar.2...@gmail.com>> Cc: Jorge Vergara <jover...@microsoft.com<mailto:jover...@microsoft.com>>; EMU WG <emu@ietf.org<mailto: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<mailto: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
