Re: [Emu] More TEAP issues

Joseph Salowey <joe@salowey.net> Wed, 30 November 2022 01:14 UTC

Return-Path: <joe@salowey.net>
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 CD4FDC14CEE5 for <emu@ietfa.amsl.com>; Tue, 29 Nov 2022 17:14:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20210112.gappssmtp.com
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 pvz35_MyJgN0 for <emu@ietfa.amsl.com>; Tue, 29 Nov 2022 17:14:25 -0800 (PST)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 BDB1DC14F74F for <emu@ietf.org>; Tue, 29 Nov 2022 17:14:25 -0800 (PST)
Received: by mail-io1-xd2f.google.com with SMTP id p193so1248999iod.6 for <emu@ietf.org>; Tue, 29 Nov 2022 17:14:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6sG9aiLVnqetA24TKppixBgDQv3g6n5SwadRGl4L194=; b=3tCNwyjIwEcA9hn1VShfMAdp1LzWvr2ro1WczE4JmqZlzmELGo4lz1Mcm+WIv+kTLt Pn75bZflvuU5UbhOUcJEnVkum5wq+SjyTzGVDKG4FJtVv0uOGQNMpeL4YbjWwxPXCgvU sodbkIgRnpSlI+V9jb20YdM+vvoJwYAfSH8oiJ8R6NFg5aQmq66ABVQO0APS568bTngG j6Tvf3CKOiz97dpUOT7VWn6s16UYn1GfLTHzbWl9kklBpYZqswBT3cpeD2PiYKXVskfU gyVy43peZKhCp0l1V6qsDjS3snwgq+YXlqE36QHRCEQNEFZeaD6xI7FYIj12fsCsPFtP HMTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6sG9aiLVnqetA24TKppixBgDQv3g6n5SwadRGl4L194=; b=BL+WLmaxsn0jyGvZpmhmi9r8/JlEYUtkSBP27f96cp+f+dGetF6C6etQrRu3LqMQsQ 93TFdoOYccYn4syl/o4NSI+Fbcob2B6w24LSbHKDmxPOnBP/NwFqctkyhhyWxCvw9u2+ FkmKcnpcWm7JgNM+dxU2+yGK3/8nPfajr2Q3Ww6CUvgUQ1yGYm9Cn69YlWDp222oIlDk 5IXLZ67XsTggOeefABGa709Kx24C/lro0XbdDrqVIC3U7oY+RJKS3vdGzkRJjbBjlxjU V7JwmMpbHbRRcPVwO73+pUQ+eahZn/x1DfTWp10iAItdLUHiqidvQizmyOT9iXpgiozr gDrA==
X-Gm-Message-State: ANoB5pk8uKUWLuUdFj8xKIf4y5FidXgHIdf4HOJGe2fYfvnXljNG4SCw x8up9v7JQz9uYoOKq8s8DlPCBCl4gQEiQMC5Jr37Xv7TfiwFDw==
X-Google-Smtp-Source: AA0mqf5uMhF8KtRWrYLlJ5UW4xiqNmlhGp91KBqtezlCuF9O1/FgMq87jhPq0kKpPBqgQTewXZ+eMRQ5EIcJwi0jmcw=
X-Received: by 2002:a02:84e6:0:b0:389:db1d:40b3 with SMTP id f93-20020a0284e6000000b00389db1d40b3mr7307848jai.3.1669770864378; Tue, 29 Nov 2022 17:14:24 -0800 (PST)
MIME-Version: 1.0
References: <449FBD6E-34F7-49A2-A9A1-72BD716E1DDA@deployingradius.com>
In-Reply-To: <449FBD6E-34F7-49A2-A9A1-72BD716E1DDA@deployingradius.com>
From: Joseph Salowey <joe@salowey.net>
Date: Tue, 29 Nov 2022 17:14:12 -0800
Message-ID: <CAOgPGoCwk3UVq7Wv+1SNh8cQta70VegiNAz917aHVhvO2QtA7A@mail.gmail.com>
To: Alan DeKok <aland@deployingradius.com>
Cc: EMU WG <emu@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003a60ad05eea5d3cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/ieUQBWQVjNtBBkQdYXYz6RomFqs>
Subject: Re: [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: Wed, 30 Nov 2022 01:14:29 -0000

On Tue, Nov 29, 2022 at 2:35 PM Alan DeKok <aland@deployingradius.com>
wrote:

>   Based on interoperability testing, it looks like implementations
> followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170:
>
> http://lists.infradead.org/pipermail/hostap/2022-July/040639.html
>
> http://lists.infradead.org/pipermail/hostap/2022-November/041060.html
>
>   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.
>
> [Joe] speaking as a participant, I'd be happy to assist with a revision.
I think it is needed.  Most of the current errata are tracked here -
https://github.com/emu-wg/teap-errata/pulls.  I think the target would be
to obsolete 7170 with a revision that just fixes the errata and makes any
needed clarifications.  We can also work on posting the Errata, but the
revised document would be more effective at getting these issues fixed.


>   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.
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>