IETF Logo Mail Archive

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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 25 July 2024 16:56 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 7B614C15106F for <radext@ietfa.amsl.com>; Thu, 25 Jul 2024 09:56:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_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=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 cytHYpQFsuPZ for <radext@ietfa.amsl.com>; Thu, 25 Jul 2024 09:56:41 -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 RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286CFC1CAF5A for <radext@ietf.org>; Thu, 25 Jul 2024 09:56:33 -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=Ogl03sGR; dkim-atps=neutral
Received: from dyas.sandelman.ca (dhcp-87b8.meeting.ietf.org [31.133.135.184]) by relay.sandelman.ca (Postfix) with ESMTPS id 883811F483; Thu, 25 Jul 2024 16:55:36 +0000 (UTC)
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id A46FAA1D76; Thu, 25 Jul 2024 09:56:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sandelman.ca; s=dyas; t=1721926586; bh=jSbQg4Io1U9RbXFg8hzAiO8KOZoi6HJz7tSgE/r4Odk=; h=From:To:cc:Subject:In-reply-to:References:Date:From; b=Ogl03sGRlcP3IrHBdtx4IHgTLdyzLfIEi6cyztl8mNDlQg3KJwvtmnSCOUxh+ZUGP JU80vNvxOulCuUl6pLzM3SE1xvXKLQABTzUB7WGBt1eYYyei5BJLqp1EhBE/sM2GJb 7MPikAxW8KrTPQbny9DoJRA3hpnqej85xUNYz8f9BsJ4/mzm62Rl+xKG/ZjQlUZhqf leQWQJXDkwHmkmefEImxnoUeiDdOu9n+IZd/NufMBm0bgGnqPQD3XDTrI8WzacBjGc Bf/oBjIfhxhQKyVK51/PrrIn481bemScHJMqohVsKru4KgcorRiCiVgXlfjTkIVJvT pzXcGHRM5lQNQ==
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id A2041A1D71; Thu, 25 Jul 2024 09:56:26 -0700 (PDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Peter Deacon <peterd@iea-software.com>
In-reply-to: <06c787ed-b989-f0ea-5a1e-0762fa63053b@iea-software.com>
References: <3A0631E2-9679-4AC6-82DC-0ECD5DDCBE03@gmail.com> <06c787ed-b989-f0ea-5a1e-0762fa63053b@iea-software.com>
Comments: In-reply-to Peter Deacon <peterd@iea-software.com> message dated "Wed, 24 Jul 2024 10:34:21 -0700."
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: Thu, 25 Jul 2024 09:56:26 -0700
Message-ID: <84133.1721926586@dyas>
Message-ID-Hash: 672ZM7HJ6RGJ32ET4N7RRPJENBS7QVEN
X-Message-ID-Hash: 672ZM7HJ6RGJ32ET4N7RRPJENBS7QVEN
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
CC: Margaret Cullen <mrcullen42@gmail.com>, 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/YuiCiWsM8L0_Y7PMHb45wrSyAm4>
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>

Peter Deacon <peterd@iea-software.com> 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.

I'm also lost as to why mutual TLS authentication isn't enough.
Yes, if some unauthenticated keys are used, there might be concern, but that
just doesn't seem to make sense to me.

--
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