This revision has small changes to the text in the length field and changes the text that describes what j represents to the last successfully generated IMCK. I think this revision is ready. Please comment on the list or the PR if you do not think it is ready.
PR for section 5 is: https://github.com/emu-wg/teap-errata/pull/8 PR for section 4 is: https://github.com/emu-wg/teap-errata/pull/7 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 included 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 generated IMCK, 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. The use of the TEAP type is to prevent cross protocol attacks in the case that the same crypto-binding TLV structure is used in multiple EAP tunneling protocols.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
