IETF Logo Mail Archive

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

Jan-Frederik Rieckers <rieckers@uni-bremen.de> Mon, 28 November 2022 23:19 UTC

Return-Path: <rieckers@uni-bremen.de>
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 E536FC152705 for <radext@ietfa.amsl.com>; Mon, 28 Nov 2022 15:19:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=uni-bremen.de
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 w3YIEZ79Nyqh for <radext@ietfa.amsl.com>; Mon, 28 Nov 2022 15:19:01 -0800 (PST)
Received: from smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.15]) (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 8FEBDC152704 for <radext@ietf.org>; Mon, 28 Nov 2022 15:19:00 -0800 (PST)
Received: from [192.168.42.47] (local.janfred.de [90.187.196.9]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4NLhHQ00LDzDCbR for <radext@ietf.org>; Tue, 29 Nov 2022 00:18:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni-bremen.de; s=2019; t=1669677538; bh=GG5BeSf4sb99N9zeiHgrkbsFY6JQ63aJAGzrnrcDjvc=; h=Date:To:References:From:In-Reply-To; b=S7D8+XpFGHbJaxWudHsvyl+wMYwKYGGDh1acrPBHrOsGSIRkjq4auiYT3YKomIZfB cHhcUHKdMFBM8/F4vjHFBwZx3e61KZWfRj/mwHiUZcW8iFr1C/Pdwhn+wzvZ+tUhwo WBYKTrCpGxXhY/EOJU22AldvDfUIrSimj6lJ6sqlUWqdJZ1S3AM1nuaBgm0uo8X/Fi qIQSY58LrzGHvJjI30PFjgP/xaYAL3JRN0gy9VGv1+obUpiBi/XMfCpnfBVLT+U0bI j1rDrbt8K2HAX7sdVgCggda6OftaBbcb36EzHZW2KBDQcTX9oY78iai0Kx9QzqzSKE eTGFXsmldgnmQ==
Message-ID: <cc61da67-e756-de20-aafa-e9485ae9ef57@uni-bremen.de>
Date: Tue, 29 Nov 2022 00:18:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0
Content-Language: en-US
To: radext@ietf.org
References: <FD0507D4-2C1D-478A-97E0-ECEEF1A5613B@deployingradius.com> <EAAC2507-5D29-4453-8881-BC8D9D5314D8@deployingradius.com> <CAOW+2dsKg_H9f3zRUnanCpgGO+G=VPyxzWa9hsrCJCpsnoBsxA@mail.gmail.com> <7CB701B8-BD8F-4ADC-9265-12FC7EBE8FB6@deployingradius.com> <CAOW+2dtDkN3Hvk1vmuyJYGP9KS5WaGDenwQBb7-g12e6SxvEzw@mail.gmail.com> <05f4711f-4f9f-7bb6-e04f-b3c9ebc73202@dfn.de> <9e24bb0f-b12b-8235-3e88-65d4c59f205c@newtoncomputing.co.uk> <e94b8273-6189-efc4-dfa5-3ab3bacbdac6@dfn.de> <7cdb23d1-1d91-71ed-14ee-157315beb278@newtoncomputing.co.uk> <7604703a-075f-7ad6-9c85-24e9a0f845fb@dfn.de> <CAA7Lko9wSP0E8tSQwQ4uhud-f+OBZf6Nw-EGf0XqLPkg8vpN8A@mail.gmail.com> <6D8C428B-D837-4FFE-9739-99C7C20FF64D@deployingradius.com> <CAOW+2dvxo0cpg5+1W-Tyo=s3Ee7EGWFnn+GgW6juEous+6+dug@mail.gmail.com> <9388DD9A-7E92-4C52-8ED8-C36B6282820F@deployingradius.com> <CAOW+2dvc7mKbtzXb_SxBQDarTP_=GrOATvi-dui=giN6jn=ffA@mail.gmail.com> <A4EE4471-92C9-4A7A-AD0B-E2C56EFF8249@deployingradius.com>
From: Jan-Frederik Rieckers <rieckers@uni-bremen.de>
In-Reply-To: <A4EE4471-92C9-4A7A-AD0B-E2C56EFF8249@deployingradius.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000209010907050603060802"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/5xN6_X9qWccRuV_ya4cKRw1bDCY>
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: Mon, 28 Nov 2022 23:19:06 -0000

On 28.11.22 23:19, Alan DeKok wrote:
>    Stefan pointed out that we should probably add a flag saying "require secure transport".
> 
>    i.e. SRADIUS has 8 octets of unused data in the packet header.  It would be good to define one as a flags field: "require secure transport".
> 
>    Then if a proxy receives SRADIUS packets with that flag set, it will refuse to proxy the packets over plain UDP / TCP.  RADIUS/TLS is fine, as TLS will take care of securing the data.

Allowing forwarding with RADIUS/TLS has the downside that the flag would 
be lost and it could result in RADIUS/UDP at some point if it is proxied 
further.
Unless we find a way to include the Flag in "plain" RADIUS, but that 
would also require all proxies to honor the new flag.

Cheers,
Janfred

v2.23.0 | Report a Bug | By Email