> 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). 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
