[radext] Re: Lack of Channel Bindings in RADIUS/(D)TLS
Alan DeKok <aland@deployingradius.com> Wed, 31 July 2024 00:07 UTC
Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3ABC151986 for <radext@ietfa.amsl.com>; Tue, 30 Jul 2024 17:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, T_SCC_BODY_TEXT_LINE=-0.01] 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 wuGyo08H_mJK for <radext@ietfa.amsl.com>; Tue, 30 Jul 2024 17:07:32 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0BEC151069 for <radext@ietf.org>; Tue, 30 Jul 2024 17:07:30 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-232.cpe.pppoe.ca [135.23.95.232]) by mail.networkradius.com (Postfix) with ESMTPSA id 7D381170; Wed, 31 Jul 2024 00:07:26 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <343079.1722369297@dyas>
Date: Tue, 30 Jul 2024 20:07:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <EF5CBC19-B514-4686-98E3-A95CDCFD7144@deployingradius.com>
References: <3A0631E2-9679-4AC6-82DC-0ECD5DDCBE03@gmail.com> <06c787ed-b989-f0ea-5a1e-0762fa63053b@iea-software.com> <84133.1721926586@dyas> <CAOW+2dtmPRL6CoeUZJSMHee+ae=DUMhEyJqzYtVHod4hgQ8xEA@mail.gmail.com> <E77247DC-B329-4805-9F3B-EA7B8C9A0093@deployingradius.com> <343079.1722369297@dyas>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Message-ID-Hash: 62H5CXP7S7CGJPSDPS2YFK2TLPELLVLJ
X-Message-ID-Hash: 62H5CXP7S7CGJPSDPS2YFK2TLPELLVLJ
X-MailFrom: aland@deployingradius.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-radext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: radext@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [radext] Re: Lack of Channel Bindings in RADIUS/(D)TLS
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/1nsP9YggO2OGblfA0SCou2QgOeY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Owner: <mailto:radext-owner@ietf.org>
List-Post: <mailto:radext@ietf.org>
List-Subscribe: <mailto:radext-join@ietf.org>
List-Unsubscribe: <mailto:radext-leave@ietf.org>
On Jul 30, 2024, at 3:54 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote: > For server to server (proxy) situations, that seems quite reasonable to > mandate 1.3. > > Are the access devices up to this? For any non-trivial ones, yes. For trivial ones, they can continue to use RADIUS/UDP until such time as the devices reach EOL. There's no reason to limit support to an intermediary upgrade path when the better solution is already 6 years old. > To me, even TLS 1.1 seems better than RADIUS/(UDP)-MD5. > (What are we calling the legacy insecure method?) RADIUS/UDP is simple enough, I think. Alan DeKok.
- [radext] Lack of Channel Bindings in RADIUS/(D)TLS Margaret Cullen
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Alan DeKok
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Margaret Cullen
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Alan DeKok
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Margaret Cullen
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Fabian Mauchle
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Margaret Cullen
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Bernard Aboba
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Bernard Aboba
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Margaret Cullen
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Michael Richardson
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Valery Smyslov
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Fabian Mauchle
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Michael Richardson
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Q Misell
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Peter Deacon
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Alan DeKok
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Alan DeKok
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Michael Richardson
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Bernard Aboba
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Alan DeKok
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Stefan Paetow
- [radext] Re: Lack of Channel Bindings in RADIUS/(… Q Misell