Re: [Emu] draft-dekok-emu-tls-eap-types discussion

[Joseph Salowey <[e-mail]>]

On Tue, Apr 21, 2020 at 11:02 AM Oleg Pekar <[e-mail]>
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://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.
>
> [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://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 <[e-mail]>
> 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 <[e-mail]>
>> Sent: Thursday, April 16, 2020 3:25 AM
>> To: Oleg Pekar <[e-mail]>
>> Cc: Jorge Vergara <[e-mail]>; EMU WG <[e-mail]>
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu
>