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

Peter Deacon <peterd@iea-software.com> Wed, 24 July 2024 17:34 UTC

Return-Path: <peterd@iea-software.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 C5E06C1840D8 for <radext@ietfa.amsl.com>; Wed, 24 Jul 2024 10:34:31 -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 JGBDE0-7x-vx for <radext@ietfa.amsl.com>; Wed, 24 Jul 2024 10:34:31 -0700 (PDT)
Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 6F263C1D4CCC for <radext@ietf.org>; Wed, 24 Jul 2024 10:34:22 -0700 (PDT)
Received: from smurf (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <B0006211692@aspen.iea-software.com>; Wed, 24 Jul 2024 10:34:21 -0700
Date: Wed, 24 Jul 2024 10:34:21 -0700
From: Peter Deacon <peterd@iea-software.com>
To: Margaret Cullen <mrcullen42@gmail.com>
In-Reply-To: <3A0631E2-9679-4AC6-82DC-0ECD5DDCBE03@gmail.com>
Message-ID: <06c787ed-b989-f0ea-5a1e-0762fa63053b@iea-software.com>
References: <3A0631E2-9679-4AC6-82DC-0ECD5DDCBE03@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; CHARSET="US-ASCII"; format="flowed"
Content-ID: <211f5f22-c0e5-6a2c-66e9-bd5aa9fa391a@iea-software.com>
Message-ID-Hash: LAOGP4QGORIOSQHE5MUQVEFUZRLABEVG
X-Message-ID-Hash: LAOGP4QGORIOSQHE5MUQVEFUZRLABEVG
X-MailFrom: peterd@iea-software.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/hUfTYbce-VGLzo3l5t_zhQlpXWc>
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 Wed, 24 Jul 2024, Margaret Cullen wrote:

> While working through the RADIUS (D)TLS document last night, I realized 
> that RADIUS/(D)TLS does not include support for TLS channel binding. 
> In other words, there is nothing in the RADIUS/(D)TLS layer that ensures 
> that both ends of a single RADIUS hop are using the same unique (D)TLS 
> session.  Without channel binding, RADIUS running over (D)TLS may be 
> open to MITM attacks including:  blocking valid traffic, spoofing 
> Access-Accepts or Rejects, viewing sensitive data, replay attacks, 
> redirection, DoS, etc.

Since channel for per-hop RADIUS data is always mutually authenticated via 
client cert or shared key I don't see a need for additional per-hop 
security.

regards,
Peter