Re: [radext] Implementation independent ALPN selection for RADIUS versions

Alexander Clouter <alex+ietf@coremem.com> Mon, 16 October 2023 08:04 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 E9CAAC14CEFE for <radext@ietfa.amsl.com>; Mon, 16 Oct 2023 01:04:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.808
X-Spam-Level:
X-Spam-Status: No, score=-2.808 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_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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="EHMc4ISa"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="NdcX1Imr"
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 TfhlnnJixKXb for <radext@ietfa.amsl.com>; Mon, 16 Oct 2023 01:04:12 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (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 05746C15152E for <radext@ietf.org>; Mon, 16 Oct 2023 01:04:11 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id C338F32009AD; Mon, 16 Oct 2023 04:04:06 -0400 (EDT)
Received: from imap46 ([10.202.2.96]) by compute3.internal (MEProxy); Mon, 16 Oct 2023 04:04:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coremem.com; h= cc: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=1697443446; x=1697529846; bh=XP Gf2ghP3oOqox3kVCTMnz1X9mUkvuMgK4oqacZevqc=; b=EHMc4ISaJBgbAQHhmJ ZnCdQnWyq4HNAo00qkYx8/8JrlM4cy1E3BwkTx/t+NW4zZsjcubvWDfqstVnPziM 4QEvdOzok98hTmK8gxdQp47CuNBmRkk1DTOwnSA1nQ9bWVOY8qezpJMfNQIxSXKc 6LGLCfxoWrbZq4M9SztNCBi+biWSude2yA3Xg3kIgWxX6ZwVmt4wU0OWIMR56Pua uwHlT/XPpojddX/acorflb5whFnCSNoLDjpRu0+nFyySQj9b7ux40kIBoGjquVA0 dWX6/MbfNvs8Flz7179pHa2GP2KDRtfsdKSfNaSAfDS6dB5QXc+aE1BPddLdiLQm c74w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=1697443446; x=1697529846; bh=XPGf2ghP3oOqo x3kVCTMnz1X9mUkvuMgK4oqacZevqc=; b=NdcX1Imrx01ZayKoyB2F8Ia9xnHCx rZVD8CwGIPXrnjUw1HwCEisXtwxU30cBf9Uy/XZvZdA6ZRai8Q+4NocbTLf36HkO rQkpCWuBzJIvyEb+/agpJGo1fQifVAVrwc0o2/EV9unXJ6y5gr9ibPFpNCLxh5yD ivOHbW7GC5qkhKQO9C2M8G3u7uwedF7H23J3YPd8d/L3BFX8WOfbmi61LkkTFhtH eI/hKjGFnoholxt6kaqnOxxD+FwZOyVmZNO48WldjzBswspR05qOGpTR+qDLSNC1 CRR076oNJr8K0x9pD1Y2M9qZcFzOoBjzcwJj+YFKrMBdNQ0pFyNqPr8IA==
X-ME-Sender: <xms:du4sZQLNk2j7kX5GRDX5Vd5YmaRvmCdsrL9PDSG5pkyNk7qxp7tDoQ> <xme:du4sZQIy7FJ_Von12XnKdDf0z237tStR0dKkOFfUgXDXvRq2zDpWkMbUGWvhpAJ1A cqJpMMQkgM7_aHZjA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrieelgdduvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehl vgigrghnuggvrhcuvehlohhuthgvrhdfuceorghlvgigodhivghtfhestghorhgvmhgvmh drtghomheqnecuggftrfgrthhtvghrnhepveegheejueevkeevvdfhheeuudefheegudeu tdelleeiteehgeffieettddugfdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomheprghlvgigodhivghtfhestghorhgvmhgvmhdrtghomh
X-ME-Proxy: <xmx:du4sZQtvt1C1PAbzjr0JYTbETQcwbI9fgyaO8bVmXdlbrUvZwEJIuA> <xmx:du4sZdaV5Vjw53-P5pmwKRuXFlQoRqJH79mqBIfI3HQ1BvyXFmCvfQ> <xmx:du4sZXbU6g9M_IqduMg8jjyqLmtTEXP9I1wRu30ttuumcWxvZN7tvQ> <xmx:du4sZYBCgV_UCh7Av0SC6NQwGnZcOuqo8fU6YoYrwB9cAl9QcDOp4A>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id ECCCC2A20085; Mon, 16 Oct 2023 04:04:05 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.9.0-alpha0-1019-ged83ad8595-fm-20231002.001-ged83ad85
MIME-Version: 1.0
Message-Id: <8a288b14-e0df-4c8e-9595-0033f2763e71@app.fastmail.com>
In-Reply-To: <42C9E043-31B8-4E1B-878F-19AC1D91A0F5@deployingradius.com>
References: <CAA7Lko-dC3R=QdUJOwXycDJ=LxkQatx0ZrTf7Q21f22zbYdR0A@mail.gmail.com> <5AC9456F-D11A-400F-9DF6-AF458EAC429D@deployingradius.com> <CAA7Lko-7FKAqBx5juqTDvhVdygS_vfDmqkPub8v-M-qmuhUk-g@mail.gmail.com> <42C9E043-31B8-4E1B-878F-19AC1D91A0F5@deployingradius.com>
Date: Mon, 16 Oct 2023 09:03:44 +0100
From: Alexander Clouter <alex+ietf@coremem.com>
To: Alan DeKok <aland@deployingradius.com>, 'Heikki Vatiainen' <hvn@radiatorsoftware.com>
Cc: radext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/6ezepZsGFVlZ6UZJnLZ0DozOxxA>
Subject: Re: [radext] Implementation independent ALPN selection for RADIUS versions
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: Mon, 16 Oct 2023 08:04:17 -0000

On Sun, 15 Oct 2023, at 20:53, Alan DeKok wrote:
>
>> This section forbids bidding down from "radius/1.1" during session resumption. Is it really necessary to allow the opposite? If the configuration changes so that "radius/1.0" is no longer used and "radius/1.1" is used instead, why not simply do a full handshake. Or in general, if ALPN strings change, full TLS handshake must be done. In case there are new ALPN strings defined in the future, this might be a useful forward compatible definition to have from the start.
>
>   I think it's OK to allow negotiation upwards.  This allows 
> implementations to re-used resumption tickets when the configuration 
> changes.  The alternative is to require full handshake, which sees, 
> inefficient.

I would not be concerned about any inefficiency of a full handshake, I suspect this is going to be really rare and only occur if either peer is upgraded (or configured) to start supporting 'radius/X.Y' which is going to be a rare event?

My concern would be if there is some sort of authentication or authorisation that an implementator/administrative may want to tie back to the original full handshake via those interim session tickets that may vary given a different ALPN negotiation?

If we can think of a single scenario, even a crazy one, we should forbid negotiation upwards too.

I cannot think of anything as this is 'transport' rather than 'peer authentication', so I'm okay with session tickets going upwards.

That said, implementation wise, I suspect most peer session tickets are going to be memory resident, so upgrading your RADIUS peer or reconfiguring and reloading may just nuke those tickets anyway so this might be all moot :)

Cheers