This is a detailed one so I’ve tried to go over it carefully. Most of it looks good but I’m unsure about this part:
> If an inner method fails or MAC verification fails then S-IMCK is not used in further calculation. It is a valid scenario that multiple authentication methods run and some fail, but the overall TEAP authentication succeeds. For example, if two inner EAP Authentication methods run and the first fails but the seconds succeeds, the calculation needs to be valid. Based on the old text, that authentication method is omitted from calculations. This is what current implementations do. My editorial comment based on some other errata would be to that text needs to specify “authentication” methods (per Jouni’s other errata) since the Identity method doesn’t factor in here. I think it would also be beneficial to be specific about the behavior of basic username and password authentication here. Oleg made some comments to this effect on another email. Our implementation doesn’t support basic username and password authentication so I don’t have any prior experience here. Jorge Vergara From: Joseph Salowey <[email protected]> Sent: Saturday, October 24, 2020 5:18 PM To: EMU WG <[email protected]> Cc: Oleg Pekar <[email protected]>; Jouni Malinen <[email protected]>; Jorge Vergara <[email protected]> Subject: Proposed Resolution to TEAP Errata 5770 Errata 5770: https://www.rfc-editor.org/errata/eid5770<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5770&data=04%7C01%7Cjovergar%40microsoft.com%7C728ceb6af6694e40e08e08d8787b669d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637391818689781723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RuRrXZ5c70r43Rmyl4s%2BVUKAA22nGtoenLElbCeUkmE%3D&reserved=0> 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 available and the sender's policy accepts MSK-based MAC, then the sender computes two Compound MAC values. The first is computed with the EMSK. The second one is computed using the MSK. Both MACs are then sent to the other side. If the EMSK is available but the sender's policy does not allow downgrading to MSK-generated MAC, then the sender SHOULD only send EMSK-based MAC. On the receiver of the Crypto-Binding TLV side: If the EMSK is not available and an MSK-based Compound MAC was sent, then the receiver validates the Compound MAC and sends back an MSK-based Compound MAC response. If the EMSK is not available and no MSK-based Compound MAC was sent, then the receiver handles like an invalid Crypto-Binding TLV with a fatal error. If the EMSK is available and an EMSK-based Compound MAC was sent, then the receiver validates it and creates a response Compound MAC using the EMSK. If the EMSK is available but no EMSK-based Compound MAC was sent and its policy accepts MSK-based MAC, then the receiver validates it using the MSK and, if successful, generates and returns an MSK- based Compound MAC. If the EMSK is available but no EMSK Compound MAC was sent and its policy does not accept MSK-based MAC, then the receiver handles like an invalid Crypto-Binding TLV with a fatal error. If the ith inner method does not generate an EMSK or MSK, then IMSKi is set to zero (e.g., MSKi = 32 octets of 0x00s). If an inner method fails, then it is not included in this calculation. It Should Say: On the sender of the Crypto-Binding TLV side: If the EMSK is not available, then the sender computes the Compound MAC using the CMK generated from MSK (CMK-MSK) of the inner method. If the EMSK is available and the sender's policy accepts MSK-based MAC, then the sender computes two Compound MAC values. The first is computed with the CMK generated from the EMSK (CMK-EMSK). The second one is computed using the CMK-MSK. Both MACs are then sent to the other side. This also means the sender must generate both EMSK and MSK based S-IMCKs. If the EMSK is available but the sender's policy does not allow downgrading to CMK-MSK MAC, then the sender SHOULD only send a MAC computed from the CMK-EMSK. On the receiver of the Crypto-Binding TLV side: If the EMSK is not available and an CMK-MSK Compound MAC was sent, then the receiver validates the Compound MAC and sends back an CMK-MSK Compound MAC response. If the EMSK is not available and no CMK-MSK Compound MAC was sent, then the receiver handles like an invalid Crypto-Binding TLV with a fatal error. If the EMSK is available and a CMK-EMSK Compound MAC was sent, then the receiver validates it and creates a response Compound MAC using the CMK-EMSK. If the EMSK is available but no CMK-EMSK Compound MAC was sent and its policy accepts CMK-MSK MAC, then the receiver validates it using the CMK-MSK and, if successful, generates and returns an MSK- based Compound MAC. If the EMSK is available but no CMK-EMSK Compound MAC was sent and its policy does not accept CMK-MSK MAC, then the receiver handles like an invalid Crypto-Binding TLV with a fatal error. The IMSK used is either the EMSK-based IMSK or the MSK based IMSK depending upon the rules outlined above. If the ith inner method does not generate an EMSK or MSK, then IMSKi is set to zero (e.g., MSKi = 32 octets of 0x00s). It is possible that two S-IMCKs for a step may be generated based on the rules above. In this case the S-IMCK for further calculations is chosen as follows. If the MAC based on the CMK-EMSK is verified then the S-IMCK generated based on the EMSK is used. Else, if the MAC based on the CMK-MSK is verified then the S-IMCK generated based on the MSK is used. If an inner method fails or MAC verification fails then S-IMCK is not used in further calculation. Section 5.4 Says: TEAP authentication assures the Master Session Key (MSK) and Extended Master Session Key (EMSK) output from the EAP method are the result of all authentication conversations by generating an Intermediate Compound Key (IMCK). The IMCK is mutually derived by the peer and the server as described in Section 5.2 by combining the MSKs from inner EAP methods with key material from TEAP Phase 1. It should say: TEAP authentication assures the Master Session Key (MSK) and Extended Master Session Key (EMSK) output from the EAP method are the result of all authentication conversations by generating an Intermediate Compound Key (IMCK). The IMCK is mutually derived by the peer and the server as described in Section 5.2 by combining the IMSKs from inner EAP methods with key material from TEAP Phase 1. Note: This revision is to clarify how to handle the case where you need to generate both MSK and EMSK keys. The original text was incomplete and ambiguous in some places.
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
