This change looks good to me. Would appreciate a sanity check of another
implementation by Oleg to make sure I have my facts straight here.
From: Joseph Salowey
Sent: Sunday, November 22, 2020 9:24 PM
To: Jorge Vergara
Cc: Oleg Pekar ; EMU WG ; Jouni
Malinen
Subject: Re: Proposed Resolution f
On Thu, Nov 19, 2020 at 8:53 PM Jorge Vergara
wrote:
> Sorry for the last minute comment on this one before the meeting. I would
> like to mark this as a “discuss” - I have some compat concern about making
> the TLV length variable. Current implementations truncate the MAC field at
> 20 octets. A
Sorry for the last minute comment on this one before the meeting. I would like
to mark this as a “discuss” - I have some compat concern about making the TLV
length variable. Current implementations truncate the MAC field at 20 octets.
Although I agree in spirit with the direction of this change,
On Sat, Oct 24, 2020 at 4:29 PM Oleg Pekar
wrote:
> > 2 The EAP Type sent by the other party in the first TEAP message. This
> is a single octet encoded as (0x37)
>
> Shouldn't we clarify the motivation for placing the octet with TEAP type
> 0x37 into the BUFFER? Joe, I remember you explained th
> 2 The EAP Type sent by the other party in the first TEAP message. This
is a single octet encoded as (0x37)
Shouldn't we clarify the motivation for placing the octet with TEAP type
0x37 into the BUFFER? Joe, I remember you explained that it is for
protection against cross protocol attacks if Cry
Errata 5768: https://www.rfc-editor.org/errata/eid5768
Proposed State: Verified
Revision:
Section 4.2.13. Says:
Length
76
It should say:
Length
36 plus the length of the 2 MAC fields
Section 4.2.13. Says:
EMSK Compound MAC
The EMSK Compound MAC field is 20 octets. This
