[Emu] [Errata Verified] RFC7170 (5845)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 01 April 2024 11:32 UTC
Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69872C14F60A; Mon, 1 Apr 2024 04:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Level:
X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id en9O4hq2whi5; Mon, 1 Apr 2024 04:32:04 -0700 (PDT)
Received: from rfcpa.amsl.com (rfcpa.amsl.com [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E03C14F6A7; Mon, 1 Apr 2024 04:32:04 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id B1DA25BDD43; Mon, 1 Apr 2024 04:32:04 -0700 (PDT)
To: j@w1.fi, hzhou@cisco.com, ncamwing@cisco.com, jsalowey@cisco.com, steve.hanna@infineon.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: paul.wouters@aiven.io, iesg@ietf.org, emu@ietf.org, iana@iana.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240401113204.B1DA25BDD43@rfcpa.amsl.com>
Date: Mon, 01 Apr 2024 04:32:04 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/Y8vggzfOFYYWBjsUFiAZUjMzSUA>
X-Mailman-Approved-At: Wed, 03 Apr 2024 11:16:43 -0700
Subject: [Emu] [Errata Verified] RFC7170 (5845)
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2024 11:32:05 -0000
The following errata report has been verified for RFC7170, "Tunnel Extensible Authentication Protocol (TEAP) Version 1". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5845 -------------------------------------- Status: Verified Type: Technical Reported by: Jouni Malinen <j@w1.fi> Date Reported: 2019-08-24 Verified 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 method completion, the server MUST send an Intermediate-Result TLV indicating the result. Notes ----- Description of whether Intermediate-Result TLV is supposed to be used in the case where only a single inner EAP authentication method is used. Section 3.3.1 says "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", 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", 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", Annex C.3 shows an example exchange with a single inner EAP authentication method with use of Intermediate-Result TLV. It looks like the majority of the places discussion this topic implies that there is going to be an Intermediate-Result TLV after each inner EAP authentication method and the text in 3.3.1 is the only clear case of conflicting (or well, at least misleading if one were to claim it does not explicitly say MUST NOT for the one inner EAP authentication method case). As such, I'd conclude the Intermediate-Result TLV is indeed going to be exchanged after each EAP authentication method and the proposed text change to 3.3.1 covers that. -------------------------------------- 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] [Errata Verified] RFC7170 (5845) RFC Errata System