IETF Logo Mail Archive

Re: [radext] Review of draft-ietf-radext-radiusdtls

Fabian Mauchle <fabian.mauchle@switch.ch> Tue, 19 March 2024 13:27 UTC

Return-Path: <fabian.mauchle@switch.ch>
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 722CEC151070 for <radext@ietfa.amsl.com>; Tue, 19 Mar 2024 06:27:29 -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_DNSWL_BLOCKED=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, 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=switch.ch
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 Nn1CKSqeaDIO for <radext@ietfa.amsl.com>; Tue, 19 Mar 2024 06:27:25 -0700 (PDT)
Received: from mx4.switch.ch (mx4.switch.ch [85.235.88.35]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4D6C151069 for <radext@ietf.org>; Tue, 19 Mar 2024 06:27:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=switch.ch; l=1621; s=selector1; t=1710854845; h=message-id:date:mime-version:subject:to:references:from: in-reply-to:content-transfer-encoding; bh=X5mykH02tGx7f1zBITXJHYHU8JftLRfMHhL2gLDxiYY=; b=bgC7mh4g1Jkc7LU5F4hZMtk0iCMYNKHrVm+XZ1pGVIX+5nlx+yTYO4j1 sZT37r5Va3417tutf1Bmoes8Tpt3RXjXclXkDMm8AZYfTc6ULZv0xd6Bp EGBrubSXC9BVBPAcPkNk346in1MkztaSKjo7QbkrKC5wf4pd/ycHUg66m rytGmSuXtNYA+59Y5NZjqHaEZosm4bvXsVMST4U23FKjBi8RKi/4ZXH3F cZkjj3jtYb38+v+3ZtZSyiSlWFptRBff/1N1CO1WrXa5a38ymu3wckiAt NqYmcXTaVK9f4tCZZZNFoGh39AXbIGv6Abq4i+ZVxlSHOT20lPN30H/AI A==;
X-IronPort-MAIL-FROM: fabian.mauchle@switch.ch
X-IronPort-AV: E=Sophos;i="6.07,137,1708383600"; d="scan'208";a="7425918"
Received: from unknown (HELO SWH-S02-EXC1.swd.switch.ch) ([172.16.60.11]) by mx4int.switch.ch with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Mar 2024 14:27:22 +0100
Received: from [130.59.17.100] (172.16.60.33) by SWH-S02-EXC1.swd.switch.ch (172.16.60.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.32; Tue, 19 Mar 2024 14:27:22 +0100
Message-ID: <16f5c0c1-6c69-4d85-83c7-fe4fbdae5aa4@switch.ch>
Date: Tue, 19 Mar 2024 14:27:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US, de-CH
To: radext@ietf.org
References: <CA9BEA9C-39EF-4764-A0FE-D122413B37F7@deployingradius.com>
From: Fabian Mauchle <fabian.mauchle@switch.ch>
In-Reply-To: <CA9BEA9C-39EF-4764-A0FE-D122413B37F7@deployingradius.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [172.16.60.33]
X-ClientProxiedBy: SWH-S06-EXC4.swd.switch.ch (172.16.60.18) To SWH-S02-EXC1.swd.switch.ch (172.16.60.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/98tLxXO9-Y4ZkbrCgoYJArlK2EE>
Subject: Re: [radext] Review of draft-ietf-radext-radiusdtls
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: Tue, 19 Mar 2024 13:27:29 -0000


On 11.03.2024 14:57, Alan DeKok wrote:
> 4.2.1.
> 
> 	... Implementations SHOULD indicate their trusted Certification authorities (CAs).
> 
>    Do RADUUS/TLS implementations do this today?
radsecproxy does, on the server side. I.e. it will send the trusted CA 
list in the ServerHello, but the client side currently ignores it (since 
it can't handle multiple client certificates anyway).


> 	... When the configured trust base changes (e.g., removal of a CA from the list of trusted CAs; issuance of a new CRL for a given CA), implementations SHOULD renegotiate the TLS session to reassess the connecting peer's continued authorization

With TLS1.3, renegotiation was dropped.
The server 'simply' has to reassess the peers certificate against the 
updated list of trusted CAs and revocation lists. If the server 
determines the clients certificate is no longer trustworthy, it MUST 
close the connection.

The same also applies to the client, which has to reassess the server 
certificate.

> 	... The DTLS encryption adds an additional overhead to each packet sent. RADIUS/DTLS implementations MUST support sending and receiving RADIUS packets of 4096 bytes in length,
> 
>    What about RFC 7499 (fragmentation)?  It provides for a way to negotiate (or at least signal) support for larger packets.
Yes, fragmentation is a thing (thought many firewalls are riddled with 
bugs regarding fragmentation), but would include the DTLS headers. Still 
the application must support receiving packets of 4096 bytes **plus** 
DTLS header **after** reassembly.


Just my $0.02

-- 
Fabian

v2.23.0 | Report a Bug | By Email