Re: [Emu] draft-dekok-emu-tls-eap-types discussion
On Mon, Jun 22, 2020 at 9:06 PM Jorge Vergara 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 > *Sent:* Monday, June 22, 2020 8:53 PM > *To:* Oleg Pekar > *Cc:* Jorge Vergara ; Jouni Malinen ; > EMU WG > *Subject:* Re: [Emu] draft-dekok-emu-tls-eap-types discussion > > > > > > > > On Tue, Apr 21, 2020 at 11:02 AM Oleg Pekar > 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=02%7C01%7Cjovergar%40microsoft.com%7Cf691061f596040be882d08d81728fe5f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637284812133625099=9B%2BrGF9AduXXuERXbDh4tTTT4I%2BnVjOI1GrLwWJNPkY%3D=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 me
Re: [Emu] draft-dekok-emu-tls-eap-types discussion
>[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 Sent: Monday, June 22, 2020 8:53 PM To: Oleg Pekar Cc: Jorge Vergara ; Jouni Malinen ; EMU WG Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion On Tue, Apr 21, 2020 at 11:02 AM Oleg Pekar 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=02%7C01%7Cjovergar%40microsoft.com%7Cf691061f596040be882d08d81728fe5f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637284812133625099=9B%2BrGF9AduXXuERXbDh4tTTT4I%2BnVjOI1GrLwWJNPkY%3D=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
Re: [Emu] draft-dekok-emu-tls-eap-types discussion
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 >> Sent: Thursday, April 16, 2020 3:25 AM >> To: Oleg Pekar >> Cc: Jorge Vergara ; EMU WG >> 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 > this even happen?>. Set S-IMCK[j] based on this IMSK[j]. This results in &g
Re: [Emu] draft-dekok-emu-tls-eap-types discussion
> > >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 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 > Sent: Thursday, April 16, 2020 3:25 AM > To: Oleg Pekar > Cc: Jorge Vergara ; EMU WG > Subject: Re: [Emu] dra
Re: [Emu] draft-dekok-emu-tls-eap-types discussion
>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 Sent: Thursday, April 16, 2020 3:25 AM To: Oleg Pekar Cc: Jorge Vergara ; EMU WG 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 inclu
Re: [Emu] draft-dekok-emu-tls-eap-types discussion
Apologies for a second round of feedback after some more time reviewing the
document contents.
Section 3 of the document describes how tunneled methods should the possibility
of Post-Handshake messages in TLS 1.3. As discussed on this mail thread:
https://mailarchive.ietf.org/arch/msg/emu/0MeocWZQLCv1pST5_2jW_ABlpMo/
it is possible for the methods in this discussion to skip the phase 2 "tunnel"
completely. Thus it seems that a similar approach as is being taken for EAP-TLS
would be needed here, since there may be no application data exchanged after
the TLS handshake completes.
Jorge Vergara
-Original Message-
From: Alan DeKok
Sent: Sunday, April 19, 2020 9:17 AM
To: Jorge Vergara
Cc: EMU WG
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion
On Apr 7, 2020, at 5:09 PM, Jorge Vergara wrote:
> On the document contents themselves, I have this review: The key derivation
> proposed for TEAP/FAST uses the definition from FAST, which is not identical
> to the TEAP derivation. Namely, FAST used MSK[j] in the derivation, but TEAP
> uses IMSK[j], which may be equivalent in some cases, but may not in others
> where the inner method exports an EMSK.
>
> Specifically, I believe this line of section 2.2 should change from
> IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound
> Keys", S-IMCK[j-1] | MSK[j], 60) To
> IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound
> Keys", S-IMCK[j-1] | IMSK[j], 60) For TEAP.
I've made the change, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-dekok-emu-tls-eap-types discussion
No hat! I support the adoption of this document! --Mohit On 4/3/20 11:48 PM, Alan DeKok wrote: > https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-01 > >I haven't seen much discussion on the document. There are still some open > questions: > > * should it be published simultaneously with draft-ietf-emu-eap-tls13? > If so, we need some consensus on this document, and quick. > > If not, when do we publish this draft? Microsoft has already said that > they won't rev their EAP-TLS implementation until they can also rev PEAP. > > * Should the document simply drop references to FAST? >It looks like the effort has moved to TEAP. >Perhaps we should note that FAST cannot be used with TLS 1.3, and that > TEAP should be used instead > > * should the document drop references to TEAP? > Given Jouni Malinen's comments on implementing TEAP, it may be worth simply > noting that we're waiting for a TEAP update document > > * Without FAST / TEAP, the document is about 4 pages of text. Is there > anything controversial, missing, etc? > > * What are the barriers to adoption and publication? > >Alan DeKok. > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-dekok-emu-tls-eap-types discussion
On Apr 7, 2020, at 5:09 PM, Jorge Vergara wrote:
> On the document contents themselves, I have this review: The key derivation
> proposed for TEAP/FAST uses the definition from FAST, which is not identical
> to the TEAP derivation. Namely, FAST used MSK[j] in the derivation, but TEAP
> uses IMSK[j], which may be equivalent in some cases, but may not in others
> where the inner method exports an EMSK.
>
> Specifically, I believe this line of section 2.2 should change from
> IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
> S-IMCK[j-1] | MSK[j], 60)
> To
> IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
> S-IMCK[j-1] | IMSK[j], 60)
> For TEAP.
I've made the change, thanks.
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
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 . 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 MalinenPGP id EFC895FA ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] draft-dekok-emu-tls-eap-types discussion
>>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? >You clarification is what I understood the intention of the RFC to be as well, and makes sense to me. I don’t think there needs to be a protocol update if this clarification sounds good to all parties. I would welcome Jouni’s thoughts as the filer of the errata. Good! Then we can leave the protocol unchanged but re-write the relevant sections 5.2, 5.3 and maybe 5.4 to define clearly the algorithm. Right, it would be great to hear from Jouni whether this will satisfy the Errata 5770. Oleg On Wed, Apr 15, 2020 at 9:31 PM Jorge Vergara wrote: > > For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning > to find the common method of TLS 1.3 support for all three or you just want > to release TLS 1.3 support at the same time for all three? > > > > It’s not our intention to try to force the same solution for every method. > We plan to update our implementations at the same time, since we anticipate > the updates will be similar (though not necessarily identical). > > > > >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? > > > > You clarification is what I understood the intention of the RFC to be as > well, and makes sense to me. I don’t think there needs to be a protocol > update if this clarification sounds good to all parties. I would welcome > Jouni’s thoughts as the filer of the errata. > > > > Jorge > > > > *From:* Emu *On Behalf Of * Oleg Pekar > *Sent:* Wednesday, April 15, 2020 9:25 AM > *To:* Jorge Vergara > *Cc:* EMU WG > *Subject:* Re: [Emu] draft-dekok-emu-tls-eap-types discussion > > > > Hi Jorge, > > For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning > to find the common method of TLS 1.3 support for all three or you just want > to release TLS 1.3 support at the same time for all three? > > > > 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. > > > > 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. > > > > 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? > > > > Thanks > > Oleg > > > > > > On Wed, Apr 8, 2020 at 12:09 AM Jorge Vergara 40microsoft@dmarc.ietf.org> wrote: > > >Microsoft has already said that they won't rev their EAP-TLS > implementation until they can also rev PEAP. > > PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the > same time and will postpone TLS 1.3 support until such a time as we are > able to make the updates together. > > >* should the document drop references to TEAP? > > Given Jouni Malinen's comments on implementing TEAP, it may be worth > simply noting that we're waiting for a TEAP update document > > I've reviewed the current errata, and acknowledge their validity, but am > not sure that any of them would impact this document. > > The most relevant errata to this document seems to be > https://www.rfc-editor.org/errata/eid5770 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5770=02%7C01%7Cjovergar%40mi
Re: [Emu] draft-dekok-emu-tls-eap-types discussion
> For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning to > find the common method of TLS 1.3 support for all three or you just want to > release TLS 1.3 support at the same time for all three? It’s not our intention to try to force the same solution for every method. We plan to update our implementations at the same time, since we anticipate the updates will be similar (though not necessarily identical). >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? You clarification is what I understood the intention of the RFC to be as well, and makes sense to me. I don’t think there needs to be a protocol update if this clarification sounds good to all parties. I would welcome Jouni’s thoughts as the filer of the errata. Jorge From: Emu On Behalf Of Oleg Pekar Sent: Wednesday, April 15, 2020 9:25 AM To: Jorge Vergara Cc: EMU WG Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion Hi Jorge, For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning to find the common method of TLS 1.3 support for all three or you just want to release TLS 1.3 support at the same time for all three? 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. 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. 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? Thanks Oleg On Wed, Apr 8, 2020 at 12:09 AM Jorge Vergara mailto:40microsoft@dmarc.ietf.org>> wrote: >Microsoft has already said that they won't rev their EAP-TLS implementation >until they can also rev PEAP. PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the same time and will postpone TLS 1.3 support until such a time as we are able to make the updates together. >* should the document drop references to TEAP? > Given Jouni Malinen's comments on implementing TEAP, it may be worth simply > noting that we're waiting for a TEAP update document I've reviewed the current errata, and acknowledge their validity, but am not sure that any of them would impact this document. The most relevant errata to this document seems to be https://www.rfc-editor.org/errata/eid5770<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5770=02%7C01%7Cjovergar%40microsoft.com%7C5d8493e9a66549355c6508d7e1599c5f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637225647341455297=VWIJTVrYLPWmg6JOPrWbiwtUJGHktaFoxGusqldLHrg%3D=0>. As noted in the errata, the calculation of keys becomes confusing when methods export both MSK and EMSK because it is not clearly specified which value IMCK[j] should take on during the calculation of S-IMCK[j]. The addition of clarifying information is welcome, but I don't believe this ambiguity currently prevents a compliant implementation - for example, an implementation could avoid this ambiguity by choosing to use either the MSK/EMSK exclusively, and communicating that to the server via the Compound MAC TLV. The server can then make a policy decision on whether it is accepting of this decision by the client and follow suit, or reject the client. The specifics of resolving this particular errata is a digression from my main point - I believe a clarification can be added to the main TEAP document at a future time without impacting the contents of this document. Ambiguity about which IMCK to use in S-IMCK calculation should not impact the definition of the cryptographic calculations. On the document contents themselves, I have this review: The key derivation prop
Re: [Emu] draft-dekok-emu-tls-eap-types discussion
Hi Jorge,
For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning to
find the common method of TLS 1.3 support for all three or you just want to
release TLS 1.3 support at the same time for all three?
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.
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.
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?
Thanks
Oleg
On Wed, Apr 8, 2020 at 12:09 AM Jorge Vergara wrote:
> >Microsoft has already said that they won't rev their EAP-TLS
> implementation until they can also rev PEAP.
>
> PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the
> same time and will postpone TLS 1.3 support until such a time as we are
> able to make the updates together.
>
> >* should the document drop references to TEAP?
> > Given Jouni Malinen's comments on implementing TEAP, it may be worth
> simply noting that we're waiting for a TEAP update document
>
> I've reviewed the current errata, and acknowledge their validity, but am
> not sure that any of them would impact this document.
>
> The most relevant errata to this document seems to be
> https://www.rfc-editor.org/errata/eid5770. As noted in the errata, the
> calculation of keys becomes confusing when methods export both MSK and EMSK
> because it is not clearly specified which value IMCK[j] should take on
> during the calculation of S-IMCK[j]. The addition of clarifying information
> is welcome, but I don't believe this ambiguity currently prevents a
> compliant implementation - for example, an implementation could avoid this
> ambiguity by choosing to use either the MSK/EMSK exclusively, and
> communicating that to the server via the Compound MAC TLV. The server can
> then make a policy decision on whether it is accepting of this decision by
> the client and follow suit, or reject the client.
>
> The specifics of resolving this particular errata is a digression from my
> main point - I believe a clarification can be added to the main TEAP
> document at a future time without impacting the contents of this document..
> Ambiguity about which IMCK to use in S-IMCK calculation should not impact
> the definition of the cryptographic calculations.
>
> On the document contents themselves, I have this review: The key
> derivation proposed for TEAP/FAST uses the definition from FAST, which is
> not identical to the TEAP derivation. Namely, FAST used MSK[j] in the
> derivation, but TEAP uses IMSK[j], which may be equivalent in some cases,
> but may not in others where the inner method exports an EMSK.
>
> Specifically, I believe this line of section 2.2 should change from
> IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
> S-IMCK[j-1] | MSK[j], 60)
> To
> IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
> S-IMCK[j-1] | IMSK[j], 60)
> For TEAP.
>
> Jorge
>
> -Original Message-
> From: Emu On Behalf Of Alan DeKok
> Sent: Friday, April 3, 2020 1:48 PM
> To: EMU WG
> Subject: [Emu] draft-dekok-emu-tls-eap-types discussion
>
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools..ietf.org%2Fhtml%2Fdraft-dekok-emu-tls-eap-types-01data=02%7C01%7Cjovergar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215437188744711sdata=ndLp%2FSzsDlX%2FKYx0UR0uf77rHgCjGej4kdZPpywuD9Q%3Dreserved=0
>
> I haven't seen much discussion on the document. There are still some
> open questions:
>
> * should it be published simultaneously with draft-ietf-emu-eap-tls13?
>If so, we need some consensus on this document, and quick.
>
>If not, when do we publish this draft? Microsoft has already said that
> they won't rev their EAP-TLS
Re: [Emu] draft-dekok-emu-tls-eap-types discussion
>Microsoft has already said that they won't rev their EAP-TLS implementation
>until they can also rev PEAP.
PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the same
time and will postpone TLS 1.3 support until such a time as we are able to make
the updates together.
>* should the document drop references to TEAP?
> Given Jouni Malinen's comments on implementing TEAP, it may be worth simply
> noting that we're waiting for a TEAP update document
I've reviewed the current errata, and acknowledge their validity, but am not
sure that any of them would impact this document.
The most relevant errata to this document seems to be
https://www.rfc-editor.org/errata/eid5770. As noted in the errata, the
calculation of keys becomes confusing when methods export both MSK and EMSK
because it is not clearly specified which value IMCK[j] should take on during
the calculation of S-IMCK[j]. The addition of clarifying information is
welcome, but I don't believe this ambiguity currently prevents a compliant
implementation - for example, an implementation could avoid this ambiguity by
choosing to use either the MSK/EMSK exclusively, and communicating that to the
server via the Compound MAC TLV. The server can then make a policy decision on
whether it is accepting of this decision by the client and follow suit, or
reject the client.
The specifics of resolving this particular errata is a digression from my main
point - I believe a clarification can be added to the main TEAP document at a
future time without impacting the contents of this document. Ambiguity about
which IMCK to use in S-IMCK calculation should not impact the definition of the
cryptographic calculations.
On the document contents themselves, I have this review: The key derivation
proposed for TEAP/FAST uses the definition from FAST, which is not identical to
the TEAP derivation. Namely, FAST used MSK[j] in the derivation, but TEAP uses
IMSK[j], which may be equivalent in some cases, but may not in others where the
inner method exports an EMSK.
Specifically, I believe this line of section 2.2 should change from
IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
S-IMCK[j-1] | MSK[j], 60)
To
IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
S-IMCK[j-1] | IMSK[j], 60)
For TEAP.
Jorge
-Original Message-
From: Emu On Behalf Of Alan DeKok
Sent: Friday, April 3, 2020 1:48 PM
To: EMU WG
Subject: [Emu] draft-dekok-emu-tls-eap-types discussion
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dekok-emu-tls-eap-types-01data=02%7C01%7Cjovergar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215437188744711sdata=ndLp%2FSzsDlX%2FKYx0UR0uf77rHgCjGej4kdZPpywuD9Q%3Dreserved=0
I haven't seen much discussion on the document. There are still some open
questions:
* should it be published simultaneously with draft-ietf-emu-eap-tls13?
If so, we need some consensus on this document, and quick.
If not, when do we publish this draft? Microsoft has already said that they
won't rev their EAP-TLS implementation until they can also rev PEAP.
* Should the document simply drop references to FAST?
It looks like the effort has moved to TEAP.
Perhaps we should note that FAST cannot be used with TLS 1.3, and that TEAP
should be used instead
* should the document drop references to TEAP?
Given Jouni Malinen's comments on implementing TEAP, it may be worth simply
noting that we're waiting for a TEAP update document
* Without FAST / TEAP, the document is about 4 pages of text. Is there
anything controversial, missing, etc?
* What are the barriers to adoption and publication?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=02%7C01%7Cjovergar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215437188744711sdata=lkoHzd0fgN4z1oalqV2jW9pewUGSnlRLeKpiFew4Yw8%3Dreserved=0
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
