IETF Logo Mail Archive

[radext] Re: Selfie Attack on TLS-PSK

Margaret Cullen <mrcullen42@gmail.com> Thu, 01 August 2024 05:46 UTC

Return-Path: <mrcullen42@gmail.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 A4EB5C16940F for <radext@ietfa.amsl.com>; Wed, 31 Jul 2024 22:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.858
X-Spam-Level:
X-Spam-Status: No, score=-1.858 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 PUtQxc_XNE6U for <radext@ietfa.amsl.com>; Wed, 31 Jul 2024 22:46:08 -0700 (PDT)
Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4188C151985 for <radext@ietf.org>; Wed, 31 Jul 2024 22:46:08 -0700 (PDT)
Received: by mail-qt1-x829.google.com with SMTP id d75a77b69052e-450217eaa62so27736221cf.3 for <radext@ietf.org>; Wed, 31 Jul 2024 22:46:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722491167; x=1723095967; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=NvmHJDMKxe62frZkpv2Yf1GGw/tNFiIHbWq8rPm9tOc=; b=L9VZdIF1UZbmAnw48j8Zyvjg+5QkYUoFIK814Ev4p9fvD8duJIbhfNjmj1+hjBKvKq PNjWJDV0HJtgekeP5TQ56LbHqFBDf9xbUUlUdzUU6cjUxDCO3rVBUZHUf2gx0zj4w5dm z7Y1LE0BBVkluxA/4UDqQTPH2CMYWNgQrbF62+RG8p6oSXeZT83bQ7peCbJ+PpVu8b/0 pkwa1jHzGV5cEBIotCWkaJCGzGuJ6mE0B/YRKZ5nGjWdxfhzZ1RNm1Z92OfH6T2iG4j0 JIN4CGcKI1NUVVCi12lY5FL53Z83bIYN5BchucnGtheBUVq7CiX+TSxTgKLyOcIoUOf4 +KJA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722491167; x=1723095967; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NvmHJDMKxe62frZkpv2Yf1GGw/tNFiIHbWq8rPm9tOc=; b=ZQD3f5+wsrvCAF2XtHVZKRLWUf8NPtAQ9ZUQUcIJgRQCECvAs1UM5fOWSi9855pp4H mEBGlsIM3dWvwqegBu97ARTdUXsZoUydZ/ZXZwGkQicQNuNUP6xFGGCTbcuki6b8orhp 1L/Tkca11KkaErzsOGa7lOcpk43x+WUtUbCR4d2fUr69exN744liryHCUvGfGCLx5k9j gg4cyrP0FLHlMw5FSwnqL8RPqWHrWrafaWCIY87dY99Lphb956oxu0RG8Y2IiiYLs62S 8ta/r+SZHfdJ2oPYm9/ZnQuxHgNYYcUbxda/JpEHy9KPbKacpmjmG+/BAMqw5BPKoq1w 6pqw==
X-Forwarded-Encrypted: i=1; AJvYcCXAfMs4nb5BAJWwEP6r/xLjuLdyWork/qncrVn87fx0jZfiAEFujh5MOkop6Atv7BaD4de/PQTg/mtNo/vlilQ=
X-Gm-Message-State: AOJu0YynQWIEcMwqXkgP4iDOUmO5G7IST2Xa8DMO2sogFukj12Cb+CVk Bj6SLD2bAeG+9UGrKM0toE1VTEf8+EARmgvEXjXxIdnC5yhuy4cYpJ2H1w==
X-Google-Smtp-Source: AGHT+IHimduGNsN9fmCgj3v3kY/63kIAVeixCIDaZykiE+Ag6G0V2tMFVX7tQALr+8SkASIbNuerFw==
X-Received: by 2002:a05:622a:1206:b0:44f:c99c:826f with SMTP id d75a77b69052e-4514f99ee1amr19001431cf.30.1722491166808; Wed, 31 Jul 2024 22:46:06 -0700 (PDT)
Received: from smtpclient.apple ([2601:18c:503:9630:f82a:28a3:3d9e:aece]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-44fe812589csm65433451cf.13.2024.07.31.22.46.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 31 Jul 2024 22:46:06 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Margaret Cullen <mrcullen42@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Thu, 01 Aug 2024 01:45:55 -0400
Message-Id: <8EFAC8BB-BF69-4232-BE68-DE2511A37662@gmail.com>
References: <E8562465-5D7E-432D-99D9-48BDCFF8C1DF@deployingradius.com>
In-Reply-To: <E8562465-5D7E-432D-99D9-48BDCFF8C1DF@deployingradius.com>
To: Alan DeKok <aland@deployingradius.com>
X-Mailer: iPhone Mail (21F90)
Message-ID-Hash: M7CAE43HEEK5JAZ7UVKAXGHCCBELUVAP
X-Message-ID-Hash: M7CAE43HEEK5JAZ7UVKAXGHCCBELUVAP
X-MailFrom: mrcullen42@gmail.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: Jan-Frederik Rieckers <rieckers@dfn.de>, 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/ZGtdo0Ww17BFUMdh7zheJaQTr8g>
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:26 AM, Alan DeKok <aland@deployingradius.com> wrote:
> 
> 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.

It was the CoA specs that made me think about things in terms of authorization…

Successfully setting up the TLS connection involves authentication, and the credentials (PSK or cert) provide identity.  Policy (typically expressed in configuration) dictates which packet types an identified peer is allowed to send to us. 

I’m not sure if we need to preclude some combinations, though, to avoid selfie attacks? Do we need to reject policy/config that indicates that any single peer can send us both RADIUS Access-Request packets and RADIUS Response packets?

Margaret

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