nday, 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
ure 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 discuss
gt;> >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 no
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],
&g
om: 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 th
es.
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 re
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
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
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
*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
&g
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
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
>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.
>*
13 matches
Mail list logo
