[Emu] More TEAP issues

Alan DeKok <aland@deployingradius.com> Tue, 29 November 2022 22:35 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A2E0BC14F727 for <emu@ietfa.amsl.com>; Tue, 29 Nov 2022 14:35:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xD2CiXYVP2NN for <emu@ietfa.amsl.com>; Tue, 29 Nov 2022 14:35:04 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com []) (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 27F7FC14F734 for <emu@ietf.org>; Tue, 29 Nov 2022 14:35:03 -0800 (PST)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca []) by mail.networkradius.com (Postfix) with ESMTPSA id 81DC759A for <emu@ietf.org>; Tue, 29 Nov 2022 22:35:00 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
From: Alan DeKok <aland@deployingradius.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
Message-Id: <449FBD6E-34F7-49A2-A9A1-72BD716E1DDA@deployingradius.com>
Date: Tue, 29 Nov 2022 17:34:58 -0500
To: EMU WG <emu@ietf.org>
X-Mailer: Apple Mail (2.3696.
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/Asg-ramjDWHr67nYVTyhZRJMI9o>
Subject: [Emu] More TEAP issues
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: Tue, 29 Nov 2022 22:35:08 -0000

  Based on interoperability testing, it looks like implementations followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170:



  I think this issue is larger than an errata.  We now have shipping code (Windows 10, Windows 11, and Cisco ISE at least) which don't follow RFC 7170.  But which do interoperate with each other.

  Hostap / wpa_supplicant follows 7170, but doesn't interoperate with Windows.

  FreeRADIUS is currently being updated to support TEAP.  For reasons of interoperability, we'd probably choose to follow Windows.

  The question is what to do next?

  I would suggest that at this point, shipping code is more important than theoretical specifications.  The implementors have shipped interoparable versions, and shipped millions of devices with a particular implementation.

  So our choices are:

1) declare the implementations broken, and update 7170 with minor tweaks for what "should" happen.  New implementations will do ??? and current implementations will do ???

2) declare 7170 irretrievably broken, and write 7170bis which defines TEAP version 2.  That document can define TEAP behavior as ???

3) declare 7170  irretrievably broken, and write 7170bis which documents how TEAP version 1 operates in practice.

  My preference would be (3).  I'd also prefer to get agreement in EMU that this is the way forward, so we can ship FreeRADIUS with a "correct" implementation.  I would very much prefer to not add to the mess by shipping code which fails to follow RFC 7170 and which also fails to follow existing implementations.

  If the WG agrees, I'd be OK acting as editor for RFC 7170bis.  The goal would be to change as little as possible of the text.  Just fix the errata, and add a note saying "ignore 7170, as it's wrong".  99% of the text is OK, and can be left as-is.

  This issue is getting timely, as there is now strong customer demand for TEAP in Q1 / Q2 2023.  So it would be good to get consensus before going down any particular path.

  Alan DeKok.