IETF Logo Mail Archive

[radext] Re: Lack of Channel Bindings in RADIUS/(D)TLS

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 30 July 2024 20:04 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 37FAEC180B46 for <radext@ietfa.amsl.com>; Tue, 30 Jul 2024 13:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=sandelman.ca
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 3rj3qvEijyIU for <radext@ietfa.amsl.com>; Tue, 30 Jul 2024 13:04:10 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0344AC180B67 for <radext@ietf.org>; Tue, 30 Jul 2024 13:04:09 -0700 (PDT)
Authentication-Results: relay.sandelman.ca; dkim=pass (2048-bit key; secure) header.d=sandelman.ca header.i=@sandelman.ca header.a=rsa-sha256 header.s=dyas header.b=VAqdu78C; dkim-atps=neutral
Received: from dyas.sandelman.ca (unknown [142.169.16.22]) by relay.sandelman.ca (Postfix) with ESMTPS id 435451F4A3; Tue, 30 Jul 2024 20:02:58 +0000 (UTC)
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 0F4DDA1DAA; Tue, 30 Jul 2024 15:54:57 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sandelman.ca; s=dyas; t=1722369297; bh=6X8LXZXyA2PDReSkVQx5YrpIerNoB8vRe+14snYRvMg=; h=From:To:Subject:In-reply-to:References:Date:From; b=VAqdu78CfCPjHIg18uqymAf8rexaxVb2LdE4QgVo1hIREh7lcGS9+1xCW4RnkqEEq fa6oY/2aTCXei2hWzZg0Iti2WDHoeJKBcR5HdOaeaHCVZWKrwsoFZb/JEcFTiI/gaU 2405x2RjrONgWJ7Oxg0xGk3qS33skJOSeezz3TvRcF3O1Lpj/podcwTn6rniuQ+cQf LxZi1qRVv+92FIJ/K+Od16qABUjsuo4s386ZRU3QG2UMHQXmnGfnv3HEfQanxGyGNB 5jPhgqce1rvHhCWX6OLx4sMyI+Aye3lAPrx0syvhIMQUcn56q/zBpEE9a5FdLXk6vn /zMO8/4amESmQ==
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 0C810A13E8; Tue, 30 Jul 2024 15:54:57 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Alan DeKok <aland@deployingradius.com>, radext@ietf.org
In-reply-to: <E77247DC-B329-4805-9F3B-EA7B8C9A0093@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>
Comments: In-reply-to Alan DeKok <aland@deployingradius.com> message dated "Tue, 30 Jul 2024 10:35:02 -0400."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Tue, 30 Jul 2024 15:54:57 -0400
Message-ID: <343079.1722369297@dyas>
Message-ID-Hash: FPDXO5EOQ46P7XGKAENP2IXWRFETAM22
X-Message-ID-Hash: FPDXO5EOQ46P7XGKAENP2IXWRFETAM22
X-MailFrom: mcr+ietf@sandelman.ca
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
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/8NNmDqCIwGT0uioIJxunZ8NYNkI>
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>

Alan DeKok <aland@deployingradius.com> wrote:
    > One additional reason for mandating TLS 1.3 support is that the major
    > RADIUS servers already support it.

For server to server (proxy) situations, that seems quite reasonable to
mandate 1.3.

Are the access devices up to this?
To me, even TLS 1.1 seems better than RADIUS/(UDP)-MD5.
(What are we calling the legacy insecure method?)


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*

v2.35.0 | Report a Bug | By Email | System Status