IETF Logo Mail Archive

Re: [radext] CUI comments in "deprecating insecure transports"

Alexander Clouter <alex+ietf@coremem.com> Wed, 26 July 2023 18:29 UTC

Return-Path: <alex+ietf@coremem.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 E4DBAC15256E for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 11:29:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=coremem.com header.b="XQ1xActP"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="afJHHXep"
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 0Qd3pi_ITlXF for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 11:29:53 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35084C151543 for <radext@ietf.org>; Wed, 26 Jul 2023 11:29:52 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 647ED5C0197 for <radext@ietf.org>; Wed, 26 Jul 2023 14:29:52 -0400 (EDT)
Received: from imap46 ([10.202.2.96]) by compute5.internal (MEProxy); Wed, 26 Jul 2023 14:29:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coremem.com; h= cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1690396192; x=1690482592; bh=aX yLeCdsUZXGKL5iDOST25zluW2dMCI/HhN5F4KlIxs=; b=XQ1xActPD3lkboUcwx hFKeMIxTG6BZZ4l7auITjO0P7f54dZc/c1wJoArAZsbL3skjXDqKPIy6Xx5S5RLG c9WNevoHKtueMV8gwkUI+K12pWLBBSlJxXmdn0fcRU01DFnyeA8+HNy5Q73N/9GN Yw1Z5LfRgGve33Wv3AdG8qcWl9b8qBizhCbpXKPs09GCHZr8d42KxaKoYx80Qhm7 a9uyUyAmEJZHZrGkZUvW5iLeI42xf7Y9WC5VQJRwXghnbLT80tYKkq5qnYPiBYFb E77NS9yex8kwUmbMvJrH+/NQ2sBzGJd+9CmHgm23iYFkvy/Iwx+V5xbG6cocr1nB 8Q8g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1690396192; x=1690482592; bh=aXyLeCdsUZXGK L5iDOST25zluW2dMCI/HhN5F4KlIxs=; b=afJHHXepdAmwIZefdPVAYDKIdiMic jImYvB4CsQbcbVwIqM8HYpBvlPTZ/gfC9RAGYLruAsulx4daO6+f3v+Nc87ZYcKi GqNylxp8dEUvSwJZtE6x0xcwhgwpb8TWXfqWwZH4L+MclUn9/CWgdJExOxeTu8Ec 1Yho3MDbNy5TQAJtmwb6T035u0mdYTpGPqettvW4IgsDVGscqbo5EzJTjW4QOqU0 vfBTsUp+mV0uOgX+jFotq/oXDG3CWyITl4KSgkHjFlYN04+/PkoO/cE4qOh1wMNI WctN/gtLgGZbHVrULclD82QVp0GLaPq9QDACrE3QOm8Dcd5/gVMXOe4GQ==
X-ME-Sender: <xms:IGbBZFHOoQbYQlAMmkAUHCwJYyWvVR8Z0byWcO3Gv3ERkLLYLCLiUA> <xme:IGbBZKW64-p9dlftZd1twlsmem5LA53NJH_CzL7_qs3AMh_VyXGtrilDwCQuxua4_ xxU0-XcQsN58_9YtA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedriedvgdduvdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedftehlvgigrghnuggvrhcuvehlohhuthgvrhdfuceorghl vgigodhivghtfhestghorhgvmhgvmhdrtghomheqnecuggftrfgrthhtvghrnhepfefffe fgvddtgeeuheegvdevleduveevudekffeugedvueffheeggeehiefhiedtnecuffhomhgr ihhnpegvgigrmhhplhgvrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheprghlvgigodhivghtfhestghorhgvmhgvmhdrtghomh
X-ME-Proxy: <xmx:IGbBZHIOI7qWJH9KrcoBLY2Eogz--Eg17c792m8XHgZ_8AEnBOxfng> <xmx:IGbBZLH-4jHmQe-8f8R4Jj-_ydDeCc5swLF3nj_UHiL_5m-wAHkzXQ> <xmx:IGbBZLU76bM2FCRnuRfyTbdqvj036Ekc1o-4JIhi6s_PxvtRPWMMEw> <xmx:IGbBZDhSBQfckHb6HrnE-3TCbPBaYtyhe8kTVkhxDOr9tL85cZyFzQ>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 249132A20085; Wed, 26 Jul 2023 14:29:52 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-592-ga9d4a09b4b-fm-defalarms-20230725.001-ga9d4a09b
Mime-Version: 1.0
Message-Id: <c06f35b0-f6bb-4ed0-bea4-bb3ec348f487@app.fastmail.com>
In-Reply-To: <A0D7BF87-C696-4C52-A0B7-E88AE5274D20@deployingradius.com>
References: <BC530A34-D348-44D0-886E-DB1ECF3A5010@deployingradius.com> <06c301d9bfc0$e07154d0$a153fe70$@gmail.com> <5F5C2E17-2061-4FFC-942A-9C4ED861EE5F@deployingradius.com> <a0df55dd-01e3-44ee-bc18-183d7057390c@app.fastmail.com> <A0D7BF87-C696-4C52-A0B7-E88AE5274D20@deployingradius.com>
Date: Wed, 26 Jul 2023 19:29:30 +0100
From: Alexander Clouter <alex+ietf@coremem.com>
To: radext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/HbUZOPImsAkNdQfay85MGI7ExLA>
Subject: Re: [radext] CUI comments in "deprecating insecure transports"
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jul 2023 18:29:58 -0000

On Wed, 26 Jul 2023, at 17:20, Alan DeKok wrote:
>> They can always block based on the TLS session resumption materials.
>
> Is the session ticket sent in the clear?  I'm not sure how a visited 
> network would block based on the ticket.

SessionTicket is there in the clear of the ClientHello, right? You cannot read the opaque part, but it is a stable identifier for about 24 hours.

>   That being said, none of this is possible in RADIUS today.  There is 
> no attribute which says "please limit simultaneous logins to N", or 
> anything similar.  This kind of extension would be necessary in order 
> to get full user privacy at the visited network.

Nothing in RADIUS states users from example.com should be able to roam at sites run by example.org but it works because of Layer-8 federation agreements.

Similarly for a federation if you do not have a CUI that is a 1:1 proxy of the user the example policy proposed in RFC4372 is not possible. This may be fine for a given federation, but I suspect on the most part people need a label that is pinned to all authentications by that user.

Cheers

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