[Emu] RFC 7170 Erratum 5844

Eliot Lear <lear@cisco.com> Wed, 22 January 2020 13:48 UTC

Return-Path: <lear@cisco.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 C4A501200EB for <emu@ietfa.amsl.com>; Wed, 22 Jan 2020 05:48:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoztHq9EPJnI for <emu@ietfa.amsl.com>; Wed, 22 Jan 2020 05:48:52 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A8C1200E9 for <emu@ietf.org>; Wed, 22 Jan 2020 05:48:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5827; q=dns/txt; s=iport; t=1579700932; x=1580910532; h=from:mime-version:subject:message-id:date:cc:to; bh=H0TK1V78UlbyFKCl6TZVuEqLFZOOh5m6V2AbQ1r78Ts=; b=WFBo5rc19aGJy3vaP3m0I2MBB4rlsVSnvdWOHig4tJJ15K4UV1fZi09N Yy7J5jSE72dRhlaJ3Bz0iYbDD59JbQLZ7Z1Uf3GjEIPKG8DV25EyKzPWM mxenXsnsvjfmZDQww0cloYH9+2YFmNEINF7bYOGxLMNXdYD/x2RH+/ZV6 Q=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos;i="5.70,350,1574121600"; d="asc'?scan'208,217";a="22428020"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jan 2020 13:48:50 +0000
Received: from dhcp-10-61-103-205.cisco.com (dhcp-10-61-103-205.cisco.com [10.61.103.205]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 00MDmnIV025817 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Jan 2020 13:48:50 GMT
From: Eliot Lear <lear@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_66F4714F-B824-4BC0-9294-FEF40632BE5B"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Message-Id: <1343586F-6443-4F0A-BB94-669DB87168A1@cisco.com>
Date: Wed, 22 Jan 2020 14:48:49 +0100
Cc: "Oleg Pekar (olpekar)" <olpekar@cisco.com>
To: EMU WG <emu@ietf.org>, Jouni Malinen <j@w1.fi>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
X-Outbound-SMTP-Client: 10.61.103.205, dhcp-10-61-103-205.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/nvP9EFUG_GCH42J05IaWyFlrJ9Q>
Subject: [Emu] RFC 7170 Erratum 5844
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 22 Jan 2020 13:48:54 -0000

If we accept erratum 5845, then it seems only natural that we should accept this erratum as well.

> 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 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.