IETF Logo Mail Archive

Re: [radext] Proposed charter text based on IETF-115 BoF

Alexander Clouter <alex+ietf@coremem.com> Thu, 24 November 2022 15:28 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 89A8EC14F732 for <radext@ietfa.amsl.com>; Thu, 24 Nov 2022 07:28:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.797
X-Spam-Level:
X-Spam-Status: No, score=-2.797 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, 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=EMoOEJlY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KdRsM/ml
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 zu-sNiW6qXG5 for <radext@ietfa.amsl.com>; Thu, 24 Nov 2022 07:28:28 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (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 F4198C14F72F for <radext@ietf.org>; Thu, 24 Nov 2022 07:28:27 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 4BD743200A15 for <radext@ietf.org>; Thu, 24 Nov 2022 10:28:27 -0500 (EST)
Received: from imap46 ([10.202.2.96]) by compute4.internal (MEProxy); Thu, 24 Nov 2022 10:28:27 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coremem.com; h= cc: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=fm3; t=1669303706; x=1669390106; bh=+PJcIY9YwU odB3rgBxRUcG4rxvCiiahijqcjQhDXeKs=; b=EMoOEJlY5G3j/a3aH9mU3TIKR7 8P4W71o01maQwdQbBja+RQoDmRH5DFYsJF86/dQIH1ApPsxnrc+Hqd8a78RU7JqW kyWTxUPRCVZnZzoKIDlNeEHl0L80s6h4VoLMzhBiuT1BJfp7TjgwVp4i6NJ/lc0Z Q/i5dK3WA2VEgltJxLIwCjQgaisJTx82oNKdvEXGd1PRkmg1c18x5/K/knbXTdLC 1h2Se5UIVC1vIHy1KLT4e5kwtK+LnikwtNUXpDviEzPJN1CsbgeRdBAPTd++cwLD yO2S+A3cZdaCzjFKkfy3JSuzx86xJ1u8pT9OAIE7d8W4trgsl3ejtHM9ZBIw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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= fm1; t=1669303706; x=1669390106; bh=+PJcIY9YwUodB3rgBxRUcG4rxvCi iahijqcjQhDXeKs=; b=KdRsM/mltaWMcT/ssicUFwasbWZDDCJcPWjAqHPR3iNu 7fwLVfe1Pyb3DlSHoLgApWYTbb6Wcf/+9XuWXv9OKKhQQKd7tqa/5TqtJ5KlYGS1 QYV3L+3qhAVjsAnwHDYPJ4w1+/PUiVBoonxAzjqiB1mF4DX4WKyMIL3YhapZE13s 9k5v5y+rSAWYG6m6D5qWpzZBURj1YjgtnyDJAV+1Rc/vC/cinfcBjYQ7YPs8E217 4FWsFH7MbVi3ERfsBPlJMXE7XeibnTlx226+sB/Aefb51o3PATS6a7mjWIBR9kXR 0hI19JInSFhRhl//SUjVvTuzm8ImrohEsstGj4xRVw==
X-ME-Sender: <xms:mo1_Y6es9oH_tZVoqRCijOizW_1Vhw1jy-25AVXLtX1wlm5JbzULOA> <xme:mo1_Y0OpDzkQI6QymSq5GVLx47WjTSTg2Uek-FuvrI5e1m1CGAa2EL7jvNpvR7WbJ dMdFMT2S0IjBAqgVw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrieefgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdetlhgvgigrnhguvghrucevlhhouhhtvghrfdcuoegrlhgv gidoihgvthhfsegtohhrvghmvghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvteejhf ehgfegleeuleefteeikefgvefhheekheevvdekueefkeeiieffhfdvgeenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhgvgidoihgvthhfse gtohhrvghmvghmrdgtohhm
X-ME-Proxy: <xmx:mo1_Y7ib4XhzybcoLXZAxEAuhEiubmJH0n04cyZV5MP6EklUBg-gJg> <xmx:mo1_Y38JeoxVtjC4r_WwzT35koyb0FhOuIQh7myt6zLG6Am2AvBFLQ> <xmx:mo1_Y2vp1ZNdqQEclgRkk3n0pIkh-lbTTdMt3XrG-avC7rCVd78Mqw> <xmx:mo1_Y05ley86ZuQgltdP0RSFsAGPSsIbf0XcJ-Euy9jc3rnRUheWeg>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 957382A20080; Thu, 24 Nov 2022 10:28:26 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1115-g8b801eadce-fm-20221102.001-g8b801ead
Mime-Version: 1.0
Message-Id: <ea1e192f-3e03-4f02-8885-455c635529df@app.fastmail.com>
In-Reply-To: <7CB701B8-BD8F-4ADC-9265-12FC7EBE8FB6@deployingradius.com>
References: <FD0507D4-2C1D-478A-97E0-ECEEF1A5613B@deployingradius.com> <E82B0ECD-4580-4F35-B07B-35685CFC5C44@aiven.io> <883f3572-121f-5ed8-7378-1a91c5525f88@iea-software.com> <EAAC2507-5D29-4453-8881-BC8D9D5314D8@deployingradius.com> <CAOW+2dsKg_H9f3zRUnanCpgGO+G=VPyxzWa9hsrCJCpsnoBsxA@mail.gmail.com> <7CB701B8-BD8F-4ADC-9265-12FC7EBE8FB6@deployingradius.com>
Date: Thu, 24 Nov 2022 15:28:06 +0000
From: Alexander Clouter <alex+ietf@coremem.com>
To: radext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/LDas5lamVuO4iexIcvIOL0EGlHg>
Subject: Re: [radext] Proposed charter text based on IETF-115 BoF
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: Thu, 24 Nov 2022 15:28:32 -0000

On Thu, 24 Nov 2022, at 14:15, Alan DeKok wrote:
>   The goal of the draft is to define a (D)TLS transport profile for 
> RADIUS.  Everything else is 100% RADIUS.
>
>   But the issue of variants is a problem.  It would be ideal to just 
> re-use RADIUS/TLS port 2083, and then do some kind of negotiation.  
> Since RADIUS doesn't include per-hop negotiation, that's difficult to 
> do.

TLS though does, and that is exposed to userspace; SSL_CTX_add_client_custom_ext and SSL_CTX_add_server_custom_ext.

This lets you do the negotiation before the first RADIUS request makes it out on to the wire.

Non-compliant systems should just ignore these extension headers and means the hop is to use vanilla-no-sprinkles RFC6614.

Am I missing something?

v2.23.0 | Report a Bug | By Email