On Sat, Oct 24, 2020 at 4:29 PM Oleg Pekar <oleg.pekar.2...@gmail.com> 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 that it is for > protection against cross protocol attacks if Crypto-Binding TLV was reused > (e.g. from PEAP). > [Joe] That's more of an editorial comment that we would hold for a document revision. I think we should try to keep the revision text at a minimum, but we certainly can include this information in the errata notes. > On Sun, Oct 25, 2020 at 12:45 AM Joseph Salowey <j...@salowey.net> wrote: > >> 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 can be the Server >> MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the >> MAC is described in Section 5.3. >> >> MSK Compound MAC >> >> The MSK Compound MAC field is 20 octets. This can be the Server >> MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the >> MAC is described in Section 5.3. >> >> It Should Say: >> >> EMSK Compound MAC >> >> The computation of the MAC is described in Section 5.3. This can >> be >> the Server MAC (B1_MAC) or the Client MAC (B2_MAC). >> >> MSK Compound MAC >> >> The computation of the MAC is described in Section 5.3. This can >> be >> the Server MAC (B1_MAC) or the Client MAC (B2_MAC). >> >> Section 5.3 Says: >> >> The Compound MAC computation is as follows: >> >> CMK = CMK[j] >> Compound-MAC = MAC( CMK, BUFFER ) >> >> where j is the number of the last successfully executed inner EAP >> method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and >> BUFFER is created after concatenating these fields in the following >> order: >> >> 1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK >> Compound MAC fields zeroed out. >> >> 2 The EAP Type sent by the other party in the first TEAP message. >> >> It Should say: >> >> The Compound MAC computation is as follows: >> >> CMK = CMK[j] >> Compound-MAC = MAC( CMK, BUFFER ) >> >> where j is the number of the last successfully executed inner EAP >> method, MAC is HMAC [RFC2104] using the hash function negotiated in >> TLS [RFC5246]. The output length is the length of the output of the >> HMAC >> function. The BUFFER is created after concatenating these fields in >> the following order: >> >> 1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK >> Compound MAC fields zeroed out. >> >> 2 The EAP Type sent by the other party in the first TEAP message. This >> is a single octet encoded as (0x37) >> >> Notes: >> >> This corrects the problem that the MAC output will vary depending upon >> the TLS hash function. It clarifies that HMAC is used with the hash >> function negotiated in TLS. It also clarifies that the EAP Type used in >> the TLS message is the TEAP EAP type encoded as a single byte. >> >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
