Subject: [Emu] Revised TEAP Erratum 5770

From: Joseph Salowey <[email-masked]>
Date: Sun, 1 Nov 2020 13:42:22 -0800

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.