Subject: [Emu] Proposed Resolution to TEAP Errata 5770

From: Joseph Salowey <[email-masked]>
Date: Sat, 24 Oct 2020 17:17:31 -0700

Errata 5770: https://www.rfc-editor.org/errata/eid5770
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.

---

From: Jorge Vergara <[email-masked]>
Date: Mon, 26 Oct 2020 19:51:05 +0000

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

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-masked]>
Sent: Saturday, October 24, 2020 5:18 PM
To: EMU WG <[email-masked]>
Cc: Oleg Pekar <[email-masked]>; Jouni Malinen <[email-masked]>; Jorge Vergara <[email-masked]>
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:

It Should Say:

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:

It should say:

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.

---

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

On Mon, Oct 26, 2020 at 12:51 PM Jorge Vergara <[email-masked]>
wrote:

> 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:
>
>
>
> 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.
>
>
[Joe] Yes I think it is fine to say EAP authentication method.   I
have been convinced that the spec requires crypto-binding with the basic
password authentication.   I'll need to add this in.

>
>
> Jorge Vergara
>
>
>
> *From:* Joseph Salowey <[email-masked]>
> *Sent:* Saturday, October 24, 2020 5:18 PM
> *To:* EMU WG <[email-masked]>
> *Cc:* Oleg Pekar <[email-masked]>; Jouni Malinen <[email-masked]>;
> Jorge Vergara <[email-masked]>
> *Subject:* Proposed Resolution to TEAP Errata 5770
>
>
>
> <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>
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Oct 2020 08:23:39 +0100

Hi,

> 
> [Joe] Yes I think it is fine to say EAP authentication method.   I have been convinced that the spec requires crypto-binding with the basic password authentication.   I'll need to add this in. 
>  

Keep in mind that there might not even be basic auth.  One case is that one just uses the OUTER auth, does some PKCS ops or extensions and then wants to conclude.  No inner in this case.  Which erratum is that covered by?

Eliot

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 27 Oct 2020 11:58:04 -0700

On Tue, Oct 27, 2020 at 12:23 AM Eliot Lear <[email-masked]> wrote:

> Hi,
>
> >
> > [Joe] Yes I think it is fine to say EAP authentication method.   I have
> been convinced that the spec requires crypto-binding with the basic
> Keep in mind that there might not even be basic auth.  One case is that
> one just uses the OUTER auth, does some PKCS ops or extensions and then
> wants to conclude.  No inner in this case.  Which erratum is that covered
> by?
>
>
[Joe]  Erratum 5775 discusses how to generate key material when there is
no inner authentication method such as the case you describe.