Subject: [Emu] Proposed resolution for TEAP errata 5775

From: Joseph Salowey <[email-masked]>
Date: Sun, 25 Oct 2020 11:15:42 -0700

Errata 5775: https://www.rfc-editor.org/errata/eid5775
Proposed Status: Verified
Revision:

Section 5.2 Says:

    S-IMCK[j] = first 40 octets of IMCK[j]
    CMK[j] = last 20 octets of IMCK[j]

where TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246].

It Should say:

    S-IMCK[j] = first 40 octets of IMCK[j]
    CMK[j] = last 20 octets of IMCK[j]

where TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246].
If no inner EAP method has been run the S-IMCK and CMK are generated as
above from S-IMCK[0].

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.  If an inner EAP method is not
 executed with successful authentication then the EMSK Compound MAC
 field contains the MAC using keys generated according to section 5.2.
 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:

Notes:

How to calculate the CMK and other keys when no inner method was run was
unspecified.  This revision specifies that the CMK is generated from
S-IMSK[0]
and the MAC goes into the EMSK field.

---

From: Oleg Pekar <[email-masked]>
Date: Mon, 26 Oct 2020 10:25:19 +0200

> If no inner EAP method has been run the S-IMCK and CMK are generated as

Joe, for me it still doesn't sound as exact enough instructions. We should
explain how to generate S-IMCK and CMK for no inner method case with more
details.

>  EAP method authentication or not.

This still remains an open question whether we MUST send Crypto-Binding TLV
after Basic-Password-Authentication exchange or not. Is
Basic-Password-Authentication treated just as a case of no inner EAP
authentication method? It is also discussed in the errata 5844 thread.

Regarding introduction of Zero-MSK flag in Crypto-Binding TLV - do you
think it is unnecessary? So if one peer doesn't export a specific inner
method MSK and ESMK and uses Zero-MSK and another peer expects MSK or ESMK
- then the Crypto-Binding TLV exchange will fail naturally. Maybe it's
worth saying exactly that if the inner method exports MSK or EMSK then each
peer MUST use it and not Zero-MSK.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 26 Oct 2020 20:22:00 -0700

> explain how to generate S-IMCK and CMK for no inner method case with more
[Joe]  Good catch,  S-IMCK[0] is only 40 octets.   Looking at this I think
it makes more sense to Change

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).

To:

If the jth inner method does not generate an EMSK or MSK, or no inner

  method has been run then IMSK[j] is set to zero (32 octets of 0x00s).

> This still remains an open question whether we MUST send Crypto-Binding
> TLV after Basic-Password-Authentication exchange or not. Is
> [Joe] I don't think so, but let's discuss on the 5844 thread.

> peer MUST use it and not Zero-MSK.

[Joe]  It doesn't seem to me that the Zero-MSK flag is necessary, I'd
rather not add new signals if we do not need them now.  If a method
generates an MSK then I think it must be used.   We can add a sentence
saying that to the above revision.

 If the jth inner method does not generate an EMSK or MSK, or no inner

 method has been run then IMSK[j] is set to zero (32 octets of 0x00s).

 If a method generates an MSK or EMSK the zero IMSK MUST NOT be used.