Subject: [Emu] Revised Erratum for 5775

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

The section 5 revision is rewritten to reflect handling of the case where
no MSK is generated and text on handling the 0 MSK is moved from errata
5770.  this erratum could use more review.  Please comment on the list or
in the PR.

Section 4 PR - https://github.com/emu-wg/teap-errata/pull/12
Section 5 PR - https://github.com/emu-wg/teap-errata/pull/11

Errata ID: 5775 - https://www.rfc-editor.org/errata/eid5775
Status: verified
Type: Technical
Revision:

Section 4.2.13 Says:

The Crypto-Binding TLV MUST be exchanged and verified before the
 final Result TLV exchange, regardless of whether there is an inner
 EAP method authentication or not.  It MUST be included with the
 Intermediate-Result TLV to perform cryptographic binding after each
 successful EAP method in a sequence of EAP methods, before proceeding
 with another inner EAP method.  The Crypto-Binding TLV is valid only
 if the following checks pass:

It should say:

   The Crypto-Binding TLV MUST be exchanged and verified before the
   final Result TLV exchange, regardless of whether there is an inner
   EAP method authentication or not. It MUST be included with each
   successful Intermediate-Result TLV to perform cryptographic binding
   after each EAP authentication or basic password method, before
   proceeding with another authentication exchange.  If no MSK or EMSK
   has been generated and a Crypto-Binding TLS is required then the MSK
   Compound MAC field contains the MAC using keys generated according
   to section 5.2. The Crypto-Binding TLV is valid only if the following
   checks pass:

Section 5.2 says:

   The first step in these calculations is the generation of the base
   compound key, IMCK[n] from the session_key_seed, and any session keys
   derived from the successful execution of nth inner EAP methods.  The
   inner EAP method(s) may provide Inner Method Session Keys (IMSKs),
   IMSK1..IMSKn, corresponding to inner method 1 through n.

It should say:

   The first step in these calculations is the generation of the base
   compound key, IMCK[j] from the session_key_seed, and any session keys
   derived from the successful execution of jth inner EAP authentication
   methods or basic password authentication. The inner EAP method(s) may
   provide Inner Method Session Keys (IMSKs), IMSK1..IMSKn, corresponding
   to inner method 1 through n.  When the jth exchange, such as a basic
   password exchange, does not derive key material then a special 0 IMSK
   is used as described below.

Section 5.2 says:

   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:

   If no inner EAP authentication method is run then no EMSK or MSK
   will be generated (e.g. when basic password authentication
   is used or when no inner method has been run and the crypto-binding TLV
   for the Result-TLV needs to be generated).  In this case, IMSK[j]
   is set to zero (i.e., MSK = 32 octets of 0x00s).  If an inner method
   fails, then it is not included in this 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. The resulting
 MSK and EMSK are generated as part of the IMCKn key hierarchy as
 follows:

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 authentication and basic password methods with key material from
   TEAP Phase 1.  The resulting MSK and EMSK are generated as part of the
   IMCK key hierarchy as follows:

Notes:

This revision clarifies handling cases when the 0 MSK is used because no
key material is derived.

---

From: Oleg Pekar <[email-masked]>
Date: Wed, 11 Nov 2020 00:10:56 +0200

A typo: "Crypto-Binding TLS" ==> "Crypto-Binding TLV"