This revision removes the modification to section 5.4 to erratum 5775. It also leaves the discussion of the 0 MSK to a separate paragraph to be revised in 5770. 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: https://github.com/emu-wg/teap-errata/pull/13 Errata ID: 5770 https://www.rfc-editor.org/errata/eid5770 Status: Verified Type: Technical 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. 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. 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. Notes: This revision clarifies handling cases where the EMSK may not be available and the MSK may not be allowed by policy.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
