The proposal is aligned with previously discussed. One small wording I would change is:
Section 4.2.13 says: It MUST be included with the Intermediate-Result TLV to perform cryptographic binding after each successful EAP authentication method in a sequence of >>>one or more<<< EAP methods, before proceeding with another inner EAP method. Just "sequence" sounds like it denotes the case where there should be more than one EAP authentication method. On Thu, Oct 22, 2020 at 3:39 AM Jorge Vergara <jover...@microsoft.com> wrote: > I agree with all the proposed resolutions. For context, there was some > prior discussion of this errata here: > https://mailarchive.ietf.org/arch/msg/emu/K_XWBMevKNdxdWskK8RkBt1ZpSQ/ > > > > Jorge Vergara > > > > *From:* Joseph Salowey <j...@salowey.net> > *Sent:* Wednesday, October 21, 2020 5:13 PM > *To:* EMU WG <emu@ietf.org>; Jouni Malinen <j...@w1.fi>; Jorge Vergara < > jover...@microsoft.com>; Oleg Pekar <oleg.pekar.2...@gmail.com> > *Subject:* Resolution of TEAP Errata 5767 > > > > Errata 5767: https://www.rfc-editor.org/errata/eid5767 > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5767&data=04%7C01%7Cjovergar%40microsoft.com%7C50b56afadcf34732d50708d8761f45d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637389223977410444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=24y%2BkrsBw1mdGuNMMgqmqiRz%2BqeFt9jVX4qUHtlUJwY%3D&reserved=0> > Status: Verified > > Revision: > > > > 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. > > > > Section 4.2.13 says: > > > > 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. > > > > It should say: > > > > It MUST be included with the Intermediate-Result TLV to perform > > cryptographic binding after each successful EAP authentication > > method in a sequence of EAP methods, before proceeding with > > another inner EAP method. > > > > Notes: > > TEAP 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" >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
