is TLV were reused. If we are going to change the
TLV/protocol version we could revisit this and other aspects of the
compound TLV to validate their security goals and implementation.
>
> Thanks
> Oleg
>
>
> On Tue, May 26, 2020 at 12:29 PM Jorge Vergara
> wrote:
>
>>
>
0 at 12:29 PM Jorge Vergara
wrote:
>
>
> *From:* Joseph Salowey
> *Sent:* Monday, May 25, 2020 9:27 PM
> *To:* Jorge Vergara
> *Cc:* Oleg Pekar ; Jouni Malinen ;
> EMU WG
> *Subject:* Re: [Emu] TEAP - RFC 7170 - Errata ID 5768
>
>
>
>
>
>
>
&g
From: Joseph Salowey
Sent: Monday, May 25, 2020 9:27 PM
To: Jorge Vergara
Cc: Oleg Pekar ; Jouni Malinen ; EMU WG
Subject: Re: [Emu] TEAP - RFC 7170 - Errata ID 5768
On Fri, May 22, 2020 at 1:18 PM Jorge Vergara
mailto:40microsoft@dmarc.ietf.org>>
wrote:
My review of this erra
etween similar
crypto binding implementations in other protocols such as EAP-FAST. I
don't think there is much ambiguity here, but I am OK with including 0x37
in the description.
>
>
> Thanks,
>
> Jorge
>
>
>
> *From:* Emu *On Behalf Of * Oleg Pekar
> *Sen
.
Thanks,
Jorge
From: Emu On Behalf Of Oleg Pekar
Sent: Tuesday, May 5, 2020 6:27 AM
To: Jouni Malinen ; EMU WG
Subject: [Emu] TEAP - RFC 7170 - Errata ID 5768
Hi Jouni,
I propose the following fix for the issues described in this errata id:
1) In Section "4.2.13. Crypto-Binding TLV"
Hi Jouni,
I propose the following fix for the issues described in this errata id:
1) In Section "4.2.13. Crypto-Binding TLV" make "EMSK Compound MAC" and
"MSK Compound MAC" fields 32 octets long (currently 20 octets). The MAC
value is truncated at 32 octets if it is longer than 32 octets or padded
