Reviewer: Elwyn Davies
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more
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
> 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 5770: https://www.rfc-editor.org/errata/eid5770
Proposed Status: Verified
Revision:
Section 5.2 Says:
On the sender of the Crypto-Binding TLV side:
If the EMSK is not available, then the sender computes the Compound
MAC using the MSK of the inner method.
If the EMSK is ava
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
