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
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
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
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,
14 matches
Mail list logo
