The following errata report has been held for document update for RFC7170, "Tunnel Extensible Authentication Protocol (TEAP) Version 1".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5767 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Jouni Malinen <j...@w1.fi> Date Reported: 2019-06-28 Held by: Paul Wouters (IESG) Section: 3.3.1 Original Text ------------- 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. Corrected Text -------------- 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. 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" -------------------------------------- RFC7170 (draft-ietf-emu-eap-tunnel-method-10) -------------------------------------- Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1 Publication Date : May 2014 Author(s) : H. Zhou, N. Cam-Winget, J. Salowey, S. Hanna Category : PROPOSED STANDARD Source : EAP Method Update Stream : IETF Verifying Party : IESG _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
