Subject: [Emu] New proposed resolution for Errata 5767

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

I think we should hold this one for document update.  The reason is there
are many places where we need to make changes, which is beyond what should
be done in the scope of an errata.  The changes are also more editorial
than technical.

Errata 5767: https://www.rfc-editor.org/errata/eid5767
Status: Hold for document Update
Type: Technical

There are many places in the document where the term "EAP Method" is used
to mean any EAP authentication method, excluding the EAP-Identity method.
In these places EAP authentication method should be used.  Some of the
places are identified below:

Section 3.3.1 says:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  If more than one method is going to be executed in
   the tunnel, then upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

It should say:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  Upon completion of each EAP authentication method in
   the tunnel, the server MUST send an Intermediate-Result TLV
   indicating the result.

Section 3.3.3 says:

  The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
  to perform cryptographic binding after each successful EAP method in a
  sequence of one or more EAP methods.

It should say:

  The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
  to perform cryptographic binding after each successful EAP authentication
  method in a sequence of one or more EAP methods.

Section 3.8.3 says:

   Upon successful completion of the EAP method in Phase 2, the peer and
   server exchange a Crypto-Binding TLV to bind the inner method with
   the outer tunnel and ensure that a man-in-the-middle attack has not
   been attempted.

It should say:

   Upon successful completion of the EAP authentication method in Phase 2,
   the peer and server exchange a Crypto-Binding TLV to bind the inner
   method with the outer tunnel and ensure that a man-in-the-middle attack
   has not been attempted.

Section 4.2.11 says:

   The Intermediate-Result TLV provides support for acknowledged
   intermediate Success and Failure messages between multiple
   inner EAP methods within EAP.

It should say:

  The Intermediate-Result TLV provides support for acknowledged
  intermediate Success and Failure messages after each inner EAP
  authentication method.

Notes:

EAP description is somewhat vague in discussion about "EAP methods" vs.
"EAP authentication methods" as it comes to the EAP methods performed in
Phase 2 within the TLS tunnel. RFC 3748 defines Identity request/response
as an EAP method. However, this method is not an "authentication method"
which is a special case of an method where the Type is 4 or greater.

RFC 7170 uses correct terminology in the first paragraph of Section 3.3.1
when talking about multiple authentication methods not being allowed by RFC
3748 in a single EAP conversation. However, many, but not all, of the
following "[EAP] method" instances are actually referring to "[EAP]
authentication method". This results in incorrect claims on when the
Intermediate-Result TLV and Crypto-Binding TLV are used. They are not used
after an EAP non-authentication method like Identity (e.g., see the example
in C.3); they are used after each EAP authentication method like EAP-pwd.

Furthermore, the comment about "more than one method is going to be
executed in the tunnel" does not sound accurate. This applies even if only
a single EAP authentication method is executed in the tunnel (Identity
method is not required to be executed). The proposed text in this errata
entry addresses these two issues in Section 3.3.1. The following additional
changes would be needed to make rest of the specification use the terms
more accurately:

3.3.3: "after each successful EAP method" --> "after each successful EAP
authentication method"
3.8.3: "completion of the EAP method" --> "completion of the EAP
authentication method"
4.2.11: "between multiple inner EAP methods within EAP" --> "after each
inner EAP authentication method"
4.2.13: "after each successful EAP method" --> "after each successful EAP
authentication method"