IETF Logo Mail Archive

[radext] Re: Selfie Attack on TLS-PSK

Alan DeKok <aland@deployingradius.com> Tue, 30 July 2024 11:26 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 4E191C14F713 for <radext@ietfa.amsl.com>; Tue, 30 Jul 2024 04:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 vs-xLPPfmJMz for <radext@ietfa.amsl.com>; Tue, 30 Jul 2024 04:26:13 -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 4B1E4C14F697 for <radext@ietf.org>; Tue, 30 Jul 2024 04:26:12 -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 2EEBE55D; Tue, 30 Jul 2024 11:26:08 +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: <f90ce022-945d-4f18-a58e-ff2fb774b86d@dfn.de>
Date: Tue, 30 Jul 2024 07:26:06 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <E8562465-5D7E-432D-99D9-48BDCFF8C1DF@deployingradius.com>
References: <032f01dade8b$1fc33c40$5f49b4c0$@gmail.com> <9BE709A1-470B-4F54-A050-9F30C7A6CBD7@gmail.com> <03ef01dadf44$85ce2220$916a6660$@gmail.com> <CAMEWqGvCS25-2+enWq_VBZhPssTssfjoQgYHZHMbhHRHoJ_bhg@mail.gmail.com> <f90ce022-945d-4f18-a58e-ff2fb774b86d@dfn.de>
To: Jan-Frederik Rieckers <rieckers@dfn.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Message-ID-Hash: MLV2MTTAOMVQ2IFRMBOFP5DX2IZQCP6J
X-Message-ID-Hash: MLV2MTTAOMVQ2IFRMBOFP5DX2IZQCP6J
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: Selfie Attack on TLS-PSK
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/xneAdTdG1O0ZFWWFGgIRYpCDTp0>
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 7:18 AM, Jan-Frederik Rieckers <rieckers@dfn.de> wrote:
> unfortunately, usually we do have connections in both directions.

  I think that's a separate issue from which identity is used for a connection.  The protection from Selfie is just to use different identities.

  On a related note, Margaret and I had discussions in Vancouver about two-way TLS connections.  While we have a "reverse CoA" draft, there's also nothing preventing other kinds of packets going down a TLS connection.  For the "connections in both directions" use-case, it may be possible to allow Access-Request packets to flow both ways.

> I never thought of it before reading about the selfie attack, but I think most eduroam services would be susceptible for this kind of attack, even on RADIUS/UDP, since people probably didn't use different shared secrets in the different directions.

  The shared secret is also tied to an IP address.  So a client which has the shared secret can't pretend to be the server, because it doesn't have the servers IP address.

  Alan DeKok.

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